G.O.S.S.I.P 阅读推荐 2023-07-10

今天要介绍的这篇论文 Devils in Your Apps: Vulnerabilities and User Privacy Exposure in Mobile Notification Systems 来自DSN 2023，并且拿到了本届会议的最佳论文奖

Android平台的（第三方）消息推送服务（push notification service）是广告主和APP的最爱，也是用户讨厌又不能舍弃的服务之一。本文作者分析了12家消息推送平台的服务（见下表），并且对超过3万个APP进行了调查，结果非常不令人放心：消息推送SDK在6705个APP中存在偷偷收集用户数据的行为，而有245个APP中存在特定的消息推送SDK对其他消息推送服务的消息进行全局监听的行为；Umeng和Mobpush两家推送服务使用HTTP协议并且还在用古老的MD5算法，导致攻击者可以基于MD5碰撞攻击来实现安全破坏（论文中有具体攻击案例），而Pushbot平台的messsage API设计有问题，可能会允许攻击者篡改推送的消息；还有174个APP，由于它们使用的消息推送SDK（Airship、Taplytics、Kumulos）的相关文档写得不好，误导它们的开发者错误地存储了相关凭据（后面会提到，具体就是KEY这样一个credential）。

问题多多，但是我们先回到消息推送服务的基本实现，来看看问题出在哪里。下图是当前的消息推送服务最常用的架构，作者将其称之为dual-platform structure，因为这里面包含了两个平台：一个host notification platform 和一个transit notification platform，前者负责对接消息的发送方（也就是不同的APP开发者），而后者负责对接用户设备上的APP。

在这种dual-platform structure下，对于开发者来说，要实现整个消息推送，需要如下四步：

1. platform enrollment and key distribution：也就是在消息推送的服务平台注册，得到一个关键的credential——KEY，后面会用到；

2. notification SDK configuration：在APP里面部署消息推送的SDK

3. device tracking：部署的消息推送SDK在APP运行时，生成不同的deviceID，来标记不同的设备；

4. notification pushing through APIs：APP开发者调用消息推送服务商提供的（RESTful）API，通知消息推送服务商去推送消息，消息推送服务器利用它们与消息推送SDK建立的信道来下发这些消息。

和此前诸多在APP（包括小程序）中寻找credential的工作类似，这篇论文首先也关注了KEY的泄露。作者发现，如果你使用了Airship、Taplytics、Kumulos这三家消息推送服务，它们的文档里面对KEY和App ID这两个参数的命名非常愚蠢，都是用KEY作为后缀（例如AAA_KEY, BBB_KEY这种形式），导致开发者容易搞错，一旦不慎把KEY写入到APP中，就会被逆向工程分析出来。作者在174个使用了这三家消息推送SDK的APP中找到了泄露的KEY！

即使KEY没有泄露，还存在另一个攻击方式，这就是篡改APP开发者发送的消息的攻击，由于Umeng和Mobpush这样的服务提供商还支持HTTP方式的RESTful API调用（从APP开发者往消息推送服务商），因此消息推送服务商很担心会有中间人攻击，就要求API调用方在消息的payload之后再加一个消息验证码，用的是MD5{Payloads||KEY}这样的构造方法。虽然但是，你都已经进行验证了，为何还要用MD5啊啊啊（不过反正HTTP都用了，也不在乎再蠢一次）！！！作者测试表明，对于一台Intel i7-8700k、GTX1080 Ti和64G内存的计算机，只需要4天就可以找到一个chosen-prefix MD5 collision（尽管这个配置有点看不起我们的区块链矿场主的钞能力）。读者可以在下面的链接找到具体的攻击示例（275M大小的数据）：

https://www.dropbox.com/sh/gviy9s1xenbl3fk/AABZLVCAqIZH81e_KlRbgmFta?dl=0

在对用户的数据收集方面，大部分消息推送SDK都偷偷收集用户行为或者设备地理位置信息（如下表）

最后，对于任意一个申请了android.permission.BIND_NOTIFICATION_LISTENER_SERVICE权限的APP（包含的消息推送SDK），由于它可以读取到通知栏上所有通知的内容，它完全可以不仅监听自己消息，还可以全局监听所有的消息，从而窥探其他APP（用户相关）的隐私信息。

当然，我们注意到，论文实验里面稍微有点不足在于APP数据集搜集的时间比较老（from December 2019 to February，2020 and from August 2021 to September 2021）。不过我们的读者肯定能够有办法去对新的APP进行验证，看现在这些问题是否还存在，对不对？

---

论文：https://people.cmix.louisiana.edu/yuan/resources/pdf/23_DSN.pdf

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