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偵錯...