forked from DavidDikker/endgame
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
5 changed files
with
122 additions
and
21 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,4 +1,58 @@ | ||
| Endgame | ||
| ======= | ||
| Endgame: Creating Backdoors in AWS | ||
| ================================== | ||
|
|
||
| Introduction from the main README should go here after we iron it out. | ||
| An AWS Pentesting tool that lets you use one-liner commands to backdoor an AWS account's resources with a rogue AWS account - or to the entire internet 😈 | ||
|
|
||
| <p align="center"> | ||
| <img src="images/endgame.gif"> | ||
| </p> | ||
|
|
||
|
|
||
| Endgame abuses AWS's resource permission model to grant rogue users (or the internet) access to an AWS account's resources with a single command. | ||
|
|
||
| Endgame demonstrates (with a bit of shock and awe) how simple human errors in excessive permissions (such a granting `s3:*` access instead of `s3:GetObject`) can be abused by attackers. These are not new attacks, but AWS's ability to **detect** _and_ **prevent** these attacks falls short of what customers need to protect themselves. This is what inspired us to write this tool. Follow the [Tutorial](./tutorial.md) and observe how you can expose resources across **17 different AWS services** to the internet in a matter of seconds. | ||
|
|
||
| The resource types that can be exposed are of high value to attackers. This can include: | ||
| * Privileged compute access (by exposing who can invoke `lambda` functions) | ||
| * Database snapshots (`rds`), Storage buckets (`s3`), file systems (`elasticfilesystem`), storage backups (`glacier`), disk snapshots (`ebs` snapshots), | ||
| * Encryption keys (`kms`), secrets (`secretsmanager`), and private certificate authorities (`acm-pca`) | ||
| * Messaging and notification services (`sqs` queues, `sns` topics, `ses` authorized senders) | ||
| * Compute artifacts (`ec2` AMIs, `ecr` images, `lambda` layers) | ||
| * Logging endpoints (`cloudwatch` resource policies) | ||
| * Search and analytics engines (`elasticsearch` clusters) | ||
|
|
||
| Endgame is an attack tool, but it was written with a specific purpose. We wrote this tool with desired outcomes for the following audiences: | ||
| 1. **AWS**: We want AWS to empower their customers with the capabilities to fight these attacks. Our recommendations are outlined in the [Recommendations to AWS](./recommendations-to-aws.md) section. | ||
| 2. **AWS Customers and their customers**: It is better to have risks be more easily understood and know how to mitigate those risks than to force people to fight something novel. By increasing awareness about Resource Exposure and excessive permissions, we can protect ourselves against attacks where the attackers previously held the advantage and AWS customers were previously left blind. | ||
| 3. **Blue Teams**: Defense teams can leverage the guidance around user-agent detection, API call detection, and behavioral detection outlined in the [Recommendations to Blue Teams](./recommendations-to-blue-teams.md) section. | ||
| 4. **Red Teams**: This will make for some very eventful red team exercises. Make sure you give the Blue Team kudos when they catch you! | ||
|
|
||
|
|
||
| ## Supported Backdoors | ||
|
|
||
| Endgame can create backdoors for resources in any of the services listed in the table below. | ||
|
|
||
| Note: At the time of this writing, [AWS Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-resources.html) 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. 😊 | ||
|
|
||
| | Backdoor Resource Type | Support | [AWS Access Analyzer Support][1] | | ||
| |---------------------------------------------------------|---------|----------------------------------| | ||
| | [ACM Private CAs](risks/acm-pca.md) | ✅ | ❌ | | ||
| | [CloudWatch Resource Policies](risks/logs.md) | ✅ | ❌ | | ||
| | [EBS Volume Snapshots](risks/ebs.md) | ✅ | ❌ | | ||
| | [EC2 AMIs](risks/amis.md) | ✅ | ❌ | | ||
| | [ECR Container Repositories](risks/ecr.md) | ✅ | ❌ | | ||
| | [EFS File Systems](risks/efs.md) | ✅ | ❌ | | ||
| | [ElasticSearch Domains](risks/es.md) | ✅ | ❌ | | ||
| | [Glacier Vault Access Policies](risks/glacier.md) | ✅ | ❌ | | ||
| | [IAM Roles](risks/iam-roles.md) | ✅ | ✅ | | ||
| | [KMS Keys](risks/kms.md) | ✅ | ✅ | | ||
| | [Lambda Functions](risks/lambda-functions.md) | ✅ | ✅ | | ||
| | [Lambda Layers](risks/lambda-layers.md) | ✅ | ✅ | | ||
| | [RDS Snapshots](risks/rds-snapshots.md) | ✅ | ❌ | | ||
| | [S3 Buckets](risks/s3.md) | ✅ | ✅ | | ||
| | [Secrets Manager Secrets](risks/secretsmanager.md) | ✅ | ✅ | | ||
| | [SES Sender Authorization Policies](risks/ses.md) | ✅ | ❌ | | ||
| | [SQS Queues](risks/sqs.md) | ✅ | ✅ | | ||
| | [SNS Topics](risks/sns.md) | ✅ | ❌ | | ||
|
|
||
| [1]: https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-resources.html |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,16 @@ | ||
| # Recommendations to AWS | ||
|
|
||
| While [Cloudsplaining](https://opensource.salesforce.com/cloudsplaining/) (a Salesforce-produced AWS IAM assessment tool), showed us the pervasiveness of least privilege violations in AWS IAM across the industry, Endgame shows us how it is already easy for attackers. These are not new attacks, but AWS's ability to **detect** _and_ **prevent** these attacks falls short of what customers need to protect themselves. | ||
|
|
||
| [AWS Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) is a tool produced by AWS that helps you identify the resources in your organization and accounts, such as Amazon S3 buckets or IAM roles, that are shared with an external entity. In short, it **detects** instances of this resource exposure problem. However, it does not by itself meet customer need, due to current gaps in coverage and the lack of preventative tooling to compliment it. | ||
|
|
||
| At the time of this writing, [AWS Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-resources.html) 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. 😊 | ||
|
|
||
| The lack of preventative tooling makes this issue more difficult for customers. Ideally, customers should be able to say, "Nobody in my AWS Organization is allowed to share **any** resources that can be exposed by Endgame outside of the organization, unless that resource is in an exemption list." This **should** be possible, but it is not. It is not even possible to use [AWS Service Control Policies (SCPS)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) - AWS's preventative guardrails service - to prevent `sts:AssumeRole` calls from outside your AWS Organization. The current SCP service limit of 5 SCPs per AWS account compounds this problem. | ||
|
|
||
| We recommend that AWS take the following measures in response: | ||
| * Increase Access Advisor Support to cover the resources that can be exposed via Resource-based Policy modification, AWS RAM resource sharing, and resource-specific sharing APIs (such as RDS snapshots, EBS snapshots, and EC2 AMIs) | ||
| * Create GuardDuty rules that detect anomalous exposure of resources outside your AWS Organization. | ||
| * Expand the current limit of 5 SCPs per AWS account to 200. (for comparison, the Azure equivalent - Azure Policies - has a limit of [200 Policy or Initiative Assignments per subscription](https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/azure-subscription-service-limits#azure-policy-limits)) | ||
| * Improve the AWS SCP service to support an "Audit" mode that would record in CloudTrail whether API calls would have been denied had the SCP not been in audit mode. This would increase customer adoption and make it easier for customers to both pilot and roll out new guardrails. (for comparison, the Azure Equivalent - Azure Policies - already [supports Audit mode](https://docs.microsoft.com/en-us/azure/governance/policy/concepts/effects#audit). | ||
| * Support the usage of `sts:AssumeRole` to prevent calls from outside your AWS Organization, with targeted exceptions. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,31 @@ | ||
| # Recommendations to Blue Teams | ||
|
|
||
| There are three general methods that blue teams can use to detect the usage of this tool: | ||
| 1. User Agent Detection | ||
| 2. API call detection | ||
| 3. Behavioral-based detection | ||
|
|
||
| ## User Agent Detection | ||
|
|
||
| Endgame uses the user agent `HotDogsAreSandwiches` by default. While this can be overriden using the `--cloak` flag, defense teams can still use it as an IOC. | ||
|
|
||
| The following CloudWatch Insights query will expose events with the `HotDogsAreSandwiches` user agent in CloudTrail logs: | ||
|
|
||
| ``` | ||
| fields eventTime, eventSource, eventName, userIdentity.arn, userAgent | ||
| | filter userAgent='HotDogsAreSandwiches' | ||
| ``` | ||
|
|
||
| This query assumes that your CloudTrail logs are being sent to CloudWatch and that you have selected the correct log group. | ||
|
|
||
| ## API Call Detection | ||
|
|
||
| Further documentation on how to query for specific API calls made to each service by endgame is available in the [risks documentation](./risks/). | ||
|
|
||
| ## Behavioral-based detection | ||
|
|
||
| Behavioral-based detection is currently being researched and developed by [Ryan Stalets](https://twitter.com/RyanStalets). [GitHub issue #46](https://github.com/salesforce/endgame/issues/46) is being used to track this work. We welcome all contributions and discussion! | ||
|
|
||
| #### Further Blue Team Reading | ||
|
|
||
| Additional information on AWS resource policies, how this tool works in the victim account, and identification/containment suggestions is [here](resource-policy-primer.md). |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters