81–90 of 101 posts
I work with AWS a lot every day and lead a team responsible for building workloads on AWS for some customers with very high security requirements. This tool terrifies me. The sheer amount of potential for misconfiguration of resources that this tool can exploit with no effort whatsoever is absolutely insane. I feel like every AWS environment I've ever seen is suddenly at risk of some angry employee compromising every…
lol you're about to get a giant offer from Amazon. Tell them you want 10x whatever they first offer and they'll say yes.
The tool is great as a free tool and very helpful, but its also not like AWS doesn't already have the people smart enough to make something just as good, if not better. It just obviously not AWS's priority. They can just leave the blame on the user for not properly managing IAM permissions.
lol you're about to get a giant offer from Amazon. Tell them you want 10x whatever they first offer and they'll say yes.
Not to sound like a jerk but why do you think this would be some "OMG" response from AWS? This is not some sort of "hacking", this is a tool that is being used to detect whether you misconfigured API access to be overly permissive. The tools job is to find them and them "abuse" them. Its not like AWS is not aware of user misconfigurations. The issue is AWS does not provide tools to detect these very well. Tools like…
Do analogous tools exist for GCP and Azure?
Not sure. I did uncover a ridiculously destructive approach to abusing Azure Service Principals in CI/CD pipelines that deploy infrastructure in Azure (Confused Deputy problem): https://kmcquade.com/2020/11/nuking-all-azure-resource-group... for sub in `az account list | jq -r '.[].id'`; do \ for rg in `az group list --subscription $sub | jq -r '.[].name'`; do \ az group delete --name ${rg} --subscription $sub --no-w…
> for sub in `az account list | jq -r '.[].id'`; do \ for rg in `az group list --subscription $sub | jq -r '.[].name'`; do \ az group delete --name ${rg} --subscription $sub --no-wait --yes; \ done; done;
The CI provider giving you an over-privileged SP to play with needs to fix that, sure. SPs start with zero role assignments, so it's particularly egregious that they gave it unnecessary permissions.
(Though, for the CI providers I'm familiar with, you the user would be the one creating the SP and providing it to the pipeline. So making it over-privileged would be your mistake.)
But it's not a Confused Deputy problem when you have a service principal with delete access to all resource groups in all subscription and tell it delete those resource groups. Confused Deputy involves a higher-privileged server forgetting to downgrade its privileges on behalf of a low-prvivilege client. The SP is the client in this case - it was created with high privileges in the first place.
Earlier quoted context omitted.
Author here :) Endgame exploits/abuses features. If it was a bug, I'd work with AWS to solve the problem, but with abusing features - that would result in years of unsatisfied feature requests. This should push the issue along. >...and it's not even a hacking tool! It can be used to backdoor resources to rogue accounts, so I'd say it's a hacking tool and can/should be used on penetration tests. I'd certainly use it o…
404. Did they pull the repo or make it private? https://github.com/salesforce/endgame
404? someone got an urgent call from AWS and politely requested to remove it since both companies are supposed to be partners?
Moved to his personal: https://github.com/kmcquade/endgame
Earlier quoted context omitted.
https://github.com/clintgibler/endgame
that's gone too :)
The main repository seems to have been taken down but it is still available at https://github.com/kmcquade/endgame and on Pypi