Let’s exploit AWS

Robust cloud security measures are critical, as more and more businesses shift their operations to Amazon Web Services (AWS). However, despite the guarantee of unparalleled efficiency and scalability, AWS environments have become popular targets for adverse cyberattacks. This article looks into the complicated landscape of AWS attack scenarios, analyzing the various vulnerabilities and exploits that compromise the security of cloud deployments. We explore how malicious actors penetrate, compromise, and take advantage of AWS infrastructures through a variety of methods, including insider threats, misconfigurations, and sophisticated cyber-attacks.

AWS provides a range of technologies that assist businesses in implementing cloud-based solutions and frequently advance cybersecurity in general. Security flaws can also affect AWS solutions, just like they can with any complicated technology. Malicious threat actors can take advantage of these flaws, whether they are recognized or not, in order to:

• Compromise sensitive business information.
• Access AWS resources without necessary authorization.

Although AWS has multiple security layers in place to prevent any isolated vulnerability in a single AWS solution from causing tangible harm or interrupting service, users of AWS should make sure their AWS systems are sufficiently protected against all known security flaws.

Inadequate Configuration

In order to demonstrate the potential consequences of security misconfigurations and the effectiveness of robust security protocols, we will model attacks on the noncompliant code and show how the compliant code reduces these risks.

• Attack — Exploiting Weak Passwords

With the same weak authentication mechanism as the noncompliant code, this code tries to upload a file to ‘anubhav-bucket’.

• Attack — Exploiting Unrestricted Access

The file that has been made public in the noncompliant code is being attempted to be uploaded to ‘public-bucket’ by this code.

What is non compliant in AWS?

When configuration changes happen among your resources, AWS Config keeps track of them all and determines whether any of the conditions in your rules are broken by them. AWS Config marks a resource and the rule as noncompliant when they both break a rule.

• Impacts of these attacks

The noncompliant environment may allow unauthorized access when the previously mentioned attack codes are used against it because of inadequate security settings.

• Implementing Security Measures

Now, let’s demonstrate how the compliant code prevents these attacks:

1. The strong and unique password used in ‘anubhav-bucket’ ensures that only authorized users can upload files.
2. Restricting ‘private-bucket’ to private access prevents unauthorized access to resources.

• Verifying Security Implementation:

To verify the effectiveness of the compliant code, rerun the attack codes against the compliant environment. You’ll observe that:

1. Attack 1 fails to upload files to ‘anubhav-bucket’ due to the strong authentication method.
2. Attack 2 fails to upload files to ‘private-bucket’ as it’s not publicly accessible.

Insecure Data Storage

Let’s simulate attacks on the noncompliant code and illustrate how the compliant code reduces these risks in order to highlight the harm caused by insecure data storage practices and the efficiency of secure data storage methods.

• Attack — Unauthorized Access to Sensitive Data

• Attack — Exploiting Lack of Access Control

• Impacts of these attacks:

Due to unsafe data storage procedures, when using the above-mentioned attack codes against a noncompliant environment, sensitive data may be exposed to unauthorized access.

• Implementing Secure Data Storage Measures

1. Sensitive data is stored with encryption using AES256, preventing unauthorized access even if the data is compromised.
2. Access control is implemented to restrict access to the stored data, ensuring only authorized users can access it.

• Verifying the Security Implementation:

To confirm that the security implementation are working, rerun the attack

codes against the compliant environment. You’ll notice that:

1. Attack 1 fails to retrieve sensitive data due to encryption.
2. Attack 2 fails to download data from ‘private-bucket’ due to proper access control.

Execute Discovery Commands on an EC2 Instance

When executing discovery commands on an EC2 instance, a number of commands are run in order to collect data regarding the AWS environment. These commands help an attacker in learning more about the AWS account, locating resources, and possibly organizing additional actions.

The noncompliant code below directly runs different discovery commands on the EC2 instance using the AWS SDK (boto3):

Boto3: Boto3 makes it easy to integrate your Python application, library, or script with AWS services including Amazon S3, Amazon EC2, Amazon DynamoDB, and more.

• The noncompliant code operates under the assumption that the EC2 instance has the required AWS credentials.
• These commands can be executed by anyone having access to the instance, which could expose private data to unauthorized parties.

By explicitly providing AWS credentials, the compliant code that follows shows how to properly secure the execution of discovery commands on an EC2 instance:

• When establishing the EC2 client, the compliant code explicitly gives the AWS credentials (access key, secret key, and session token).
• It ensures right authorization and limits access to authorized users only by doing this.

Download EC2 Instance User Data

Retrieving the user data connected to an EC2 instance is referred to as “downloading EC2 instance user data.” Scripts, configurations, and other data that are run at instance startup can be found in user data. An attacker might try to download user data in the context of an attack scenario in order to learn more about how the instance is configured, obtain private data, or take advantage of any misconfigurations.

The AWS SDK (boto3) is used by the following noncompliant code to retrieve user data for several EC2 instances. Anyone with access to run this code can retrieve user data as it assumes that the code has the required AWS credentials and permissions. This code is not authorized, which means that unauthorized people may see sensitive information:

By explicitly providing AWS credentials, the compliant code that follows shows how to properly secure the retrieval of user data from an EC2 instance:

• When establishing the EC2 client, the compliant code expressly provides the AWS credentials (access key, secret key, and session token).
• By doing so, it ensures proper authorization and restricts access to authorized users only.

Local FileSystem

Investigating the local filesystem after obtaining interactive access to a service such as an EC2 instance is a crucial step in determining the extent of the compromised system. Although the first steps may be similar to those of breaking into a server in a typical situation, the cloud-based architecture of AWS environments brings special considerations. The following are the main steps in investigating the local filesystem in an AWS environment:

1. Discovery of Sensitive Information:

• Passwords and Credentials: Examine configuration files, application logs, temporary directories, and other files for stored passwords, API keys, or other sensitive credentials.
• Application Files and Documentation: Look through the filesystem for documentation, scripts, or application-specific files that could provide information about how the system is configured and runs.
• Home Directories: Look through user home directories for anything that might be considered sensitive data, like SSH keys or configuration files with information about privileged access.
• Environment Configuration: Examine configuration files and environment variables for any settings or parameters that might reveal security holes or private information.

2. Privilege Escalation:

• Misconfigurations: Search for files, directories, or services that have been configured incorrectly as these could be used to elevate privileges on the system.
• Kernel Exploits: Examine the system for software installed on it or kernel vulnerabilities that could be used to obtain more access.
• Permissive Privileges: Determine which services or processes are operating with elevated privileges and look into possible ways to take advantage of these rights in order to further escalate privileges.

3. Pivoting to Other Services:

• Port Scanning: Use port scans to find services that are operating on different systems or within the same network and might be targets for lateral movement or additional exploitation.

AWS Cloud Environment Specific Considerations:

• Discovery of AWS Access Credentials: Particular attention should be paid to AWS access credentials kept in the filesystem, such as temporary security tokens, access keys, or IAM user credentials.
• Verification of AWS Metadata Endpoint: Verify that the AWS metadata endpoint can be accessed at common URLs like http://169.254.169.254/ or its IPv6 equivalent. Unauthorized access to this endpoint may expose private data or even make it possible to exploit the instance metadata service (IMDS).

Amazon AWS VPN Client 2.0.0

Through secure SSL channels, enterprises can access private networks and AWS services with the help of fully managed VPN solutions from AWS.

Two significant flaws in the AWS VPN client 2.0.0 allowed hackers to escalate their access privileges and reveal hash values that could be used to decipher the login credentials of authentic users.

• Vulnerability 1: OpenVPN config files

One vulnerability concerns the validation of OpenVPN configuration files. It is possible to inject external configuration commands into these files and set them up to execute the AWS VPN client with elevated system privileges. This increases the possibility of privilege escalation and denial of service attacks by giving hackers partial or total control over AWS VPN configurations.

• Vulnerability 2: Reference paths for authentication

The reference paths for security authentication are revealed by the second vulnerability. The network level authentication hash function value is disclosed by the VPN when it verifies the file path, and this information may be utilized to decrypt user credential information like pin codes and passwords.

The 3.0.0 version of the AWS VPN client now has these vulnerabilities fixed.