This will be a new series of posts about the Hacker101 CTF. I will be going through the challenges in the order they are presented in the site and explaining how I solved them and what was going through my mind as I approached each challenge. I will mostly focus on the web, crypto and math challenges, but an occasional misc challenge might sneak in.
The goal of CTFs in general is to uncover flags, which are hidden in the challenges and have the format
^FLAG^...$FLAG$. With that out of the way, let’s begin with the first challenge called
This is an easy challenge containing four flags with the goal of teaching you some common web vulnerabilities.
When I jump into a challenge I like to start by manually investigating what is possible within the constraints of the user interface. In this case the challenge is a simple CMS with the following features:
- View page
- Edit page
- Create page
The first flag only requires us to create a new page with a title containing HTML tags. The steps taken were:
- New page
- Choose a title like
<b>Hello</b>or your favourite HTML tag
- Go back to the main page and we will receive an alert with the first flag
I tried to also add
<script> tags to the body of a page without success, but exploring the other existing pages gives us the hint that our CMS supports
Going to the post with the name
Markdown Test and clicking on
Edit this page we see that we can add buttons and links to our posts. The button element usually has handles like
onclick, so I went ahead and added
onclick="alert(1)" to the button.
After saving the page and trying to click on the button the alert did not fire, so I went to the source code to see what was wrong and I noticed that a new flag was appended as an attribute of my button. Pretty neat!
At this point we got HTML injection and XSS. Another common web vulnerability is called SQL injection, or
SQLi. This usually happens on endpoints that accept a parameter like an
ID or a similar identifier, but can also be found on any endpoints accepting user input. In our CMS we have two locations accepting identifiers:
My first test was to add a single quote to
/page/1', but we get
404 as a response code. This implies the endpoint is correctly escaping our user input. Don’t be discouraged when the first few endpoints are not vulnerable to the attack you are trying to perform, it’s pretty common that developers overlook something in a bigger web application.
In our case hitting
/page/edit/1' with the same payload gets us another flag, which proves that the endpoint was vulnerable to SQL injection.
There’s another common vulnerability on endpoints that accept identifiers called Insecure Direct Object Reference, commonly abbreviated to
IDOR. Seeing the page IDs and no authorization in place makes me want to try and enumerate the web application for other IDs. Here’s the approach I took:
- Create a sequence of numbers, for example, 1 to 20 and persist those in a file:
seq 20 > range.txt
- Scan all these numbers, I’ve used ffuf to do it:
ffuf -w range.txt https://<subdomain>.ctf.hacker101.com/page/FUZZ
We get as a result:
1 [Status: 200, Size: 239, Words: 12, Lines: 15] 4 [Status: 403, Size: 234, Words: 27, Lines: 5] 11 [Status: 200, Size: 253, Words: 8, Lines: 14] 2 [Status: 200, Size: 433, Words: 19, Lines: 16] :: Progress: [20/20] :: Job [1/1] :: 0 req/sec :: Duration: [0:00:00] :: Errors: 0 ::
Page 1 and 2 are the default pages when we create our challenge, page
11 is the page I’ve created when we got our first flag. Among those numbers we never interacted with page number
4, but notice how the status of page 4 is being returned as
403 when we try to access
Turns out we can also bypass this by going to the
/page/edit/4 endpoint and we get our last flag.
This challenge is a great introduction to common CTF themes. I particularly liked that the
GET /page/4 endpoint was protected, but
/page/edit/4 wasn’t since this is a common issue even in enterprise level systems when they are not following secure by default practices.
Thanks for reading and I will see you in our next post!