使用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个函数，如下所示。

usrsctp_conninput // receives incoming SCTP DtlsTransport::SendPacket // sends outgoing SCTP cricket::SctpTransport::SctpTransport // detects when SCTP transport is ready calculate_crc32c // calculates checksum for SCTP packets sctp_hmac // performs HMAC to guess secret key sctp_hmac_m // signs SCTP packet SrtpTransport::ProtectRtp // suppresses RTP to reduce heap noise

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

目标设备的二进制文件还有三个地址偏移量，这是利用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中大多数错误的攻