[HN Gopher] Show HN: Endgame - An AWS Pentesting tool to backdoo...
___________________________________________________________________
Show HN: Endgame - An AWS Pentesting tool to backdoor or expose AWS
resources
Author : kmcquade
Score : 284 points
Date : 2021-02-16 14:16 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| sdfhbdf wrote:
| Anybody have a mirror? It seems to have been taken down from
| GitHub.
|
| 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.
| 0xmohit wrote:
| https://github.com/kmcquade/endgame
| andrewjmyers wrote:
| I don't know that I would call them a direct competitor. Heroku
| uses AWS for a lot of it's infrastructure. They are a pretty
| big AWS customer.
| metallikop wrote:
| The repo is gone but the code is still on PyPI:
| https://pypi.org/project/endgame/
| sodality2 wrote:
| 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...
|
| >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!
| kmcquade wrote:
| 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 :)
| Operyl wrote:
| I'm impressed you were able to get your employer (Salesforce)
| to actually let you publish this under their organization.
| Kudos to that.
| kerng wrote:
| Yes, surprised also, given past stories around Defcon.
|
| I think it's great to have audit tools like this. It makes
| people realize how vulnerable their accounts are.
|
| Does a similar tool exist for Salesforce and Heroku?
| jasperran wrote:
| 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.
| mushufasa wrote:
| 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.
| Blahah wrote:
| Can you share the code somewhere else? It's been taken down
| from github
| cambalache wrote:
| https://files.pythonhosted.org/packages/0c/f0/9eced7d6c5748
| 3...
| stjohnswarts wrote:
| So did you just put this out there or did you give AWS
| Security peeps a week or two notice?
| jasperran wrote:
| This isn't exploiting a vulnerability. This requires
| authentication and uses AWS features. Why would they need
| to alert AWS?
| sodality2 wrote:
| Well, you know the saying about eggs and omelettes. I wish
| you luck with getting AWS to listen to you!
| kmcquade wrote:
| Thanks :)
| denismurphy wrote:
| you're an evil genius
| nic-waller wrote:
| Impressive tool, but the supporting documentation is what I
| appreciate most.
|
| 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.
| kmcquade wrote:
| Great feedback! I will update the docs accordingly.
| procrastinatus wrote:
| Do analogous tools exist for GCP and Azure?
| [deleted]
| kmcquade wrote:
| 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;
| yevpats wrote:
| Cool. Another tool in the space -
| https://github.com/cloudquery/cloudquery open-source framework to
| ask questions about your cloud infrastructure with SQL.
| jarym wrote:
| Something tells me this is not AWS specific - how do
| GCP/Azure/Heroku stack up in comparison?
| artful-hacker wrote:
| I for one would specifically be interested in someone's review
| of Azure Defender, since it claims to be able to handle AWS and
| GCP
| pachico wrote:
| 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.
| sk5t wrote:
| 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?
| syntheticcorp wrote:
| The main repository seems to have been taken down but it is still
| available at https://github.com/kmcquade/endgame and on Pypi
| arkwin wrote:
| Thanks!
| bwaine wrote:
| It would be nice if this was the other way round :'''''(
|
| # 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-run
|
| Looks like it can be reversed with --undo, but brown trousers
| time if you groggily run it at 08:30am coffee in hand.
| gchamonlive wrote:
| dry run should be the default, and for you to actually do
| damage, you should explicitly run with a flag like `--commit`
| or `--deploy-evil-payload "yes I am certain of this"`
| [deleted]
| kmcquade wrote:
| 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.
| Serow225 wrote:
| Yes please, thanks!!
| [deleted]
| idclip wrote:
| Seems to have been taken down. A shame id have enjoyed reading
| that code
| l33tman wrote:
| 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.
|
| 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.
| kmcquade wrote:
| 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.
| kmcquade wrote:
| > 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.
| urda wrote:
| > First, authenticate to AWS CLI using credentials to the
| victim's account.
|
| ... 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.
| ManWith2Plans wrote:
| 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.
|
| 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.
| [deleted]
| stjohnswarts wrote:
| Initially stuff like this is scary but it leads to good things
| in the end. Tighter security, opening customers eyes. Etc.
| Probably the better black hatters already knew about these and
| your organization wasn't really worth anything to them so they
| skipped it. At least tools like these help us security
| neophytes have a little bit of a fighting chance out there on
| the Wild Wild Web.
| poxrud wrote:
| There are a lot of other tools in this space and people that
| specialize in AWS pentesting. Another popular tool is Pacu:
| https://rhinosecuritylabs.com/aws/pacu-open-source-aws-explo...
| cddotdotslash wrote:
| I can almost guarantee you that attackers focusing on AWS
| environments have all sorts of similar (if not worse) tools.
| The fact that this is public hopefully terrifies AWS into
| improving their security usability and making these kinds of
| exposures more difficult. What's important to remember is that
| there isn't actually any _vulnerability_ here (the tool still
| requires valid authentication to work); it just makes it 100x
| easier to automate.
| xahrepap wrote:
| The scary part is who has built tools like this before but
| people didn't know they existed?
|
| 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!
| simonebrunozzi wrote:
| Make sure you check AWS' pentesting policy [0].
|
| [0]: https://aws.amazon.com/security/penetration-testing/
| jasperran wrote:
| Given that they wrote a tool dedicated to pentesting AWS, I'm
| sure the author is very familiar with that.
|
| Also the pentesting policy explicitly states that customers can
| pentest without approval.
| tbrock wrote:
| Can someone explain why you'd ever want to run this in the non-
| dryrun mode?
|
| 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.
| stevehawk wrote:
| for me, my environments are in different AWS accounts and can
| be torn down and stood back up rather quickly. so it wouldn't
| be a big deal to let this destroy a dev environment in the name
| of science so that i could implement improvements.
| artful-hacker wrote:
| Red team exercises come to mind.
| ramimac wrote:
| Exposing resources to a specific "evil principal" via Endgame
| would be reasonable in some attack simulations/red team
| engagements
| hnjst wrote:
| To test autoremediation and alerting. At least in the
| environment I'm evolving these days it makes sense.
| arkwin wrote:
| It's gone now. :( I should have cloned it, anyone have a clone?
| jaegerpicker wrote:
| Not a clone but you can download the code from here:
|
| 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.
| pachico wrote:
| 404? someone got an urgent call from AWS and politely requested
| to remove it since both companies are supposed to be partners?
| grapes wrote:
| Here's the source:
| https://files.pythonhosted.org/packages/0c/f0/9eced7d6c57483...
| poxrud wrote:
| https://github.com/clintgibler/endgame
| placebo wrote:
| that's gone too :)
| bdibs wrote:
| It looks that way.
|
| Looks like some of it was archived though at https://web.archiv
| e.org/web/20210216153239/https://github.co....
|
| Also still live at PyPI: https://pypi.org/project/endgame/
| pachico wrote:
| Of course this was going to happen. Who knows, probably this
| way the author achieved what be wanted and those policy
| exploits will be revisited, at last.
| booleanbetrayal wrote:
| 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.
|
| 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.
| kapilvt wrote:
| fwiw the opensource (and cncf incubator project)
| https://cloudcustodian.io 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.
| robblbobbl wrote:
| 404 now
| [deleted]
| sandGorgon wrote:
| @kmcquade ur awesome ! we are users of
| https://github.com/salesforce/policy_sentry and definitely
| definitely https://github.com/salesforce/cloudsplaining .
|
| If I could give you guys money, I would. You should totally build
| a startup around it.
| kmcquade wrote:
| Aw, thank you. I really appreciate that.
| sub7 wrote:
| lol you're about to get a giant offer from Amazon. Tell them you
| want 10x whatever they first offer and they'll say yes.
| avi_vallarapu wrote:
| 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.
|
| https://news.ycombinator.com/item?id=26146440
___________________________________________________________________
(page generated 2021-02-16 23:00 UTC)