A-A+

SN某接口CRLF注入艰难利用 – cookie复写可打全站XSS

2017年06月06日 09:44 漏洞安全 暂无评论 共2182字 (阅读3,600 views次)

【注意:此文章为博主原创文章!转载需注意,请带原文链接,至少也要是txt格式!】

请注意,本文主要说明攻击思路。

CRLF注入这个漏洞我碰到的真是特别少,有印象的是总共碰到过两次,那两次还都无法实际利用,可能过滤了换行的参数吧。不过这次也算是巧合SN发现了几处CRLF注入,这里我挑选了一处比较有意思的来说说,如下图。

 

http://xxxx.SN.com/cxxxxxxxxs?sid=16xxxxxx8&tid=1612xxxxxxxxx0614&ap=NDQzxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxfDB8fA==

当访问上面的URL的时候如下图:

SN某URL302跳转

SN某URL302跳转

 

上面URL参数中有个AP参数,这个值明显是base64编码的参数。

通过base64解码ap参数的值发现。值是:

4439xxxxxxxx421|37c949xxxxxxxxxxa9ddcbe|100xxxxx22|161xxxxxxxxx614|16xxxxx78|http://xxxx.SN.com/jxxxxxxx0.html|cpm|2017-06-14 16:37:55|1497xxxxxxx1188|58.2xx.xx2.35|0||42xxxxx83|0|148617xxxxxx798|15xxxxx4|16|100|192.1xx.xxx.37|0||

 

这里感觉指向的就是 解码后http://xxxx.SN.com/jxxxxx0.html这个地址,然后,后缀还加上了cpm这个参数值。

这里随便更改了一下地址,然后编码,再然后访问了一下,确实就跳转到了我随便放入的URL地址,可以确定这个参数由我控制。那么尝试了一下%0a换行,看看是否有CRLF注入,但是如图:

重新编码AP值,然后看返回数据

重新编码AP值,然后看返回数据

这里发现,你怎么编码它就怎么返回你编码的值。然后直接不编码尝试了一下。

不编码 是否可以构造恶意攻击

不编码 是否可以构造恶意攻击

本来以为这样就可以直接注入写入恶意的cookie,把恶意的代码写入其中,但是如图【程序把值html实体化了】:

payload 被html实体化了

payload 被html实体化了

这个地方花了很多的时间,因为把html实体化了(左右尖括号、单引号)这些都不可用,当时想了很多办法什么提前闭合返回Connection: close头部等等,但是都因为尖括号无法使用而

后来翻看以前的给SN提交的CRLF注入,发现,URL编码问题。因为其他接口调用cookie,只要恶意的cookie的值是[一次]URL编码会自动被解码。所以,最终利用URL编码绕过程序的html实体编码。

写入含有恶意攻击的cookie及值

写入含有恶意攻击的cookie及值

这里需要注意,一定要确保你写的cookie会被对方的程序会调用。(这里就需要你自己细心的查找了。)

只要诱导用户访问了下面的这个地址:

http://xxxx.SN.com/cxxxxxks?sid=16xxxx78&tid=1612xxxx0614&ap=NDxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxjM3fDB8fA==

只要访问了这个URL地址,直接会跳转到SN的首页,然后再次访问http://任何其他站点.suning.com/app/cart2/prxxxxe/shxxxxnfo.do 等其它调用此mtixxxxo cookie的时候就会中招。当然,因为直接可以301跳转,所以完全可以直接跳转到上面的那个地址。最终类似于反射XSS的payload如下:

CRLF漏洞利用最终效果图

CRLF漏洞利用最终效果图

 

 

最终说一下,首先如果有人访问了我构造好的恶意链接,然后恶意链接会复写他的cookie,当他访问任何SN的系统,只要有调用我复写恶意cookie的地方,都会触发XSS代码。而且这样神不知鬼不觉。

中招之后。。。。

xss平台已经成功收到对方信息

xss平台已经成功收到对方信息

 

对方SRC给分。

CRLF 高危 100分(利用过程详细)

CRLF 高危 100分(利用过程详细)

布施恩德可便相知重

微信扫一扫打赏

支付宝扫一扫打赏

×

给我留言