6 ms·
I hear about subdomain takeovers with S3 all the time. It seems insane Amazon doesn't require any domain verification.
by jtsiskin 5y ago
I hear about subdomain takeovers with S3 all the time. It seems insane Amazon doesn't require any domain verification.
- tyingq 5y agoWhat 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.
- 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.
- deleted 5y ago[deleted]
- vegardx 5y agoThis 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.)
- exikyut 5y agoRelatedly, the thought of properly storing your web server's full access logs indefinitely comes to mind, for a baseline of "until I write some exactingly specific filtering logic and I get 0 unclassified results back out". Doesn't have to happen immediately, but by all means hoard 50GB of traffic logs until you do get it done. That sort of thing. You'd naturally be capturing the requested host here, ideally along with all other request headers. And ideally flagging unknown host headers in close to real time, so you can have fun with your visitors next time they say hello :>
- csmpltn 5y agoS3 allowing customers to incorporate a "domain" or any part of it as part of the bucket's name is a contributing factor here, in my opinion. The name of the bucket (which ends up being a part of the bucket's URL) should be entirely outside of the user's control. Make it a random 32 character string (and make it such that old strings can't ever be recycled). This way people can't "register" buckets for domains they don't own.