篇幅较长,建议先收藏。
阅读时间:10min
目
录
一、故事背景
二、实战案例
1. Set-Cookie重构
危害>>> Cookie中毒-服务器错误
2. Captcha重构
危害>>> 验证码图片"变形虫"
3. Phone&SMS_code重构
危害>>> 手机号劫持&短信钓鱼
三、总结
一、故事背景
其实“重构”的名字是我自己取的,因为这些方法是在实战中探索到的。总的来说,都属于服务端逻辑设计缺陷,名字不重要。
实战案例的基础思路来源分别是
《黑客攻防技术宝典—web实战篇》中的CRLF注入剖析
key的Fuzz captcha DOS分享
"乌云"逻辑漏洞历史文章
在这些基础思路上,我创新了几种攻击思路手法。危害程度肯定是不如RCE惊天地,不如CVE泣鬼神。但谁让我这么菜呢?由于实验室的师傅们很厉害了!0day我挖不到。面对同一测试目标时,RCE会的不如他们多。信息收集又不够他们全面。身为被实验室收留的小混子选手,毫无存在感的我能做什么?苦思冥想后,就试试边缘化的东西吧。故而转向一些比较冷门的渗透技巧,希望有些作用。
二、实战案例
0x01 Set-Cookie 重构
01
第一步,漏洞场景
漏洞利用的场景发生在不太被师傅们所关心的网站中英文切换处。
(出于安全保护,我不能截全图,请不要破坏)
02
第二步,构造恶意请求数据包
1. 先看一下正常“切换English”操作时的请求和响应数据包
其实打码完特征很明显,language参数出现在三个位置。
2. 下面啰嗦分析下
分析:
<<左边Request
①Cookie中的"H-language=zh-cn",表示页面使用的是“中文”语言。
②POST主体中的"language=en-us",告诉服务器,我要切换成的语言类型。
>>右边Response
③Set-Cookie中的"H-language=en-us",服务器说,如你所愿。
3.最关键的一步,篡改上面分析的第②步数据包参数,"language=en-us"改成"language=en-usN10th",中毒的Cookie都用N10th的作为标识。
发送后,我们看一下响应的数据包。
Set-Cookie被重构,很简单,至此完成恶意数据包请求。
03
第三步,多端验证POC
如果只是重构,不能造成危害,那有什么用。
POC:
松开放行上面步骤的数据包后,会发现页面提示服务器错误。此时我们可以查看本地的Cookie值为"en-usN10th",OK,成功缓存使Cookie中毒。
我们再使用pc端其它浏览器、ios端Safari浏览器等任意平台,去访问URI。同样都是直接爆出服务器错误。
这里要注意的一点,如果你用某浏览器打开过正常页面,则正常的cookie会缓存到本地,在cookie未过期的时间内,是不受影响。只有第一次打开此页面,或深度清缓存cookie数据等方法也可以。
移动端推荐使用via浏览器验证,设置每次退出后,清除所有数据缓存。
危害就是,一个HTTP请求就能让当前域下所有的业务功能拒绝服务。
注意,我说的是当前域,而不是服务器。所以如果这台服务器的http://1.1.1.1/被攻击而拒绝服务了,但不代表http://1.1.1.1:8000/受影响。
因为是服务端代码重构漏洞,不要忘记帮别人更改回来。包括下面的captcha重构。那如何更改回来呢?只需要重新发送一次正常的数据包请求。
(1)本地手动更改cookie为正常值,再找到切换语言处。
(2)正常点击一次中/英文,重新重构Set-Cookie。服务端逻辑即可恢复正常。
0x02 Captcha 重构
01
思路来源
key分享过captcha dos攻击,即验证码DOS攻击。可造成服务器资源耗尽,CPU飙升情况。网上有很多文章,Google搜一下”验证码DOS“,会有很多案例。所以不再仔细介绍。
(知道有的人懒,贴两个网上搜的案例,不懂地快速了解下)
https://www.jianshu.com/p/bc51fc289183
http://www.aiyuanzhen.com/index.php/archives/69/
(图片来源网上验证码DOS案例)
本文介绍的Captcha重构的漏洞,利用方法跟验证码DOS的一模一样,但不同的是,最终关注的危害结果。
(ps:下面的内容是在你了解怎么使用验证码DOS攻击后再看的)
02
验证码变形虫
开始复现
**场景1:变大消失验证码字符
**
①测试中碰到的一个带有验证码登录页面——打开验证码URL
②Fuzz出验证码的宽和高等参数名——发送类似"width=4000&height=4000"请求——服务器慢悠悠的返回一个超大的验证码图片。
至此很多师傅发现验证码图片的大小可控,就会去进行DOS攻击,但实际上我们可能已经重构了服务端captcha验证码的生成逻辑。
③回到前端刷新,验证码已经因为变得巨大,而让字符看起来消失了。
场景2:变小消失验证码图片
既然图片可变大,那也可变小。
看另一个案例,首先打开正常页面,找出验证码获取接口。
这里设置width=1&height=1。仔细看会有一个亮点,即1pix。
回到前端,刷新验证码。
**场景3:变化功能成失效
**
某又一次测试中,遇到过不仅能改变宽高像素,还能控制参数n来决定验证码字符数量。
当时我将n修改为0,此时回到前端刷新验证码。
这时候,其实服务端验证码就已经失效了,因为验证码字符数=0,即无需验证。但由于前端策略限制,我们需要先任意输入一个1作为占位符,然后抓包删除,就可以无限次爆破了。验证码功能宣布失效。
03
小结
小结一下,验证码变形虫三种危害场景:变大变小能干扰业务;变化功能可失效。
最后提醒一句,服务端captcha逻辑被你重构了,别忘了给人家改回来。
**0x03 SMS_Code_ 重构
**_
利用重放攻击,造成的短信轰炸漏洞,已经是众所周知了。但其实这个接口还可能劫持任意手机号进行恶意注册登录、重置他人密码,还可能进行短信验证码钓鱼你知道吗?话不多说,实战。
01
攻击手法1——手机号劫持
这种攻击手法,我在实战中碰到过的很多次利用场景。
实战案例复现:
①在注册登录或修改密码处,寻找发送短信验证码功能的接口
②抓包修改phone的参数值为"phone=手机号1,手机号2"
③即可让手机号卡1和手机号卡2获取到相同的验证码。
此漏洞一旦存在,危害巨大,可任意重置他人密码,任意手机号注册登录。
简单至极的技巧,仅仅是在原有手机号1后,添加一个逗号和手机号2。
但,你能发现吗?
02
攻击手法2——短信验证码钓鱼
这是在上面的思路基础上,无意中拓展的思路。
实战案例复现:
①还是在注册登录或修改密码处,寻找发送短信验证码功能的接口
②抓包——寻找phone的参数位置——修改为"phonNum=手机号1,手机号2",注意看这里的手机号2我们写的是187xxxxxxxx。
③我们看一下收到的短信
第一条是一个正常的短信
第二条短信是,"phonNum=手机号1,手机号2"参数里逗号后的内容,即手机号2"187xxxxxxxx"当作短信验证码内容,向手机号1发过来了!!
立即想到短信验证码可控,思路变成"phonNum=手机号,短信验证码"。
我知道你在想什么,是不是直接能给管理员手机号发我控制的验证码内容,然后直接用这个验证码登录管理员账户。岂不是高危了。
但,后来发现,并不能登录。
...
......
思绪到这就断了,风险程度又降到低危。
后来想到,既然不能可控的验证码无法登录,那就打组合拳来提升危害程度。
④钓鱼创新思路
果然可以收到短信
仔细看这是一个超链,可以打开后跳转淘宝首页成功。
再想想,如果我们构造的这个链接,是一个钓鱼链接,受害者打开后让他输入账号密码,从而达到钓鱼窃密。又或者是一个下载恶意软件的链接。
其实到这就已经可以向用户手机发送可控的短信钓鱼了,但我还不满足。如果不知道哪些手机号注册了,难道瞎发么?
继续找脆弱点,发现回显提示。
那接下来,继续打组合拳。我们就可以通过该接口,写个脚本简单遍历出该平台注册的手机号,再发送钓鱼短信。
OK,当遍历出存在的手机号时,我们发送一个钓鱼URI链接。
如果只是简单的短信轰炸,顶多造成资源消耗,但如果结合用户遍历+钓鱼攻击的手法,危害就提升了两个度。
03
小结
在传统的短信轰炸上,增加了两种攻击手法:手机号劫持和短信验证码钓鱼。其实这些思路,都是在我看完了乌云上所有的逻辑漏洞文章后,自己在实战中和探索到的。我把它称之为Phone&SMS_code重构。这个漏洞的逻辑缺陷,不像上面两个案例一样的持续性重构,我把它称之为一次性重构。
针对攻击手法1——手机号劫持,除了在短信发送的接口添加逗号+手机号2外,还可以尝试phone=[phone1,phone2]这种方法。
针对攻击手法2——短信钓鱼,除了在短信发送的接口添加逗号+钓鱼URL外,还可以尝试phone=phone1&sms_text=111111,补齐参数这种方法。
好了,思路被榨干了...
要去自闭一段时间了,什么时候回来
或许9号,或许19号,或许29号。
0x04 总结
或许身处黑暗,或许面目狰狞,还会被人看作狡黠阴暗。但无论网络世界有多邪恶,请不要忘记,白帽子的心里依然充满阳光。九号N10th。
END
技术研究总是孤独的
边缘化的东西更是如此
一个只专注于冷门渗透技巧
研究灰黑产的暗侍卫
——冷渗透