0x0前言

14年11月筆者在百度xteam博客中看到其公開了此前報(bào)告給Google的CVE-2014-8507漏洞細(xì)節(jié)——系統(tǒng)代碼在處理經(jīng)由短信承載的WAP推送內(nèi)容時(shí)產(chǎn)生的經(jīng)典SQL注入漏洞，影響Android 5.0以下的系統(tǒng)。于是對(duì)這個(gè)漏洞產(chǎn)生了興趣，想深入分析看看該漏洞的危害，以及是否能夠通過(guò)一條短信來(lái)制作攻擊PoC。

在斷斷續(xù)續(xù)的研究過(guò)程中，筆者發(fā)現(xiàn)了SQLite的一些安全特性演變和短信漏洞利用細(xì)節(jié)，本著技術(shù)探討和共同進(jìn)步的原則，結(jié)合以前掌握的SQLite安全知識(shí)一同整理分享出來(lái)，同各位安全專家一起探討Android平臺(tái)中SQLite的安全性，如有錯(cuò)誤之處，也請(qǐng)大家斧正。

0x1起：食之無(wú)味，棄之可惜

鼎鼎大名的SQL注入漏洞在服務(wù)器上的殺傷力不用多說(shuō)，可惜虎落平陽(yáng)被犬欺，SQL注入漏洞在Android平臺(tái)長(zhǎng)期處于比較雞肋的狀態(tài)。比較典型的漏洞例子可以參考：http://www.wooyun.org/bugs/wooyun-2014-086899。

雖然Android平臺(tái)大量使用SQLite存儲(chǔ)數(shù)據(jù)導(dǎo)致SQL注入很常見，而SQL注入的發(fā)現(xiàn)也相對(duì)簡(jiǎn)單，但其危害十分有限：在無(wú)其他漏洞輔助的情況下，需要在受害者的手機(jī)上先安裝一個(gè)惡意APP，通過(guò)這個(gè)惡意載體才可能盜取有SQL注入漏洞的APP的隱私數(shù)據(jù)(如圖1)。很多人會(huì)說(shuō)，都能夠安裝惡意APP了，可以利用的漏洞多了，還要你SQL注入干嘛。正是因?yàn)檫@個(gè)原因，導(dǎo)致SQL注入漏洞一直不被大家所關(guān)注。

圖1 通過(guò)SQL注入漏洞獲取某APP的敏感信息

0x2承：遠(yuǎn)程攻擊的大殺器

14年TSRC平臺(tái)的白帽子雪人提出了一種存在已久，在Android平臺(tái)卻鮮未被提起的SQL注入利用方式：load_extension。通過(guò)一些簡(jiǎn)單漏洞的配合，SQL注入漏洞可以達(dá)到遠(yuǎn)程代碼執(zhí)行的可怕威力。

簡(jiǎn)單來(lái)說(shuō)，為了方便開發(fā)者可以很輕便的擴(kuò)展功能，SQLite從3.3.6版本(http://www.sqlite.org/cgi/src/artifact/71405a8f9fedc0c2)開始提供了支持?jǐn)U展的能力，通過(guò)sqlite_load_extension API(或者load_extensionSQL語(yǔ)句)，開發(fā)者可以在不改動(dòng)SQLite源碼的情況下，通過(guò)動(dòng)態(tài)加載的庫(kù)(so/dll/dylib)來(lái)擴(kuò)展SQLite的能力。

圖2 SQLite從3.3.6版本開始支持動(dòng)態(tài)加載擴(kuò)展

便利的功能總是最先被黑客利用來(lái)實(shí)施攻擊。借助SQLite動(dòng)態(tài)加載的這個(gè)特性，我們僅需要在可以預(yù)測(cè)的存儲(chǔ)路徑中預(yù)先放置一個(gè)覆蓋SQLite擴(kuò)展規(guī)范的動(dòng)態(tài)庫(kù)(Android平臺(tái)的so庫(kù))，然后通過(guò)SQL注入漏洞調(diào)用load_extension，就可以很輕松的激活這個(gè)庫(kù)中的代碼，直接形成了遠(yuǎn)程代碼執(zhí)行漏洞。而在Android平臺(tái)中有漏洞利用經(jīng)驗(yàn)的同學(xué)應(yīng)該都很清楚，想要把一個(gè)惡意文件下載到手機(jī)存儲(chǔ)中，有許多實(shí)際可操作的方式，例如收到的圖片、音頻或者視頻，網(wǎng)頁(yè)的圖片緩存等。類似的案例筆者也見到過(guò)，如下圖遠(yuǎn)程利用SQL注入load_extension在某APP中執(zhí)行了惡意的SQLite擴(kuò)展。

圖3 Android APP中SQL注入導(dǎo)致的遠(yuǎn)程代碼執(zhí)行

0x3轉(zhuǎn)：攻與防的對(duì)立統(tǒng)一

也許是SQLite官方也意識(shí)到了load_extension API的能力過(guò)于強(qiáng)大，在放出load_extension功能后僅20天，就在代碼中(http://www.sqlite.org/cgi/src/info/4692319ccf28b0eb)將load_extension的功能設(shè)置為默認(rèn)關(guān)閉，需要在代碼中通過(guò)sqlite3_enable_load_extensionAPI顯式打開后方可使用，而此API無(wú)法在SQL語(yǔ)句中調(diào)用，斷絕了利用SQL注入打開的可能性。

圖4 SQLite默認(rèn)關(guān)閉了load_extension能力

湊巧的是，出于功能和優(yōu)化的原因，Google從 Android 4.1.2開始通過(guò)預(yù)編譯宏SQLITE_OMIT_LOAD_EXTENSION，從代碼上直接移除了SQLite動(dòng)態(tài)加載擴(kuò)展的能力(如圖4)。

圖5 Google在Android 4.1中禁用了load_extension

雖然有了以上兩層安全加固，但Android平臺(tái)的安全問(wèn)題往往不是這么容易就能夠解決的。和Android平臺(tái)五花八門的機(jī)型和系統(tǒng)版本一樣，部分手機(jī)生廠商和第三方數(shù)據(jù)庫(kù)組件并未跟隨官方代碼來(lái)關(guān)閉自身代碼中SQLite動(dòng)態(tài)加載擴(kuò)展的能力，默認(rèn)便可以直接使用SQL注入load_extension，導(dǎo)致這些手機(jī)或者APP極易被遠(yuǎn)程攻擊。

總結(jié)來(lái)說(shuō)，利用SQLite的load_extension遠(yuǎn)程實(shí)施攻擊，適用于4.1.2以前的官方Android版本，或者是部分手機(jī)廠商的機(jī)器，又或者是使用到某些第三方數(shù)據(jù)庫(kù)組件的APP。客觀來(lái)看，這種攻擊手法的攻擊面并不算寬，并會(huì)隨著高版本Android的普及和手機(jī)廠商的代碼跟進(jìn)而越來(lái)越窄。

那么除了最直接最暴力的load_extension攻擊方式之外，SQL注入是不是又變得一無(wú)是處了?在魔術(shù)師一般的安全人員手里，不管多么不起眼的攻擊方式都可能被用到極致。百度xteam的CVE-2014-8507就是一個(gè)很好的例子。

0x4合：一條短信就控制你的手機(jī)

接下來(lái)，我們回到最開始的問(wèn)題，如何通過(guò)一條短信來(lái)控制手機(jī)?

事實(shí)上在看到CVE-2014-8507后，筆者花費(fèi)了大量時(shí)間嘗試在標(biāo)準(zhǔn)Android機(jī)器中，通過(guò)彩信發(fā)送惡意so庫(kù)，隨后通過(guò)短信激活惡意so庫(kù)的方式，來(lái)實(shí)現(xiàn)控制手機(jī)。最終由于SQLite自身的sqlite3_enable_load_extension保護(hù)和系統(tǒng)代碼其他若干個(gè)方面的限制，成功在smspush進(jìn)程完成SQL注入后，卻沒有辦法進(jìn)一步利用惡意so庫(kù)，無(wú)法完成正在意義上的控制手機(jī)。

另外一方面，百度xteam對(duì)CVE-2014-8507的利用已經(jīng)很精彩，結(jié)合WAP推送處理代碼的特點(diǎn)利用SQL注入提供數(shù)據(jù)，完成了打開通過(guò)短信任意APP的導(dǎo)出Activity的攻擊，結(jié)合上其他的系統(tǒng)或者APP漏洞，不難達(dá)到真正意義上控制手機(jī)的效果。

作為狗尾續(xù)貂的補(bǔ)充，接下來(lái)和大家探討一下如何在真實(shí)手機(jī)中通過(guò)自行構(gòu)造PDU給任何Android 5.0以下機(jī)器發(fā)送含有SQL注入代碼的WAP推送消息。

承載攻擊的是WAP推送功能，而正常的短信APP無(wú)法通過(guò)短信發(fā)出WAP推送，通過(guò)短信群發(fā)等其他運(yùn)營(yíng)商提供的短信接口，也無(wú)法發(fā)出WAP推送消息。筆者通過(guò)一段時(shí)間對(duì)短信PDU格式的研究后發(fā)現(xiàn)，在Android vendor RIL之上進(jìn)行一些修改，普通的手機(jī)也能夠發(fā)出WAP推送消息。下圖6的sendSMS函數(shù)(http://androidxref.com/4.4.4_r1/xref/frameworks/opt/telephony/src/java/com/android/internal/telephony/RIL.java)在每次發(fā)送短信前都會(huì)被系統(tǒng)調(diào)用，其中的第二個(gè)參數(shù)我們可以得到完整的原始PDU，通過(guò)對(duì)PDU內(nèi)容進(jìn)行一些修改，我們可以把普通的短信變成WAP推送消息。在此位置進(jìn)行改動(dòng)，隨后PDU在替換后向底層傳之后，也能成功的被基帶解析并發(fā)送，接收方也能成功的接受并處理。

圖6 Android vendor RIL中的短信發(fā)送函數(shù)

普通短信的PDU中，包含了信息中心的號(hào)碼，發(fā)送方的號(hào)碼，接收方的號(hào)碼，時(shí)間戳以及短信內(nèi)容文本(如下圖7)。而WAP推送和普通短信的最重要區(qū)別，就是WAP推送承載的是WBXML格式的多媒體消息而不是普通文本，通過(guò)修改PDU中的類型標(biāo)志位并附加上WBXML格式的內(nèi)容，一條合法的WAP推送消息就能成功的從手機(jī)中發(fā)出。

圖7 典型的短信PDU格式

為了方便測(cè)試和演示，筆者寫了一個(gè)轉(zhuǎn)換WAP推送的Xposed模塊(如下圖)。激活后，通過(guò)短信APP中發(fā)送給任何人的普通短信都會(huì)自動(dòng)轉(zhuǎn)換成包含CVE-2014-8507 SQL注入漏洞的WAP推送，自動(dòng)打開對(duì)方手機(jī)的設(shè)置界面。關(guān)鍵的PDU處理代碼請(qǐng)點(diǎn)擊這里下載，請(qǐng)勿用于任何非測(cè)試用途。

圖8 轉(zhuǎn)換普通短信為WAP推送的Xposed模塊代碼

0x5后記：如何使APP的數(shù)據(jù)庫(kù)使用更安全

從2014年騰訊整體漏洞的數(shù)據(jù)來(lái)看，跟數(shù)據(jù)庫(kù)安全相關(guān)的全部都跟SQL注入漏洞有關(guān)。因此，能夠封堵SQL注入漏洞，基本上就能安全的使用數(shù)據(jù)庫(kù)了。下面結(jié)合歷史漏洞給出以下幾點(diǎn)安全建議供大家參考(如果是騰訊的同學(xué)就方便多了，我們終端安全團(tuán)隊(duì)為業(yè)務(wù)定制了數(shù)據(jù)庫(kù)安全組件)：

1. 不直接使用原始SQL語(yǔ)句，而是使用具備預(yù)編譯參數(shù)能力的SQL API;

2. 如果一定要使用原始SQL語(yǔ)句，語(yǔ)句中不應(yīng)有進(jìn)行任何字符串拼接的操作;

3. 如非必要，記得主動(dòng)調(diào)用SQL API關(guān)閉動(dòng)態(tài)加載擴(kuò)展的能力;

4. 使用數(shù)據(jù)加密(如SqlCipher)擴(kuò)展SQLite數(shù)據(jù)存儲(chǔ)的安全性。

0x6相關(guān)鏈接

[1] http://lcx.cc/?i=4428

[2] https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-8507

[3] http://xteam.baidu.com/?p=167

[4] http://www.sqlite.org/cgi/src/tree?ci=trunk

[5] https://android.googlesource.com/platform/external/sqlite/

[6] https://android.googlesource.com/platform/frameworks/base/+/android-4.4.4_r2.0.1/packages/WAPPushManager/

[7] http://androidxref.com

[8] http://www.gsm-modem.de/sms-pdu-mode.html