0x0前言

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

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

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

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

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

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

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

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

圖2 SQLite從3.3.6版本開始支持動態加載擴展

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

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

0x3轉：攻與防的對立統一

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

圖4 SQLite默認關閉了load_extension能力

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

圖5 Google在Android 4.1中禁用了load_extension

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

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

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

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

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

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

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

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

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

圖6 Android vendor RIL中的短信發送函數

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

圖7 典型的短信PDU格式

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

圖8 轉換普通短信為WAP推送的Xposed模塊代碼

0x5后記：如何使APP的數據庫使用更安全

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

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

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

3.   如非必要，記得主動調用SQL API關閉動態加載擴展的能力；

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