Oops. People pay a lot of money to MarkMonitor because their promise is to not make such mistakes.

When I was a customer, screwing up a parking page isn't the kind of mistake my employer was paying them not to make. My employer was paying them not to let outside groups change our domain's DNS settings.

But that was for domains we were actively using. I don't even remember if we had a parking page on the domains we only had to sit on; if we did, while it wouldn't have been great, it also wouldn't have been a big deal for them to show something attacker controlled for a little while. Parked domains weren't in active use, didn't have links going to them, and probably shouldn't seem credible to others.

I think we might have set up the parked domains to just redirect to our main website, but yeah.

it also wouldn't have been a big deal for them to show something attacker controlled for a little while

This is understating the risk. If an attacker obtains control over a website for even a brief period of time, they can go to a certificate authority and obtain a domain validation for the domain (including all subdomains) that's valid for one year. At the end of that year, they can use the domain validation to obtain an SSL certificate that's valid for up to one year, even if they no longer control the website. This means that following a brief takeover, the domain continues to be vulnerable to attack for two years, which would be a problem if a parked domain is transitioned to active use during that time.

Nowadays a bit lessened by CT logs, so you (or MM) can at least notice and cause the cert to be revoked.

Yes, although the attacker can defer logging the certificate to CT until the moment before the certificate is used in an attack, so you would not have much time to respond.

How? The CA submits records (precertificates) to the logs before it signs the cert.

Precertificates are optional. Alternatively, the CA can skip creating a precertificate. The certificate would not contain any embedded SCTs. Instead, the certificate is logged using the add-chain endpoint[1], and the returned SCTs are delivered via an extension to the TLS handshake or an extension in a stapled OCSP response[2]

[1] https://datatracker.ietf.org/doc/html/rfc6962#section-4.1

[2] https://datatracker.ietf.org/doc/html/rfc6962#section-3.3

Logging is not a policy requirement of the trust stores.

It's a condition for your certificates to work in some popular browsers (notably Chrome and Safari) but not a policy requirement.

This is on purpose. Google themselves for example will get a certificate issued, say, today, for shiny-new-google-product.example and then only at the last moment do they log that certificate when spinning up the web site https://shiny-new-google-product.example/ to launch shiny-new-google-product -- you can't find out about it in the CT logs because it wasn't in there earlier.

Now, the readily available and especially free certificates most people use are logged before issuance as you describe using the poisoned "pre-certificate" feature from RFC 6962 (in theory this will one day be replaced by a 6962bis actual pre-certificate document rather than poisoned X.509 certs) but that is not at all mandatory, it's just convenient because it requires no workflow changes. You get a certificate, it's a bit bigger (it has SCTs baked inside it) and it just works.

If you do things the hard way, you must ensure your server application software understands what SCTs are and can send them to clients as necessary. You save some bytes talking to clients that don't want the SCTs, and you get to have this just-in-time logging behaviour if you want that.

The other reason it isn't against policy to issue without logging is that some archaic systems that are subject the Web PKI rules but aren't actually talking to the public Internet, and especially to web browsers, do not have logging, it's not a thing for them. This will probably go away in the next few years, these systems age out, but they still existed when I last looked.

thanks for the context, that pretty much answered all my follow-up questions. :)

The "weird old systems" case sounds like something were maybe it could be required for DV-certs?

At the end of that year, they can use the domain validation to obtain an SSL certificate that's valid for up to one year, even if they no longer control the website.

Can you explain this further? I don't understand.

Are you saying they could MITM the request that the CA makes to the website when it tries to do domain valudation? If that's the case, why is it limited to 2 years? Why couldn't they continue to do this indefinitely?

So if I understand the issue correctly, MarkMonitor pointed all of those domains to S3, without first creating S3 buckets for the domains in question?

Yes, they first pointed them to S3, then created the parked domain page for each of them. There was a window where anyone could have claimed the bucket.

And ultimately they still own the domains and can always point them to a new IP address at any time. The window for exploitation seems kind of small and temporary.

The window for exploitation seems kind of small and temporary.

That depends on whether you are attacking the clients or the server. If an attacker obtained a domain cert or wildcard cert, while in control of the domain, then the attacks can continue.

How? They now have a cert for that domain but the domain owner can point the domain to any IP address he wants. The article mentions this, but I don’t see the vuln. Can you explain?

MITM

I think we are going to need a little bit more. How does the attacker get traffic to route to them?

DNS is very easy to spoof and redirect. There are proposals to secure it (DNSSEC, DNS-over-TLS, DNS-over-HTTPS) but none are widely used and instead the server's certificates are used to both authenticate the correct destination and encrypt traffic to it.

Redirecting traffic is much easier than generating certificates so a valid cert held by a bad actor can be a serious vulnerability.

Agreed. The title is misleading...there were no domains 'taken', which would imply a change of ownership, especially in the context of a registrar.

'for the taking', ie: they were vulnerable to a domain takeover. The title is entirely accurate. They didn't say they were 'taken'.

Good point, I can see that perspective. I guess I should have used 'ambiguous' instead of misleading. My first thought, with current wording, is that they were allowing transfers out or letting domains expire. Perhaps I spent too much time in the registry business.

This should be something added to an AWS Security Hub check, e.g. do you have Route53 pointed to an unregistered domain. Otherwise, I can't find fault with AWS at all. Now I have to review our domains on Monday.

Please bug your TAM if you have one about this. I’ve bugged ours. S3 should not serve a bucket as a website without domain verification. In the interim, we’ve built middleware where a bucket serving content can’t be removed until the dns record has been.

Or use CloudFront with an S3 bucket as backing for this use case, like you'd expect? CloudFront has domain name verification.

The point is that without domain verification, it won't stop someone else from registering that bucket (which is what happened with the domains in this article).

The point is that S3 isn't a CDN. If you use it as a CDN, it's on you to ensure it'll work for your use case. CloudFront, however, is a CDN, and as expected, has domain verification.

Whether it's a CDN is irrelevant. This is already a supported use-case for S3 which is why it even has this functionality.

It's one of many products that supports serving under custom hostnames and all such products should have domain verification.

I hear about subdomain takeovers with S3 all the time. It seems insane Amazon doesn't require any domain verification.

What do they require? You can just claim any S3 bucket you want that's been 'abandoned'?

No, S3 buckets named after hostnames are served when said hostname is pointing to S3 servers .

Bob owns bob.com and sets CNAME bob.com.us-east-1.amazonaws.com. Eve creates the bucket and can now serve any static content she wants.

Maybe Bob shouldn't have set cname bob.com.us-east-1.amazonaws.com if he didn't own the bucket?!

That seems pretty reasonable to me. How should AWS verify domain ownership if not control over the CNAME?

it doesn't verify control over the CNAME from the person creating the bucket, that's the criticism, instead it lets any AWS user claim it. (The usual verification method would be something like requiring a TXT record to be set with a secret that's tied to the bucket, and I guess for route53 users they could integrate settings from there)

Right, but the owner of the domain needs to create a CNAME record that points to AWS for a bucket they don't control. How is that not purely on them?

The bucket can be created before they can do so, which is exactly what happened to MarkMonitor here. Now, technically you could create the bucket first before setting the CNAME, but this can quickly go wrong (especially when handling hundreds of domains) and it regularly does. There's no need to keep this footgun around.

Google provides several options for site verification. They provide a string you must place on your website using one of the following ways:

- DNS TXT record

- HTML meta tag

- Upload a file with a randomized name to your site root

This is the reverse situation. What's going on here:

- Bob makes bob.com and sets the CNAME to be bobstaticsite.s3.aws

- Bob forgot to make a bucket called bobstaticsite.s3, and Alice, scanning the DNS records, creates it instead. Now Alice is serving data on Bob's domain

Am I missing something? How would AWS S3 stop you from creating a CNAME? Or how is this their responsibility? Don't make that CNAME entry pointing to a bucket you didn't create yet / don't own?

One final thing: S3 is not CloudFront. And CloudFront, AWS's CDN, does require domain name verification.

AWS can't stop you from creating the CNAME, but AWS could stop Alice from creating the bucket, or (IMHO better) not serve HTTP(S) traffic for bob.com from that bucket unless it is confirmed that the bucket belongs to the owner of bob.com.

Could Eve then just register bob.com and point it to bob's random bucket to mess with him?

And shouldn't Alice be able to register Alice.com and point it at Bob's bucket if she feels like it?

It seems like the answer already exists: don't create CNAMEs haphazardly.

(But please explain it to me if I'm missing something here)

Amazon can't "know" out of all domains if one has a CNAME pointing to a bucket name though. Even if they did, that would be open to abuse by anyone.

Am I missing something? How would AWS S3 stop you from creating a CNAME? Or how is this their responsibility?

They (AWS) should not accept traffic on that hostname until ownership - tightly bound - is proven.

This also helps avoid related cases, such as deleting a bucket (which now frees it up) - other services like Heroku have similarly been vulnerable to this takeover hack because of a lack of strict verification: https://0xpatrik.com/subdomain-takeover-providers/

Every new bucket, service or account handling traffic for a domain should require re-verification. That verification should never persist beyond the lifetime of that resource.

They (AWS) should not accept traffic on that hostname until ownership - tightly bound - is proven.

Why shouldn't they ? Don't you think it can be a useful feature ?

If they cared, a reasonable choice would be to lean on the Web PKI. It is usual in the Web PKI for the leaf certificates to be certified both to identify a server (which is what is ordinarily done) and to identify a client. The only name usually provided for the subject is a DNS name, but in this case that's exactly the identity we want to prove.

That is, you'd prove you control www.example.com to AWS the exact same way www.example.com proves it is www.example.com to a web browser.

If you control the cname its trivial to get a cert.

What's the method of attack here? Bob at some point stops using the site and deletes the bucket but not the DNS entry, and you notice that and create a new bucket with that now-available name?

No

This company never created the S3 buckets at all but set them in the CNAME, for domains that were purchased but never used

They can change the CNAME at any time, it’s a pretty dumb but inconsequential exploit. Potentially some purchaser didn’t use generally free and default whois privacy and could be associated with offbrand content.

Potentially someone observant can earn a bunch of ad dollars on a popular domain.

This feels like a typical "why we can't have nice things"-scenario. You're in control of DNS. You decided to create the DNS-record to point to S3. It's a little odd to then come complaining when Amazon does what you wanted it to do.

A fun exercise could be to boot up a machine on pretty much any cloud provider and set up a simple webserver to respond to all Host-headers. Heck, I'm pretty sure you could make nginx only respond requests where both the Host-header and A/AAAA-record were correct with some Lua magic. In this scenario, would you blame the cloud provider or the administrator of the domain?

(Not necessarily you-you, but you get he idea.)

I found a similar issue in a huge, very popular site. Thousands of root domains ripe for the taking. I sent a heads up to the company in question, but never got a reply--

Have they fixed the issue?

I think it's the issue with mark monitor and not s3/aws.

What if mark monitor would put all parked domains to bob.com.mys3.com service? Me, as mys3 provider I'm at fault? I doubt.

What if mark monitor would point to an IP address they don't own? Still not their fault?

While many domains began responding with an S3 404, others began switching from S3 to the parked page. What is interesting is that DNS was not involved — all domains pointed to 93.191.168.52 both before and after the issue.

I don't get this. These domains weren't configured with CNAME DNS entries like one normally does. Does this mean MarkMonitor's parked domain name server was trying to load from S3, then falling back to something else if that failed?

I suspect what happened (as the author of the post) is that given the IP address is from Akamai, they misconfigured Akamai to naively proxy the traffic towards S3.

S3 will just pick a bucket based on the Host header in the request, and it seems like Akamai just proxied that from the client.

They should be using cloudfront to serve those pages over https.

This is satire, right?

Can someone explain how a subdomain takeover is done in layman terms?

Subdomain points to a hosting provider. Hosting doesn’t know who the owner is (yet) and waits for someone to sign up/register. Attacker signs up before the real owner does, is lucky that the hosting provider does not verify ownership, and is able to serve whatever they want on the domain, for example a fake website or fake verification files.

What does the OP's "S3 detection" mean in this context?

I'm not clear how the list of vulnerable domains was collected in this instance - presumably he had to know which domains to create buckets for?