AWS Support able to access any S3 object due to permission change
1–10 of 134 posts
Re: AWS Support able to access any S3 object due to permission change
#2KMS Encrypted objects shouldn't be affected though
Re: AWS Support able to access any S3 object due to permission change
#3Reverted 22 hours ago: https://github.com/z0ph/MAMIP/commit/b6f696cebc7b9a4f71dd34c...
Re: AWS Support able to access any S3 object due to permission change
#4It’s their servers, they can do whatever they want with them. What are you going to do about it they have physical access, you have an API key.
Suggestion, if you want to secure your data don’t put it on other peoples computers, and for fucks sake don’t store your crypto keys on someone else’s computer.
Re: AWS Support able to access any S3 object due to permission change
#5KMS Encrypted objects shouldn't be affected though
Aren't KMS keys created by Amazon?
Re: AWS Support able to access any S3 object due to permission change
#6KMS Encrypted objects shouldn't be affected though
Aren't KMS keys created by Amazon?
Yes but this role did not add the necessary privileges for it to use customer KMS keys. You can’t get an S3 object that’s encrypted with a KMS key if you don’t also have permission to decrypt with that key.
Of course Amazon could just give themselves access to decrypt with your KMS keys too, but that didn’t happen here.
Re: AWS Support able to access any S3 object due to permission change
#7It’s their servers, they can do whatever they want with them. What are you going to do about it they have physical access, you have an API key. Suggestion, if you want to secure your data don’t put it on other peoples computers, and for fucks sake don’t store your crypto keys on someone else’s computer.
A very shortsighted take. Sure, yes "they" can do whatever they want.
But even in the world you are imagining where AWS is peeking at customer's data willy-nilly, I have to imagine you don't believe that every tech support representative should have default access to every AWS customer's storage data, do you?
Even a dishonest unethical company that created backdoors for its employees would surely gate their backdoors.
This change (a mistaken one that was rolled back immediately) would have given the keys through the front door to presumably thousand low-level employees.
BTW, AWS spends a long time talking about how verifiably they do not have access to customer data. If you're interested in crypto (otherwise not sure why you are referencing it here), this kind of thing should be right up your alley: https://www.youtube.com/watch?v=4J8REvs7zaY
Re: AWS Support able to access any S3 object due to permission change
#8It’s their servers, they can do whatever they want with them. What are you going to do about it they have physical access, you have an API key. Suggestion, if you want to secure your data don’t put it on other peoples computers, and for fucks sake don’t store your crypto keys on someone else’s computer.
That is a really false statement. This is why contracts, audits,... exists and they define what each party can and can't do. When in violation this could result in huge fines, loss of business,...
You can also securely storage your data on other servers by using client-side encryption.
Not every business/person has the means or knowledge to have their own datacenter.
Re: AWS Support able to access any S3 object due to permission change
#9Okay, opinions up front: I don't think this is worthy of "declaring a security incident. Having some experience working behind the scenes, just because this policy was changes this way doesn't mean "All AWS Support personnel had unrequited access to your S3 objects." To me, this reads as Twitter inflammatory nonsense. Here's why:
* KMS Encrypted objects would not be accessible because the support personnel would need permission policies that grant `kms:decrypot` permissions to encrypted objects. The only way this could wind up happening is if you are granting the AWS Support principal access in the KMS Key Policy.
* Objects with a default-deny bucket policy could not have been circumvented with the support team's escalated privilege. So if you have a policy that looks something like this, that data was not exposed:
{
"Action": "Deny",
"NotPrincipal": [...]
* Internal Checks. AWS has a lot of protections and checks in place to prevent their support personnel from accessing metadata about S3 objects. They don't have tools to fetch the actual objects unless your really high up the food-chain. Think like, people with a legal or security related reason to need to review data.
Nevertheless, I'll share some nuggets of wisdom I've accrued over the years, in a hopes to save y'all some time:
If you have an NDA with AWS, I'd recommend reaching out to your TAM and asking them about what the potential exposure was; and make sure to ask about the internal access control mechanisms.
But everyone who's concerned and DIDN'T set up data access logging already: 1) Consider turning that on to trace potential disclosures in the future. 2) Open up a case with Premium Support under the CloudTrail, state that you have a security incident and you need to retrieve data events for the time of 2021-12-23 to 2021-12-22. If granted to you, save that sucker in S3 and query it for requests coming from `support.amazonaws.com` in Athena. [0]
Hopefully this helps some of y'all.
[0] https://aws.amazon.com/premiumsupport/knowledge-center/analy...
Re: AWS Support able to access any S3 object due to permission change
#10Okay, opinions up front: I don't think this is worthy of "declaring a security incident. Having some experience working behind the scenes, just because this policy was changes this way doesn't mean "All AWS Support personnel had unrequited access to your S3 objects." To me, this reads as Twitter inflammatory nonsense. Here's why: * KMS Encrypted objects would not be accessible because the support personnel would need…
"Declaring an incident" means there's something to investigate, it didn't mean anything bad has happened: it's detection of a non-conformity. The output of the incident would look similar to what you wrote.
Any time the wrong permissions are assigned and confidentiality is potentially breached, I think you have to have an incident. Arguably in some jurisdictions, it's a legal requirement to ensure you have a near miss not an actual breach.