Day two in the Advent of Cyber 3 (2021) continues where day one left off. McSkidy needs to check if any other employee elves have left/been affected by the Grinch Industries attack we saw signs on yesterday.
WARNING: Spoilers and challenge-answers are provided in the following writeup.
Official walk-through video is as well available at TryHackMe! Advent of Cyber 3 - HTTP Cookies & Authentication Bypasses - "Day 2" - YouTube.
Day 2 - Elf HR Problems
Today, we are going to work with cookies. We need to manipulate and manage cookies for a website in a "malicious" use-case, as to get access to the HR-system for the Best Festival Company that Grinch Industries has hacked.
To do so, understanding on how cookies in browsers work, is beneficial.
When accessing websites etc., the browser uses a protocol named HTTP/HTTPS. This protocol is stateless, meaning that the server where you are requesting the webpage from, cannot distinguish between you and others. That is of cause not ideal if you are required to login or similar. To deal with this (and many other use-cases), we have cookies.
Cookies is metadata that the server sends to your browser and the browser stores locally on your machine. This locally stored data, has many attributes, where the most important is the name and value. Furthermore, cookies have an expire-datetime when the browser is instructed to delete the specific cookie. This is often used for "session-cookies", that is identification-cookies used to verify your login and similar only existing in a temporary manner.
See more at https://en.wikipedia.org/wiki/HTTP_cookie
The two most used HTTP(S) requests is GET and POST. These are used by your browser to sent requests on your behalf, to the webserver to receive a webpage. GET is the most simple, where we just request a single webpage/-resource - e.g. an image, page or similar. Below is shown a simple GET-request for an example.org webpage.
GET /index.html HTTP/1.1
Host: www.example.org
User-Agent: Mozilla/5.0 Firefox/87.0
...Firstly in the first line, the request-type is specified for the protocol, then what resource is requested and the protocol-version. The next line is what webserver-host is going to be requested and then we see an attribute called User-Agent - this one tells the webserver what browser, system etc. that you are using. Multiple more attributes is available.
The webserver will then respond with the requested resource (provided that you are allowed, no errors happens etc.) via a protocol-response. One example is shown below.
The first line again shows the protocol-version and then a status-code. The most common status code is 200 OK which means the request/response was successful. The multiple attributes can be found - normally information about the server (like the User-Agent), date for the response, definitions on cookies to create, the type and length of the resource-content followed by a blank line. After this, the resource is found.
HTTP/1.1 200 OK
Server: nginx/1.15.8
Date: Wednesday, 24 Nov 2021 13:34:03 GMT
Content-Type: text/html
Content-Length: 98
<html>
<head>
<title>Example page</title>
</head>
<body>
Hi, this is an example webpage.
</body>
</html>For POST the process is more or less the same, though user-provided details (e.g. login-details) will be found as attributes in the request-header.
When a webserver wants to create a cookie, it will provide the following structure in the response-header:
Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnlyAn example response-header:
HTTP/1.0 200 OK
...
Set-Cookie: SSID=Ap4P…GTEq; Domain=foo.com; Path=/; Expires=Wed, 13 Jan 2021 22:23:01 GMT; Secure; HttpOnly
...The Challenge
To help McSkidy "hack-back" and gain access to the HR-systems again, we are provided the website of https://static-labs.tryhackme.cloud/sites/aoc-cookies/
We are then instructed to create an account and verify the cookies created for the session.
But oh no! We do not have the correct permissions:
Though, looking at the cookies, we see a new cookie called user-auth - a cookie very much looking as a Session-cookie.
The first question is then answered, and looking at the cookie-value we need to figure out the encoding as to decode the value-data. When presented with a large textstring only consisting of the characters 0-9 and a-f, one can often assume the data to be encoded in the "hexadecimal" system.
A quick check with CyberChef, https://gchq.github.io/CyberChef/#recipe=From_Hex('None'), we has a confirmation on this theory as the decoded data is human-readable:
{company: "The Best Festival Company", isregistered:"True", username:"Hacky McHackface"}Next we are asked to provide the data object-format of the data, and knowing a bit object-formatting we clearly sees the JSON format is used. JSON is a very common format to serialize data in - both when dealing with data on websites, API's ans similar. You can see more about JSON on https://en.wikipedia.org/wiki/JSON.
Now to the real fun - Manipulating the cookie. From yesterdays challenge, we know that any user-submitted data should never be trusted. Looking at the decoded cookie value-data, we see a JSON-attribute called "username". Very suspicious and interesting. Could the whole session-security for the website only be verified by what username is reported in this "user-auth"-cookie? If so, then we would be able to change this username to something as perhaps "admin" that might be a real authenticated username in the system, and then gain access to secured data/site? Let's try.
Firstly we have the decoded JSON data, here we just change the username to "admin" and re-encode that data in hexadecimal. This is doable using CyberChef again:
Submitting the received hexadecimal value, and we have the next answer in the challenge.
Taking this value, and replace the cookie-value for the webpage we have - and BUM! We are now authorized and have access to the system.
And with that, answers for the last two questions is available for us.