Full Report
A targeted campaign exploited Server-Side Request Forgery (SSRF) vulnerabilities in websites hosted on AWS EC2 instances to extract EC2 Metadata, which could include Identity and Access Management (IAM) credentials from the IMDSv1 endpoint. [...]
Analysis Summary
# Vulnerability: SSRF Abuse Against AWS EC2 Instances Utilizing IMDSv1
## CVE Details
- CVE ID: Not explicitly provided for the SSRF issue, but the context discusses a generic threat exploiting Server-Side Request Forgery (SSRF) against sites hosted on AWS EC2 using the legacy Instance Metadata Service Version 1 (IMDSv1).
- CVSS Score: Not provided.
- CWE: CWE-918 (Server-Side Request Forgery) is the underlying mechanism exploited.
## Affected Systems
- Products: Web applications hosted on Amazon Web Services (AWS) Elastic Compute Cloud (EC2) instances.
- Versions: Instances configured to use **AWS Instance Metadata Service Version 1 (IMDSv1)**. Instances using IMDSv2 are generally protected against this specific attack vector.
- Configurations: Applications vulnerable to Server-Side Request Forgery (SSRF) that interact with the internal EC2 metadata IP address (`169.254.169.254`).
## Vulnerability Description
The vulnerability stems from the presence of Server-Side Request Forgery (SSRF) flaws within web applications hosted on AWS EC2. Attackers exploit these SSRF vulnerabilities to force the vulnerable application to make requests to the local, internal IP address `169.254.169.254`. This IP serves the EC2 Instance Metadata Service (IMDS). If the instance is running IMDSv1, external requests can indirectly retrieve sensitive instance metadata, including configuration details and, critically, IAM security credentials, leading to account compromise.
## Exploitation
- Status: **Actively exploited in the wild** (Campaign active between March 15 and 25).
- Complexity: **Low** (The article notes a systematic approach with rotating parameters, but the core exploit relies on existing SSRF and vulnerable IMDSv1 configuration).
- Attack Vector: **Network** (Remote SSRF exploitation).
## Impact
- Confidentiality: **High** (The primary goal is stealing AWS credentials/IAM keys).
- Integrity: **High** (Compromised credentials allow manipulation of cloud resources).
- Availability: **Potential** (Depending on the privileges of the stolen role, resource deletion or degradation is possible).
## Remediation
### Patches
No specific application patches are detailed in the context, but the recommended remediation is a configuration change:
- Update / Migrate all EC2 instances to use **AWS Instance Metadata Service Version 2 (IMDSv2)**. IMDSv2 requires session tokens (authentication) to access metadata, mitigating SSRF attacks targeting the metadata endpoint.
### Workarounds
- For applications running on IMDSv1 that cannot immediately migrate to IMDSv2:
- Implement stringent outbound firewall/Security Group rules to block access to the internal metadata IP address (`169.254.169.254`) from application processes, if possible.
- Review and harden the application logic that handles external URLs to defend against all SSRF attempts.
## Detection
- Indicators of compromise: Logs showing HTTP requests originating from the application server targeting the internal IP address `169.254.169.254` (specifically paths like `/latest/meta-data/` or `/user-data/`).
- Detection methods and tools: Monitoring network flow/access logs for internal traffic to **`169.254.169.254`** from application servers. Reviewing F5 Labs threat reports/recent vulnerability data for emerging patterns.
## References
- Vendor advisories: AWS documentation regarding the migration from IMDSv1 to IMDSv2.
- Relevant links:
- General article source: bleepingcomputer com/news/security/hackers-target-ssrf-bugs-in-ec2-hosted-sites-to-steal-aws-credentials/
- F5 Labs threat trends report (referenced for exploitation data).