Looks like some of it was archived though at https://web.archive.org/web/20210216153239/https://github.co....
Also still live at PyPI: https://pypi.org/project/endgame/
Also https://github.com/hirajanwin/endgame is still up as of 00:58 Wednesday, February 17, 2021 Coordinated Universal Time (UTC). Zip file download of that Git repo here: https://web.archive.org/web/20210217005905/https://codeload....
>At the time of this writing, AWS Access Analyzer does NOT support auditing 11 out of the 18 services that Endgame attacks. Given that Access Analyzer is intended to detect this exact kind of violation, we kindly suggest to the AWS Team that they support all resources that can be attacked using Endgame
...and it's not even a hacking tool!
>...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 on a pentest :)
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 everything very very quickly.
I'm betting over at AWS they're almost as terrified by this as I am.
At least now we all have access to the same tool. Maybe this one won't have everything the "secret" tools have. But it's a good start!
Also I guess it might have been a not so nice from an almost direct competitor of AWS - salesforce - to publish something like that. Salesforce owns heroku.
I understand that if you have these problems you've already effectively granted those permissions anyway but actually executing them before someone finds them lowers the bar quite a bit for other baddies to attack.
So for example if you've created some IAM API keys and embedded in an app for example, and you (incorrectly) believe the permissions only grant the app to fetch some static media files from an S3 bucket, the tool can discover incorrect configurations that would allow someone who extracted the key to change permissions of the bucket.
Nit: The tool can discover and abuse excessive permissions.
... right. This is just a glorified "what can this IAM user do" tool. There is literally no actual pentesting done. Not much different than having the key to your neighbor's front door and seeing how many things inside their house are unlocked for you.
# this will ruin your day
endgame smash --service all --evil-principal ""
# This will show you how your day could have been ruined
endgame smash --service all --evil-principal "
" --dry-runLooks like it can be reversed with --undo, but brown trousers time if you groggily run it at 08:30am coffee in hand.
FWIW, if you run `endgame smash` with `--service all`, then it spits out a huge "WARNING" in ASCII art with an explanation and a confirmation prompt.
But I agree, we should have dry-run on by default.
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.
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;
> 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.
I think the prevention guide could be improved by providing an example service control policy that blocks known dangerous IAM actions like ecr:SetRepositoryPolicy for all but a specific security principal.
If I could give you guys money, I would. You should totally build a startup around it.
Also the pentesting policy explicitly states that customers can pentest without approval.
https://pypi.org/project/endgame/#files
I was thinking about putting a new repo with the code in it but I'd rather not risk the wrath of AWS since my job kinda depends on the service. Which probably says something about the state of Faang companies that I'm even concerned about it.
Or these forks, but I wouldn't be surprised if they vanish:
https://github.com/agnivesh/endgame/ https://github.com/brandongalbraith/endgame
Case in point, in the last week alone, I've discovered a Fargate EKS managed platform upgrade getting botched behind the scenes (unexpected containerd versions, etc), as well as a lack of support out of RDS Proxy for things like the latest stable default Postgres offering (12.5) in RDS. They released 12.0 to the preview channel in November of 2019 ... how long does it take exactly to get support for something like that?
All that is to say, I would not be expecting any improvements to AWS Access Analyzer anytime soon, despite this tool's debut.
So can it be used with bad intention, yes. But if I am a hacker, would i want to open all the available doors? or choose 1 or 2 doors only instead and keep the rest as is!!
