# Summary This was a real fun CTF and I really enjoyed solving the challenges. Great job on creating the challenges. This is my writeup for the "12 Days of Hacky Holidays CTF". I hope you enjoy reading it, and I hope others reading it will pick up a trick or two. # Flags: This is all the flags found during the CTF * Flag 1: flag{48104912-28b0-494a-9995-a203d1e261e7} * Flag 2: flag{b7ebcb75-9100-4f91-8454-cfb9574459f7} * Flag 3: flag{b705fb11-fb55-442f-847f-0931be82ed9a} * Flag 4: flag{972e7072-b1b6-4bf7-b825-a912d3fd38d6} * Flag 5: flag{2e6f9bf8-fdbd-483b-8c18-bdf371b2b004} * Flag 6: flag{18b130a7-3a79-4c70-b73b-7f23fa95d395} * Flag 7: flag{5bee8cf2-acf2-4a08-a35f-b48d5e979fdd} * Flag 8: flag{677db3a0-f9e9-4e7e-9ad7-a9f23e47db8b} * Flag 9: flag{6e8a2df4-5b14-400f-a85a-08a260b59135} * Flag 10: flag{99309f0f-1752-44a5-af1e-a03e4150757d} * Flag 11: flag{07a03135-9778-4dee-a83c-7ec330728e72} * Flag 12: flag{ba6586b0-e482-41e6-9a68-caf9941b48a0} # Intro Like a lot of other bounty hunters I enjoy reading security related news on Twitter, but on this particular day, something in my feed caught my attention. It was this tweet from [Hackerone](twitter.com/hacker0x01) announcing "12 days of hack holiday": {F1138752} The first thought that hit me was: "A CTF with one flag each day? Maybe I can solve one flag each day AND get some sleep as well? This sounds like an unusual CTF, this is going to be a first. I'm in!" # Writeup Before we start I would like to introduce the common tools that I have used to solve this CTF, and that I use during my regular security research. * [FFuF](https://github.com/ffuf/ffuf) - This is an awesome tool, and if this is not familiar to you I highly recommend you check this out. This tool can be used for almost every kind of fuzzing related to web. FFuF is usually used in conjunction with a suitable wordlist for the target. When you use this tool always rate limit it, since the default number of threads and request per second is pretty aggressive. You can use -t to control the number of threads and -rate to control the number of request per second. Be nice to the other CTF players and do not overflow the server with traffic. * [SecList](https://github.com/danielmiessler/SecLists) - A very nice collection of wordlists (maybe the best) that is usually used together with a tool, such as FFuF, to do directory brute force, password guessing or other similar things. All wordlists I have used to solve this CTF can be found in the SecList project. * [Burp](https://portswigger.net/burp) - Every web applications testers go-to intercepting proxy. This has been used to proxy almost all traffic during this CTF. * Python - An awesome programming language, that is really fast to create small scripts that can automate some cumbersome manual task. To solve this CTF, a couple of Python script was written to automate some of the tasks. * [Cyberchef](https://gchq.github.io/CyberChef/) - Nice tool to decode/hash/brute force etc. Really fast to just hash or decode something. Ok, now that we are done with the intro, let us get to some hacking! As always, we start by reading the [program brief](https://hackerone.com/h1-ctf) linked from the announcement tweet. We find the scope and observe that the only in scope domain is `hackyholidays.h1ctf.com`. So we need to ensure that we only send traffic to hackyholidays.h1ctf.com in order to be within the scope of the CTF. ## Flag 1 - robots.txt By browsing to https://hackyholidays.h1ctf.com we are greeted with the following image: {F1138753} This is not that interesting. Of course the Grinch want to keep out us out, we are here to take down his network such that he can not ruin the holidays! To find out if the server is hosting any other interesting files or endpoints, we run [FFuF](https://github.com/ffuf/ffuf) with a good wordlist. Since we know very little about the target, a good starting point is usually the [common.txt](https://github.com/danielmiessler/SecLists/blob/master/Discovery/Web-Content/common.txt) file from the awesome [SecLists](https://github.com/danielmiessler/SecLists/) project. So by running a content-discovery with FFuF using the common.txt wordlist and filtering out the 404 responses, we get the following result: {F1138795} From the FFuF result, We observe that we get a 200 OK response from the /robots.txt endpoint. This is usually a good starting point to find other, app specific locations, that the common wordlists do not contain. So by browsing to the [robots.txt file](https://hackyholidays.h1ctf.com/robots.txt) in our browser we get the following result from the server, containing the first flag: {F1138757} Flag 1 is: `flag{48104912-28b0-494a-9995-a203d1e261e7}` * * * ## Flag 2 - s3cr3t ar3a If we observe the robots.txt from the previous step closely, we see that it has one disallow entry in the file, namely `/s3cr3t-ar3a`. If we points our browser to [https://hackyholidays.h1ctf.com/s3cr3t-ar3a](https://hackyholidays.h1ctf.com/s3cr3t-ar3a) endpoint in our browser we see the following page: {F1138758} It looks like the page has been moved. But before we move on, we should inspect the HTML to verify that there is no part of the web page that contains any hidden information. We can use the Chrome developer tools to inspect the HTML, and lo and behold! The second flag is displayed in front of our eyes inside the data-info attribute on one of the div tags: {F1138759} Flag 2 is: `flag{b7ebcb75-9100-4f91-8454-cfb9574459f7}` * * * ## Flag 3 - People Rater Along with flag 2 in the data-info attribute of the div, a `next-app` attribute with the value `/apps` was set. This indicates that in order to find the next flag we must navigate to [https://hackyholidays.h1ctf.com/apps](https://hackyholidays.h1ctf.com/apps). As soon as the challenge was release a link appeared to the "People Rater" application. By clicking the link we are greeted with the mission brief for the People Rater application: **Mission brief**: `The grinch likes to keep lists of all the people he hates. This year he's gone digital but there might be a record that doesn't belong!` So we need to find a record that does not belong in the People Rater application. If we start by clicking on one of the items in the Grinch People Rater list, we observe that a HTTP request is made to the back-end URL `/people-rater/entry`. When the user clicks the item "Tea avery" in the list, the URL is called with the id parameter set to `eyJpZCI6Mn0=`. The `ey` part is usually an indicator of a base64 encoded JSON payload. So by decoding the base64 value in your favorite decoder ([Cyberchef](https://gchq.github.io/CyberChef/) or using the [Burp suite](https://portswigger.net/burp) decoder) we get the value: `{"id":2}`. By clicking on the other items in the in the list, we get a similar request but with another id. To figure out the valid set of ids, we can use Burp intruder and fuzz every number from 0 to 100 in the id field. If we do this, we find that by sending a payload with the id of 1 we get the following payload from the server: ```json { "id": "eyJpZCI6MX0=", "name": "The Grinch", "rating": "Amazing in every possible way!", "flag": "flag{b705fb11-fb55-442f-847f-0931be82ed9a}" } ``` Flag 3 is: `flag{b705fb11-fb55-442f-847f-0931be82ed9a}` * * * ## Flag 4 - Swag Shop **Mission Brief**: `Get your Grinch Merch! Try and find a way to pull the Grinch's personal details from the online shop.` So we will need to find the Grinch's personal detail from the shop, let us explore the shop to check if it is possible. By clicking the purchase button, from the front page of the application, a POST request to the following url is made: `/swag-shop/api/purchase.` The /api part of the URL looks very interesting. To check if there is some other endpoints on the /api path, we can run FFuF against it with the common.txt file from SecList: {F1138760} The FFuF run yields three endpoints: /session, /stock and /user. Let us start by looking at why /user yields a 400 response, not 200 that the other endpoints yields. By browsing to the following url: `https://hackyholidays.h1ctf.com/swag-shop/api/user` we can access the user endpoint path of the API, which gives the following message: ```json {"error":"Missing required fields"} ``` A 400 response and a message like this is sometimes an indication that the endpoint is expecting some parameters, but we are not providing them. A fast way to check if we may be missing some parameters is to do a parameter brute force with FFuF. We choose the burp-parameter-names.txt wordlist from SecList to perform this brute force. We will filter out any 400 responses, to check if any of the parameter names will yield any other responses than 400: {F1138761} So the by adding the parameter uuid, we get a 404 response instead of a 400. If we now navigate our browser to the URL with the parameter uuid set to value, like this: `https://hackyholidays.h1ctf.com/swag-shop/api/user?uuid=value` we get the following JSON response from the endpoint: ```json {"error":"Could not find matching uuid"} ``` This is a clear indication that if we can find a valid uuid, we may get a valid response from this endpoint, hopefully containing some information about the user. Looking back at the initial fuzz we did to discovery API endpoints we see that there is a /session endpoint on the api path. By navigating to [https://hackyholidays.h1ctf.com/swag-shop/api/sessions](https://hackyholidays.h1ctf.com/swag-shop/api/sessions) we get a response back that contains a JSON list of sessions values that is base64 encoded. By decoding them we find one UUID inside the "user" property of the third user with the value: `C7DCCE-0E0DAB-B20226-FC92EA-1B9043` By navigating the browser to the URL: `https://hackyholidays.h1ctf.com/swag-shop/api/user?uuid=C7DCCE-0E0DAB-B20226-FC92EA-1B9043`, we get the following JSON response from the server that contains the Grinch's personal details and the flag: ```json { "uuid": "C7DCCE-0E0DAB-B20226-FC92EA-1B9043", "username": "grinch", "address": { "line_1": "The Grinch", "line_2": "The Cave", "line_3": "Mount Crumpit", "line_4": "Whoville" }, "flag": "flag{972e7072-b1b6-4bf7-b825-a912d3fd38d6}" } ``` Flag 4 is: `flag{972e7072-b1b6-4bf7-b825-a912d3fd38d6}` * * * ## Flag 5 - Secure Login **Mission brief:** `Try and find a way past the login page to get to the secret area.` So for this flag we will have to find a way to get past the login page, and access the secret area. When we open the application, a login page where we must enter a username and password, in order to log in, is displayed. If we enter the username "admin" with the password "admin", the following message is displayed back to the user: `Invalid Username`. Since only the username is mention in the message displayed back to the user, this application may give another error message for a valid user. If this is the case we can distinguish between a valid user and an invalid user. That means we can find a valid user and launch a password brute force attack against the user, and if we are lucky gain access to the secret area. Lets give it a try! We fire up FFuF again to do a brute force attack against the username to check if we are able to discover any valid users: {F1138764} In this run with FFuF we use the -fr option to filter out the regular expression "Invalid Username". This means that each result that is returned from FFuF does not contain the specified regular expression. From the result we see that the username `access` will respond with something other than "Invalid Username" in the response. If we try to login manually via the browser with the username "access" and a random password, the application will now return the message: `Invalid Password`. If we now run FFuF again, but change the fuzz location to the password field with the username set equal to "access", we can brute force the password of the access user: {F1138762} So the username / password combination of `access / computer` will result in a 302 redirect from the server. If we try the discovered credentials in the browser, the 302 redirect from the server will set an access cookie named "secure-login" and redirect back to "/secure-login". Now, since we are logged in, the page will show a table with secure files that the user can download: {F1138763} The page says that there is no files to download, maybe if we could become another user there would be some files for us to download. If we look closely at the secure-login cookie, the value starts with a familiar "ey" pattern. This value is not only base64 encoded, it is also URL encoded. So if we are to retrieve the correct decoded value we must first URL decode before we base64 decode the value in order to preserve the correct value. After decoding our secure-login cookie we end up with the following JSON object: ``` {"cookie":"1b5e5f2c9d58a30af4e16a71a45d0172","admin":false} ``` The admin property of the cookie is set to false, pretty interesting. Let us check what happens if we change the value from false to true, base64 encode it and then URL encode it. We end up with the following value: ``` eyJjb29raWUiOiIxYjVlNWYyYzlkNThhMzBhZjRlMTZhNzFhNDVkMDE3MiIsImFkbWluIjp0cnVlfQo%3D ``` If we change the secure-login cookie to this new value, via the browsers developer tools, we get the following result when refreshing the page: {F1138765} Ok, so we now got a file to download. Let us download the file and check the content of the zip file. By clicking the link in the table, the "my_secure_files_not_for_you.zip" file is downloaded. But when we try to extract the file via `unzip my_secure_files_not_for_you.zip` we are prompted for a password. Ok, so we need to crack the password on the zip file. We can do this by using the [fcrackzip](https://github.com/hyc/fcrackzip) utility with the rockyou.txt wordlist. By running frackzip towards this downloaded zip file, with the rockyou.txt wordlist as input, we get the following result: {F1138766} From the result we see that the password is: `hahahaha`. So if we now try to unzip the file with unzip again and enter the password, two files are now extracted. The first file is an image with the name XXX.png. Please cover the eyes of any children near the screen before you scroll down: {F1138767} And the second file is the flag.txt file that contains the 5th flag. Flag 5 is: `flag{2e6f9bf8-fdbd-483b-8c18-bdf371b2b004}` * * * ## Flag 6 - My Diary **Mission brief:** `Hackers! It looks like the Grinch has released his Diary on Grinch Networks. We know he has an upcoming event but he hasn't posted it on his calendar. Can you hack his diary and find out what it is?` So we need to hack the Grinchs diary to retrieve and find his upcoming event. Upon browsing to the URL `https://hackyholidays.h1ctf.com/my-diary/` we are immediately redirected to `https://hackyholidays.h1ctf.com/my-diary/?template=entries.html`. The template parameter looks really interesting and may hint to a Local File Inclusion vulnerability. Let us do a short content discovery with FFuF to see if there are any other interesting files on the server. {F1138768} If we browse to the index.php via the URL `https://hackyholidays.h1ctf.com/my-diary/index.php`, the server will just redirect us back to the main page. Let see if the template parameter may be vulnerable by changing the value from `entries.html` to `index.php` instead. When we open the following URL: `https://hackyholidays.h1ctf.com/my-diary/?template=index.php`, the browser will just display a blank page, but if we inspect the page with developer tools or look at the HTTP response in Burp, we discover the following PHP code is returned in the HTTP response: ``` YOU SUCK!{{template:cbdj3_grinch_footer.html}} ``` It is very interesting that the campaign contains the ability to include a template via the `{{template:

h1-ctf: h1-ctf : 12 days of hack holiday writeup