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数据存储的安全性。
