From Credentials to Control: Exploiting AWS RDS

Introduction

Amazon RDS (Relational Database Service) is a widely used managed database solution offered by AWS, making it a critical asset in many cloud environments. However, its prominence also makes it a prime target for attackers aiming to access sensitive data. This article focuses on how attackers can exploit misconfigurations or vulnerabilities in AWS environments to gain unauthorized access to RDS instances and their backups.

Attackers often seek to share and access RDS snapshots, enabling them to exfiltrate data to external AWS accounts for further analysis or misuse. This technique provides them with long-term control over the data and minimizes the risk of detection compared to direct access. We will delve into the following aspects of such an attack:

1. How attackers identify and extract sensitive credentials.
2. Methods to enumerate RDS snapshots and backups.
3. Techniques for exfiltrating RDS snapshots to an external AWS account.
4. Strategies to mitigate these risks and secure AWS environments against such attacks.

Attack Flow

Step 1: Extracting Credentials from Environment Variables

AWS Lambda functions often store sensitive credentials, such as database connection strings, in environment variables. An attacker with access to the AWS Management Console or an exploited Lambda execution environment can retrieve these credentials.

Step 2: Enumerating RDS Backups

After obtaining credentials, the attacker leverages AWS SDK (Boto3) to list RDS backups. This enables the attacker to identify snapshots and potentially exfiltrate sensitive data.

Step 3: Exfiltrating RDS Snapshots to Another AWS Account

After identifying RDS snapshots, the attacker modifies the snapshot's permissions to share it with a different AWS account under their control. This allows the attacker to download and access the snapshot data externally.

Why Exfiltrate Instead of Access Directly? The attacker may choose to exfiltrate the snapshot to another AWS account instead of accessing the existing one directly for several reasons:

1. Persistence and Control: By copying the snapshot to another account, the attacker gains persistent access to the data, even if the original RDS instance or snapshot is deleted or access is revoked.
2. Avoiding Detection: Accessing the original snapshot or database might generate logs and alerts within the compromised account. Exfiltrating the snapshot reduces the chances of immediate detection.
3. Analysis Flexibility: In their own environment, the attacker can analyze the data without restrictions, restore it to a different RDS instance, and potentially modify the data without impacting the source environment.

Once shared, the attacker can access the snapshot in the target account and restore it to an RDS instance for further exploitation.

Step 4: Accessing Sensitive Data in the RDS Instance

Using the compromised credentials, the attacker connects to the RDS instance and queries sensitive tables.

Mitigation Actions

1. Secure Environment Variables

• Use AWS Secrets Manager: Store credentials securely in AWS Secrets Manager and retrieve them at runtime.
• Restrict IAM Roles: Use least privilege principles to grant Lambda functions access to secrets.

2. Enable Encryption

Ensure all RDS snapshots and databases are encrypted using AWS KMS. Encryption protects data at rest, even if unauthorized access is achieved.

3. Monitor for Suspicious Activity

• Enable AWS CloudTrail to monitor API calls.

4. Implement Network Controls

• Restrict inbound traffic to RDS instances by using security groups.
• Use VPC endpoints for Lambda-RDS communication to avoid exposure to the public internet.