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

Plain Text1

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