Android平台的SQL注入漏洞浅析(一条短信控制你的手机)-木庄网络博客

本文整理自网络，侵删。

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极易被远程攻击。

阅读剩余部分