by mhb on 2/12/25, 1:35 PM with 10 comments
by easton on 2/12/25, 2:03 PM
I suppose the lesson is to not publicize your bucket names, if possible? Or if not, leave them present but empty in AWS and don't actually delete the buckets?
by mschuster91 on 2/12/25, 2:06 PM
Amazon is being a bad netizen here and has been from the start with S3 - yes, the original fault lies with careless app / appliance developers, obviously, but AWS has had sooo many security issues caused by their default settings, complex configuration, bucket takeover possibility and by having one large global namespace for all tenants instead of always adding the account ID as a suffix in the domain (like they do now with, say, ECR). Hell if you know a juicy target bucket, you can just poll its name and wait for some poor sod to make a fat finger mistake or not paying their bills and then immediately take over the bucket.
AWS should at the very least only allow re-registering a bucket from the original account - and if it or its super organization get deleted, the bucket name is gone forever until someone can prove by, say, providing corporate register documents showing a legitimate claim.
by INTPenis on 2/12/25, 5:22 PM
I just kept provisioning so the IP is long lost but it only took 3 attempts to get this IP from the cloud provider.
I still can't really explain it because the guardian is not hosted at that cloud provider, but maybe it was a test environment? Also kinda scary that active requests were coming in.
by hypeatei on 2/12/25, 2:13 PM
Couldn't this happen with a domain too? e.g. you stop paying and someone else takes it over but your app is still pinging it.
I don't see how AWS is really special here to be honest. If you can't guarantee you'll always have <thing that provides updates> then you should probably add in a signing mechanism to your software to verify it's coming from the original devs.