How Secure is a CIS/AWS Compliant Cloud Environment?

Alleen beschikbaar in het Engels

Blogpost 29 April 2021 by Roy Stultiens, Security Analyst at Secura

At Secura we see clients wanting to comply with industry standards or security baselines to make sure their cloud environment is properly secured. In cloud environments, one of the common baselines is from CIS (Center for Internet Security [1]). These baselines bring value and basic security to an environment, however you actually might still be at risk of an attack as our research shows.

One of our security analysts has conducted a research to find out how secure a fully CIS compliant AWS cloud environment is and if that would protect against commonly found misconfigurations and vulnerabilities. Results are that with three commonly used baselines still 4 out of 6 common attacks can be carried out. Within this article we share the details of this research and provide advice on common misconfigurations or security flaws to support you in securing your cloud.

Commonly used Security Benchmarks/Baselines

First the most popular AWS security frameworks were gathered as commonly used by our clients and from our experience in cloud assessments. For AWS, three security frameworks were identified, namely:

• CIS Amazon Web Services Foundations benchmark v1.2 (2018) [2]
  This benchmark is by far the most popular and provides 49 security recommendations about IAM, Logging, Monitoring and Networking. The recommendation is either level 1 or level 2, where level 2 are defense in-depth measures that might impact performance of a service. The recommendations are generic and can be applied on all AWS environments.
• CIS AWS Three-tier Web Architecture benchmark v1.0 (2016) [3]
  The Three-tier benchmark consists of 96 recommendations, specified to specific services, such as EC2 (Elastic Computing) and databases. The document is aimed on using the three-tier architecture. To implement this benchmark on other architectures requires in-depth knowledge from the user.
• AWS Foundational Security Best Practices standard [4]
  This standard is released by AWS and in constant development. At the time of writing it has 70 security recommendations, whilst during the research it consisted of 31 rules. All rules are service specific and are fully integrated with the AWS Security Hub.

Common Misconfigurations and/or Vulnerabilities in Cloud/AWS

While Secura uses security benchmarks and baselines in her cloud assessments, our experts tend to take a holistic approach versus only checking these baselines. In real-life conducted cloud assessments, many different misconfigurations and vulnerabilities were found. A selection of the most common ones are:

1. Server Side Request Forgery (SSRF) on EC2 [5]
   In this scenario, an AWS compute instance (EC2) is launched with permissions to read S3 buckets. However, the webservice running on the instance contains a vulnerability which allows an attacker to let the server execute requests on his behalf. An attacker can abuse this to query the Instance Metadata Service of AWS and extract the credentials that the machine uses to access the S3 buckets. More details can be found in this video.
2. Secrets stored in user-data on EC2 instances [6]
   User-data on EC2 instances is often used for first-boot setup scripts. It might be tempting to store secrets such as API or access keys in the user-data, such that these can be pushed to the machine during installation. However, this data is unencrypted and can be extracted using the Instance Metadata Service or using the AWS Console. Storing secrets in user-data is not only a risk for outside attackers, also insiders might extract valuable information. More details can be found in this video.
3. Public snapshots from EBS volumes [7]
   Elastic Block Store (EBS) volumes are the hard drives of EC2 instances. Using snapshots to be able to return the machine to a previous state is a common and good practice. AWS allows users to share their snapshots, either with a specific AWS accounts or with all accounts (public). Public snapshots can be cloned by everyone, the data residing in the snapshot is not safe and can easily be extracted and scanned for any secrets. See the research of Bishopfox.
   
4. Public read/write permissions on S3 buckets
   Perhaps the best known cause of data breaches are misconfigured S3 buckets. These buckets allow near unlimited storage and can be configured to allow public access. If this configuration is made, only having the bucket name is enough to extract all data.
5. Code injection vulnerabilities in Lambda functions [8]
   They can be used for all kinds of tasks, such as object labeling, image processing and notifications. To successfully perform these tasks, the functions are often given permissions via IAM Roles on other AWS services, such as S3 or EC2. When the event is fired, the Lambda function triggers and executes the programmed code. If this code contains an injection vulnerability, an attacker might be able to extract the system variables of the function. This includes the AWS credentials that are used to access other AWS services. More details can be found in this video.
6. Secrets stored in environment variables in Lambda functions
   Lambda functions are serverless compute services monitoring the environment. When creating a Lambda function, it is possible to assign environment variables, which can be used by the code inside the function. Often these variables include secrets, such as API keys or even access credentials. The environment variables can be extracted by an attacker if a code injection vulnerability exists in the code. In addition, inside attackers can read the configured environment variables in plain text.

A Vulnerable Compliant Environment

To test if actual compliant cloud environments are at risk for the above mentioned attacks, we set up an AWS test environment. All of these vulnerabilities were developed into deployable scenarios with the use of Terraform. Terraform is an infra-as-code software tool, which allows users to define infrastructure code. This ensures that each time the scenarios are deployed, they are exactly the same and don’t require manual configurations.

The AWS test environment was configured to be compliant with the different benchmarks and security standards. Then the resources were deployed using Terraform. After the deployment, the environment was scanned to ensure it was still compliant with the security standards.

Results

Each attack was executed in the test environment. The results can be found in the table below, where X indicates not protected and otherwise the relevant control is displayed:

The results indicate that the most common security benchmark, the CIS AWS Foundations benchmark, does not protect against any of the implemented attacks! The framework gives a more secure environment, but it lacks in-depth defenses for popular and commonly used AWS services such as EC2, S3 and Lambda.

The Three-tier framework prevents having public EBS snapshots due to controls 1.5 and 1.6., but other attacks or misconfigurations are still possible. Controls 1.5 and 1.6 ensure that the EBS volumes are encrypted. This prevents snapshots from being publicly shared, since the decryption key is not publicly accessible. This framework is less often seen as it is harder to apply to generic cloud architectures.

The AWS Foundational Security Best Practices standard provides better protection, especially against publicly exposed S3 buckets. The controls S3.1 – S3.3 explicitly control that buckets should not be publicly readable or writable. This prevents the number one reason for cloud related data breaches. Also the EC2.1 control prevents EBS snapshots, however even with this baseline implemented the environment is still susceptible for 4 out of the 6 attacks!

About Secura

Written by Roy Stultiens. Roy is one of Secura’s cloud experts. With strong passion for cloud security, he is an active member in the cloud knowledge group. Together with this group he performs regular cloud pentests and share experiences with colleagues and clients in this fast developing field.

Footnotes:

[1] Center for Internet Securtiy: https://www.cisecurity.org
[2] CIS Amazon Web Services Foundations White Paper: https://d0.awsstatic.com/white...
[3] CIS Amazon Web Services Three-tier Web White Paper: https://d0.awsstatic.com/white...
[4] AWS Foundational Security Best Practices standard: https://docs.aws.amazon.com/se...
[5] Server Side Request Forgery (SSRF) on EC2: https://youtu.be/6U-DpyEoVRs
[6] Secrets stored in user-data on EC2 instances: https://youtu.be/-p5yCrrsTFA
[7] Dufflebag: Uncovering Secrets in Exposed EBS Volumes: https://labs.bishopfox.com/tec...
[8] Code injection vulnerabilities in Lambda functions: https://youtu.be/gl2hEmN67ms