电商APP后门风波：你的隐私安全吗？

一、小白剧场小白：东哥，现在网购真是太方便、划算了。大东：没错，互联网和数字货币让我们能够足不出户地了解世界，也能够足不出户地买到我们想要的东西。小白：我现在已经离不开网络了，用的东西基本都是从网上的购物APP买的。大东：小白，说起电商APP来，你最近有没有用过电商APP啊？小白：没有啊，但是我手机里有这个软件，有一段时间没用了。东哥，为什么突然这么问？大东：你不知道吗？最近有一个安全研究团队发表了一篇报告，说这个APP疑似能提权控制手机，从而绕过隐私合规监管，收集用户的各种信息。小白：什么？真的假的？哪些信息都被收集了？大东：报告里说，其收集的用户隐私信息包括但不限于社交媒体账户资料、位置信息、WiFi信息、基站信息甚至是路由器信息等等。小白：天哪，那不是相当于把我的所有网络活动都暴露给他们了吗？他们要这些信息干什么？大东：可能是为了隐蔽安装，提升装机量，并使用户无法卸载程序。也可能是为了攻击竞争对手、窃取用户隐私数据，反正肯定不是什么好事。小白：这可太恐怖了，我现在就去卸载程序。大东：这个事情警示我们作为普通用户，在享受网络便利的同时也要提高自己的安全意识和防范能力。毕竟，在互联网上没有绝对的隐私和安全。小白：那东哥，这个APP是怎样实现提权的呢？
二、手机漏洞利用链大东：这个要追溯到2022 年，Google 的 Project Zero 发布了一个在野漏洞利用的分析，警告攻击者已经瞄准各手机厂商的 OEM 代码部分，挖掘出其中的脆弱点和漏洞，组合出了一套完整的提权攻击 Exploit。小白：一套提权攻击？难道利用的漏洞不止1个吗？大东：没错，Project Zero 分析的漏洞利用链包含四个部分，完全由公司代码中的漏洞组成。小白：那第一步是利用的什么漏洞呢？能达成什么样的效果呀？大东：第一步攻击者利用了漏洞 (CVE-2021-25337)，这是一个 system_server 中导出的 semclipboardprovider 所存在的任意文件读写，允许攻击者以 untrusted_app 身份读写 users_system_data_file，也就是一般 system_app 的私有数据文件。小白：只是读取数据的话应该无法提权吧，后续攻击者是怎么做的呢？大东：第二步，攻击者参考了 TTS 漏洞研究成果，利用 TTS 中从自身配置文件加载任意动态链接库的能力，将第一个漏洞转化为了一个 system_app 提权漏洞。小白：这攻击者可够高端的，参考该漏洞研究成果来攻击。大东：没错，而在攻击者获取了 system_app 权限的代码执行能力后，攻击者执行最后两步，向内核进发。小白：拿下内核以后就完成真正的提权了吧，攻击者是怎么做的呢？大东：首先，攻击者将手机设备中未更新的 Mali GPU 驱动内核信息泄露漏洞 (CVE-2021-25369) ，和手机自己的 kmsg 泄露“特性”组合利用，最终获得内存基址和 addr_limit 地址。小白：简直防不胜防啊，谁能想到这一步攻击者居然还利用到了手机系统的特性呢。大东：黑客就是会通过你想不到的方式从你想不到的地方攻击系统。小白：最后，攻击者是利用哪个漏洞与内核信息泄露漏洞结合提权的呢？大东：攻击者最后使用 DECON driver 中的 UAF 漏洞 (CVE-2021-25370)， 结合堆风水，最终，利用 signalfd 系统调用修改 addr_limit，转化为内核任意地址读写，完成提权。至此，一套完整的提权攻击 Exploit 全部完成。小白：这可太精妙了，一环扣一环啊，东哥，这些漏洞现在已经修复了吗？我有点慌。大东：截至目前，上述攻击所涉及漏洞已全部修复。

提权攻击涉及的三星漏洞信息（图片来自网络）**

小白：东哥，我不太明白，这个跟我们前面说的APP提权非法获取隐私数据有什么关系？大东：其实OEM 漏洞攻击是一个很典型的案例，从这个案例可以看出，与 AOSP、上游 Kernel 的漏洞挖掘难度相比，手机厂商 OEM 代码部分的漏洞挖掘难度要低很多，且利用通常也相当稳定。所以我们经常可以看到，各种间谍软件的作者会频繁利用手机 OEM 代码漏洞作恶。小白：东哥，打断一下，这个AOSP是什么意思？大东：AOSP是“Android Open-Source Project”的缩写，中文名称为Android 开放源代码项目，它相当于源代码。小白：明白了。那我们继续前面的话题吧，难道这次APP提权攻击也是利用的OEM代码漏洞吗？
三、电商APP如何提权窃取用户信息？ 大东：该厂商持续挖掘新的安卓 OEM 相关漏洞，在其公开发布的 App 中实现对目前市场主流手机系统的漏洞攻击。小白：太黑暗了，身为服务公众的厂商，居然做这种攻击行为。这个厂商是利用什么方法进行提权的呢？大东：该互联网厂使用的第一个黑客技术手段，是利用一个近年来看似默默无闻、但实际攻击效果非常好的 Bundle 风水 - Android Parcel 序列化与反序列化不匹配系列漏洞，实现 0day/Nday 攻击，从而绕过系统校验，获取系统级 StartAnyWhere 能力。小白：东哥，这个Parcel是什么？大东：它是Android Framework 中一个核心的对象传递机制，那些希望被通过 Parcel 传递的对象需要定义 readFromParcel 和 writeToParcel 接口函数，并实现 Parcelable 接口。小白：这个序列化与反序列化不匹配系列漏洞出现是因为接口函数的实现有缺陷吗？大东：没错，理论上来讲，匹配序列化和反序列化函数应当是自反等效的，但系统 ROM 的开发者在编程过程中可能会出现不匹配的情况，例如写入的时候使用了 writeLong，读取的时候却使用了 readint。小白：这个应该不算是什么大问题吧！大东：这类问题在运行过程中一般不会引起注意，也不会导致崩溃或错误，但在攻击者精心布局下，却可最终利用 Settings 和 system_server 进程，将这个微小的错误转化为 StartAnyWhere 提权。小白：千里之堤也可溃于蚁穴，看来不能忽略这些小错误啊。大东：Android 近年来累计已修复上百个这类漏洞，并在 Android 13 中对 Parcel 机制做了改革，杜绝了大部分此类攻击面。但对绝大部分未升级到 Android 13 的设备和用户来说，他们仍处于危险之中。小白：还好我的设备升级到了Android 13。东哥，利用反序列化漏洞提权后攻击者接下来可以做什么？大东：下图介绍了其漏洞利用链中的核心环节，在完成提权后，该 App 事实上已经完成了反客为主，通过 App 控制了用户的整个手机系统。
漏洞利用链中的核心环节（图片来自网络）

小白：能控制手机系统，那就代表可以收集、窃取用户的隐私信息了。大东：不仅如此，该 App还使用了其他黑客技术手段。小白：啊？还使用了什么手段，不是已经可以窃取用户信息了吗？大东：该 App使用的另一个手段是利用手机厂商 OEM 代码中导出的 root-path FileContentProvider， 进行 System App 和敏感系统应用文件读写；进而突破沙箱机制、绕开权限系统改写系统关键配置文件为自身保活，修改用户桌面（Launcher）配置隐藏自身或欺骗用户实现防卸载。小白：玩得可真花啊，居然还能这么干，真是开眼界了。大东：还有更厉害的呢。它还可以通过覆盖动态代码文件的方式劫持其他应用注入后门执行代码，进行更加隐蔽的长期驻留；甚至还实现了和间谍软件一样的遥控机制，通过远端“云控开关”控制非法行为的启动与暂停，来躲避检测。小白：遥控非法行为的启动与暂停，这想得可真周到啊。大东：总结一下就是该互联网厂商通过上述一系列隐蔽的黑客技术手段，在其合法 App 的背后，达到了：隐蔽安装，提升装机量；伪造提升 DAU/MAU；用户无法卸载；攻击竞争对手 App；窃取用户隐私数据；逃避隐私合规监管等各种涉嫌违规违法目的。小白：难道这种行为没人发现并投诉吗？大东：目前，已有大量终端用户在多个社交平台上投诉反馈：该 App 存在莫名安装、泄漏隐私、无法卸载等问题。小白：唉，这种非法行为直接让本该守护安全的白帽，被滥用成侵害用户的黑帽！太可恶了。大东：在手机设备复杂的供应链中，发现漏洞、修复漏洞、防范漏洞本就不易。若还有不法者利用漏洞牟利，将白帽变成黑帽，更会让用户和行业受伤。小白：这个事件是不是也可以算成一种另类的供应链攻击。大东：也可以这么理解，这次的事件可以当成供应链程序源头污染，不过他跟2022年发生的NODE-IPC供应链投毒事件不同的是，他没有在程序中故意引入漏洞，而是在程序中植入漏洞利用代码。小白：我记得2021年有类似的供应链污染事件，详见文章《供应链感染？这款名为“老裁缝”的激活工具到底做了什么？》大东：小白，记得很清楚嘛！小白：那肯定呀，东哥教的不能忘啊，针对这类事件，应该怎样针对性防御呢？大东：首先肯定是手机厂商需要更重视自研代码的安全，削减不必要的、可能被攻击者利用的攻击面；然后监管机构需要针对此类行为进行治理，根据现有法律法规严格执法、监管，严肃问责，以构建一个更安全的数字环境。小白：嗯嗯，个别公司的错误不该连带整个行业背负骂名，更不该由我们用户承担后果。
四、小白内心说 现在有公司打破底线，将白帽黑客作为武器，利用他们掌握的黑客技术寻找并利用漏洞，为自身牟取非法利益。应当回归守护安全的初心，让技术发挥应有的正向作用。漏洞研究如同钉钉子，以破为手段，但以固为目的。技术的价值转化都应该在法律和道德的约束下展开。