Android 中的特殊攻击面（一）——邪恶的对话框



• 0x00 介绍



所谓攻击面，既是系统处理正常输入的各种入口的总和，也是未授权攻击者进入系统的入口。在漏洞挖掘中，攻击面是最为核心的一个概念，超越各种流派、各种专业方向而存在，无论Web还是二进制，也无论Windows还是Android，总是在研究如何访问攻击面，分析与攻击面有关的数据处理代码，或者Fuzz攻击面。漏洞挖掘工作总是围绕着攻击面在进行。



就Android系统和App而言，通常所知的本地攻击面无外乎暴露组件、binder服务、驱动和套接字，远程攻击面无外乎各种通信协议、文件格式和网页链接。然而，实际漏洞案例总是鲜活的，总有一些鲜为人知的攻击面，出现的漏洞颇为有趣，甚至很有实际利用价值，所以这里准备写一个系列，记录发现的一些有趣漏洞。先来谈谈与用户发生交互的对话框。



• 0x01 人机交互对话框

在AOSP的漏洞评级标准中，中危漏洞和高危漏洞的评级都有这么一条：



* High：Local bypass of user interaction requirements for any developer or security settings modifications

* Moderate: Local bypass of user interaction requirements (access to functionality that would normally require either user initiation or user permission)

系统中需要用户交互进行确认的地方，一旦可以绕过修改安全设置或者产生安全影响，即认为出现了漏洞，这里与用户交互的对话框就是一种特殊的攻击面。



• 0x02 用户确认绕过



在与用户交互的对话框中，拨打电话对话框通常比较特殊，开发人员容易忽视其被外部直接调用绕过用户交互后的安全影响。Android历史上就曾出现这种漏洞，如CVE-2013-6272。



然而在一些流行的社交网络软件中，其VoIP拨号功能也容易出现此类漏洞，恶意程序可以绕过用户交互直接拨号到另一个用户，这样另一个用户就可以监听受害用户手机的麦克风，使受害用户的隐私泄露。



俄罗斯知名的社交软件VK.COM曾出现这样一个漏洞: Bypass User Interaction to initiate a VoIP call to Another User

主要原因在于

`com.vkontakte.android.LinkRedirActivity`可以传入一个Provider，而这个Provider中可以指定其他用户的id

ContentValues cr_vals = new ContentValues();        cr_vals.put("data1", 458454771); //target user_id        cr_vals.put("name", "unused");



当启动该Activity的时候就会直接向指定id的用户拨号。问题在于，作为拨号过程，这里需要设计一个对话框让用户确认。刚开始VK.COM并不认为这是一个漏洞，后来使用HackerOne的仲裁机制，邀请其他Android领域的知名安全专家一起参加讨论才说服厂商，修复最终添加了一个确认对话框，用户确认后才允许拨号。



同样，Line也出现过类似的漏洞，绕过用户交互向另一用户拨打Audio Phone，Line将这个漏洞归为Authentication Bypass，同样在修复中加入了一个用户确认对话框。



• 0x03 用户确认欺骗 

除了对话框绕过以外，攻击者还可以在对话框中显示欺骗的内容，达到clickjacking的效果。



CVE-2017-13242: 蓝牙配对对话框欺骗

这个漏洞发生在我们经常使用的蓝牙配对对话框中，如下图是正常的蓝牙配对对话框：





这里的Angler是对端的蓝牙配对设备。但是这个设备名是攻击者可控的，能否在这个攻击面上造成安全影响呢？



我们将对端的蓝牙配对设备名变长，并插入一个换行符，改为“Pair with Angler \n to pair but NOT to access your contacts and call history”，那么蓝牙配对对话框显示为：





虽然有一些奇怪，但用户一定会在是否共享通讯录和通话记录这个问题上比较纠结，“是的，我允许配对，但我不想共享通讯录和通话记录！”于是，误导配对用户勾选下面的复选框，反而达到与用户期望相反的目的，正中攻击者的下怀。



这个漏洞于2018年2月修复，可惜Google的修复并不完全，只是在Settings App中的Strings.xml作了限制，不允许对端配对的蓝牙设备名传入，将配对对话框中的提示内容变成了一个固定的字符串。但是，这个修复并不完全，没有考虑到其他蓝牙连接的入口。



CVE-2018-9432: 蓝牙通讯录和短信访问协议对话框欺骗



Android蓝牙协议还支持PBAP和MAP Server，分别用于其他设备通过蓝牙访问手机的通讯录和短信，通常我们开车时通过蓝牙拨打电话、访问手机通讯录就使用了PBAP协议。通过PBAP协议和MAP协议，可以无需配对，直接在手机上弹出对话框，让用户确认是否访问通讯录和短信。PBAP协议确认对话框如下图所示：





但同样，临近攻击者可以将配对设备heen-ras重新命名，并插入许多的换行符

pi@heen-ras:~ $ sudo hciconfig hci0 name "heen-ras 想要访问你的通信录和电话簿， 要拒绝它吗？>​…(skip)​>> "



然后再次通过PBAP协议访问手机通信录，使用"nOBEX"这个脚本

pi@heen-ras:~/bluetooth-fuzz/nOBEX $ python3 examples/pbapclient.py <victim_bluetooth_address>



此时通讯录确认对话框如下：





对比上下两图，确认对话框中的重要信息被隐藏了，并显示出相反的结果。在内部实际环境进行模拟检测，发现普通用户对此毫无招架，一般都会选择“是”，结果通讯录被全部窃取。这个漏洞最终于2018年7月修复，使用的方法是在BluetoothDevice类中过滤配对蓝牙设备名中的\r\n字符。



值得一提的是，同样是插入攻击设备蓝牙适配器的换行符，还可以远程注入蓝牙配置文件，攻击者可以设置蓝牙设备名绕过配对与Android设备建立蓝牙连接，这个严重级别的漏洞也在去年所修复，与上述两个漏洞异曲同工。同样是攻击面思维，漏洞作者将可控的蓝牙设备名传入蓝牙配置文件带来安全影响，而我们这里则是将蓝牙设备名传入配对对话框欺骗普通用户。



• 小结

从攻的角度来看，对话框是一种特殊的攻击面；从防的角度来看，对话框也是一种重要的安全机制，开发者需在对安全或隐私有影响的操作前设置用户交互对话框，在用户同意后才可进行敏感操作，并仔细检查对话框中传入的内容，防止对用户进行点击欺骗。



• 参考文献

[1]https://source.android.com/security/overview/updates-resources



[2]https://curesec.com/blog/article/blog/CVE-2013-6272-comandroidphone-35.html



[3]https://android.googlesource.com/platform/packages/apps/Settings/+/7ed7d00e6028234088b58bf6d6d9362a5effece1%5E%21/#F0



[4] https://github.com/nccgroup/nOBEX



[5]https://android.googlesource.com/platform/frameworks/base/+/a6fe2cd18c77c68219fe7159c051bc4e0003fc40



[6] http://sploit3r.xyz/cve-2017-13284-injection-in-configuration-file