Hacker News Reader

Comment by tptacek | Hacker News Reader

10-15 years ago, if you asked me what would get your SAAS shop owned up, I'd have said an overlooked SQL injection vulnerability.

5-10 years ago, I'd have said credential stuffing in your accidentally-exposed admin app.

Today, without question: it's AWS misconfiguration or credential leaking.

View on HN

If the admin app were not exposed, wouldn’t credential stuffing work just as well on the VPN interface?

No, because the people whose credentials tend to get stuffed in these examples tend not to be the people who use the VPN. Like, it happens, but "tier 2 support" is the victim I'm usually thinking about here.

it's AWS misconfiguration or credential leaking.

By AWS themselves? Does that actually happen a lot?

No, by AWS users. There are safe ways to configure AWS and there are very unsafe ways, and the very unsafe ways are easy, well-documented, and on the UX "happy path".

Oh ok, I was about to start freaking out. This just looks like AWS salesperson had some doc in a world readable bucket - sort of like if a building contractor forgot the proposed plans for a superhero HQ in a public dropbox folder. The AWSery seems almost incidental.

We hear about these mis-configurations leading to publicly-viewable things that shouldn't be publicly viewable all the time. This makes me wonder what is the default security setting? It seems like -- and this is from the outside looking in, I have little experience with AWS -- whatever the default is, it's not nearly strict enough. Shouldn't the default config be pretty restrictive for security's sake? Or is this a case of trying to dumb it down in the name of "usability" or "streamlining the UI" or some other marketing fluff crap (aka "for people who don't/won't/can't RTFM")?

I just checked, and the default for creating a new S3 bucket through the console is not public readable. However, getting the right permissions in place for real-world work is not trivial if you haven't put some time in the docs so I suspect people end up shoving wild cards and the like in their access policies.

The default is private to the owning AWS account. You’re meant to generate short-term tokens in your backend code to authorize specific requests, embedding them in the URLs you pass to others. People who are abusing S3 as a substitute for Dropbox or Google Drive (or using it from any context other than custom server-side software) won’t do that, so they set resources as public to make things work.

Reply on news.ycombinator.com