8 ms·
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.
by pyentropy 5y ago
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.
- 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.
- moltar 5y agoGoogle 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
- ctvo 5y agoThis 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.
- detaro 5y agoAWS 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.
- chaboud 5y agoCould 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)
- detaro 5y ago> Could Eve then just register bob.com and point it to bob's random bucket to mess with him? If it blocks creation, she would have to know the bucket name Bob would want to create soon. At which point she could just create the bucket instead. > And shouldn't Alice be able to register Alice.com and point it at Bob's bucket if she feels like it? She can only do that with this method if Bob's bucket is called "alice.com". Doesn't seem important to support for random unrelated people, if its for a dedicated setup where Bob manages a thing for Alice you could always have a way of granting that permission specifically or to opt out of the verification. > It seems like the answer already exists: don't create CNAMEs haphazardly. "don't make mistakes". If people keep making a mistake all the time, that's not the greatest answer. There's a reason most other providers that allow you to point a domain at them do some verification.
- tialaramex 5y agoIf 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.
- bawolff 5y agoIf you control the cname its trivial to get a cert.
- tialaramex 5y agoSure, but the point of this choice is to make it easy for a third party to verify your identity, the exact same problem as for web browsers visiting an HTTPS site.
- 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.