GitHub Pages zero day with wildcard subdomains allows anyone to publish on your site

By William Entriken

3 minutes

Summary

Domains that use a wildcard subdomain to point (using CNAME or A records) to GitHub Pages allow anybody to host websites there. This could lead to serious problems such as phishing, malicious software downloads and damaging their brand.

We demonstrate this by publishing 20 subdomain websites to the most popular websites and explain how others could exploit this.

Recommendations are given to the owners of these websites and to GitHub Pages administrators.

Proof of concept

We launched these websites to show what is possible:

Other notes

Through this vulnerability, anyone can create a website and make it look like it was coming from you. Malicious hackers can perform illegal activity via this subdomain, and make it appear as if the owner of this domain was responsible for this, or, at least tarnish the domain owner’s reputation.

Right now, somebody could publish a page on your domain name, like login. api. password-reset. and make it look just like your website. They could:

Most websites do not want this type of subdomain freedom, however some sites like Wikia, GitHub pages, and Blogspot use this technique to give people their own sites, however this is closely monitored for any of the activity mentioned above.

Recommendations for domain owners

You will need to login to your domain name registrar to fix this problem.

GitHub Pages warns that:

Warning: We strongly recommend not using wildcard DNS records, such as *.example.com. A wildcard DNS record will allow anyone to host a site at one of your subdomains.

And also:

In all cases, you probably want to delete the wildcard record (“*”) that points to GitHub Pages urls—185.199.108.153, 185.199.109.153, 185.199.110.153, 185.199.111.153.

Then some of this advice might apply to you:

Recommendations for GitHub Pages

The most secure fix would be to verify domain ownership by using a TXT record before publishing sites. This also prevents domain frontrunning, separate attack not discussed here.

Because domain verification slows down the most common scenario it might be not desirable.

At a minimum, consider to resolve some random subdomain for Pages websites, this will show you if there is a problem. You could then warn customers if there is a problem and/or include a required “confirm” button to acknowledge the risk.

Tools used to discover bug

Thank you to Majestic for providing the Majestic Million list of websites. We used this as a starting point for checking for vulnerable sites.

A basic check for vulnerability is done with:

dig +noall +answer foobar-ploople-boopersnoot.example.com

Where foobar-ploople-boopersnoot is some random text.

This can be run in batch by selecting the domain name column, prepending the random text, into a flat file and running:

cat domains | xargs -P 100 – dig +noall +answer | tee -a fpb

⚠️ Warning, this will simultaneously look up one million DNS queries across 100 threads at full blast. Your ISP might not like this. Verizon FiOS banned me from using DNS about halfway through the list.

Total search time is less than an hour on one machine.

⚠️ Consider using a VPN (including passthrough DNS) for any project like this :-)

Disclosure schedule

Acknowledgements

Thank you to the many contributors here for preparing command line approaches, looking up contact information, discussing the ethical approach we are using here and providing the motivation to get through an afternoon to help some random other souls out there who’s websites might be misconfigured.

▧

Comments

There are no comments yet.

Please discuss this topic anywhere and let me know any great comments or media coverage I should link here.