猫头鹰
信安舆情早知道

过狗注入研究历史及最后突破思路

471735012

前言

个人觉得web免杀很容易,包括一句话 一句话连接端,只要晓得个可以过狗的加密方式就行,而且POST下防护不如GET下防护等级高(经本人测试得出的结论,如果你看完此贴,你也会发现)。包括大马,免杀也很容易,各种加密或云端大马(我现在用的就是云端大马),过狗上传方法也很多,我现在晓得两种过狗上传方法,但是过狗注入吧,一直没头绪,也算是运气比较好,发现了个有意思的东西,所以几天就给研究出来了,也就是前阵子的事,那时还没加入90,是在吐司发的帖,一共是2弹,第一弹失败,第二弹成功了。所以把我的思路和大家分享下。

首先是做了一些尝试(都是网上的方法),然后一部分所谓的大牛说:用sqlmap的tamper脚本来绕过,于是我开始了苦逼的测试之旅↓下面这个是失败的过程,也让大家知道tamper比较真实的一面。

现在都是安全狗,没办法,只好本地测试过狗注入了。不然永远停留在被狗咬的悲剧境地。

正常界面↓图1

3315075678

用xor 5>6返回正常 xor 5>4返回错误,可以绕过安全狗的初步判断是否存在注入点

order by 安全狗也不拦截,可以正常判断字段数 为22

但是下一步猜表名的的时候就悲剧了↓图2

1313169510

被咬了。。

继续测试↓图3

3

id=1137 UNIOn SELEcT 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22 fro

这样也会被咬,只要在一起 都会被咬。以前的% /**/等 二次编码啊,这些都不行喽。。

于是考虑没必要花很多时间手工注入,用sqlmap的模块测试,↓

sqlmap.py -u http://192.168.1.125/Production/PRODUCT_DETAIL.asp?id=1137 -technique U -p id -batch -tamper “space2morehash.py”

space2morehash.py模块,自动转换空格为随机字符,结果如图4↓

4

前面明明提示有注入。但是后面又提示没有注入了,看来是判断的时候没问题,sqlmap进行其他探测的时候被狗拦截了。

init.py模块尝试↓图5

5

apostrophemask.py↓图6

6

apostrophemask.py 作用:用utf8代替引号↓图7

7

…………….后面又根据功能尝试了一些sqlmap自带的py绕过脚本,都不行

随后又尝试提交长字符,↓图8

8

虽然已经超过了安全狗默认的url上限长度2048 但还是被拦截。

——————-以上就是第一弹失败的过程————————

其实包括参数污染,长度干扰这些等等很多方法都试过了,完全没用,乌云红老师一提交,大家都没得玩(大玩家除外,有能力我服 搞技术就是这样)。

路还很长,我肯定不会放弃,本来是打算哪怕搞个一年,我也要给搞出来。不然连狗都过不了还好意思讲我是搞渗透的。于是有了第二弹↓

过狗注入研究第二弹——【结贴-已成功突破安全狗】

先是收集了各种已爆出的过狗注入方法,相信对思路有些帮助。

用的是asp+access的环境

GET提交方式下↓

and //拦截

order by //不拦截

xor 5>6 //不拦截

单纯的union //不拦截

单纯的select //不拦截

union select //拦截 去掉任意一个语句的其中一个字符,都不拦截

编码、注释、参数污染什么的不用提了,大家都懂。不过我始终认为,有些东西没办法过滤完全的(1.可能是疏忽,结合各种方法突破的可能性大些 2.可能考虑到性能)

GET方式下,基本就到这里了,只要union select就被搞死了。各种测试无果。

考虑到sql可以增删改查,注入当然也一样。如果可以直接添加管理员进去也不错,头疼的是如果不经过select查询,没办法确定有哪些表和字段,但是查表又被咬,如果可以突破的话,那查字段内容也不是问题了,所以修改和添加无从谈起了。

于是开始用post来测试,毕竟还是有很多脚本的参数接受方式是request

看过一个过狗上传是利用♣这个特殊符号的 传送门http://www.wooyun.org/bugs/wooyun-2010-0104444

据说安全狗对一些特殊符号没有免疫力,还是自己测试一下,于是在网上找了特殊符号大全,在POST下提交果然发现了一些情况 ↓图1

9

为了直观查看效果,我把sql语句给输出了 可以看到这个С经过POST提交以后变成了正常的!号,这里的С不是大小写,也不是全角c,是个宽字节的字符。

我的思路是,既然С这个符号可以解释成!那么肯定还有别的宽字节符号可以解释成字母、数字、正常符号。如果把正常的注入语句都替换成可以解释的宽字节,那么效果是什么样子呢。 于是继续测试

花了一整天时间手工测试了近两万个特殊符号,最终提取到以下的有意义字符,如图2↓

10

上面的特殊符号都可以经过POST提交后解释成我们常用的字符、数字、字母、于是把正常的语句给替换一下,看看效果

正常语句↓

id=1137%20union%20select%201,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22

替换后↓

ぉфнббгз%20uюiяю%20こхlхуt%201Ь2Ь3Ь4Ь5Ь6Ь7Ь8Ь9Ь10Ь11Ь12Ь13Ь14Ь15Ь16Ь17Ь18Ь19Ь20Ь21Ь22

前面的id=1137、union、select、逗号 全部替换了,访问结果如图3↓

12

没有被狗咬,解释也正常。稍微激动了一下,然后直接用id=1137%20union%20select%201,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22提交,也没被咬。我擦,看来POST提交方式下 不拦截union select组合(没带上from时,但是GET不带from都拦截)

然后经过漫长的测试以后,得知↓

union select //POST下不会被拦截

union select 1,2,3,4……22 //不会被拦截

union select 1,2,3,4……22 from //立马被咬

union select 1,2,3,4……22 fro //不拦截

union selec 1,2,3,4……22 from //不拦截

unon select 1,2,3,4……22 from //不拦截

也就是只要Union select from 组合在一起就要被咬死,和中间的字段没关系。

然后考虑深度替换一下这三个语句

union 替换为↓

uю%69яю //这里把i不用宽字节 直接url编码 其他的字符都用对应的宽字节

select 替换为↓

こхlх%уt //t不编码 其他的都宽字节 中间插上%

from 替换为↓

цR%яэ //宽字节+%

另外↓

%20 全部替换为↓

%ва //в是2的款字符 а是0的宽字符 测试没问题后,才决定这样搞、

, 替换为

Ь //,号的宽字节

最后→→→→→数字全部替换成相应的宽字节 id=1137也替换

结果如↓

id=1137%20union%20select%201,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22%20from%20admin

ぉфнббгз%ваuю%69яю%ваこхlх%уt%ваб,в,г,д,е,ж,з,и,й,ба,бб,бв,бг,бд,бе,бж,бз,би,бй,ва,вб,вв%вацR%яэ%ваちфэぉю

提交看看效果,如图4↓

13

还是被虐了。

最终没找%的宽字节,不然还想再试试。

肯定还是要继续测试下去,这个事不会放弃,希望大家可以给点建议,测试出来了,在坛里肯定会间接的给出方法。

各位大牛有什么想法都可以说一下,我暂时无话可说,只等有新思路,继续搞。

说明

1.我不知道网上是否有人提出过,但是利用特殊字符(款字节)来绕过安全狗,我完全是根据自己的思路来的。

2.到这里肯定没有结束,当时失败以后非常!!不!甘!心!于是继续测试,搞了有10分钟,成功突破安全狗了。

14 15

心中十分开心,但没到很激动的程度,我始终认为很多事情都是水到渠成的事,坚持下去成功是必然的结果。

突破思路↓

其实也是用刚才的宽字节思路,配合以前爆出的某种方法。原谅我不能直接说出来,这东西见光死,我用不了了没关系,可以继续花时间研究,但是咱们还是交流思路,有心的坛友自然能搞出来。

拓展

关于局限性↓

1.坦白说 我研究出来的这个方法接收方式必须要是request,虽然我不懂asp,但是长期搞站看来asp接收方式基本都是request

关于款字节的影响范围

1.关于这个款字节的影响范围,发出来的时候有吐司的坛友认为只有IIS才行。 下面是过程↓

由于这个大牛已经把帖子重新编辑了,所以看不到原来内容了,基本就是他说 这个是IIS的问题,局限性很大。

然后发出了一个某前辈的研究文章 传送门→http://blog.sina.com.cn/s/blog_85e506df0102vo9s.html

于是我开始测试,总觉得这个不是IIS的问题,就比如说款字节绕过魔术引号,谁能说是IIS的问题?于是我找了几个不同搭建平台的站点,进行了测试。原回复如下↓

感谢前辈分享,学习了原理,受教。然而我认为这不是搭建平台的问题,就像宽字节突破魔术引号gpc一样。刚才我用小旋风一键集成环境搭建测试了一下,不用IIS。结果如下↓

1.用集成环境搭建测试↓

16

我这里用了小旋风,一样可以成功解析宽字节。

2.另外我百度随便找了php的站,↓

17

不可利用的是get方式,post 和 cookie都可以,目标注入点接收方式是request就比较占便宜了。

以上就是我测试和拓展的结果,宽字节唯一局限的个人认为是提交方式,GET下肯定不行,POST和cookie均可,但是在非GET下利用宽字节,空格必须编码(普通注入也是)。

另外对于sqlmap的tamper脚本,个人有些看法。虽然我用tamper没测试成功,但是仍然觉得tamper的帮助很大,无论是针对性绕过还是研究注入绕过都有很多帮助,我给分享一下tamper相对应的绕过表。图如下↓

183700xzffzthyhj0muuyy

等等很多,针对性绕过和每个tamper脚本的详细作用及方法。

附件下载地址

 

【原文:过狗注入研究历史及最后突破思路    MottoIN小编整理发布】

转载请注明来自MottoIN,未经允许不得转载!MottoIN » 过狗注入研究历史及最后突破思路

分享到:更多 ()

评论 抢沙发

评论前必须登录!

 

MottoIN 换一个角度看安全

寻求报道联系我们