0x01 初衷以及適用場景
android的usb調試模式本是為開發者而設計的，開發者在應用開發的過程中可用其對應用進行調試或測試。
adb提供一系列有助於開發的功能，例如應用安裝與卸載，備份與恢復，日誌的輸出與過濾，並且，它還提供一個權限相當可觀的、很人性化的adb shell。
除開發者外，逆向分析人員在對應用進行逆向分析以及動態調試的時候，也會使用到adb接口，例如通過該接口對so或者smali進行動態調試與跟踪，動態對一些功能性的代碼進行驗證等等。
然而便利性與安全性在某種程度上是成反比的，在其豐富的功能之下，也存在著一系列安全問題。
0x02 adb的資訊洩露與權限洩露問題
如果應用在發佈時，沒有把logcat所輸出的調試信息刪除掉，那麼很有可能造成敏感信息的洩露，輕微的情況，例如logcat可能打印出應用所訪問的網頁連結或一些其它的中間變量，重則可能把帳號密碼也洩露出來，畢竟安卓開發門檻低，開發者水平難免參差不齊。
為了方便調試，開發者甚至可能會這麼寫：
logcat資訊洩露的情況在曾經的烏雲上披露過很多起，例如：
WooYun: 途牛網app logcat信息很多起，例如：
WooYun: 途牛網app logcat信息很多起，例如同團聊的聊天內容
WooYun: 衝浪瀏覽器logcat出用戶簡訊
WooYun: 杭州銀行Android客戶端登入帳號密碼資訊本地外洩
此外，目前市面上許多應用程式漏洞掃描平台也會著重把安卓logcat的濫用掃描出來呈現於報告中，例如騰訊金剛審計系統、阿里聚安全、360顯危鏡(前捉蟲獵人)等。這也從側面體現了這個問題的普遍性。
除了開發者的失誤之外，adb本身的設計方面也有一些瑕疵，曾經有一篇論文專門對該問題進行過研究：《Bittersweet ADB : Attacks and Defenses》。
透過ADB或一個申請了ADB權限的Android應用程序，可以在不申請權限的情況下監控短信、電話記錄等隱私信息，監控/模擬屏幕點擊事件，訪問其它應用程序的私有目錄，對Android設備進行DoS攻擊等。
而上述行為大部分可以透過adb shell dumpsys指令得到，更具體內容可查看參考連結[2]。
0x03 安卓備份問題
這是一個相當古老的問題了，在低版本的安卓系統中，在對某個應用進行備份操作時，會將其私有數據一併給備份出來，然後即可通過特定的工具把它們提取出來，如下圖：
那麼應用的私有數據中一般有些什麼?首先便會有個人的身份憑證，或者是帳號密碼或者是別的憑證，一般應用對私有數據是比較有信心的，畢竟它被稱為“私有數據”，因而挺多應用都直接明文存著，有些雖然有加密處理，但是通過對應用的逆向分析，即可將數據進行解密，例如從某客戶端中backup出的內容中含有以下檔案：
透過對apk進行逆向可發現其解密過程，照著解密類別與方法抄一遍即可解密：
又如微信的資料庫，有文章曾分析過微信資料庫的加密過程，並給出了其加密金鑰的產生方式，如果微信本地資料庫，uin，imei同時被拿到，便可根據後兩者算出資料庫的加密金鑰，並對加密後的資料庫進行解密，這時你的所有聊天記錄都直接曬在太陽下了。
除了直接手動解密資料以外，還可以將這些資料透過adb restore原封不動地恢復到另一個手機上，從而進行身分偽造，例如droidsec上的文章《兩分鐘竊取身邊女神微博帳號》(參考連結[4])
有人注意到在使用adb backup時需要手動點擊確認才可進行備份，如果攻擊者沒有機會點擊螢幕，就沒有問題了，不過安卓有個機制叫做輸入輸出子系統，在adb shell 下可以執行sendevent指令，可以模擬各種使用者輸入，具體每種機型不一樣，在我的機器上發送如下event便可模擬點擊允許操作：
#EV_KEY BTN_TOUCH DOWN sendevent /dev/input/event7 1 330 1 #EV_ABS ABS_MT_POSITION_X 366 sendevent /dev/input/event7 3 53 366 #EV_ABS ABS_MT_POSITION_Y 690 sendevent /dev/input/event7 3 54 690 #EV_SYN SYN_REPORT 00000000 sendevent /dev/input/event7 0 0 0 #EV_KEY BTN_TOUCH UP sendevent /dev/input/event7 1 330 0 #EV_SYN SYN_REPORT 00000000 sendevent /dev/input/event7 0 0 0
0x04 透過adb種馬
🎜既然透過adb可以安裝應用，而且還是靜默的，那麼自然也可以在使用者沒有感知的情況下給你種馬。 🎜不過一般的馬可能並沒有圖標與界面等等增加被發現幾率的東西，而沒有被launch過的應用是不能運行的，也就是說它們所註冊的BroadcastReceiver都是收不到東西的， 它需要一個喚醒的過程。
所幸adb shell也可以實現這個喚醒過程，透過adb shell am指令可以啟動特定應用包的特定元件，如此小馬就可以成功跑起來了。
當然，如果攻擊者有更強勁的方式，例如直接adb push一個exploit上去，提權到root，就更加簡單粗暴了。
0x05 惡意程式碼注入
這種手段就相對優雅一些了，在連接usb調試的情況下，可以透過一系列命令，向手機上已安裝的應用中註入一段自訂的惡意程式碼，這段程式碼可以是簡單地彈一聲問候，也可以是非常複雜的遠控。
為了進一步增加可信度，可以選本來就申請了很高權限的應用進行注入，例如對一款通訊錄管理軟體進行注入後，它請求讀取你的聯絡人列表，看起來沒毛病。
儘管學術界與工業界有很多防止重打包的措施，但是在實際測試中，這種攻擊手段的成功率著實不低，並且，就算對某個應用注入失敗了，最粗暴的方法還可以pm list packages -3把所有的套件都列出來都搞一遍試試。
以下我自己寫了一個簡單的程序，對開啟USB調試的手機上某應用注入一段metasploit meterpreter http reverse shell的payload，整個過程中不需要對手機進行任何操作，大體工作流程如下：
當再次點擊注入後的應用之後，在監聽伺服器上開啟的handler上即可接收到一個meterpreter的shell :
以上，便可在服務端對安卓應用進行遠端控制了，拿到Android meterpreter shell之後，可以做的事情很多，包括隱私竊取、發送短信，打開網頁，截圖、照相。
甚至，可以調用你的前置後置攝像頭進行即時監控。
所支援的部分指令如下：
0x06 最後
在4.4以後的安卓版本，若要連接android裝置上的adbd，需要對host機器進行指紋的驗證，這在很大程度上又降低了透過這些方式被攻擊的可能性。不過如今PC上的安卓管理軟體都是大力提倡你打開usb調試，甚至會一步一步教你怎麼打開，因此還是會有相當大一部分人暴露在此風險之下。
如上可見，透過adb可以做的事情還是很多的，以上只是列舉了一部分，並且是當前常用的一些小手段，想要完全防止被上述手段攻擊，最簡單而有效的辦法便是關閉USB調試，並且盡量在正規的應用市場下載可信的應用程式。
畢竟，設想如果你正在火車站或者某公共場所，使用不知誰放在在那兒的公共充電插口，其背後是一台惡意的計算機，而你剛好打開了，或者在它的誘導下，打開了USB偵錯...
