Hacking AWS: HackerOne & AWS CTF 2021 writeup

People interested in AWS Security probably know projects like CloudGoat, flaws and — but I was lacking something new — and here came HackerOne CTF! Last week between 5 and 12 April they organised a CTF together with AWS — and it was a brilliant experience!
If you are interested in Cloud Security or just why I thought it was so brilliant — let’s jump into the reading!

How it started

It’s a Sunday evening — I’m chilling before the workweek and reading some news on the internet. I found an interesting article about the new AWS tool for creating least-privilege IAM policies… And that caused something to click — I forgot about the AWS CTF! And I was hyped to verify my skills by doing it, so — it’s 7 PM — let’s begin!

First challenge — obtaining access to the AWS account

Solving Server-Side Request Forgery

The first thing we see going into the challenge is this landing page:

Landing page

Input box for URL — classic 😄
So, why not use it?

Testing SSRF

HTTP response of our request has a page parameter which is…

Base64 decoded response

Base64 encoded response from the requested URL!

So now I had two thoughts:

  • Command injection — to retrieve environments by for example something like that: “;env” or inject some other command
  • Server-Side Request Forgery (SSRF) — to try communicating with hidden services inside a subnet or with a meta-data server.

Why did I think that? First — a hunch. Furthermore few things I had in head:

In the situation of serverless service (hosted using Lambda), env command would retrieve stored variables (where the access keys obtained from the function’s execution role are stored!)

Second thought — if the input is not validated, then we could try to communicate with internal addresses, perform port scanning or try to harvest data from meta-data server (which is specific for cloud deployments).

After trying the most basic payloads of command injection which did not work, I decided to try communicating with and… bingo!

Request to metadata server

Status 200! So now, there are two things we can pull out from it — User Data and used role temporary access keys!

User data extraction

User Data often stores some sensitive data, like passwords, keys, etc. (what is worth mentioning, that is an incorrect configuration). Let’s try to read it from /latest/user-data:

User data extraction

And we can see something interesting in the response!

S3 bucket — first thought — “Check if this bucket is publicly available” — and as I thought, I did by using my AWS account (with S3FullAccess policy):

Red herring in S3 bucket

And as you can see — it was only a red herring 🙁.

Meta-data server & temporary access keys

As you may or may not know, meta-data server of EC2 instance under path: /latest/meta-data/iam/security-credentials/<role_name> stores access keys to the used role!

Role from metadata

By requesting /latest/meta-data/iam/security-credentials I’ve obtained role name.

And then extracted access keys:

Access keys

Let’s check what we got using AWS CLI — sts get-caller-identity could be called by every entity:

Testing obtained role

We are in!

Second challenge - going deeper

Enumeration & data extraction

Okay, so we are in — what now?

We should get to know what we can do — and because that’s a CTF I’m not scared about brute-forcing IAM permissions (normally it would be very loud and someone should notice a scan like that).

I’ve used enumerate-iam to do the job for me:

Enumerating permissions

And I’ve found something — list-secrets from Secrets Manager and EC2 describe-instances.

Let’s check it out!

I could use normal AWS CLI, but I want to show a little bit more and present a useful tool called Pacu — and more specifically enum__secrets script. It enumerates the Secrets Manager and Parameter Store in every region (or just the one specified).

Pacu found secrets

And there they are! Let’s see them:

Secrets content

Okay — so we’ve got not 10, but 1 secret. probably because of redundancy between regions.

At the moment of finding it, I tried adding it as HTTP header and URL parameter (hoping for some different response from the service) — but nothing new came. I assumed that it probably would be useful later.

So I jumped to the second privilege I had — describe-instances.

With having SSRF vulnerability in mind, I decided to check private IP addresses of existing machines (the region was guessed by trial and error method):

IPs of running instances

SSRF again

I tried all four IP addresses, and one of them returned a different response than the others:

Different response from one of the instances

So now it is known where the API key from Secrets Manager should be used 😉

By using it, I obtained access to the internal application:

Accessed content

As I marked on the screenshot, the JavaScript file was included, by requesting and decrypting it I obtained a nice description of what paths are available:

JavaScript code

Spoiler — /api/get_machines was not working, so /api/get_status is the one we should be interested in. And there’s something we saw already — addr parameter — I assumed that there would be SSRF again, and I was correct, but I doubted for the moment…
You would probably laugh — because of a typo I made in the URL I was obtaining the wrong response for something like 10–20 minutes 😔

I again tried to call the meta-data server, and I was successful — screenshot with correctly written URL — it is important to remember about correct encoding!

Internal metadata

You know the drill — I accessed user-data (nothing new here), requested role name and obtained temporary access keys of it:

New temporary access keys

We are “deeper” in 😉

Third challenge — recovering the flag

Disastrous secret

This is the moment that took me a while, because of my mistake.

I started from… enum__secrets:

New secret

And obtained h101_flag_secret_secondary which at first was fantastic, but it turned out to be disastrous! I didn’t have a clue what to do — tried using it as HTTP Header, URL parameter, POST parameter, looked up online hash databases (to try dehashing).

The welcome screen from the challenge did not help:

Landing page for flag submition

Submit the flag along with your username

I started trying to submit it like , :, hashing the whole string — nothing worked.

Looking upon the HackerOne Twitter comments and Discord channel didn’t help too.

Before this part, everything went so smoothly, that I was really surprised with this turn of events.

So I thought, what is the best thing to do if nothing works?

Return to the last successful point and start everything over.

One step backward, two steps forward

I’ve got a new role, what can I do? Maybe start with smaller steps and… Check our privileges!

Enumerating permissions 2

Oh my… there it is — S3 list-buckets — the thing that I omitted at first.

So let’s list the buckets:

Available buckets

I had the listing privilege of only one of them. There was a single README file that I downloaded and read:

Content of

Instruction on how to generate the flag — nice! From this point, everything went smoothly again.

I requested the internal endpoint:

Internal endpoint

Obtained SQS queue URL using AWS CLI:

SQS queue URL

Sent SQS message:

Sending SQS message

Retrieved generated secret:

Retrieving secret

And traded it for the flag:



Ending thoughts

What can I say — that was a refreshing and interesting challenge! I liked the idea of this kill-chain and how realistic it was — bugs I found were similar to the ones I’m finding during AWS infrastructure penetration tests and configuration assessments (part of my job).

It took me something like 3 hours to obtain the flag and additional 3 hours after as I tried to solve secret_secondary_flag. If this was a red herring — I have to say it wasn’t the nice one. I still think that it had to be something, so send me a message if you know more about this 😉.

As a reward for solving the challenge, I obtained an invitation to a private bug bounty program 😄.

Congrats if you also solved the challenge! If not — remember to “Try harder” next time 😉.

I suggest also following me on Twitter to be up to date with my publications!