Real world exploitation of a misconfigured crossdomain.xml
As we all know, sometimes the best way to wrap your head around a vulnerability is to see it being exploited. Rather than continuing to talk about the vulnerability in theoretical terms, I can now start to share some specific examples.
If the victim user is authenticated with any live.com linked account (msn, outlook, etc), and they visit a malicious site, the owner of the malicious site can retrieve the victim user’s entire search history, including the sites they visited by way of the search engine.
The vulnerable configuration (fixed now):
Proof of Concept
Note: In the proof of concept, I show the attack from the perspective of the victim. Unlike a real exploitation, the "victim" is going through Burp to illustrate what is going on behind the scenes.
Prerequisite: The victim is currently authenticated with msn.com, live.com, bing.com, etc. This is a screenshot of the victim logged in and viewing the information that we (the attacker) are going to steal. The victim does not need to be on this particular page for the attack to work.
Step 1: Attacker hosts a malicious SWF on his/her server, and socially engineers a victim to arrive at the attacker’s site.
Step 2: The victim, while logged into msn.com, live.com, bing.com, etc, loads the malicious html page:
As you can see, the POC html page just instructs the victim's browser to execute the SWF file.
Step 3: The victims browser downloads and loads the SWF
At this point, the exploitation is over from the perspective of the victim. Let's switch to the attacker's perspective, and look at the stolen data.
Here is the data collector script on the attacker's server:
As I mentioned in my previous post, this php file takes the entire data portion of the incoming HTTP message and writes it to a file in /tmp. You can get a lot fancier with this, such as creating a separate file per victim, or by parsing the file within php and only writing the relevant information to disk, but this was sufficient for the POC that I sent to Microsoft.
Step 7: The attacker can now parse the stolen data. The command just parses out the search queries from the source code of the stolen page. What is shown is basically the last 10 or so things I searched for on my Microsoft Surface.
root@kali:/var/www# cat /tmp/bing.txt | xmllint --format - | grep "sh_item_qu_query"
This next command does the same thing, but it extracts the URL's that I visited as a result of my bing searches:
root@kali:/var/www# cat /tmp/bing.txt | xmllint --format - | grep "sh_item_cl_url"
The malicious SWF could have easily made multiple requests, walking back the timestamp each time, essentially downloading everything the victim has ever searched for on Bing.com.
If you look closely at the very first picture in the POC, you will notice that victim was viewing https://ssl.bing.com/profile/history. You should also notice that the exploit SWF requests the sensitive data from https://www.bing.com/profile/history. This is where I got lucky.
I *think* the developers made the following assumption:
- When a user is authenticated, we send them to ssl.bing.com, and that crossdomain.xml does not exist, so all is good.
- When a user is unauthenticated, we send them to www.bing.com. Even though we have a very permissive crossdomain.xml, only unauthenticated users will use this part of the site, so no sensitive information can be stolen via Flash.
So really, I was only able to really exploit the overly permissive crossdomain.xml file and gain access to the sensitive information because the application sent the sensitive history information to authenticated users, even when they requested the data from www.bing.com/profile/history. If Bing told authenticated users to use ssl.bing.com/profile/history or get lost, I would not have had a very exciting demo.
Questions? Concerns? Leave me a note in the comments!
Gloss