So, one of the Really Cool Things (RCT®) about working as a pentester at TRUE is that we get to play games. No, not video games (though my wife and I are getting pretty good at Dead by Daylight), but online hacking games, more commonly known as Capture the Flag games or CTFs. There are several of these on the Interwebs for those of us who are so inclined to break into stuff but want to do it LEGALLY. That brings up a very important note about the Hacking/Breaking & Entering/Social Engineering activities we perform for our clients at TRUE (and *take note* kiddies):
We do it legally, under contract.
We're trained professionals. Don't try this at home. Except for in CTFs. :)
CTFs are the same...websites with online hacking games in the form of web applications, servers one can connect to through a VPN, reverse-engineering challenges (download a binary, and find a flag). However, they're all LEGAL and most are free. A simple Google search will help you find the CTFs you are looking for or visit ctftime.org.
There are several reasons we compete in these hacking games. We learn tons of new things, we encounter new technologies, and we learn new hacking techniques and skills. Oh, and, sometimes we compete AGAINST each other to see who can get through a challenge the quickest. I'm sad to say that I haven't fully completed the entire FLARE-ON CTF yet, but Michael Oglesby (TRUE's VP of Security Services) kills it almost every year (and is always WAYYYY ahead of me at the time). FLARE-ON is reverse-engineering skills than breaking into a network/system, but it's still fun and really helpful in understanding how internals of software work.
However, the CTF I want to cover today is the 2019 SANS Holiday Hack Challenge (HHC), aka KringleCon 2: Turtle Doves, which ran from December 2019 to January 13th, 2020. You can find more information about this CTF at https://holidayhackchallenge.com. It's still online now (along with all of the other SANS HHCs from years past), so people can play at any time!
The KringleCon 2 story: Someone is trying to sabotage Christmas (again), and it’s up to the player to figure out who, why, and how to stop them. There are a lot of really cool challenges in KringleCon2 which may be difficult for people who have never worked with the tools/techniques that the challenges are presenting. For this reason, the Holiday Hack Challenges are first and foremost about learning. The KringleCon team have put together many helpful videos on the challenge subjects. These are not necessarily “how-to” videos, but rather a review of the overall concept presented in the challenge, which can be used to help complete the challenge. It's important to note that KringleCon2 was awesome not only from a Red Team (attacker) perspective, but because it also involved Blue Team (Defensive) challenges, including reading logs with Splunk and Zeek (BRO), some of which are tools I've never worked with before.
Now, let me say this up front: This is not a walkthrough or a writeup about how to complete the KringleCon 2 challenges. There are plenty of those out by now, and many that are way better than what I could do. This is more of an overview of some of the challenges I loved and how I completed them. The challenges were mixed between “Terminal Challenges” (Linux command line and various PowerShell challenges) and wildly different types of challenges like web application hacking, reverse engineering binaries, or identifying key “bitting” from a picture. The point of these challenges is to complete the objective, which unlocks a badge in your profile. Of course, after completing all the challenge objectives, you win! So, without further ado, let's dive into some of my favorites, shall we?
The Challenge - Holiday Hack Trail -
Most people who went to elementary school in the late ’80s/early ’90s probably played The Oregon Trail. It was an educational computer game where you had to make a trek through the wilderness of the Oregon Trail while driving in a covered wagon with limited supplies (food/weaponry/medicines), many family members, and other people following you. It was all about survival in 1848.
The Holiday Hack Trail was another take on this concept. The point of the game is to make it to KringleCon by December 25th with everyone alive, and it has three modes: Easy, Medium and Hard.
You need to pay for supplies, such as Reindeer, Runners, Food, Meds, and Ammo. You start with a certain amount of all of these items and can buy some before starting out. If you run out on the way (you will!), you can acquire more through Trade or Hunting, or buying them.
Now, as I've said before, the point of these challenges is to complete the objective, which unlocks a badge in your profile. This time the objective was to make it the distance to KringleCon by December 25th with everyone still alive, but on Hard mode. It can be completed on Easy or Medium mode (and there are fun little hacks in there if one is so inclined), but the badge is not awarded for Easy or Medium mode. Here’s the caveat: it's impossible to complete this game on Hard mode without a little hacking. People die of dysentery.
Go hack something…
Holiday Hack Trail is a Web Application (web app) challenge. This means we're going to need to use a couple tools to monitor the requests back and forth between the server, specifically, a web browser (Hacker's choice! I prefer Google Chrome.), and a neat little tool called Burp, which is an HTTP intercepting proxy. While I won't get into how to setup Burp to work with your browser (there's TONS of tutorials on this elsewhere), I will show what I saw going through Burp from the browser to the server.
When you click "GO", a POST request is sent to server (http://trail.elfu.org) with several parameters in it, including the distance, the date (split into month and day), Names of people in the party, their health points, reindeer, runners, money, ammo, meds, food, etc., which the server would then send as a response with the distance left to go, randomly decreasing the number of supplies and certain health points. The most important parameter here though isthe "hash" parameter. It only shows up in Hard mode, so this has to have something to do with the game.
POST Request:
POST /trail/ HTTP/1.1
Host: trail.elfu.org
Connection: close
Content-Length: 464
Cache-Control: max-age=0
Origin: https://trail.elfu.org
<snipped>
Referer: https://trail.elfu.org/trail/
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: trail-mix-cookie=4557ee92ac533cd23247e470ef797d651667a7fb
pace=2&playerid=a6ba3069-8ffc-49ad-b108-8b0fa89c720e&action=go&difficulty=2&money=0&distance=118&curmonth=9&curday=2&name0=Kendra&health0=100&cond0=0&cause0=&deathday0=0&deathmonth0=0&name1=Ron&health1=100&cond1=0&cause1=&deathday1=0&deathmonth1=0&name2=Mathias&health2=100&cond2=0&cause2=&deathday2=0&deathmonth2=0&name3=Sally&health3=100&cond3=0&cause3=&deathday3=0&deathmonth3=0&reindeer=4&runners=4&ammo=10&meds=2&food=104&hash=c24cd76e1ce41366a4bbe8a49b02a028
The hash is an MD5 hash, and it's meant to be a validation checksum of certain parameters in the POST request. When you crack the hash, you can see it's equal to the number 253:
aaron@hotdog:~$ sudo hashcat -a3 -m0 c24cd76e1ce41366a4bbe8a49b02a028
hashcat (v5.1.0) starting...
OpenCL Platform #1: Intel(R) Corporation
========================================
* Device #1: Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz, skipped
OpenCL Platform #2: NVIDIA Corporation
======================================
* Device #2: GeForce GTX 1080, 2027/8111 MB allocatable, 20MCU
* Device #3: GeForce GTX 1080, 2029/8119 MB allocatable, 20MCU
* Device #4: GeForce GTX 1080, 2029/8119 MB allocatable, 20MCU
* Device #5: GeForce GTX 1080, 2029/8119 MB allocatable, 20MCU
Hashes: 1 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates
Applicable optimizers:
* Zero-Byte
* Early-Skip
* Not-Salted
* Not-Iterated
* Single-Hash
* Single-Salt
* Brute-Force
* Raw-Hash
Minimum password length supported by kernel: 0
Maximum password length supported by kernel: 256
c24cd76e1ce41366a4bbe8a49b02a028:253
Session..........: hashcat
Status...........: Cracked
Hash.Type........: MD5
Hash.Target......: c24cd76e1ce41366a4bbe8a49b02a028
Time.Started.....: Wed Jan 29 17:00:14 2020 (0 secs)
Time.Estimated...: Wed Jan 29 17:00:14 2020 (0 secs)
Guess.Mask.......: ?1?2?2 [3]
Guess.Charset....: -1 ?l?d?u, -2 ?l?d, -3 ?l?d*!$@_, -4 Undefined
Guess.Queue......: 3/15 (20.00%)
Speed.#2.........: 189.7 MH/s (0.12ms) @ Accel:64 Loops:62 Thr:1024 Vec:1
Speed.#3.........: 0 H/s (0.00ms) @ Accel:64 Loops:62 Thr:1024 Vec:1
Speed.#4.........: 0 H/s (0.00ms) @ Accel:64 Loops:62 Thr:1024 Vec:1
Speed.#5.........: 0 H/s (0.00ms) @ Accel:64 Loops:62 Thr:1024 Vec:1
Speed.#*.........: 189.7 MH/s
Recovered........: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts
Progress.........: 80352/80352 (100.00%)
Rejected.........: 0/80352 (0.00%)
Restore.Point....: 0/1296 (0.00%)
Restore.Sub.#2...: Salt:0 Amplifier:0-62 Iteration:0-62
Restore.Sub.#3...: Salt:0 Amplifier:0-0 Iteration:0-62
Restore.Sub.#4...: Salt:0 Amplifier:0-0 Iteration:0-62
Restore.Sub.#5...: Salt:0 Amplifier:0-0 Iteration:0-62
Candidates.#2....: sar -> Xqx
Candidates.#3....: [Generating]
Candidates.#4....: [Generating]
Candidates.#5....: [Generating]
Hardware.Mon.#2..: Temp: 38c Fan: 27% Util: 0% Core:1771MHz Mem:4513MHz Bus:16
Hardware.Mon.#3..: Temp: 42c Fan: 27% Util: 52% Core:1885MHz Mem:4513MHz Bus:16
Hardware.Mon.#4..: Temp: 43c Fan: 27% Util: 31% Core:1911MHz Mem:4513MHz Bus:16
Hardware.Mon.#5..: Temp: 39c Fan: 27% Util: 18% Core:1885MHz Mem:4513MHz Bus:16
Started: Wed Jan 29 17:00:00 2020
Stopped: Wed Jan 29 17:00:15 2020
The significance of this number is that it's the sum of several parameters of the POST request. Which ones? I'll leave that as an exercise for the reader. :)
#Winning
So, if we tweak the parameters, and adjust the hash to reflect the adjusted parameters, then we might be able to hack our way through and win this challenge. The key is knowing what the distance needs to be to win (remember the objective of the game), reflecting that in the hash, and then sending that to the server.
And....we have a winner!
So, why is this important?
This exploit is an example of a Web Parameter Tampering attack. According to OWASP's Web Parameter Tampering page:
"The Web Parameter Tampering attack is based on the manipulation of parameters exchanged between client and server in order to modify application data, such as user credentials and permissions, price and quantity of products, etc. Usually, this information is stored in cookies, hidden form fields, or URL Query Strings, and is used to increase application functionality and control." [1] https://owasp.org/www-community/attacks/Web_Parameter_Tampering
Understanding how all of the parameters of this challenge (including the validation checksum parameter - the "hash") work together on the backend server, I was able to manipulate them in the client-side POST request to affect the outcome of the game and gain a victory for myself.
During web app penetration testing, my team and I have found that many of the web apps we attack have these types of vulnerabilities which we can then exploit. As an attacker, it's my job to find ways to make a web app perform in a way that it wasn't designed to do: find parameters and change them to see how the web app reacts, try to get some code injection through the web app (SQL injection, Cross-Site Scripting, or Local File Include vulnerabilities), or access to other areas of the web app that a normal user is not supposed to have access to.
As an incredibly simplified example, some web app may have an HTTP Cookie header with an MD5 (or SHA1/SHA256/etc.) hash of the username that is logged in. If an attacker knows this information and has an idea of other usernames with access to that web app, then the attacker can generate a new hash with a different known username and bypass authentication to the site or escalate their privileges from a normal user to an administrator of the site.
Remediation?
At TRUE, when we discover and exploit these types of vulnerabilities in a web app, our reports not only contain the exploits and outcomes but also how to remediate these vulnerabilities on the backend in the servers or in the code where possible. Once that fix is implemented, we can retest to ensure the attack is not repeatable.
How would I recommend KringleCon remediate this particular vulnerability? This hash was easy to compute and crack because it was the sum of all the numbers. Instead of just the sum of all the numbers, I would recommend using the sum multiplied by a rather large number on the backend server for the hash. Even if the hash was cracked, it would still be difficult to know the exact parameters to tamper with to break the web app due to the large number used to compute the hash. Also, to be fair this is a simple application. Something more serious would use a cryptographically secure pseudorandom number generator for the number generation and then store that on the backend somewhere.
If you’ve read this far, congratulations! Get yourself a cookie and some coffee! I hope this has been a fun and informative review of how parameter tampering can cause your web app (and administrators!) to have a bad day.