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.<p>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.<p>I'm betting over at AWS they're almost as terrified by this as I am.
My first thought was "why is salesforce publishing essentially a hacking tool? why can't they bring it up privately, surely a large enough company will have some weight to their request?" but then I remembered AWS...<p>>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<p>...and it's not even a hacking tool!
It really seems that AWS cares more about the cadence of shiny new managed solutions than they do about maintaining and upgrading their existing solutions. I wouldn't characterize it as willful negligence, quite yet, but some processes are definitely broken.<p>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?<p>All that is to say, I would not be expecting any improvements to AWS Access Analyzer anytime soon, despite this tool's debut.
Note that as far as I could tell, this is a tool to check which unexpected AWS modifications can be done from API keys that you do make public in the first place. It doesn't "hack" an account per se.<p>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.
It would be nice if this was the other way round :'''''(<p># this will ruin your day<p>endgame smash --service all --evil-principal "<i>"<p># This will show you how your day could have been ruined<p>endgame smash --service all --evil-principal "</i>" --dry-run<p>Looks like it can be reversed with --undo, but brown trousers time if you groggily run it at 08:30am coffee in hand.
fwiw the opensource (and cncf incubator project) <a href="https://cloudcustodian.io" rel="nofollow">https://cloudcustodian.io</a> can detect and remediate these modifications to embedded iam policies (across many resource types) in realtime that share beyond an organizations/accounts boundaries. its like access analyzer except its flexible enough to understand internal org distinctions (dev/prod separation) and allowed access to third parties.
Anybody have a mirror? It seems to have been taken down from GitHub.<p>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.
Impressive tool, but the supporting documentation is what I appreciate most.<p>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.
Can someone explain why you'd ever want to run this in the non-dryrun mode?<p>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.
The main repository seems to have been taken down but it is still available at <a href="https://github.com/kmcquade/endgame" rel="nofollow">https://github.com/kmcquade/endgame</a> and on Pypi
So, this is essentially a script to mess up your AWS resource permissions by using a privileged account to an extent that a) might surprise folks who haven't thought too deeply on the matter, and b) will be challenging to uncover using AWS's own audit facilities, is that fair to say?
@kmcquade ur awesome ! we are users of <a href="https://github.com/salesforce/policy_sentry" rel="nofollow">https://github.com/salesforce/policy_sentry</a> and definitely definitely <a href="https://github.com/salesforce/cloudsplaining" rel="nofollow">https://github.com/salesforce/cloudsplaining</a> .<p>If I could give you guys money, I would. You should totally build a startup around it.
Does anyone have any ideas as to why this is being taken down? Hacking tools are released all the time. Why did this one make such a big ripple in the pond?
It is great that it is Public because as it will create some sense of urgency. Similar to how you expose a Bug on Aurora like following, every such finding will directly/indirectly help a user in making good decisions and understand how to be careful.<p><a href="https://news.ycombinator.com/item?id=26146440" rel="nofollow">https://news.ycombinator.com/item?id=26146440</a>
<a href="https://github.com/brandongalbraith/endgame" rel="nofollow">https://github.com/brandongalbraith/endgame</a> still has it as of this morning, the several I marked last night waiting to ask at work about it have disappeared, so dunno how long this one will be tehre.
Cool. Another tool in the space - <a href="https://github.com/cloudquery/cloudquery" rel="nofollow">https://github.com/cloudquery/cloudquery</a> open-source framework to ask questions about your cloud infrastructure with SQL.
Except it's not "Pentesting tool to backdoor" anything.
It's simply modifying an access given you already have credentials to do that.
You can do the same with aws cli (oh horror /s).
We use both AWS and Salesforce and I'm surprised about this tool being developed by SF after all the whistle and bells about the partnership between the two.
nothing of security threat I guess. It uses your permissions, to modify the current permissions for different product. If u do have permissions to modify things, then this will work. if you have no permissions, it will fail.<p>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!!