G.O.S.S.I.P 阅读推荐 2023-11-10 基于Inotify的钓鱼攻击

我们今天介绍的这篇论文来自2023年的Euro S&P会议，是一篇讨论Android平台上实施钓鱼攻击的论文，其实攻击本身危害并不大，关键是这里怎么利用了Inotify机制来监视其他APP的活动，作者对相关的技术细节的讨论非常系统和全面，写作上值得学习。

Android系统最初并不限制APP去获取当前系统中活跃的应用列表，这导致恶意软件能够轻易推测出其他APP的运行情况，于是随着后续的升级，Android系统逐渐收紧这类权限。后续有一些攻击通过访问procfs来获取信息，从Android 7.0开始也被严格管控了。本文提出的利用Inotify的攻击，实质上是通过监控文件系统的读写变化，发现特定的APP启动的信号，然后在这个精确的时间窗口中，通过一个安装在同设备上的恶意APP插入钓鱼的界面（或者提示窗口），诱骗用户到恶意APP上去执行相关操作（由于恶意APP能够通过Inotify推测出到底是哪个APP启动，也就能够相应地准备好钓鱼界面）。

首先简单介绍一下背景知识：Inotify机制是Linux 内核从 2.6.13 开始引入的一种文件变化通知机制，Android平台也支持。本文并不是第一个考虑利用Inotify机制来进行攻击的工作，作者提到了2016年的一篇研究工作（Inishing: a ui phishing attack to exploit the vulnerability of inotify in android smartphones 发表在IEICE TRANSACTIONS on Information and Systems (vol. 99, no. 9, pp. 2404–2409, 2016) 上，很好奇作者是怎么发现这个研究结果的）。然而，2016年的这个攻击，也需要依赖procfs的访问，因此目前已经无法实施。事实上，现在要实施类似的钓鱼攻击，限制条件非常多，攻击效果也并不好，但是本文的叙述技巧非常好，最终说服了审稿人，我们来仔细看看论文后续是怎么展开的。

首先，作者要说明利用Inotify机制去精确判断哪个APP正在启动，是目前的一项技术空白，这样就比直接说“我们提出了一种基于Inotify机制的攻击”要更有吸引力。在论文的第四章，作者通过调查AndroZoo数据集中的10000个恶意APP（他们专门开发了两套静态分析工具，一套分析Java代码，一套分析native代码），检查里面对Inotify相关API的使用，发现只有4.2%的样本会使用Inotify相关API，但是并没有什么恶意软件会把Inotify机制当作APP启动的预测器来使用，这就说明作者至少在技术上是领先于黑产的。

既然遥遥领先了，接下来作者还要严格证明Inotify机制是能够精确发现特定APP的启动的，怎么证明呢？这里作者设计了名为inoTool的工具（作者号称是2000行左右的python脚本），通过实际测试4863个热门的Android APP（100 most downloaded free apps for the 50 categories in the Google Play Store，刨掉了没法在模拟器上运行的）。但是实际上这个inoTool工具是一个基于eBPF的监控和分析工具，作者开源代码库（如下地址）中实际上是用Go语言（以及libbpfgo）实现了一个eBPF file system event analyzer！不过作者在第五章非常详细地介绍了对每个APP如何监控、以及如何确认这个APP是否存在特定的Inotify相关特性（可被用来当作一种fingerprint，作者将其称为app-dependent events）。

https://gitlab.eurecom.fr/totoR13/inotify-analyzer

经过实验，作者确认了有接近五分之一的热门APP产生了特定的app-dependent events，但是怎么利用这些指纹来攻击（附录C），不过到此为止，离实际能真正发起攻击还有很远的距离，论文的真正有趣的地方是在第七章，继续看！

在第七章中，作者提出了三种基于Inotify机制的攻击。第一种攻击需要知道APK的安装路径（例如/data/app/xxxx），但是在新版的Android系统上，在安装的时候，路径有随机化，因此无法提前预测。而且在Android 11以后，APP必须主动申请QUERY_ALL_PACKAGES权限才能向PackageManager服务查询这个路径信息（或者在metadata里面主动注册需要查询的APP的列表）。不过，如果APP开发时采用的API level低于30，这个强制策略（package visibility）是默认关闭的（考虑到兼容性），这种情况下恶意APP还是可以不需要申请任何权限去查询PackageManager服务。此外，作者发现了一个“诡计”（ruse）：如果实现了下面这么一个intent filter，就可以查询到所有“launchable”的APP，也就是那些在Android桌面上注册过一个快速入口的APP。不过这个技巧应该是此前就有很多人知道的，作者向Google报告这个问题后，Google回复说这个之前就有人报告过，只是还没公开（也没把它当成漏洞吧）。

第二种攻击可以在不知道APK的安装路径的情况下实施，其实就是对那些会在/sdcard下面访问特定文件的APP进行识别（啊，就这……）不过这个攻击在Android 10 (API 29)引入scoped storage，也就是只允许特定的APP去访问SDCard上的特定文件以后，就大幅度降低了这种攻击的可行性（在作者的数据集中，在Android 10及以后的系统中，有问题的APP从18.1%暴跌到0.7%）。

有意思的是，如果在设备上使用了外置的SDCard（哈哈哈年轻人你们是不是没经历过这个时代），会有个很隐蔽的问题——外置的SDCard在系统里面有两种配置选项，一种是portable，一种是internal，如果是portable配置（也就是说这张卡还可能拿到其他设备上用），上面的所有文件就变成全局可读（也就是可以被Inotify机制监控到），这引入了一些小小的安全隐患。

第三种攻击是对此前攻击的改进——前面的攻击假定手机上安装了非常多的APP，要区分到底是哪个APP启动，而实际上一般手机上平均只会安装35个APP，这时候的区分难度会大大降低。当然，这时候恶意APP需要首先收集到手机上安装的APP列表，也就是需要申请QUERY_ALL_PACKAGES这个权限。不过作者认为，申请这个权限太可疑了，于是提出了另一种方法——巧妙利用scoped storage。

我们知道APP在使用scoped storage策略之后，即使在SDCard上的文件也无法访问，但是这种“立入禁止”的提示信息反而变成了可以被利用的一个点。以Discord这个APP为例，它会创建/storage/emulated/0/Android/data/com.discord/这样一个私有的文件夹，然后大家就知道这设备上肯定装了Discord对不对？恶意APP可以使用getExternalStorageDirectory去查一下这个路径是否存在就好了。此外，在Android系统中，有一个API——java.nio.file.Files.exists允许普通权限的应用去查询特定的文件是否存在（前提是要指定完整的路径和文件名称）而不需要权限，因此恶意APP完全可以事先调查清楚每个APP会往/storage/emulated/0/Android/data/里面写入什么文件，然后就查一下看看这些个文件是否存在，就可以把大部分APP都查出来。作者统计表明，在调查的4863个APP中，至少2383个存在可区分的文件特征（在/storage/emulated/0/Android/data/里面写入特定文件），而且这只是静态分析的保守估计，可能还有许多APP在动态测试后也会发现更多的可区分信息。

最后，作者指出，如果能在SEAndroid上定制一些策略，限制第三方APP随意去利用Inotify机制监控文件（特别是.apk文件）的读写，就能很好对抗这种攻击。不过，作者调研了AOSP和第三方的ROM（如下表），发现官方的SEAndroid policy并没有任何针对这种攻击的限制。

论文：https://www.s3.eurecom.fr/docs/eurosp23_inotify.pdf

原文始发于微信公众号（安全研究GoSSIP）：G.O.S.S.I.P 阅读推荐 2023-11-10 基于Inotify的钓鱼攻击