Thousands of Unused WordPress Domains Vulnerable to Takeover

There are thousands (Over 14,000 at the time of writing this) of top-level domains which can be used by anyone to host any content they'd like. These domains are pointing to WordPress.com, but don't have an account registered.

The Issue

Subdomain takeover is a well-worn technique popular with bug bounty hunters. Microsoft describes this issue as a "high-severity threat" which "enable[s] malicious actors to redirect traffic intended for an organization’s domain to a site performing malicious activity."

This problem isn't limited to just subdomains. Several providers allow their customers to use a custom domain for hosted content. WordPress is one of these providers.

WordPress.com provides their users with the ability to connect an existing domain to their WordPress site instead of using a WordPress subdomain. For example: instead of o565.wordpress.com, I could use the custom domain o565.com.

WordPress provides instructions which describe how to use a custom domain:

1. First, attach your domain to your WordPress.com site.
2. Update your domain’s “name servers” to point to WordPress.com. <- In most cases, this looks like the only step completed for these vulnerable domains.
3. Set your connected domain as the primary site address.

Finding the vulnerable domains

Finding these unclaimed WordPress instances is simple.

Disclaimer: I tested the takeover process using a domain I owned. I didn't attempt a takeover for any other domain discovered.

1. Gather a list of domains that use ns#.wordpress.com as a name server (# being 01, 02, ...).

2. Visit the domain. Look for text (xxx.wordpress.com doesn't exist). This tells us that the account the domain points to is unclaimed.

Here's a simple script that does some of this work for us:

#!/bin/bash

# randomize domain list
domains=$(sort -R ./domains.txt)
for domain in $domains
do
  echo "[.] Checking $domain..."
  result=$(curl -LsI -m 5 -o /dev/null -w %{url_effective} $domain)
  if [[ "$result" == "https://wordpress.com/typo/?subdomain="* ]]; then
      echo "[!] VULNERABLE ($domain)"
  fi
done

3. Complete the takeover by registering the subdomain.
 - Click "Do you want to register"
 - Sign up for a wordpress.com account
 - Build your site
 - Publish (Go Live)
 - ???

Reporting

This was reported to Automaticc via their HackerOne page. Because this is a known issue, it was closed as a duplicate.

Potential Mitigations

I realize that *.wordpress.com domains are configured by end users and that this issue doesn't fit into the normal scope of vulnerability/bug bounty programs. In short, users configure their domain with WordPress name servers, don't complete the configuration, and this issue manifests.

WordPress does a good job restricting what their free tiers can do. The free tier restricts JavaScript, can't configure redirection, can't use custom plugins, etc. The requirement to pay for WordPress to get these features makes this less attractive for some attacks. With that said, I imagine a couple of possible additional solutions to this issue:

1. Have users prove ownership of a domain before associating a domain with a wordpress subdomain. Google relies on DNS TXT records as one method to validate domain ownership.
2. Require additional post configuration (in addition to WordPress nameservers) before associating a domain with a subdomain.

That's it! Thank you.

Supporting Material/References:

GitHub - EdOverflow/can-i-take-over-xyz: “Can I take over XYZ?” — a list of services and how to claim (sub)domains with dangling DNS records.

&quot;Can I take over XYZ?&quot; — a list of services and how to claim (sub)domains with dangling DNS records. - GitHub - EdOverflow/can-i-take-over-xyz: &quot;Can I take over XYZ?&quot; — a list o...

GitHubEdOverflow