G.O.S.S.I.P 阅读推荐 2022-11-16 ThirdEye

In many Asian legends, the third eye is meant to provide “perception beyond ordinary sight” – see https://en.wikipedia.org/wiki/Third_eye

不光是中国的二郎神有三只眼睛，在世界各国特别是亚洲国家的神话中，第三只眼睛都被视为是超自然的洞察力的体现（不是在吐槽你，Dr. Strange），那么把这种洞察力用在我们的安全研究领域怎么样？今天为大家介绍的CCS 2022研究论文Hidden in Plain Sight: Exploring Encrypted Channels in Android apps中，作者就设计了一个名为ThirdEye的分析系统，它的功能是什么呢？

本文作者可能没有读过我们在2016年发表的研究论文An Empirical Study of Insecure Communication in Android Apps，但是他们也注意到了相同的问题，那就是在Android平台上，大量的APP在标准的加密通信协议之外，还会“自作主张”地使用一些非标准加密通信方式，尽管密码学家们一直呼吁大家别这样做，奈何许多开发者还是喜欢非主流。本文的核心研究目标就是去大规模调研此类（可能不安全的）加密通信。

实事求是的说，在读完论文之后，我们会发现ThirdEye的设计部分只能说是四平八稳。如上图所示，整个ThirdEye可分为四个部分，其中的Device manager负责安装APP并对其进行一些非常基本的分析；UI interactor是里面为数不多的比较新颖的部分，利用了一系列用户界面交互技术来驱动APP运行，其中最有特色的是调用了翻译功能来测试非英语界面的APP；至于Operations logger和Data flow inspector，大家如果熟悉Android APP分析，应该不会觉得很陌生，基本上还是那几样最基础的工作——对特定函数和API接口的接管，以及对网络、文件等系统活动的监视分析

读者们完全可以把本文当做一篇measurement study来读，而不再对ThirdEye的技术细节进行过多的关注。让我们来看看作者的一些有趣的发现。首先关注一下调查的对象：作者对15522个免费的Android APP进行了大规模的分析，这些APP基本上覆盖了最流行的应用。而ThirdEye最后成功分析了其中的12598个APP。特别注意的是ThirdEye是运行在真实设备上的，这一点很赞——作者用的是Pixel 4 和 Pixel 6（安装的Android 12系统）完成的分析（特别是UI测试）。

针对所有这些被测的APP，作者进行了详细的统计。作者发现有6075个APP执行了加密解密操作，而其中47.52%（2887/6075）涉及到网络通信和文件读写。在下表中，作者详细统计了各种不同类型的敏感信息是如何被（不同类型的通信协议）发送的。

更进一步，作者对加密通信的内容（通过hook特定的API截获对应的明文）中不同类型的数据内容进行了分析，然后得出了下表的一些统计信息：

除了关注客户端的非标准加密行为，作者也特别留意了这些行为背后对应的服务器地址，看看下表你是不是会心一笑~ 其中排行第一的appsflyer.com背后对应了appsflyer SDK，这个SDK在1386个APP中用到，还对自己进行了加壳防护。

作者发现，有262个APP会使用那些完全可被现在的密码分析技术直接威胁的弱算法，包括DES、RSA-384 和 RSA-512。

而具体到究竟哪些数据被加密处理（并发送），其中主要包括GPS和Wi-Fi路由器的SSID信息。作者专门点名了Baidu Search（com.baidu.searchbox），这个APP不仅关心自己使用的SSID，还扫描附近所有可用的SSID，然后用非标准的加密通信上传给服务器……

除了直接的网络通信，作者还发现很多APP先把数据加密（大部分还用的固定密钥）存放在Android的共享数据存储（也就是/sdcard），然后其他APP可以利用这个“隐秘信道”来读取信息。

本文的第七章给出了很多吸引眼球的结论——直接曝光了一些知名APP的行为，当然，很多这些行为我们在国内已经是司空见惯了。例如作者发现Dailyhunt这个印度知名的新闻类APP会把用户数据先用AES加密，然后再放在HTTPS里面传输（AES密钥则用硬编码的RSA-1024公钥加密了以后一起传输），不得不说，这种做法在国内APP里面真的是很常见。而另一个知名的文件共享APP——SHAREit则更直接，用HTTP来传输AES加密的数据以及用硬编码的RSA-1024公钥加密以后的AES密钥。比前面的APP还要坑的是UC Browser（com.UCMobile.intl），它把许多敏感信息（例如device ID, WiFi
MAC, advertisement ID, GPS location）直接用固定的对称密钥加密然后用HTTP就这样发送了。。。

读完本文，最大的感受就是尽管ThirdEye的设计四平八稳，但是作者实验做得很扎实啊！我们是不是就应该这样，少点花里胡哨的包装，多点细致入微的观察呢？

---

论文PDF：http://users.encs.concordia.ca/~mmannan/publications/ThirdEye-CCS2022.pdf
开源代码：https://github.com/SajjadPourali/ThirdEye

原文始发于微信公众号（安全研究GoSSIP）：G.O.S.S.I.P 阅读推荐 2022-11-16 ThirdEye