0x0前言

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

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

0x1起：食之無味，棄之可惜

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

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

圖1 通過SQL注入漏洞獲取某APP的敏感信息0x2承：遠程攻擊的大殺器

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

     簡單來說，為了方便開發(fā)者可以很輕便的擴展功能，SQLite從3.3.6版本（http://www.sqlite.org/cgi/src/artifact/71405a8f9fedc0c2）開始提供了支持擴展的能力，通過sqlite_load_extension API（或者load_extensionSQL語句），開發(fā)者可以在不改動SQLite源碼的情況下，通過動態(tài)加載的庫（so/dll/dylib）來擴展SQLite的能力。

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

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

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

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

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

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

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

圖5 Google在Android 4.1中禁用了load_extension

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

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

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

0x4合：一條短信就控制你的手機

        接下來，我們回到最開始的問題，如何通過一條短信來控制手機？

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

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

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

       承載攻擊的是WAP推送功能，而正常的短信APP無法通過短信發(fā)出WAP推送，通過短信群發(fā)等其他運營商提供的短信接口，也無法發(fā)出WAP推送消息。筆者通過一段時間對短信PDU格式的研究后發(fā)現(xiàn)，在Android vendor RIL之上進行一些修改，普通的手機也能夠發(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ā)送短信前都會被系統(tǒng)調(diào)用，其中的第二個參數(shù)我們可以得到完整的原始PDU，通過對PDU內(nèi)容進行一些修改，我們可以把普通的短信變成WAP推送消息。在此位置進行改動，隨后PDU在替換后向底層傳之后，也能成功的被基帶解析并發(fā)送，接收方也能成功的接受并處理。

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

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

圖7 典型的短信PDU格式

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

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

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

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

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

2.   如果一定要使用原始SQL語句，語句中不應有進行任何字符串拼接的操作；

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

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