4 ms·

Delivering Malware Through Abandoned Amazon S3 Buckets

14 points by mhb 2y ago

easton 2y ago
Original article: https://labs.watchtowr.com/8-million-requests-later-we-made-the-solarwinds-supply-chain-attack-look-amateur/ https://labs.watchtowr.com/8-million-requests-later-we-made-... 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?
- remram 2y ago
  Or sign your artifacts.
mschuster91 2y ago
The fact that this is possible at all is mindboggling. 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.
- remram 2y ago
  AWS should do better with buckets than the rest of the world does with domains?
hypeatei 2y ago
> Amazon S3 buckets that had previously been used across commercial and open source software products, governments, and infrastructure deployment/update pipelines—and then abandoned. 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.
- Shank 2y ago
  > Couldn't this happen with a domain too? Yes, and you really hope someone implemented certificate pinning for this exact reason, but it often is not the case.
  - smileybarry 2y ago
    Probably better to just do update signing, certificates rotate frequently and at some point you’re bound to run into an enterprise customer with a MITM / caching proxy.
- smileybarry 2y ago
  I guess the worse part about S3 buckets vs domains is that it’s bound to AWS (would you maintain a dead AWS account with an empty bucket forever after you switched to GCP?), and potentially more expensive than domain upkeep. (Not really but there’s always the worry of keeping a cloud account with resources left unmonitored) At least with a domain you can park it somewhere and pay a yearly renewal fee without worrying.
deleted 2y ago
[deleted]
INTPenis 2y ago
Slightly related but I noticed something interesting back when the Tor project released the Snowflake proxy. I was provisioning VPS with Snowflake and due to some trial and error I had to re-provision a few times. One of the times I checked the web server logs and saw HTTP requests for theguardian.com. 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.
- mschuster91 2y ago
  Cosmic rays [1], and no this is not a joke. Alternatively, there have been instances where routers and switches had bit-flip errors that ended up corrupting packets that passed through them. Or DNS caches that cached DNS responses for far longer than the specified TTL values - these are a real PITA for modern loadbalancers and are probably what caused your misdirected requests. [1] https://news.ycombinator.com/item?id=2944445 https://news.ycombinator.com/item?id=2944445

14 points by mhb 2y ago

Original article: https://labs.watchtowr.com/8-million-requests-later-we-made-the-solarwinds-supply-chain-attack-look-amateur/ https://labs.watchtowr.com/8-million-requests-later-we-made-... 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?

remram 2y ago
Or sign your artifacts.

mschuster91 2y ago

The fact that this is possible at all is mindboggling. 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.

remram 2y ago
AWS should do better with buckets than the rest of the world does with domains?

hypeatei 2y ago

> Amazon S3 buckets that had previously been used across commercial and open source software products, governments, and infrastructure deployment/update pipelines—and then abandoned. 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.

Shank 2y ago
> Couldn't this happen with a domain too? Yes, and you really hope someone implemented certificate pinning for this exact reason, but it often is not the case.
- smileybarry 2y ago
  Probably better to just do update signing, certificates rotate frequently and at some point you’re bound to run into an enterprise customer with a MITM / caching proxy.
smileybarry 2y ago
I guess the worse part about S3 buckets vs domains is that it’s bound to AWS (would you maintain a dead AWS account with an empty bucket forever after you switched to GCP?), and potentially more expensive than domain upkeep. (Not really but there’s always the worry of keeping a cloud account with resources left unmonitored) At least with a domain you can park it somewhere and pay a yearly renewal fee without worrying.

deleted 2y ago

[deleted]

INTPenis 2y ago

Slightly related but I noticed something interesting back when the Tor project released the Snowflake proxy. I was provisioning VPS with Snowflake and due to some trial and error I had to re-provision a few times. One of the times I checked the web server logs and saw HTTP requests for theguardian.com. 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.

mschuster91 2y ago
Cosmic rays [1], and no this is not a joke. Alternatively, there have been instances where routers and switches had bit-flip errors that ended up corrupting packets that passed through them. Or DNS caches that cached DNS responses for far longer than the specified TTL values - these are a real PITA for modern loadbalancers and are probably what caused your misdirected requests. [1] https://news.ycombinator.com/item?id=2944445 https://news.ycombinator.com/item?id=2944445