深入分析TikTok：移动应用安全与网络流量检测技术

引言

最近，一则新闻引起了我的注意：美国政府考虑禁止一款在移动设备上流行的应用程序——TikTok。原因是该应用涉嫌将美国公民的数据发送给中国政府。这引发了我对移动应用数据隐私和监控资本主义策略的兴趣。作为信息安全专业人士，我们都知道应用程序和设备在某种程度上会“监视”用户，但具体程度如何？

本文旨在介绍如何开始进行移动设备和Android应用分析，以回答这个问题。我们将专注于被动分析，例如识别网络流量和API调用，而不操纵数据发送到API服务器。

设备基线分析

我使用了一台已root的Google 6P手机（华为制造的Android手机），运行Android 6.0和Kali NetHunter，主要用于Android应用测试。首先，我想查看在安装TikTok之前，手机尝试连接哪些远程主机。

我配置了一个Raspberry Pi 4设备作为接入点，以便捕获设备流量。使用David Fletcher在2017年发布的指令稍作修改后，无线接入点功能正常。手机连接到网络后，我关闭了手机，然后启动tcpdump监听br0接口，并将数据包捕获写入文件。接下来，我启动手机并让其闲置一小时，同时运行pcap。注意，手机中没有SIM卡，因此只能使用WiFi接入点，且没有其他设备连接到该接入点。

分析pcap有多种方法，Wireshark是最流行的工具之一。我也喜欢使用命令行工具，因为它们更容易生成可进一步处理的数据。分析网络流量时，我喜欢从长尾和短尾分析开始，即查看哪些主机通信最多，哪些最少。这在大规模数据中寻找异常值很有价值。

使用tshark（Wireshark的命令行版本）可以生成这种分析。首先，查看设备执行最多的DNS查询。

在我们的案例中，只有51个唯一主机，但仍有一些有趣的结果。如预期所示，有许多对Google主机的请求。毕竟，这是一个Google设备和操作系统。对2020年的技术人员来说，Google不断跟踪用户位置和行为是显而易见的，但这是另一个话题。我的目标是发现意外的东西。因此，运行相同的tshark命令，但排除“google”和“gstatic”术语。

这将主机列表减少到23个。查看输出，我们可以安全地将ytimg.com（YouTube）和ntp.org从可疑列表中移除。注意，在分析的这个阶段，“可疑”意味着需要进一步调查，而不是认为它是恶意的。恶意需要被证明。

作为一个过去曾使用cloudfront.net传递恶意软件通信的人，48次对d2to8y50b3n6dq.cloudfront.net的查询引起了我的注意，作为分析师，我想调查一下，akamaized.net也是如此。我认为假设所有内容分发网络（CDN）流量都是良性的不是一个好主意。攻击者希望隐藏在噪音中，而CDN是一个很好的地方。

使用whois，app-measurement.com域名似乎与Google相关，因此我们可以将其搁置以进行分析。此外，手机上安装了Instagram，因此我们也可以忽略相关域名。尽管有趣的是，在重启后，设备在没有打开Instagram应用的情况下，会尝试与相关主机通信（可能是API）。

xtrapath3.izatcloud.net域名似乎与Android操作系统和GPS配置相关。因此，我们转向这些看起来奇怪的DNS查询：

• qiqgyezmfcqf.example.org
• oxxlgxxwtp.example.org
• jmnqdgx.example.org
• jmnqdgx
• qiqgyezmfcqf
• oxxlgxxwtp

它们看起来确实与恶意内容相关，对吧？嗯，事实证明，Chrome这样做有很好的理由。一些ISP会响应未解析的DNS请求，显示他们控制的页面。这些页面通常包含广告。通常，广告服务器传播恶意软件，至少用户可能不想看到广告。Chrome会注意到这些请求是否解析相同的A记录，如果是，则阻止任何相应的广告。这是Android手机上的预期行为。

lightstep-collector.api.ua.com和identity.api.ua.com域名基于whois信息似乎与Under Armor相关。这可以解释，因为设备上安装了MapMyRun。

insightapi.p3-group.com似乎更难解释。whois信息受域名隐私保护。访问p3-group.com网站，他们似乎是一家技术咨询公司，但网站是用WordPress构建的，虽然看起来“不错”，但在WordPress站点中搭建虚假内容并不难。并不是说它不合法，只是在这个分析阶段我无法合理解释流量，认为需要进一步调查。我们将其放入可疑箱。

cdn.ampproject.com域名似乎与Google相关，用于加速移动设备上的搜索。这留下了两个反向DNS查询：89.62.225.13和160.62.225.13。一个似乎与德国的电信公司和托管在德国ISP的制药公司相关。我以前见过whois不准确，IP地址被重新分配的情况，但由于不容易解释，我们将其放入可疑箱。

因此，从所有DNS主机中，需要进一步调查的主机列表是：

• D2to8y50b3n6dq.cloudfront.net
• p3ins.akamized.net
• 89.62.225.13.in-addr.arpa
• 160.62.225.13.in-addr.arpa

为了进一步调查，我们转向Wireshark和Burp Suite。在Wireshark中打开pcap，使用过滤器找到我们感兴趣的两个查询。

1

dns.qry.name == 160.62.225.13.in-addr.arpa

似乎两个PTR记录都指向server-13-225-62-89.ewr53.r.cloudfront.net。

没有其他流量到IP地址或server-13-225-62-89.ewr53.r.cloudfront.net和地址。我仍然认为反向查询很奇怪，但没有额外的流量，很难说存在恶意通信。下一步是尝试在设备的文件系统上找到IP地址的引用，看看它们可能与什么关联。但我们应该先处理其余的网络流量。

由于我们在Wireshark中打开了pcap，让我们查看协议层次结构，看看是否有其他协议 besides HTTP and TLS 需要调查。这可以在统计菜单下找到。预计手机的大部分流量将是HTTP和TLS，尽管我以前见过使用其他协议的情况。在这个案例中，HTTP、TLS和ICMP似乎是我们唯一想调查的协议。

除了ping本地网络网关外，所有ICMP流量似乎是ICMP目标端口不可达，因此不太可能是任何类型的ICMP隧道或其他通过ICMP的隐蔽通信。

此时，我们应该开始查看HTTP/S流量。在我看来，最好的方法是设置Burp Suite Professional作为拦截代理。我建议为任何级别的应用测试花钱购买专业版，因为它物超所值。然而，社区版也应该足以分析请求和响应，这主要是我们将使用它的目的。

一旦Burp Suite启动，您需要配置代理以监听移动设备也所在的网络，因为默认是运行Burp的本地主机地址。可能这只是同一个WiFi网络。这可以在代理选项卡下的选项选项卡中找到。

在运行Burp的系统上配置一个网页浏览器（我推荐Firefox用于网页和应用测试），并配置它使用代理。在Firefox中切换代理设置和无代理的一个方便工具是FoxyProxy Standard扩展。

一旦浏览器配置完成，访问http://burp并点击CA Certificate下载CA证书。下载后，在这里，将证书导入Firefox的证书存储。这可以在首选项和隐私与安全下找到。点击查看证书，然后导入并按照提示选择使用此证书识别网站。

让移动设备通过Burp Suite代理可能有点棘手，取决于使用的Android版本。这就是为什么我尽可能使用Android 6.0进行测试。从Android 7.0开始，操作系统不再尊重用户证书存储来识别网站。因此，使用Android 6.0进行测试通常更容易一些。

为Android 6.0安装Burp Suite证书：

• 配置浏览器使用Burp并访问http://burp
• 下载cacert.der，重命名为cacert.crt
• 使用adb push cacert.crt /mnt/sdcard/Download
• 在设备上 – 设置>安全>从存储安装，选择cacert.crt

如果您使用Android 7.0及更高版本，您需要将证书安装为系统级证书。这里的说明应该可以帮助您开始。

从手机上，设置代理，转到已连接WiFi网络的高级选项，然后选择手动代理设置，输入在Burp Suite中配置的IP地址和端口。

一旦我的手机通过Burp通信，我重启它以查看相同的流量是否会出现在Burp中。D2to8y50b3n6dq.cloudfront.net域名似乎用于下载证书存储。下载了两个文件，cdnconfig.zip和truststore.zip。

zip文件的内容与URL所述一致，目的是下载证书存储内容。这似乎解释了D2to8y50b3n6dq.cloudfront.net和p3ins.akamized.net流量。虽然我不完全确定这在设备上下载后如何使用，但它似乎不是恶意的。然而，我没有验证truststore文件中的每个CA。如果这是公司设备，这种努力可能是值得的。

在这一点上，我相当放心，至少在数据包捕获运行的一小时内，没有数据在我不知情的情况下从手机中窃取，或其他类型的泄露或恶意软件。这是否意味着我100%确定某些东西不会每天或每月一次检查命令和控制服务器？完全不是，但我相当确信设备没有被主动入侵。

应用分析

现在轮到TikTok。在从Google Play Store安装之前，我使用ADB列出手机上已安装的包。

1

adb shell ‘pm list packages –f’

我开始在应用评估中这样做，因为有时应用名称不明显。然后我从Play Store安装了TikTok，并尝试用ADB找到它。果然，它没有命名为与TikTok相关的任何东西。

我创建了两个文本列表，并使用Python找到它们之间的差异。应用名称是com.zhiliaoapp.musically。注意，事后我意识到我完全忘记了命令行工具diff。过去几个月我一直在用Python，当你有锤子时，一切看起来都像钉子。

接下来，我使用ADB定位基础APK并从设备中拉取它以进行静态分析，使用以下步骤：

1
2

adb shell pm path com.zhiliaoapp.musically
adb pull /data/app/com.zhiliaoapp.musically-1/base.apk path/to/desired/destination

一旦APK文件被复制出来，我在MobSF中处理它以通过自动静态分析获得应用概述。我喜欢从MobSF开始移动应用评估，因为它自动化了一些我 otherwise 需要手动执行的任务。

应用似乎相对复杂，有16个导出的活动、22个导出的服务、22个导出的接收器和4个提供者。活动是用户交互，类似于Windows OS上的应用程序，用户与应用交互。服务是执行某种操作的背景任务。广播接收器向其他Android应用或Android OS发送和接收消息。内容提供者管理应用数据并帮助与其他应用共享数据。

所有这些本质上都是应用的攻击面，可能以某种意外方式被操纵。在我看来，最好的方法是使用Drozer框架。

事实证明，TikTok是一个相对较大的应用，我在渗透测试中分析的大多数Android应用只有这个攻击面大小的四分之一。详细分析这些必须留到以后的博客文章，因为数量众多，且它们可能无法帮助我们回答原始问题——如果有的话，哪些个人数据从应用中发送？

MobSF可以提供一些有趣的信息，因为它从Android清单中提取权限信息。很难确定应用是否过度许可，以及是否有不必要的权限被授予，但与导出意图的大小一样，有许多声明的权限。有67个声明的权限。与我分析的其他应用相比，这是一个相对较大的数量。