8 ms·
What do they require? You can just claim any S3 bucket you want that's been 'abandoned'?
by tyingq 5y ago
What do they require? You can just claim any S3 bucket you want that's been 'abandoned'?
- pyentropy 5y agoNo, 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.
- huibf 5y agoMaybe Bob shouldn't have set cname bob.com.us-east-1.amazonaws.com if he didn't own the bucket?!
- bawolff 5y agoThat seems pretty reasonable to me. How should AWS verify domain ownership if not control over the CNAME?
- detaro 5y agoit 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)
- fastball 5y agoRight, 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?
- Sebb767 5y agoThe 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.
- ctvo 5y agoS3 is not a CDN. S3 is a distributed file system. Use a CDN for CDN use cases (CloudFront) and you wouldn't have these issues. There's a chance a normal AWS user may not understand the above distinction, a sophisticated actor like MarkMonitor (whose business is THIS) should. Instead they had a security incident. That's it. They used the wrong AWS service. They configured massive numbers of domain DNS records incorrectly. They risked their customer's reputations.
- detaro 5y agoIf thousands of people keep making a mistake when using your product, you can go "purely on them, not our problem", true. Or you can do something to your product to make the mistake less likely to cause a problem.
- 5y ago
- zerocrates 5y agoWhat'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?
- detaro 5y agoOr as happened here, bob points the site to S3 because he plans to put something there later, and Eve beats him to it.
- vmception 5y agoNo 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.
- yellow_lead 5y agoI don't think it's as inconsequential as you say. Coinbase.ca and google.ar were two of these domains. The author noted that TLS certs could have been minted and then used in MITM attacks, if, for example, Coinbase began operating in Canada.