My Backdoors to Your AWS Infrastructure – Part 1: Public EC2
Micha? Brygidyn
Cloud Security Architect | AWS Ambassador | Security Researcher | Conference Speaker | AWS Community Builder
Some time ago I promised a series of articles on backdoors in Amazon Web Services (AWS), and it's time for the first part. In this article, I'll cover the first group - public Elastic Compute Cloud (EC2) instances.
Before we dive into the details - a backdoor is a hidden entry point into a system that allows unauthorized access to its resources. In AWS, a backdoor can be created by exploiting vulnerabilities in access control mechanisms, such as IAM users and roles, and security groups. A backdoor can be used to steal sensitive data, perform malicious actions, or launch attacks against other systems, among other things. Proper understanding of access controls significantly helps to prevent backdoor attacks.
Now, let's move on to the technical aspects of creating backdoors in AWS.
A new public EC2 instance with IAM Role
The first scenario we'll explore is creating a new, public EC2 instance. Here's how it works:
Phase 1: Preparation
To create a backdoor instance, I begin by baking an Amazon Machine Image (AMI) – a virtual machine image that I will use as a template. To create the image, I first need to run a new instance on one of the AWS accounts I have access to. On the EC2, I install tools that may be needed later. I also create a user with SSH access and sudo privileges. This way, I won't need an EC2 key-pair on the target account, which means fewer required permissions. Once the image is ready, I share it with all AWS accounts on which I plan to create my backdoors.
Phase 2: Execution
The attack relies on exploiting already obtained access at the appropriate level. In an ideal scenario, the attacked account already has EC2 instances with assigned IAM roles. To start a new EC2, I only need permissions for the ec2:RunInstances action. The difficulty arises when providing the required parameters. While I know the AMI ID because it is my previously shared image, the rest is usually unknown. To obtain this information, I will need the ec2:DescribeInstances action and at least one existing EC2 from which I can read the subnet and Security Group IDs, as well as the instance profile name and ARN. After starting my new EC2, all that remains is to attach an existing instance profile to it using the ec2:AssociateIamInstanceProfile action.
Summary:
With permissions to perform only three seemingly harmless actions (ec2:RunInstances, ec2:DescribeInstances, ec2:AssociateIamInstanceProfile), I was able to create the first backdoor in the attacked AWS environment.
Local user added to any running public EC2 instance
In the second scenario, I will utilize an existing instance with public access.
Phase 1: Preparation
None - The EC2 instance is already running and is accessible from the public internet.
领英推荐
Phase 2: Execution
The first step is to create a user on the selected public EC2 instance, which can be done in several ways.
The easiest way is if I can find SSH access to the EC2 while gaining access to the AWS account. Then, I can simply log in to the compromised user account and create my own user.
However, what if I don't have SSH access?
Here, AWS Systems Manager comes to the rescue. It has more than one way to accomplish my task. The critical assumption is that the attacked EC2 instance must be managed, meaning that the SSM agent is installed and communicating with the API. The SSM Agent is preinstalled by default on multiple AMIs provided by AWS (https://docs.aws.amazon.com/systems-manager/latest/userguide/ami-preinstalled-agent.html):
If my permissions on the attacked AWS account allow me to execute the ssm:StartSession action and I know the EC2 ID, I can easily create a session and gain SSH access using AWS CLI or the console.
Or I can use ssm:SendCommand action to execute various commands on selected EC2 instances without even logging in to them.
It's worth noting that the SSM Agent can be a backdoor in itself if someone is not aware of its existence, and cloud developers have access to the above actions.
Summary:
Permissions to execute two more actions (ssm:StartSession, ssm:SendCommand), frequently used by many teams, allow for easy creation of a backdoor hidden in your existing infrastructure.
I'm in!
So, what does access to EC2 on someone else's AWS account really give me?
Firstly, AWS API with permissions defined by policies attached to the assigned IAM role. I can extract temporary access keys from the instance to use them outside of EC2. However, if I don't want to be detected too quickly by GuardDuty, it's wiser to perform these actions directly from EC2.
The second benefit is access at the VPC level. I am able to "talk" to any other network resource, provided the Security Group rules allow me to do so (if not, I can just modify them!).
In both scenarios, only the minimum options were presented. Each additional permission would allow me to do more - change the IAM role assigned to the EC2, modify Security Group rules, or loosen NACL.
Risks associated with backdoors in AWS can be severe. Having a backdoor in your environment can lead to data breaches, system compromise, and other malicious activities. As cloud computing continues to grow in popularity, securing access control mechanisms in AWS becomes increasingly important. By understanding the risks and following the Principle of Least Privilege, you can minimize the likelihood of backdoor attacks and protect your systems and data.
In order to connect to an EC2 with SSM, don’t you need valid AWS credentials for that AWS account?
AWS Architect / DevOps Evangelist / Lead
1 年Michal this is an excellent article for planning attack scenarios during security audit. By reading this article I got a feeling that back-door-SSM is actually front-door-AWS, and the main (implied) culprit here is that some people lose credentials to not audited IAM user accounts with an admin-like ssm:* policy?