Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Personal capacity? #17

Closed
seriousme opened this issue Dec 9, 2021 · 3 comments
Closed

Personal capacity? #17

seriousme opened this issue Dec 9, 2021 · 3 comments

Comments

@seriousme
Copy link

https://github.com/SummitRoute/csp_security_mistakes#aws-aws-employee-posts-customer-access-keys-and-information

The Register reports:

A spokesperson for Amazon has told us the code repository was used by the engineer in a personal capacity, and claimed no customer data or company systems were exposed.

https://www.theregister.com/2020/01/23/aws_engineer_credentials_github/

@julianwieg
Copy link

would include this. Shows a lack of security controls for AWS employees if they can use repos outside their approved env.

@seriousme
Copy link
Author

Question is whether the data was leaked using his company credentials?
If I would work for AWS (which, for the record, I do not) and I post data from my private AWS account on GitHub then it wouldn't be a lack of AWS security controls. If I would post AWS customer data that I obtained using my AWS company account then it would definitely be a lack of AWS security controls!

So the context does matter in my view.

@0xdabbad00
Copy link
Contributor

The situation is not entirely clear, with Upguard possibly portraying the situation as being worse than it was, and AWS possibly trying to make it look less severe to save face. We have to consider that Upguard possibly incorrectly identified what they saw or possibly were misleading to gain reads, and equally that AWS's legal or public relations may be trying to mislead us. For example this statement from Chris Vickery:

Of course AWS tried very hard to claim “nothing to see here”, but I personally reviewed the files. There was much to see there.

It seems everyone is aligned that an AWS employee had a public github repo with contents that should not have been public, as AWS does not try to argue that point. The point of contention is what the contents were. At one extreme this may have been AWS customer data and at the other extreme just the individual's personal data, with the possibility of something in between existing.

It seems apparent that "Amazon Confidential" data was included in the repo as Upguard included a screenshot of this in their post and AWS's statement only argues that "no customer data or company systems were exposed".
image

Now if this is just internal training materials then that is not too concerning, but is still an incident as exposure of confidential information is an issue I would include this repo, maybe with just a low severity though.

However, Upguard's post also mentions the following:

  • "mentions of hostnames to identify likely AWS customers being assisted by the engineer"
  • "Other files contained collections of auth tokens and API keys for third party providers. One such file for an insurance company included keys for messaging and email providers."
  • "correspondence with AWS customers"

Depending on definitions, AWS can claim that is not "customer data", but this seems like a noteworthy incident to me. I've added some text to the issue to identify that it is not entirely clear what happened: 9ffda19

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants