kmcquade

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.

Love using Depot. The speed improvements are insane

> 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.

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.

Aw, thank you. I really appreciate that.

Great feedback! I will update the docs accordingly.

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-wait --yes; \ done; done;

Dry run as default is a good idea. I'll open a GitHub issue for that.

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.

Thanks :)

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 :)

Did you open source it? If not, you definitely should.

I wish.

You are so right on the SELinux comparison. Of course, in this case, there are way more developers that are required to write them.

Reiterating what was mentioned in the thread - the best way to avoid this wildcard situation and make it easier for developers is to use Policy Sentry[0]

Thought I’d mention this for those who read the title and the comments instead of clicking on the tools. This will solve most of your problems with writing IAM policies for machine roles.

[0] https://github.com/salesforce/policy_sentry

You just need a single IAM action - iam:GetAccountAuthorizationDetails (https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetA...).

I’ll definitely add that to the README. Thanks

PMapper is definitely a great tool. It’s best used in Pentests for validating some privilege escalation paths. It has the benefit of analyzing IAM trust policies, resource based policies, viewing escalation paths in a graph based approach. Very underrated indeed.

Cloudsplaining is faster at creating a more comprehensive report. We realize that there is lots of damage that can be done just by being able to modify Infrastructure, even when your privileges fall short of legit privilege escalation.

I think the example report will illustrate this best for you. Check it out here: https://opensource.salesforce.com/cloudsplaining/

Thanks! I’m glad you like it. Let me know if you have any feedback - here, in the Gitter channel (link in the Readme), or on Twitter (kmcquade3)

With this.

https://github.com/salesforce/policy_sentry

(Disclaimer: I am the author)

Not one step exactly, but it is by far the easiest way to write least privilege IAM policies. Otherwise, it becomes impossible to ensure IAM policies are written securely and at scale. This way, all custom IAM policies are written with the exact same methodology.

Pretty awesome that it’s open source.

For large companies there are some proprietary solutions for this. Example:

https://www.trendkite.com/

Disclaimer: family member works there so that’s the reason I’m aware that this niche exists.

> "I'm pretty excited, I've never won a single thing in my life before. And to do it in service of taking down evil patent trolls? This is one of the best days of my life, no joke. I submitted because software patents are garbage and clearly designed to extort money from productive innovators for vague and obvious claims. Also, I was homeless at the time I submitted and was spending all day at the library anyway." — Garrett, San Francisco

This guy is a legend.

My email is also in my profile :)

Aardvark and Repokid revoke privileges based on AWS Access Advisor, which tells you when certain services have not been used within X amount of days/months. But it only does this for services, not for actions. So the resulting API calls are not very granular.

It does, but some disclaimers: 1. The generated policies have Resources set to all, not to a specific resource ARN 2. It downloads all of the CloudTrail logs. This takes a while. Cloudtracker (https://github.com/duo-labs/cloudtracker) uses Amazon Athena, which is more efficient. In the future, I'd like to see a combined approach between all three of these tools to generate IAM policies based on Cloudtrail logs. 3. It is accurate to the point where there is a 1-to-1 mapping with the IAM actions vs CloudTrail logs. As I mentioned in other comments, since not every IAM Action is logged in CloudTrail and not every CloudTrail action matches IAM Actions, the results are not always accurate.

With that being said, it is a wicked tool and you should try it out.

I hear you. Generating IAM policies based on CloudTrail records would be amazing. See my comment here: https://news.ycombinator.com/item?id=21262954#21264166

I hope to build this into our roadmap.

Updated.

Good feedback - I will put that stuff in the README. Was thinking about doing that earlier today. Thanks!

Yep. Sentinel is for paid customers only, so it has to go through Terraform enterprise.

Oh yeah it's super powerful. And it's not vendor-dependent like Sentinel & TF Enterprise (although I really love TF Cloud).

Here's an example of using OPA + Conftest with Terraform that you might be interested in: https://github.com/kmcquade/conftest-terraform-multifolder-p...

Unfortunately IAM Access Advisor only points to use of services (ex: S3-wide, EC2-wide), not use of IAM Actions. So it's useful, but it has serious limitations. I am hoping that they provide more granular results in the future.

Thanks!

aws-iam-generator still requires you to write the actual policy templates from scratch, and then they allow you to re-use those policy templates.

Consider the JSON under this area of their README: https://github.com/awslabs/aws-iam-generator#managed-policie...

It's essentially a method for managing their policies as code - but it doesn't make those policies restricted to certain resources, unless you configure it that way. Using `policy_sentry --write-policy --crud`, you have to supply a file with resource ARNs, and it will write the policy for you, rather than supplying a policy file, and hoping the ARNs fit that use case.

Does that make sense?