原创蓝牙App漏洞系列分析之一CVE20170601

作者:小荷才露尖尖角@MS509Team

0x01 概要

2017年5月的Android安全公告修复了我们提交的一个蓝牙提权中危漏洞,这个漏洞尽管简单,但比较有意思,能够使本地恶意App绕过用户交互,使用户强制接收外部传入的蓝牙文件。漏洞概要如下:

  • CVE: CVE-2017-0601
  • BugID: A-35258579
  • 严重性: 中
  • 影响的Google设备: All
  • Updated AOSP versions: 7.0, 7.1.1, 7.1.2

0x02 漏洞分析

蓝牙App暴露了一个广播接收器com.android.bluetooth.opp.BluetoothOppReceiver,本地普通App可以向这个Receiver发送广播,查看其OnReceive方法,包含了对多种传入广播Intent Action的处理,但是大多数Intent Action处于保护状态,简单用adb shell可以一一对其测试,比如

提示如下错误,说明action处于保护状态

但是android.btopp.intent.action.ACCEPT这个Intent Action,却没有保护

进一步分析AOSP代码,发现传入这个Action的Intent时,会将Intent携带Uri指向的db进行更新,更新为用户确认状态。

这个db其实就是蓝牙文件共享的provider,对应的uri为content://con.android.bluetooth.opp/btopp,当通过蓝牙共享接收、发送文件时,该数据库都会增加新的条目,记录接收、发送的状态。该provider记录的信息可以参考BluetoothShare

因此,如果我们在Intent中传入某个蓝牙共享对应文件的uri,那么它在蓝牙文件共享Provider中的状态就会被更改为用户确认状态。这里继续进行猜想,进一步,如果我们刚好通过蓝牙传入某个文件,将其状态改为用户确认,是否文件就无需确认,自动接收了呢?幸运的是,的确如此。

0x03 漏洞利用

这里还有一个问题要解决,content://com.android.bluetooth.opp/btopp只是整个provider的uri,我们如何知道刚刚通过蓝牙传入文件的uri呢?通过暴力穷举,下面的PoC简单地解决了这个问题,

0x04 测试方法

通过蓝牙向测试手机发送文件,此时,手机将会出现提示,要用户拒绝或者接受,这个对话框将会出现约1分钟

此时运行POC,文件将会自动接收,因此这是一个本地用户交互绕过。如果有恶意程序利用该漏洞一直在后台运行,那么手机将会被强制接收任意蓝牙传入的文件。

0x05 修复

Google在Framework的AndroidManifest文件中,将android.btopp.intent.action.ACCEPT和DECLINE设为保护状态,普通App无法发出携带这些action的Intent。

0x06时间线

2017.02.09——提交Google

2017.03.01——漏洞确认

2017.05.01——补丁发布

2017.05.04——漏洞公开

 

授权转载自先知社区:https://xianzhi.aliyun.com/forum/read/1570.html