Android平台的SQL注入漏洞浅析(一条短信控制你的手机)

  发布时间:2016-02-01 22:28:28   作者:佚名   我要评论
14年11月笔者在百度xteam博客中看到其公开了此前报告给Google的CVE-2014-8507漏洞细节——系统代码在处理经由短信承载的WAP推送内容时产生的经典SQL注入漏洞,影响Android 5.0以下的系统
(福利推荐:【腾讯云】服务器最新限时优惠活动,云服务器1核2G仅99元/年、2核4G仅768元/3年,立即抢购>>>:9i0i.cn/qcloud

(福利推荐:你还在原价购买阿里云服务器?现在阿里云0.8折限时抢购活动来啦!4核8G企业云服务器仅2998元/3年,立即抢购>>>:9i0i.cn/aliyun

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

相关文章

  • 有了短信验证你的钱到底是怎么被强刷走的 警惕手机木马

    本以为有了手机短信验证应该很安全了,没想到银行卡里的钱还是能被刷走,关键是一条短信都没收到。到底是怎么回事?原来是手机木马搞得鬼,很多奇怪的第三方软件作为木马拦
    2016-06-13
  • 手机木马盗取网银过程大揭秘 验证码短信尤为关键

    360手机安全中心接到大量用户举报,称其遭受短信诈骗,被骗金额多数以万计。最终都是因为用户中招后,验证码被木马偷偷转发到不法分子手机中。
    2015-09-21
  • 手机里的信息到底安不安全?手机数据泄露大揭秘

    如果你给自己的手机设置了PIN码,甚至忘记了连自己也解不开;又或者设置了比划甚至指纹解锁,然后以为这样的手机就是安全的了。是的,对于一般的人来说算安全了,可是对于
    2016-06-03
  • 你的手机有没有ROOT? ROOT后的手机漏洞防不胜防

    也许你的手机ROOT只是为了安装一款游戏,安装一个工具。对我们普通人来说,ROOT代表着方便和自由,其实你不知道的是,它同时也为黑客带来了侵犯你隐私的方便和自由。看看RO
    2016-06-25
  • 让手机炸弹不在神秘

    下载一个手机炸弹软件 随便输入一个手机号码然后选择次数之类的 利用WSockExpert_Cn.exe监听手机炸弹 得出http://sms.98960.com/pages/user-newlogin.asp?number=130881
    2009-06-28
  • 手机病毒的剖析与防治

      手机病毒是病毒的一个分支,虽然其存在只有短短数年,但在将来很可能会随着3G的推广而大量涌现。   病毒类型:手机病毒   病毒目的:破坏手机系统,狂发短信等  
    2009-06-28
  • 手机短信验证码安全吗 警惕手机短信木马

    现在想换个手机越来越麻烦,很多APP要重新下,手机里保存的宝贝也要转移,有时候这些事情甚至让我放弃了换个更好的手机的想发,更不用说换手机号了。各种网站、邮箱、账号
    2016-07-11

最新评论

?


http://www.vxiaotou.com