About.me suffered from a Cross Site Scripting flaw I found a few days ago. The interesting thing about this flaw is that it was cookie based. The following post details how I found it and what I did to confirm that it was exploitable, it also discusses some interesting points to consider when you find a XSS triggered by Cookie Values.
First of all some of you may have the following issues with Cookie Based XSS namely:
Having both an SSL/TLS protected version and a non TLS/SSL version of a web site means attackers can set malicious payloads via the non-protected domain and have them trigger on the protected ones, violating the trust associated to the TLS/SSL versions.
Practically the way you would do this is to set the malicious cookie for the vulnerable domain---namely the one that actually sources the malicious value in the cookie; so if the cookie is set for something like the about.me domain only, once you intercept a request and return a cookie of matching value you can override any flags associated to the cookie by abusing the Cookie Precedence rule in most browsers---the behaviour varies from browser to browser but there's almost always a way to abuse this, would make an interesting topic for study!
Also if any non-active content of the page being sourced from the TLS/SSL domain is fetched over a non-TLS/SSL channel i.e Mixed Display, this attack still applies because it allows just enough window for attackers to intercept and abuse Cookie Precedence.
So hopefully I've argued my point clearly and convinced you that it is possible to trigger this payload, especially during a MITM attack; so start your ettercap filters gentleman the pwn is on!
Here's what I saw when I started noticing the vulnerability:
The webflash cookie contains a JSON formatted message namely:
{"status":"ok","message":"[message]"}
this gets reflected in the page, here's an example:
Here's what I tried to do to trigger the attack, basically replace the "message" portion of the JSON with some juicy HTML:
to be fair I used this payload actually:
{"status":"ok","message":"<textarea onmousemove='alert(1);'>"}
And here's what about.me returned, once I reloaded the page:
It also triggered on some of the other paths:
about.me has put mitigation in place against this attack.
Why post about this?
Well purely because this payload delivery method was quite interesting and I haven't seen anything like it in a while, also the way browsers treat cookies make it quite a hard XSS to classify, is it purely a reflected XSS if the payload can be stored on client side? Do Browser based XSS filters protect against this payload?
Many other questions pop up and I thought I'd let you guys know about it in case it leads to other people asking really awesome questions; the way things go in security research is when weird instances of classic vulnerabilities are discovered it almost always causes an entire wing of infosec research to spur off and new vulnerabilities to be discovered.
There may also be some people who purely forgot about Cookie based payloads because--in my experience--they are quite rare, hopefully this post puts Cookie based XSS under the relevant category in a lot of penetration testers minds.
About Cookie Based XSS
First of all some of you may have the following issues with Cookie Based XSS namely:
- How do you trigger this payload if the Cross Origin Policy prevents malicious domains from setting cookies for other domains?
- Sure, Man in the Middle About.me but the TLS/SSL will trap your efforts, so neh!
Having both an SSL/TLS protected version and a non TLS/SSL version of a web site means attackers can set malicious payloads via the non-protected domain and have them trigger on the protected ones, violating the trust associated to the TLS/SSL versions.
Practically the way you would do this is to set the malicious cookie for the vulnerable domain---namely the one that actually sources the malicious value in the cookie; so if the cookie is set for something like the about.me domain only, once you intercept a request and return a cookie of matching value you can override any flags associated to the cookie by abusing the Cookie Precedence rule in most browsers---the behaviour varies from browser to browser but there's almost always a way to abuse this, would make an interesting topic for study!
Also if any non-active content of the page being sourced from the TLS/SSL domain is fetched over a non-TLS/SSL channel i.e Mixed Display, this attack still applies because it allows just enough window for attackers to intercept and abuse Cookie Precedence.
So hopefully I've argued my point clearly and convinced you that it is possible to trigger this payload, especially during a MITM attack; so start your ettercap filters gentleman the pwn is on!
The About.me XSS
Here's what I saw when I started noticing the vulnerability:
The webflash cookie contains a JSON formatted message namely:
{"status":"ok","message":"[message]"}
this gets reflected in the page, here's an example:
Here's what I tried to do to trigger the attack, basically replace the "message" portion of the JSON with some juicy HTML:
to be fair I used this payload actually:
{"status":"ok","message":"<textarea onmousemove='alert(1);'>"}
And here's what about.me returned, once I reloaded the page:
It also triggered on some of the other paths:
about.me has put mitigation in place against this attack.
Why would you want to trigger XSS via Cookies?
Well here are a few things that make Cookie Based XSS interesting- The payload can be stored on client side, turning the browser cache into a weapons arsenal. You can get it cached quite persistently by setting a large lifetime/expiry date for the cookie
- The payload will trigger every time a user makes a request to the vulnerable domain.
- I imagine some browser based protection won't or possibly won't be able to audit cached responses, so you may be able to evade quite a lot of protection using this method.
Comments
Post a Comment