Premise
In this walkthrough, we covered how website cookies work, the security threats, and security best practices. We used an example lab from TryHackMe Advent of Cyber 2 / 2020 Day 1 scenario name: A Christmas Crisis
Room Link
TryHackMe Advent of Cyber Challenge Description
“The Best Festival Company’s brand new OpenVPN server has been hacked. This is a crisis!
The attacker has damaged various aspects of the company infrastructure — including using the Christmas Control Centre to shut off the assembly line!
It’s only 24 days until Christmas, and that line has to be operational or there won’t be any presents! You have to hack your way back into Santa’s account (blast that hacker changing the password!) and getting the assembly line up and running again, or Christmas will be ruined!”
Room Answers / Day 1
Deploy your AttackBox (the blue “Start AttackBox” button) and the tasks machine (green button on this task) if you haven’t already. Once both have deployed, open FireFox on the AttackBox and copy/paste the machines IP into the browser search bar.
Register for an account, and then login.
What is the name of the cookie used for authentication?
In what format is the value of this cookie encoded?
Having decoded the cookie, what format is the data stored in?
Figure out how to bypass the authentication.
What is the value of Santa’s cookie?
Now that you are the santa user, you can re-activate the assembly line!
What is the flag you’re given when the line is fully active?
How Cookies Work
I start by explaining the basics of cookies. They’re super useful for identifying users, so you don’t have to sign in to websites over and over again. If you clear your browser’s cookies, you’ll have to sign in again because those identifying cookies are gone.
Cookies also store information about your permissions on a website, like whether you’re an admin, a regular user, or an editor. They can even remember your preferences, like if you prefer a dark or light theme for a website.
I then explain that cookies are generated on the server-side and stored in your browser’s directory. They’re usually exchanged over HTTP, but for security, it’s much better to use HTTPS. Every cookie has a name and a value, and the security threats are usually found in the value.
Security Threats with Cookies
Next, I dive into the security risks that come with cookies. If someone can change or steal your cookie values, they could potentially hack into your account or even the entire website if the cookie belongs to an admin.
The ability to change or steal a cookie really depends on the security measures that have been put in place on the backend, like encoding or encryption.
Securing Your Cookies
To keep your cookies safe, I talk about a few security measures that developers can use:
- HTTPOnly Flag: This is a flag that’s set on the server-side. It prevents the cookie from being accessed by client-side scripts, which helps to prevent cross-site scripting (XSS) attacks.
- Secure Flag: When a developer sets this flag, it makes sure that the cookie value is only sent over HTTPS and is encrypted. This means it won’t be displayed over HTTP.
- Path: By setting a path, you can restrict the modification of the cookie to a specific directory.
Hacking Demo: From User to Admin
To show you how this all works in practice, I walk through a scenario from TryHackMe. I log in as a regular user and then use my browser’s developer tools to inspect the cookies.
I find a cookie named “oath” with a value in hexadecimal format. I then decode this hexadecimal value to plaintext and find that it contains sensitive information like my username and company, which is a big security no-no.
To show how this can be exploited, I change the username in the plaintext value to “santa” (the admin username in this scenario). I then convert this modified plaintext back to hexadecimal and paste the new value into the cookie editor in my browser. After a quick refresh of the page, I have admin access!
I wrap up by explaining that if the website had used HTTPS and encrypted the cookie with something stronger than hexadecimal, this attack wouldn’t have been possible.
