篇幅较长，建议先收藏。
阅读时间：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
技术研究总是孤独的
边缘化的东西更是如此
一个只专注于冷门渗透技巧
研究灰黑产的暗侍卫
——冷渗透
