Hijacking of abandoned subdomains part 2

TL;DR: Other ways to do a complete subdomain takeover. MSN is vulnerable to this as per below. As we’ve said before, check and validate all your DNS Resource Records immediately.

After our previous blog advisory about the subdomain takeover, we were contacted by Szymon Gruszecki, an independent security researcher and a frequent reporter in the Facebook White Hat Bug Bounty. Kickstarted by our advisory, he got in touch with us explaining a different method, together with a live PoC.

 What Szymon wrote

Regarding your recent blog post I wanted to add that last year performed a scan on top 5000 domain names from Alexa global rank and discovered 49 subdomains of different domains (that is ~1% of all ones) that point in CNAME records to not registered, forgotten domains or their subdomains. So in this case if you want to own not used subdomain just simply buy an expired domain name and configure its DNS zone.

And here is a small PoC. Yesterday after your post reading I decided finally to publish owned-like message on one of forgotten subdomains of The Microsoft Network, racing.msn.com. Take a look at http://racing.msn.com (Archived version:http://web.archive.org/web/20141022215330/http://racing.msn.com/ )

The takeover of a Microsoft subdomain

PoC-image of racing.msn.com:

Since the registration of msnbrickyardsweeps.com has expired, he could buy it and suddenly racing.msn.com starts showing his content since racing.msn.com has a CNAME record pointing to msnbrickyardsweeps.com.

Email will listen to CNAME records

MX-records are fetched from the CNAME, so racing.msn.com gets the same MX-records as msnbrickyardsweeps.com. Now you could set up email accounts with @racing.msn.com, and receive all emails sent to this domain, you can use the hostmaster, postmaster, admin, administrator or webmaster email addresses to create a SSL-certificate on this subdomain.

Creating a msn.com SSL-certificate

A visitor would not be able to validate that the domain is in fact not a real msn.com-page, making a potential phishing attack using a subdomain easy and dangerous. 100% foolproof. It is now possible to generate SSL-certificates for a msn.com-domain and you’re able to fetch potential secure-cookies which are only sent over HTTPS, as well as httpOnly-cookies.

Control of both client and server

Stealing secure-cookies is possible since we control both the server-side and client-side of this domain. Some endpoints in the msn.com-network could also be restricted using SOP or cross domain-policies to only allow connections between *.msn.com domains which in this case would’ve been completely valid.

Is it really “hacking”?

In the above example, MSN hasn’t been hacked even though it looks that way. They have just pointed a subdomain to Szymon’s domain using a CNAME-record. However, imagine the case where it wasn’t a researcher doing this – but rather someone aiming to steal credentials. Microsoft has already been notified about this issue, and will probably remove this CNAME-entry any time soon.

Other scenarios

It’s not only CNAME entries that can be vulnerable to this, other records can also be used, such as DNAME and NS. Szymon created a table showing what happens using certain DNS-entries (Resource Records) and what data that can be inherited across domains. These may be obvious, however for the record:

• CNAME defines an alias for another domain. The alias should be verified by the receiving party.
• DNAME is a little bit similar to CNAME, but defines an alias for all higher-level names of a domain name (a kind of delegation).
• NS allows for a delegation the entire subdomain to another DNS zone.
• MX defines a mail server responsible for accepting emails. Although MX can’t be used to takeover a subdomain as shown previously, it’s still possible to takeover the email handling and create SSL-certificates for a MITM-attack (Man-in-the-Middle). What’s interesting here is also, as mentioned in the RFC, if an MX-record does not exist, the A/AAAA-record will be used instead.

Finally, Szymon also showed us examples where people have mistyped the RR’s data instead of typing in “www.example.com”, writing “wwwexample.com”, where somebody could just buy the wwwexample.com domain.

In conclusion, even though the administration of DNS record is a hassle by itself, the Resource Records needs to be constantly validated and checked. Not only for unused services, but for typos and/or misconfigurations.