[HN Gopher] Hacking misconfigured AWS S3 buckets: A complete guide
___________________________________________________________________
Hacking misconfigured AWS S3 buckets: A complete guide
Author : yarapavan
Score : 134 points
Date : 2024-09-09 15:41 UTC (7 hours ago)
(HTM) web link (blog.intigriti.com)
(TXT) w3m dump (blog.intigriti.com)
| arter4 wrote:
| The interesting thing is, most people wouldn't do the same things
| (say, chmod 777 all the things) on a public NAS.
|
| If this assumption is true, it begs the question. Why do people
| act like public cloud storage is more secure than "private", on
| prem storage?
|
| Do users expect safe defaults (as in, "default deny")?
|
| Is it just a matter of attitude, where people think public cloud
| is more secure because it's not managed by (potentially short-
| staffed) corporate IT teams, even if it's not completely managed
| by the cloud provider?
|
| Or is there something else?
| dewey wrote:
| > most people wouldn't do the same things (say, chmod 777 all
| the things)
|
| I wouldn't be so sure about that, it still happens a lot that
| this is the default reply in many help forums.
| arter4 wrote:
| On an exposed NAS?
|
| Everything is possible, I know, but the amount of hacks
| related to S3 misconfigurations
| (https://github.com/nagwww/s3-leaks), including major
| companies, still makes me wonder.
| HL33tibCe7 wrote:
| Cloud permissions are just more complicated, which means people
| make mistakes like this. No one is intentionally setting their
| buckets to be world readable.
| hulitu wrote:
| > Why do people act like public cloud storage is more secure
| than "private", on prem storage?
|
| Because Microsoft, Google, Amazon told them that the "cloud is
| more secure".
| Hikikomori wrote:
| Buckets are default deny, takes several steps to enable public
| access with warnings along the way, if you use web console.
| stevekemp wrote:
| Buckets are default deny, now. But for many many years they
| were not, and the defaults almost certainly changed due to
| the many many examples of "accidental exposure".
| ljm wrote:
| I'd love to know what the original architects of S3 think
| now, looking back, of S3 buckets being globally unique.
|
| AWS has certainly enjoyed a class of vulnerabilities caused
| by the way they allocate resources and expose them over
| DNS, but S3 is just a simple namespace.
| faangguyindia wrote:
| >If this assumption is true, it begs the question. Why do
| people act like public cloud storage is more secure than
| "private", on prem storage?
|
| #1 risk people are concerned about is dataloss where cloud
| wins.
|
| That's where cloud is more secure comes from. I've not lost any
| data in GCS or S3.
|
| But same cannot be said for local copies of data.
|
| 321 strategy is best for most cases.
| Thaxll wrote:
| The same reason people 777 on Linux, stuff does not work how I
| fix the problem quicky.
| dylan604 wrote:
| Especially when fighting SELinux.
| treflop wrote:
| It's because systems are highly complex and there are a
| thousand little things that you need to know to use them. Once
| you have experience working with it (or even reading enough
| docs), you know which of those thousand things should take up
| the most space in your mind.
|
| But if you are new and are pressed for time, you only look at
| maybe a fraction of those thousand things, and inevitably you
| miss some important things.
|
| AWS used to not have sane defaults for S3 buckets.
| paulpauper wrote:
| Thinking about creating intentionally misconfigured buckets with
| encrypted files that look like they have valuable stuff so the
| hackers waste tons of resources decrypting them only to see they
| are worthless
| csto12 wrote:
| Couldn't this backfire by possibly generating a large AWS bill?
| paulpauper wrote:
| they would copy the file offline and decrypt it there
| edwinbalani wrote:
| It costs money to serve S3 objects out to the internet
| though. S3 GET request billing + the usual AWS egress fees,
| after you've burned through the free quotas. Egress is
| currently $0.09 per GB + tax.
| itintheory wrote:
| Make the bucket requester-pays https://docs.aws.amazon.co
| m/AmazonS3/latest/userguide/Reques...
| the_arun wrote:
| I wish AWS showed who has access to every S3 bucket created right
| at the S3 console. It shows permissions but doesn't show external
| view.
| kstrauser wrote:
| Access Analyzer is the tool for that.
| alexchantavy wrote:
| It also doesn't show effective accesses from
| users/groups/roles/things-across-accounts; I've found that even
| Access Analyzer gets it very wrong sometimes. I wrote a bit on
| this here: https://eng.lyft.com/iam-whatever-you-say-iam-
| febce59d1e3b.
| encoderer wrote:
| In 2018 I added S3 bucket monitoring to my SaaS, Cronitor.io but
| we eventually retired it because AWS seems mostly to have solved
| this.
|
| It's hard in the console to make buckets public, it's obvious
| when they are, and Amazon sends emails about public buckets just
| in case you're not using the console.
| travismcpeak wrote:
| This does a great job of highlighting why properly configuring
| infrastructure is hard: S3 buckets (one of the most simple cloud
| infra services) have 70 configuration options.
|
| Imagine you're a junior dev and your manager says "just spin up
| an S3 bucket and drop the data there, and make sure your app can
| access it".
|
| S3 does have some sensible defaults, but a lot of Terraform
| modules do not...imagine somebody who now has to decipher S3's
| basic properties, ACLs, IAM, etc.
| hemloc_io wrote:
| Hah I've had some fun with this, and even submitted bug reports
| that were never looked at.
|
| I have like the worlds largest collection of license plate photos
| now. :)
| msarrel wrote:
| Nice work!
| OJFord wrote:
| This is just a list of 'how to do x with awscli [and if the
| bucket allows unauthenticated users to do x then you will get a
| result]'.
|
| Unless I'm missing something there's nothing particularly..
| interesting or thought out here? May as well read the docs for
| available s3/s3api operations - there's more!
___________________________________________________________________
(page generated 2024-09-09 23:00 UTC)