Subdomain takeover of sumo-cdn.prod.mozaws.net

RESOLVED FIXED

Status

Websites
Other
RESOLVED FIXED
2 years ago
a year ago

People

(Reporter: arneswinnen, Assigned: jason)

Tracking

({sec-low, wsec-impersonation})

unspecified
sec-low, wsec-impersonation
Bug Flags:
sec-bounty +

Details

(Whiteboard: [reporter-external] [web-bounty-form] [verif?], URL)

Attachments

(2 attachments)

(Reporter)

Description

2 years ago
Note: Highly similar to earlier report https://bugzilla.mozilla.org/show_bug.cgi?id=1304736 & https://bugzilla.mozilla.org/show_bug.cgi?id=1305450

Your online asset sumo-cdn.prod.mozaws.net still had a DNS A entry pointing to an Amazon Cloudfront CDN server, but it was not registered there anymore. This allowed anyone (and luckily in this case, me :-) to claim this domain and start serving content for it via Cloudfront. It is currently serving one of my S3 buckets, e.g. http://subdomaintakeover.s3.amazonaws.com/index.html is equal to http://sumo-cdn.prod.mozaws.net/index.html . The impact is two-fold:

- The subdomain takeover of the HTTP version allows me to acquire a valid SSL certificate for it, and thus upgrade it to an HTTPS subdomain takeover. Many Certificate Authorities support automated domain verification through hosting a specific HTML file in the root directory of a (sub)domain (e.g. Lets Encrypt, GoDaddy, Comodo, ...). Since the subdomain takeover yields the attacker complete control over the webserver serving the subdomain, this would be trivial. This was not actually performed as a PoC to not upset you by generating a malicious SSL certificate for your domain, but feel free to give me a heads up if you are not convinced and would like me to actually proceed with this attack scenario. I have done this before, it's only 1 command with Let's Encrypt. The certificate could be used in Man-in-the-Middle attacks, and to contribute to the point below.

- Stealthy impersonation of Firefox. An attacker could start hosting convincing phishing pages asking for sensitive information of customers, such as credentials. Due to the mozaws.net Top-level domain and the https:// in the URL bar (see point above), this would most likely be very effective against existing Mozilla users. An attacker can leverage the usual web technologies to convince victims: HTML, JavaScript, Plugins, ..., so one could also see it as a Cross-site Scripting issue on a Mozilla-owned asset. Additionally, an attacker could also use it to negatively affected Mozilla's reputation, e.g. by hosting questionable content and spreading this on the internet (e.g. malware) or going directly to the press. 

The subdomain "sumo-cdn.prod.mozaws.net" was (and still is) an A record pointing to an Cloudfront CDN server (depending on your location, the latter will resolve differently):

# nslookup sumo-cdn.prod.mozaws.net 8.8.8.8
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	sumo-cdn.prod.mozaws.net
Address: 54.192.98.102
Name:	sumo-cdn.prod.mozaws.net
Address: 54.192.98.247
Name:	sumo-cdn.prod.mozaws.net
Address: 54.192.98.245
Name:	sumo-cdn.prod.mozaws.net
Address: 54.192.98.47
Name:	sumo-cdn.prod.mozaws.net
Address: 54.192.98.101
Name:	sumo-cdn.prod.mozaws.net
Address: 54.192.98.106
Name:	sumo-cdn.prod.mozaws.net
Address: 54.192.98.6
Name:	sumo-cdn.prod.mozaws.net
Address: 54.192.98.142

However, the hostname "sumo-cdn.prod.mozaws.net" was not claimed anymore on Cloudfront, resulting in a Cloudfront error page when visiting the subdomain before the takeover (see screenshot "1. Before takeover.png"). Subsequently, a new Amazon Cloudfront CDN endpoint was created and linked to an attacker-controlled origin server (http://subdomaintakeover.s3.amazonaws.com). For the new Cloudfront CDN endpoint, "sumo-cdn.prod.mozaws.net" was designated as hostname successfully. This concluded the subdomain takeover (see screenshot "2. After takeover.png"). URL: http://sumo-cdn.prod.mozaws.net/index.html

The root cause of the vulnerability is the dangling A record pointer to Cloudfront from the affected subdomain. It is advised to remove the DNS A pointer from sumo-cdn.prod.mozaws.net to the Cloudfront CDN server. This will mitigate the root cause vulnerability. If you are interested in keeping the subdomain on the Cloudfront CDN, I'll have to release it first before you can reclaim it. In that case, just let me know.
 
Regards,

Arne Swinnen
https://www.arneswinnen.net
Flags: sec-bounty?
(Reporter)

Comment 1

2 years ago
Created attachment 8796278 [details]
1. Before takeover.png
(Reporter)

Comment 2

2 years ago
Created attachment 8796279 [details]
2. After takeover.png
:jason - Could you help us with this one?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(jthomas)
Keywords: sec-low, wsec-impersonation
Would is also be possible to have an audit done of cloud service domains for this particular issue on common domains (GitHub Pages, Heroku, Akamai, Edgecast, etc.) so we can sort these out all at once?
Arne: many thanks for the submission, we're getting the right people involved to sort this out.  Thanks!
Assignee: nobody → jthomas
(Assignee)

Comment 6

2 years ago
sumo-cdn.prod.mozaws.net is valid and currently in use. Arne can you release it so that we can add it to our cloudfront account?
Flags: needinfo?(jthomas)
(Reporter)

Comment 7

2 years ago
Hi,

I've just released it, it should become available for you anytime soon.

Arne
(Assignee)

Comment 8

2 years ago
sumo-cdn.prod.mozaws.net is now configured as an Alias in our Cloudfront account.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
Group: websites-security
See Also: → bug 1304785
bounty covered in bug 1304785
Flags: sec-bounty? → sec-bounty-
Flags: sec-bounty- → sec-bounty?

Updated

2 years ago
Flags: sec-bounty? → sec-bounty+
You need to log in before you can comment on or make changes to this bug.