Hacker News Reader

Comment by roseway4 | Hacker News Reader

Per the complaint, it doesn't sound like the bucket was exposed to the world. Rather, security credentials were "obtained":

> Capital One determined that the first command, when executed, obtained security credentials for an account named XXXX-WAF-Role, that in turn, enabled access to certain of Capital One's folders at the Cloud Computing Company.

Unsure how one would obtain credentials for an IAM Role, but the above verbatim from the complaint.

* edited to reflect this is lifted from the complaint, not indictment.

View on HN

> Unsure how one would obtain credentials for an IAM Role, but the above verbatim from the complaint.

You use your own credentials and issue an API call to do it. If you're using the AWS CLI, it's "aws sts assume-role".

We do something similar with our accounts. You can place a restriction on the role that an MFA token must be used while assuming the role, so this allows you to give out longer-term credentials to your devs/admins that can then be used (with an MFA token) to assume a more privileged role.

The role itself needs to be configured with a trust relationship that allows for this, and many roles are restricted to AWS services (i.e. you are authorizing an AWS service to assume the role--not a specific user). I've never used WAF before though, so I'm not sure if it's typical for the WAF role to have that trust relationship or not.

It's possible an STS token was obtained using the role. If you're not monitoring where those tokens are issued to and used from, you're gonna have a bad time.

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credenti...

I recall a newbie dev at our company some years back accidentally posted creds in code to github. I have talked about this here before - but - we had paid for 200 repos.. problem was he made a new repo, which became 201 - which since we had only paid for 200, github auto makes the next one public. Bots slurp these and hunt...

They used those creds to launch like 1700 gpu machines across the globe for a bitcoin mining network...

The culprit was from germany...

We got it cleared and AWS forgave all the charges.

It doesn’t matter. There is never a reason for credentials to be anywhere near your repository. If you’re running locally, you should have your credentials in your home directory (via aws configure). If you are running your code on AWS either on an EC2 instance, lambda, or Docker you should be using the role associated with the execution environment.

Every SDK that I have used let’s you use a constructor without a parameter and can get your credentials from the config file/role.

i know, this was a few years ago, and these types of practices were still being developed out in the greater community (lambda didnt exist yet, dockeer was still nascient etc)

I’m sympathetic in that a lot of people started learning this on the fly but that was widely recognized as bad practice even before Amazon was founded and various patterns for doing it right were widely established.

(If anyone needs me, I’m busy feeling old after remembering having this conversation with a new PHP developer in 1998)

Haha, agreed...

He was a remote worker and aparently had a poor handler on our end. I was head of ops not in dev, so i just had to deal with the fallout.

If it's an instance role and you are on the EC2 instance, then "curl http://169.254.169.254/latest/meta-data/iam/security-credent... will return the credentials.

Reply on news.ycombinator.com