That seems pretty reasonable to me. How should AWS verify domain ownership if not control over the CNAME?
- DNS TXT record
- HTML meta tag
- Upload a file with a randomized name to your site root
- 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.
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)
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.
Since CNAME records can point to other domains, I’m not sure how AWS is supposed to police this and allow cross-referencing from other parties. Blocking based on any CNAME presence could turn into a bucket-squatting exploit pretty quickly.
A CNAME record is an “I’m pointing my domain at some other place” record. Redirect to something out of your control, S3 or otherwise, and you’re handing over control of the returned content. That doesn’t so much strike me as a mistake but more as the way that CNAME records were designed to work.
> That doesn’t so much strike me as a mistake but more as the way that CNAME records were designed to work.
"I hold something into a saw, and it gets cut. That doesn’t so much strike me as a mistake but more as the way that saws are supposed to work. Why are all these fingerless people saying our saws should have safety features?!"
We know such things happen to all kinds of people all the time. It has been part of actual security problems. We know how to fix it, because many service providers do require validation. Why not consider the validation?
What is the actual mechanism you think should be implemented, and how does that support cross-party referencing while avoiding other modes of vulnerability (e.g. denial of service)?
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.
Why shouldn't they ? Don't you think it can be a useful feature ?
If someone else creates the bucket on their AWS account, I am stuck. I would have to use a different hostname, or use a more complex workaround. Since creating empty buckets costs nothing, it effectively allows DoSing hostnames from an S3 hosting standpoint.
It would be one thing to allow this behavior if a domain owner explicitly wanted it, via a TXT record or something, but as it is, it's a poorly designed solution.
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.
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.