Top 7 AWS security vulnerabilities based on real-world tests

Imagine you ordered a security assessment of your AWS infrastructure, hoping that the report would be juicy in wicked hacking techniques. However, the document starts with things like “Lack of MFA for users” or “Lack of Log File Validation”. These security misconfigurations might sound a little disappointing right? Let me show you why these findings could be a real threat or even a business killer in some cases.

In this article, I’ll focus on the most common vulnerabilities (according to our own tests), that are exploitable and could lead to unpleasant consequences.

To give you a bit of a heads up – below is a list of vulnerabilities that are discussed later in this article:

1. Sensitive data in X in plaintext
2. Publicly accessible SQS
3. Publicly accessible S3
4. Privilege escalation
5. Wide cross-account access
6. Lack of monitoring
7. Lack of Transfer Lock

Disclaimer – probably you would be a little surprised that I’m not writing about the most popular AWS vulnerabilities overall, but that’s because they are already well known and described – highlighting the less obvious ones may be more beneficial for the community 😉

About risk level – it always depends on the case, and it could differ. In this article, I categorized the risks as they appear in our reports.

1. Sensitive data in X in plaintext

First things first – what could be X? EC2 User Data, EC2 Auto Scaling Launch configuration, Lambda environment variables, Elastic Beanstalk environment variables, CloudFormation Stack parameters – these are places where we are often finding unencrypted and hardcoded secrets. 

Secrets could be retrieved by any user with suitable privileges (for example ec2:DescribeInstances or autoscaling:DescribeLaunchConfigurations). The severity of this issue depends on the nature of the secret. Usually, it is rated as medium or high risk, based on the following factors:

1. Privileges needed to read secrets are commonly used by a client, probably unconsciously as they aren’t required for most of the users/roles to do their work.
2. Secrets found may have critical risk impact  – Jira recovery admin password, Gitlab runner credentials, Sonar credentials, credentials to monitoring services – to sum up, services with access to our code repositories, internal discussions, bugs, documentation – a lot of data which shouldn’t be accessible for an anonymous user.
3. As our red team tests show, it is always possible to own an account within the company by targeted phishing. It isn’t the hardest thing to takeover a developer account, read the credentials and get access to a lot of things, or escalate further inside a private network.

Risk: Medium or high.

Hint: Store your secrets in AWS Secret Manager! You could also use the Systems Manager Parameter Store (but remember to use encrypted parameters!).

2. Publicly accessible SQS

Publicly accessible SQS indicates that it is possible to read messages from it. We found that typically if SQS is opened to read, it is also opened to write or delete. All of this means that anonymous user can read messages, write some malicious data, or delete real messages before they are handled by your code.

Leaking sensitive data, Denial-of-Service of an application, executing malicious tasks – these are a few of the consequences, as it depends on how you use SQS.

Risk: High

Hint: Modify queue Access policy – disallow public access, configure access only for services that actually need it.

3. Publicly accessible S3

As my last research shows, public buckets are still a problem. During our assessments, we often find publicly readable buckets, sometimes even writable. It means that an anonymous user can read stored data and in the worst-case scenario – overwrite it (which is equivalent to deleting it, if Versioning is disabled) or host malicious content using our bucket. If the bucket is hosting static content, then having write privilege gives an option to change anything inside and for example inject XSS.

Risk: From low to high (highly depends on the content and privileges of the bucket)

Hint: Disallow public read access (until it’s a static content bucket) and write access using ACLs or Bucket policy. Turn on Block Public Access options if you want to ensure it.

4. Privilege escalation

Privilege escalation is a classical vulnerability that allows obtaining more privileges than one account originally had. For example, a typical case is to give an employee iam:PassRole and ec2:RunInstances permissions, to give it the ability to create a new EC2 instance and pass an existing role to it. If a role with higher privileges that could be assumed by EC2 exists, then this employee is able to escalate his privileges by creating a new instance with this role.

It is a common problem for AWS environments that grew quickly, managing a multi-account environment is a different thing and could be challenging. The second problem is trusting AWS Managed policies too much. They can offer way more privileges than is needed, which could create a situation where privilege escalation is possible. Also remember, that AWS updates these policies regularly. They could change them in a way, which could create escalation opportunities in your account.

Risk: High

Hint: A simple recipe doesn’t exist in this case. If we know about privilege escalation, modify IAM policies to mitigate it. The most important thing is to prevent a situation like that – avoid Inline policies, use Least Privilege Principle when creating new policies, use Groups for user management. Remember that privilege escalation could be done using services like EC2 or Lambda, by passing the role.

5. Wide cross-account access

Using AWS Organizations and different AWS accounts for dividing projects and different stages (test, prod, etc.) is recommended. Employees in order to work, have to move in between different accounts, which could be done for example by obtaining temporary security credentials – in other words, assuming roles. But what could go wrong? What if Trust policies are misconfigured and anyone can assume the Admin role (privilege escalation scenario)? Imagine that everyone can access any account (also production stage). Owning one user account would be equal to obtaining access to every account.

Risk: Medium or high

Hint: Limit the amount of people which can access production and security accounts. Use Least Privilege Principle – give access to the accounts which the employee really needs, not to everyone.

6. Lack of monitoring

That’s the common mistake – having monitoring services turned off or using them only in one or two regions. Without monitoring, we won’t know if there is any malicious movement. Furthermore, any forensic action would be impossible – we won’t know how an attacker gained access to which AWS account was used, or what was done – and in the case of monitoring only a few regions, the attacker could target unmonitored ones. The absolute minimum is to turn on CloudTrail in every enabled region.

Risk: Medium

Hint: Make use of the AWS monitoring services – configure CloudTrail (and run it in every enabled region), turn on GuardDuty. Turning on AWS Config in the used regions could be also beneficial. There are other services which could help, but these are the few most important ones.

7. Lack of Transfer Lock

This is the vulnerability that is often overlooked – I also wasn’t sure if I should put this one here. The process of transferring the domain to another registrar seems secure enough. However, not so long ago Cyberis identified a vulnerability which enabled a possibility of domain hijacking by using logic error. Domain hijacking could be devastating for the company (both financially and PR), as it gives an attacker the ability to host a website under your domain. Turning Transfer Lock is really simple mitigation to a lot of problems from a situation like this.

Risk: Low

Hint: Enable Transfer Lock option on your Route53 Domains.

Conclusion 

I’ve described seven vulnerabilities, but remember – there is a lot more than that! I wanted to highlight the most common ones from our own reports. Maybe it’s not too loud about them, but they could lead to serious consequences. Misconfigurations like “Lack of MFA for users” or “Lack of Log File Validation” which I mentioned at the beginning, are also important – having modified logs probably isn’t the best thing for forensics.

I’m planning to describe some of these seven problems in the future – exploitations chains, full remediations and more detailed descriptions.

We recently updated our AWS guide too. If you deal with these solutions on a daily basis, I am sure it will help you a lot:

If you want to be up to date with my cloud security work, you can also follow me on Twitter and / or Linkedin.

Paweł Kusiński Senior IT Security Consultant