利用WebRTC开发Android Messenger

这是关于利用WebRTC中的漏洞利用Messenger应用程序的三部分系列。博客文章中讨论的CVE-2020-6514已使用这些CLS在7月14日进行了修复。本系列重点介绍了当应用程序未安装WebRTC补丁程序以及安全问题的通信和通知中断时可能出现的问题。在第2部分中，我描述了Android上的WebRTC漏洞攻击。在本节中，我将探讨它在哪些应用程序上工作。

在编写利用漏洞时，我最初通过更改WebRTC的源代码并重新编译它来更改发送到目标设备的SCTP数据包。这对于攻击封闭源代码的应用程序是不现实的，所以我最终转而使用Frida来挂接攻击设备的二进制代码。Frida的挂钩功能允许在调用特定本机函数之前和之后执行代码，这允许我利用漏洞更改传出的SCTP数据包以及检查传入的数据包。从功能上讲，它等同于更改攻击客户端的源代码，但不是在编译时对源代码进行更改，而是由Frida在运行时动态进行更改。此处提供了利用漏洞的来源。

利用漏洞攻击还需要目标设备二进制的三个地址偏移量。系统函数和malloc函数之间的偏移量，以及上一次POST中描述的小工具和malloc函数之间的偏移量是其中的两个。这些偏移量位于libc中，这是一个Android系统库，因此需要根据目标设备的Android版本来确定它们。还需要从Cricket：：SctpTransport vtable的位置到全局偏移表中malloc的位置的偏移量。这必须从被攻击的应用程序中包含WebRTC的二进制文件中确定。

请注意，提供的利用漏洞脚本有一个严重的限制：每次读取内存时，只有在设置了指针的第31位时才会起作用。第2部分解释了出现这种情况的原因。利用脚本提供了一个示例，说明如何修复此问题并使用FWD_TSN块读取任何指针，但这并不是针对每个读取实现的。出于测试目的，我重置了设备，直到WebRTC库映射到合适的位置。

通过在Google Play上的APK文件中搜索usrsctp中的特定字符串，确定了集成WebRTC的流行Android应用程序列表。大约有200个用户超过500万的应用程序似乎在使用WebRTC。我对这些应用程序进行了评估，以确定它们是否可能受到利用漏洞中的漏洞的影响，以及会有什么影响。

事实证明，应用程序使用WebRTC的方式多种多样，但可以分为四大类。

投影：在用户同意增强可用性的情况下，将移动应用程序的屏幕和控件投影到桌面浏览器中。

流式传输：音频和视频内容从一个用户发送到多个用户。通常有一个中间服务器，因此发送者不需要管理可能数以千计的对等点，内容会被记录下来供以后查看

对于这些类别中的每一个类别，利用漏洞中使用的漏洞的影响是不同的。投影的风险很低，因为建立WebRTC连接需要进行大量的用户交互，而且用户首先可以访问连接的两端，因此损害另一端几乎没有什么好处。

流媒体的风险也相当低。虽然当流的观看者数量较少时，某些应用程序可能会使用点对点连接，但它们通常使用中间服务器来终止来自发送对等点的WebRTC连接，并开始与接收对等点的新连接。这意味着攻击者通常不能将格式错误的数据包直接发送到对等点。即使采用对等流传输的设置，目标也需要用户交互才能查看流，并且通常无法限制谁可以访问流。因此，使用WebRTC的流应用程序可能对有针对性的攻击没有用处。当然，这些漏洞也有可能会影响流媒体服务使用的服务器，但本研究没有对此进行调查。

浏览器几乎肯定容易受到WebRTC中的大多数错误的攻击，因为它们允许对如何配置进行大量控制。要利用浏览器中的此类缺陷，攻击者需要设置一个与对等连接中的其他对等设备行为相似的主机，并说服目标访问启动对该主机的呼叫的网页。在这种情况下，该漏洞将对JavaScript中的其他内存损坏漏洞产生类似的影响。

会议是WebRTC的最高风险使用，但漏洞的实际影响在很大程度上取决于应用程序用户之间的联系方式。风险最高的设计是这样一个应用程序，在该应用程序中，任何用户都可以根据标识符联系任何其他用户。一些应用程序要求被呼叫者在进行呼叫之前已经以特定方式与呼叫者进行了交互，这使得用户更难联系目标，并且通常降低了风险。有些应用程序要求用户输入代码或访问链接才能开始通话，这也有类似的效果。还有一大组应用程序很难或不可能呼叫特定用户，例如聊天轮盘赌应用程序，以及具有允许用户开始呼叫客户支持的特征的应用程序。

在这项研究中，我将重点放在允许用户联系特定其他用户的会议应用程序上。这将我的200个应用程序列表减少到14个应用程序，如下所示。

这份榜单编制于2020年6月18日。请注意，有几个应用程序被删除，因为它们的服务器在那一天没有运行，或者它们很难测试(例如，需要观看多个广告才能拨打一个电话)。

这篇博客文章不会指出一个测试过的应用程序，因为在测试过程中发现了一个严重的附加漏洞，该漏洞尚未修复或已达到披露截止日期。此博客帖子将在披露截止日期过后更新。

以下部分介绍我针对上述应用程序测试利用漏洞的尝试。请注意，由于应用程序的数量，每个应用程序花费的时间有限，因此不能保证考虑对WebRTC的每一次攻击。虽然我非常相信被发现可被利用的应用程序确实是可被利用的，但我对被发现不可利用的应用程序就不那么有信心了。如果您出于保护用户的目的需要了解特定应用程序是否易受攻击，请联系供应商，而不是依赖此帖子。

我从测试Signal开始，因为它是这个列表中唯一的开源应用程序。Signal将WebRTC集成为名为ringrtc的库的一部分。我构建了ringrtc，然后使用符号发出信号，然后将所需的符号与攻击者设备上的Frida脚本挂钩。我尝试了这个漏洞，大约90%的时间是有效的！

此攻击不需要用户与目标设备进行任何交互，因为Signal在应答传入呼叫之前启动WebRTC连接，并且此连接可以接受传入的RTP和SCTP。由于错误376要求将释放的堆分配替换为线程执行的相同大小的下一次分配，并且偶尔另一个线程会同时执行相同大小的分配，因此在信号和其他目标上，利用漏洞攻击不是100%可靠的。失败会导致用户通常看不到的崩溃，因为进程会重新启动，但会出现未接呼叫。

此漏洞是在2020年1月13日发布的信号4.53.6上执行的，因为在我完成漏洞攻击时，Bug 376已经在信号中打了补丁。CVE-2020-6514在更高版本中也已修复，并且ASCONF在usrsctp中也已禁用，因此不再可以访问导致错误376的代码。Signal最近还实现了一项功能，当呼叫者不在被呼叫者的联系人中时，需要用户交互才能启动WebRTC连接。Signal也已停止在测试版中使用SCTP，并计划在测试后将此更改添加到发布客户端。此处提供了此利用漏洞的来源。

Duo也是一个有趣的目标，因为它预装在如此多的Android设备上。它动态链接Android WebRTC库libjingle_peerconnection_so.so，没有明显的修改。我在RDA中对这个库进行了逆向工程，以找到需要挂接的所有函数的位置，然后修改Frida脚本以基于它们与导出符号的偏移量来挂接它们。我还修改了Cricket：：SctpTransport vtable和全局偏移表之间的偏移量，因为它不同于Signal中的偏移量。这一漏洞也对Duo起到了作用。二人组攻击的源代码可以在这里获得。

此漏洞不需要任何用户交互，因为与SIGNAL一样，DUO在应答呼叫之前启动WebRTC连接。

该漏洞在2019年12月15日发布的版本68.0.284888502.DR68_RC09上进行了测试。自那以后，该漏洞已被修复。此外，在这款应用程序发布时，Duo可以呼叫任何安装了Google Play服务的Android设备，无论是否安装了Duo。现在情况不再是这样了。用户现在需要设置DUO，并将呼叫者放在他们的联系人中，才能接收来电。

虽然Google Hangout使用WebRTC，但它不使用数据通道，也不交换SDP来建立呼叫，因此没有明显的方法从对等设备启用它们。因此，该漏洞在Hangout上不起作用。

Facebook Messenger是另一个有趣的目标。它有大量的用户，根据它的文档，任何用户都可以根据自己的手机号码呼叫任何其他用户。Facebook Messenger将WebRTC集成到一个名为LibrtcR11.so的库中，该库动态链接到另一个库libxplat_third-party_usrsctp_usrsctpAndroid.so中的usrsctp。Facebook Messenger动态下载这些库，而不是将它们包含在APK中，因此很难识别我检查的版本，但它是在2020年6月22日下载的。

LibrtcR11.so库似乎使用了大约6年前的WebRTC版本，因此在Cricket：：SctpTransport类出现之前。也就是说，类似的类Cricket：：DataMediaChannel似乎容易受到CVE-2020-6514的攻击。Libxplat_third-party_usrsctp_usrsctpAndroid.so库看起来更现代，但包含Bug376的易受攻击代码。也就是说，似乎不可能从Facebook Messenger访问此代码，因为它被设置为使用RTP数据通道而不是SCTP数据通道，并且不接受通过会话描述协议(SDP)更改通道类型的尝试。虽然尚不清楚此设计背后的动机是否是安全，但这是一个很好的例子，说明限制攻击者访问功能可以如何降低应用程序的漏洞。Facebook还会等到呼叫应答后才启动WebRTC连接，这进一步降低了影响它的任何WebRTC漏洞的可利用性。

有趣的是，Facebook Messenger在一个名为LibrtcR20.so的库中还包含了一个更新版本的WebRTC，但应用程序似乎并没有使用它。通过在Android上设置系统属性，可以让Facebook Messenger使用备用库，但我找不到攻击者可以使设备切换库的方法。

与Facebook Messenger类似，而Viber版本13.3.0.5似乎包含易受攻击的代码，但该应用程序在创建PeerConnectionFactory时会禁用SCTP。这意味着攻击者无法访问易受攻击的代码。

VK是Mail.ru发布的一款社交网络应用程序，在允许每个用户呼叫他们之前，用户必须明确允许特定的其他用户联系他们。我在VK上测试了我的漏洞，它需要一些修改才能工作。首先，VK不使用数据通道作为其WebRTC连接的一部分，所以我必须启用它。为此，我用Java编写了一个挂接nativeCreateOffer的Frida脚本，并在创建报价之前调用了createDataChannel。这足以在两台设备上启用SCTP，因为目标设备根据攻击者提供的SDP确定是否启用SCTP。WebRTC的版本也比我为其编写漏洞的版本旧。WebRTC不包含任何版本信息，因此很难确定，但根据日志条目，该库似乎至少有一年的历史。这意味着利用漏洞使用的“假对象”中的一些偏移量是不同的。通过几处更改，我就可以利用VK了。

VK向目标设备发送SDP提议以启动呼叫，但目标在用户接受呼叫之前不会返回SDP应答，这意味着此利用需要目标在WebRTC连接开始之前应答呼叫。这意味着除非目标手动应答呼叫，否则攻击将不起作用。在下面的视频中，在用户应答之后，漏洞攻击需要相当长的时间才能运行。这是由于我是如何设计利用漏洞的，而不是由于它使用的漏洞的基本限制。具体地说，即使漏洞利用脚本可以更快地生成特定数据包，利用漏洞攻击也会等待usrsctp生成特定数据包，并且还会在可以检查响应时使用延迟来避免数据包重新排序。只要付出足够的努力，此攻击很可能在不到5秒的时间内运行。还请注意，我更改了利用漏洞攻击来处理单个传入呼叫，而不是上面利用漏洞攻击中的两个传入呼叫，因为期望目标快速连续应答两次呼叫是不现实的。这不需要对利用漏洞的工作方式进行重大更改，尽管这确实会使利用漏洞的代码更加复杂和难以调试。

无论如何，要求用户在呼叫之前必须选择接受攻击者的呼叫，以及要求用户接听呼叫并保持在线几秒钟，与没有这些功能的应用程序相比，这种利用漏洞攻击对VK的用处要小得多。

针对VK 6.7(5631)执行测试。与Facebook一样，VK也动态下载其WebRTC版本，因此很难指定其版本，但测试是在2020年7月13日进行的。VK已经更新了他们的服务器，这样用户就不能使用包含数据通道的SDP发起呼叫，因此利用漏洞不再起作用。请注意，VK不使用WebRTC进行两方呼叫，只使用组呼叫，因此我使用组呼叫测试了此漏洞。此处提供了利用漏洞的来源。

OK和Tamtam是由同一家供应商发布的类似的消息传递应用程序，也是Mail.ru。他们使用动态下载的WebRTC版本，该版本与VK使用的版本相同。因为库是完全相同的，所以我的漏洞也在OK上起作用了，而且我也没有费心去测试Tamtam，因为它太相似了。

与VK一样，在目标通过与电话交互应答呼叫之前，OK和TAMTAM不会返回SDP应答，因此这不是对OK和TAMTAM的完全远程利用。OK还要求用户选择接受来自另一个用户的消息，然后该用户才能呼叫他们。TAMTAM稍微宽松一些，例如，如果用户验证了电话号码，任何有他们电话号码的用户都可以联系他们。

测试于7月13日(星期一)在OK版本20.7.7上执行。仅SDP测试在TAMTAM版本2.14.0上执行。从那时起，这些应用程序的服务器已经更新，因此包含数据通道的SDP不能用于发起呼叫，因此利用漏洞不再起作用。

Discorde详细记录了它对WebRTC的使用。该应用程序使用中间服务器进行WebRTC连接，这意味着对等方不可能向另一个对等方发送原始SCTP，而这是利用漏洞工作所必需的。不和谐还需要几次点击才能进入呼叫。由于这些原因，不和谐不会受到本文讨论的漏洞的影响。

JioChat是一款即时通讯应用程序，允许任何用户根据电话号码呼叫任何其他用户。分析版本3.2.7.4.0211，它的WebRTC集成似乎包含这两个漏洞，并且应用程序在被呼叫者接受传入呼叫之前交换SDP提供和应答，因此我预计该攻击将在没有用户交互的情况下工作。然而，当我测试它时情况并非如此，结果是JioChat使用了一种不同的策略来阻止WebRTC连接启动，直到被调用者接受了调用。我可以很容易地绕过这个策略，并让利用漏洞在JioChat上工作。

不幸的是，JioChat的连接延迟策略引入了另一个漏洞，该漏洞已经修复，但披露期限尚未过期。因此，有关如何绕过它的详细信息将不会在此博客文章中分享。此处提供了没有此功能的利用漏洞的来源。JioChat最近更新了他们的服务器，因此包含数据通道的SDP不能用于发起呼叫，这意味着利用该漏洞在JioChat上不再起作用。

Sack和ICQ的相似之处在于，它们都集成了WebRTC，但不使用库的传输功能(请注意，Slake没有直接为音频呼叫集成WebRTC，它集成了集成WebRTC的Amazon Chime)。它们都只将WebRTC用于音频处理，但实现了自己的传输层，并且不使用WebRTC的RTP和SCTP实现。因此，它们不容易受到本文讨论的bug和许多其他WebRTC bug的影响。

BOTIM有一种不同寻常的设计，它阻止了利用漏洞的工作。每个对等方不是调用createOffer并交换SDP，而是根据来自对等方的少量信息生成自己的SDP。默认情况下，此应用程序不使用SCTP，并且无法使用SDP将其打开。因此，使用此漏洞是不可能的。BOTIM似乎确实有一种模式，可以与对等机交换SDP，但我想不出如何启用它。

该利用漏洞在另一个应用程序上以完全远程的方式工作，但设置该利用漏洞会暴露该应用程序中明显的附加严重漏洞。漏洞的泄露期过后，将发布应用程序上利用漏洞行为的详细信息。

在分析的14个应用程序中，WebRTC在4个应用程序上启用了完全远程攻击，在另外两个应用程序上实现了一次单击攻击。这突出了在移动应用程序中包含WebRTC的风险。WebRTC不会带来与其他视频会议解决方案有本质不同的风险，但是在应用程序中包含视频会议的决定会带来一个很大的远程攻击面，否则就不会出现这种情况。WebRTC是为数不多的移动应用程序的完全远程攻击面之一，通常也是Android的完全远程攻击面之一。在几乎所有将其用于视频会议的应用程序中，它可能是风险最高的组件。

视频会议对于某些应用程序的功能至关重要，但在其他应用程序中，它是一个很少使用的“额外”功能。低使用率并不会降低视频会议给用户带来的风险。它对软件很重要。

.