使用WebRTC开发Android Messenger：第3部分

这是一个由三部分组成的系列文章，内容涉及：利用WebRTC中的BUG和利用Messenger应用程序。本系列文章重点阐述了当应用程序不能应用于WebRTC补丁程序以及通信和安全问题通知中断时可能出问题的方面。

文 / Natalie Silvanovich

原文链接：

https://googleprojectzero.blogspot.com/2020/08/exploiting-android-messengers-part-2.html

Part 3: Which Messengers?

在使用WebRTC开发Android Messenger：第2部分中，我描述了Android上对WebRTC的一个应用。在本节中，我将探索它用于哪些应用程序。

The exploit

在编写这个BUG时，我最初通过修改WebRTC的源代码并重新编译它来修改发送到目标设备的SCTP数据包。这对于攻击封闭源代码的应用程序是不实际的，因此我最终改用使用Frida来挂接攻击设备的二进制文件。

Frida的挂钩功能允许在调用特定的本机函数之前和之后执行代码，这允许我的BUG改变传出的SCTP包以及检查传入的包。从功能上讲，这相当于改变攻击客户机的源代码，但是这些改变不是在编译时在源代码中进行的，而是由Frida在运行时动态地进行的。

该BUG的源代码可以在这里找到：

https://bugs.chromium.org/p/project-zero/issues/detail?id=2034#c6

攻击设备需要挂载7个函数，如下所示。

这些函数可以作为符号连接，或者作为二进制中的偏移量。

目标设备的二进制文件还有三个地址偏移量，这是利用BUG进行攻击所必需的。系统函数和malloc函数之间的偏移量，以及上一篇文章中描述的gadget和malloc函数之间的偏移量就是其中两个。这些偏移量在libc中，libc是一个Android系统库，因此需要根据目标设备的Android版本来确定。还需要从cricket:：SctpTransport vtable的位置到全局偏移表中malloc位置的偏移量。这必须由被攻击应用程序中包含WebRTC的二进制文件确定。

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

Android Applications

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

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

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

l 流：音频和视频内容从一个用户发送到多个用户。通常有一个中间服务器，因此发件人不需要管理可能的数千个对等方，并且会记录内容以便以后查看

l 浏览器：所有主要的浏览器都包含WebRTC以实现JavaScript WebRTC API

l 会议：两个或更多用户通过音频或视频进行实时通信

对于每种类别，利用BUG的影响是不同的。投影是低风险的，因为建立WebRTC连接需要大量用户交互，并且用户首先可以访问连接的两面，因此通过损害另一面几乎无济于事。

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

浏览器几乎可以肯定会受到WebRTC中大多数错误的攻击，因为它们允许对配置方式进行大量控制。要利用浏览器中的此类错误，攻击者需要设置一个主机，该主机的行为与对等连接中的其他对等主机相同，并诱使目标用户访问启动对该主机的调用的网页。在这种情况下，该BUG将与JavaScript中的其他内存损坏BUG具有类似的影响。

会议是WebRTC的最高风险使用方法，但BUG的实际影响取决于应用程序用户之间的联系方式。最高风险的设计是一个应用程序，在这个程序中任何用户都可以根据标识符与任何其他用户联系。有些应用程序要求被调用者在进行呼叫之前必须以特定的方式与调用者进行交互，这使得用户很难联系到目标，并且通常会降低风险。有些应用程序要求用户输入代码或访问链接来启动调用和发起呼叫，这也有类似的效果。还有一大堆很难或不可能呼叫特定用户的应用程序，例如聊天轮盘赌应用程序，以及具有允许用户启动呼叫客户支持功能的功能的应用程序。

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

该列表是在2020年6月18日编制的。请注意，一些应用被删除是因为它们的服务器当天未运行，或者它们很难测试（例如，需要观看多个广告才能进行一次呼叫）。

由于在测试过程中发现了一个严重的其他BUG，该BUG尚未修复或未达到披露的最终期限，因此在此博客文章中将不会标识已测试的一个应用程序。披露截止日期过去后，将更新此博客文章。

Testing the Exploit

以下部分描述了我针对上述应用程序测试BUG利用的尝试。请注意，由于应用程序数量众多，每个应用程序花费的时间有限，因此无法保证会考虑针对WebRTC的每种攻击。尽管我非常确信可以被利用的应用程序确实可以被利用，但是我对被发现无法利用的应用程序没有把握。如果出于保护用户的目的，您需要了解特定应用程序是否易受攻击，请与供应商联系，而不是依赖此帖子。

Signal

我从测试Signal开始，因为它是此列表中唯一的开源应用程序。Signal将WebRTC集成为称为ringrtc的库的一部分。我先构建了ringrtc，然后构建了带有符号的Signal，然后将所需的符号与Frida脚本挂钩在攻击者设备上。我尝试了该BUG利用，并且大约90％的时间都有效！

**视频1：https://youtu.be/YGK_SmVzVkE

此攻击不需要用户与目标设备进行任何交互，因为Signal在接听来电之前启动了WebRTC连接，并且该连接可以接受传入的RTP和SCTP。该BUG在Signal和其他目标上并非100％可靠，因为错误376要求将释放的堆分配替换为该线程执行的具有相同大小的下一个分配，并且有时另一个线程会在该线程中进行相同大小的分配。与此同时。故障会导致崩溃，这通常对用户不可见，因为该过程会重启，但会出现未接来电。

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

Google Duo

Duo也是一个有趣的目标，因为它已预装在许多Android设备上。它可以动态链接Android WebRTC库libjingle_peerconnection_so.so，而无需进行明显的修改。我在IDA中对该库进行了反向工程，以查找所有需要挂接的函数的位置，然后修改Frida脚本以根据它们与导出符号的偏移量来挂接它们。我还修改了cricket ::SctpTransport vtable和全局偏移量表之间的偏移量，因为它与Signal中的有所不同。该BUG也适用于Duo。DuoBUG利用的源代码在这里。

**视频2：https://youtu.be/fBuFFmRg_LA

此BUG不需要任何用户交互，就像Signal一样，Duo在应答呼叫之前启动WebRTC连接。

该BUG利用程序已于2019年12月15日发布的68.0.284888502.DR68_RC09版本进行了测试。此BUG已得到修复。同样，在发布此应用程序时，Duo可以调用任何安装了Google Play服务的Android设备，而不管是否已安装Duo。现在已经不是这样了。用户现在需要设置Duo，并将呼叫者放在他们的联系人中，以便接收来电。

Google Hangouts

Google Hangouts使用WebRTC时，它不使用数据通道，也不交换SDP来建立呼叫，因此没有明显的方法可从对等方启用它们。因此，该BUG无法在Hangouts中使用。

Facebook Messenger

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

librtcR11.so库似乎使用的WebRTC版本大约有六年的历史，因此早于cricket :: SctpTransport类就已经存在。就是说，类似的cricket :: DataMediaChannel类似乎容易受到CVE-2020-6514的攻击。libxplat_third-party_usrsctp_usrsctpAndroid.so库似乎更现代，但是包含Bug 376的易受攻击的代码。也就是说，似乎不可能从Facebook Messenger获取此代码，因为它被设置为使用RTP数据通道而不是SCTP数据通道，并且不接受通过会话描述协议（SDP）更改信道类型的尝试。虽然还不清楚这种设计背后的动机是否是安全性，但这是一个很好的例子，说明了限制攻击者对功能的访问可以如何减少应用程序的BUG。Facebook在启动WebRTC连接之前也会等待一个呼叫被应答，这进一步降低了任何影响它的WebRTCBUG的可利用性。

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

Viber

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

VK

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

VK将SDP报价发送到目标设备以启动呼叫，但是目标用户直到用户接受呼叫后才返回SDP应答，这意味着利用此BUG需要目标在WebRTC连接启动之前应答呼叫。这意味着除非目标手动应答呼叫，否则攻击不会起作用。在下面的视频中，该BUG利用程序/攻击 在用户回答后需要相当长的时间才能运行。这是由于我设计BUG利用程序的方式，而不是由于BUG利用的基本限制。尤其是，利用BUG利用程序会等待usrsctp生成特定的数据包，即使它们可以通过利用BUG脚本更快地生成，也可以使用延迟来避免在可以检查响应时对数据包进行重新排序。经过充分的努力，此攻击可能会在不到五秒钟的时间内运行。还要注意，我更改了BUG利用程序，使其只能处理一个来电，而不是上述BUG利用中的两个来电，因为期望目标快速连续两次接听电话是不现实的。尽管这样做确实使BUG利用代码更加复杂且难以调试，但并不需要对BUG利用的工作方式进行重大更改。

**视频3：https://youtu.be/hoigoOeaeYE

不管怎样，与没有这些功能的应用程序相比，用户必须选择接受来自攻击者的呼叫，然后才能进行呼叫，再加上要求用户应答呼叫并保持在线几秒钟的要求，这一BUG利用对VK的作用大大降低。

针对VK 6.7（5631）进行了测试。像Facebook一样，VK动态下载其WebRTC版本，因此很难指定其版本，但是测试于2020年7月13日进行。VK自此更新了服务器，以使用户无法使用包含数据通道的SDP发起呼叫 ，因此该BUG利用不再有效。请注意，VK不会将WebRTC用于两方通话，而仅用于群组通话，因此我使用群组通话测试了此BUG利用。该BUG的来源可在此处获得。

OK and TamTam

OK和Tamtam是同一供应商（也是Mail.ru）发布的类似消息传递应用程序。他们使用动态下载的WebRTC版本，该版本与VK使用的版本相同。由于库是完全一样的，因此我的BUG利用也可以正常工作，并且我也不必费心测试TamTam，因为它是如此相似。

**视频4：https://youtu.be/5ZoYQ9QhUzU

与VK一样，OK和TamTam在目标通过与电话交互应答呼叫之前不会返回SDP应答，因此这不是对OK和TamTam的完全远程攻击。“确定”还要求用户选择接受其他用户的消息，然后该用户才能呼叫他们。TamTam更为宽松，例如，如果用户验证了电话号码，则拥有其电话号码的任何用户都可以与他们联系。

测试于7月13日星期一在OK的20.7.7版本上进行。仅SDP测试在TamTam 2.14.0版本上进行。从那时起，这些应用程序的服务器已更新，因此无法使用包含数据通道的SDP来发起呼叫，因此该BUG利用不再起作用。

Discord

Discord已彻底记录了其对WebRTC的使用。应用程序将中间服务器用于WebRTC连接，这意味着对等方不可能向另一方发送原始SCTP，而这是利用BUG所必需的。不和谐也需要点击几下才能进入通话。基于这些原因，不和谐不受本文讨论的BUG的影响。

JioChat

JioChat是一个消息传递应用程序，它允许任何用户基于电话号码呼叫任何其他用户。分析版本3.2.7.4.0211，它的WebRTC集成似乎同时包含两个BUG，并且应用程序在被叫方接受传入呼叫之前交换SDP提供和应答，因此我希望该BUG能够在没有用户交互的情况下起作用。但是，当我进行测试时情况并非如此，事实证明JioChat使用了不同的策略来阻止WebRTC连接开始，直到被叫方接受了呼叫。我能够轻松绕过该策略，并获得在JioChat上运行的BUG。

**视频5：https://youtu.be/PC1kIrDeOOA

不幸的是，JioChat的连接延迟策略引入了另一个BUG，该BUG已得到修复，但披露期限尚未到期。因此，此博客文章中不会共享有关如何绕过它的详细信息。没有此功能的BUG利用源可在此处获得。JioChat最近更新了其服务器，因此无法使用包含数据通道的SDP来启动呼叫，这意味着该BUG利用不再适用于JioChat。

Slack and ICQ

Slack和ICQ相似之处在于它们都集成了WebRTC，但是没有使用库的传输功能（请注意，Slack并不直接集成WebRTC进行音频呼叫，而是集成了Amazon Chime，后者集成了WebRTC）。他们俩都只使用WebRTC进行音频处理，但实现了自己的传输层，并且不使用WebRTC的RTP和SCTP实现。因此，他们不容易受到本博客文章中讨论的错误以及许多其他WebRTC错误的影响。

BOTIM

BOTIM具有不寻常的设计，可阻止BUG利用。与调用createOffer和交换SDP不同，每个对等方基于来自对等方的少量信息生成自己的SDP。默认情况下，此应用程序不使用SCTP，并且无法使用SDP打开它。因此，不可能使用此BUG。BOTIM看起来确实有一种模式，它可以与对等方交换SDP，但我不知道如何启用它。

Other Application

该BUG利用程序在另一个应用程序上以完全远程的方式工作，但是对BUG利用程序的设置显示该应用程序中存在明显的其他严重BUG。该BUG的披露期限到期后，将释放该BUG在应用程序上的行为的详细信息。

Discussion

The Risk of WebRTC

在分析的14个应用程序中，WebRTC对四个应用程序启用了完全远程利用，而对另外两个应用程序启用了一键式攻击。这凸显了将WebRTC包含在移动应用程序中的风险。与其他视频会议解决方案相比，WebRTC不会带来实质性的风险，但在应用程序中包含视频会议的决定引入了一个巨大的远程攻击面，否则将不会出现这种情况。WebRTC是移动应用程序（通常是Android）中为数不多的完全远程攻击面之一。在几乎所有将其用于视频会议的应用程序中，它可能都是风险最高的组件。

视频会议对于某些应用程序的功能至关重要，但在另一些应用程序中，它却是很少使用的“额外功能”。低使用率不会使视频会议对用户造成任何风险。对于软件制造商来说，重要的是要考虑视频会议是否是其应用程序中真正必要的部分，并充分了解视频会议给用户带来的风险。

WebRTC Patching

这项研究表明，许多应用程序在向WebRTC应用安全更新方面落后。Bug376在2019年9月被修复，但在分析的14个应用程序中，只有两个修补了它。有几个因素导致了这一点。

首先，usrsctp没有用于识别和传达BUG的正式流程。相反，bug376与其他任何bug一样已得到修复，因此该代码直到2020年3月10日才被引入到WebRTC中。即使在修补之后，这个bug也没有在Chrome稳定通道的安全提示中被注意到，WebRTC告诉开发者在这里寻找安全更新。告诉开发人员寻找安全更新。这意味着，使用旧版本WebRTC和cherry pick修复程序的应用程序的开发人员，或者与WebRTC分开包含usrsctp的应用程序的开发人员不会意识到需要应用此补丁程序。

不过，这还不是全部，因为许多应用程序都将WebRTC作为未修改的库包含在内，并且自2020年3月以来，Chrome安全说明中还包含其他WebRTCBUG。另一个促成因素是，直到2019年，WebRTC都没有向集成商提供任何安全修补指导，实际上，他们的网站不准确地表示，该库中从未报告过BUG，这是因为WebRTC安全BUG通常存储在Chromium错误跟踪器中，并且没有考虑这些BUG对非当时的浏览器集成商。我分析的许多应用程序都具有早于此的WebRTC版本，因此，此不正确指南的遗留之处很可能仍然导致应用程序无法更新WebRTC。尽管WebRTC已经做了很多工作，使集成商可以更轻松地修补WebRTC，例如允许大型集成商申请BUG的预先通知，但集成商仍然有很多人只看到了旧指南。当然，如果有更好的指导，也不能保证集成商会遵循更好的指导，但考虑到长期以来集成商很难知道何时以及如何更新WebRTC，即使他们愿意，这很可能会产生影响。

集成商还有责任使WebRTC保持最新的安全修复程序，其中许多在此方面都失败了。令人惊讶的是，看到这么多版本的WebRTC已经使用了一年多。开发人员应该监视他们集成的每个库中的安全更新，并及时应用它们。

Application Design

应用程序设计会影响WebRTC带来的风险，并且对许多研究的应用程序进行了精心设计。限制WebRTC的安全影响的最简单，最重要的方法是，在被叫方通过与设备进行交互来接受呼叫之前，避免启动WebRTC连接。这会将可能迅速危害任何用户的攻击转化为需要用户交互的攻击，并且不会在每个目标上都成功。这也使得质量较低的BUG实际上不可利用，因为虽然完全远程攻击可以多次尝试而用户不会注意到，但需要用户应答呼叫的攻击需要尝试少量尝试。

延迟启动WebRTC连接会影响性能，并且会妨碍或排除某些功能，例如为被呼叫者提供呼叫预览。该BUG利用的应用程序中，有两个在没有用户交互的情况下启动了连接，还有两个需要用户交互。JioChat和我们尚未确定的应用程序试图使用独特的技巧来延迟连接，直到用户接受呼叫为止，而不会影响性能，但结果引入了BUG。开发人员应该知道，延迟WebRTC连接的最佳方法是避免在用户接受调用之前调用setRemoteDescription。其他方法可能实际上不会延迟连接，并可能导致其他安全问题。

降低WebRTC安全风险的另一种方法是限制攻击者可以呼叫的人，例如，要求被呼叫方在其联系人列表中包含该用户，或者只允许同意在应用程序中互相发送消息的用户之间进行呼叫。就像延迟连接一样，这大大减少了攻击者不费吹灰之力就能到达的目标。

最后，集成商应将攻击者可以使用的WebRTC功能限制为应用程序所需的功能。许多应用程序不容易受到此特定攻击的影响，因为它们已有效禁用了SCTP。其他人没有使用SCTP，但是没有以阻止攻击者使用它的方式禁用它，而我能够启用它。禁用WebRTC中功能的最好方法是在编译时将其删除，某些编解码器支持此功能。也可以通过PeerConnection和PeerConnectionFactory禁用某些功能，这也非常有效。特性也可以通过过滤SDP来禁用，但重要的是要确保过滤器是健壮的并经过彻底测试。

Conclusion

我为Android的WebRTC编写了一个BUG攻击，涉及usrsctp中的两个BUG。这个BUG在Signal、googleduo、JioChat和另一个应用程序上是完全远程的，需要用户在VK、OK和TamTam上进行交互。其他休闲包没有受到影响，因为他们有效地禁用了SCTP。多个应用程序使用的WebRTC版本不包含针对BUG利用的任何BUG的修补程序。一个仍未修补。补丁程序吸收率低的部分原因是WebRTC历史上提供的补丁程序指导不力。集成商可以通过要求用户交互来启动WebRTC连接，限制用户可以轻松调用的用户并禁用未使用的功能来降低WebRTC的风险。他们还应该考虑视频会议是否是其应用程序的重要和必要功能。

Vendor Response

在这篇博客文章中提到的软件供应商在这篇文章公开发布之前被给予了一个审阅的机会，并提供了一些回复，如下：

WebRTC

修复了用于绕过ASLR和移动指令指针的WebRTC错误。WebRTC不再直接将SctpTransport指针传递到usrsctp，而是使用映射到SctpTransport的不透明标识符，而忽略无效值。我们已经识别并修补了每一个受影响的Google产品，并使用WebRTC联系了50个应用程序和集成商，包括本文分析的所有应用程序。对于所有尚未修补该BUG的应用程序和集成器，我们建议更新到WebRTC M85分支，或修补以下两个问题。

Mail.ru

用户安全是所有Mail.ru G集团的产品（包括VK，OK，TamTam等产品）的最高优先事项。根据我们收到的有关BUG的信息，我们立即开始将移动应用程序更新为最新版本的WebRTC的过程。此更新当前正在进行中。我们还在我们的服务器上实现了算法，不再允许在我们的产品中利用此BUG。此操作使我们能够在收到利用BUG演示的信息后3小时内为所有用户修复该问题。

Signal

我们感谢在发现这些BUG和改进WebRTC生态系统安全性方面所做的努力。Signal在被发现之前已经发布了一个防御补丁来保护用户免受此攻击。除了对调用库进行例行更新外，我们还将继续采取主动措施，以减轻未来WebRTC错误的影响。

Slack

我们很高兴看到这份报告得出结论，Slack不受引用的WebRTC BUG和BUG攻击的影响。在了解到这一风险后，我们进行了额外的调查，并确认我们的整个呼叫服务没有受到此处描述的BUG和调查结果的影响。

LiveVideoStackCon 2020 北京

2020年10月31日-11月1日