One of the highlights of the end of the calendar year is the SANS Holiday Hack Challenge. This year, I took the time to work through the challenges. It was fun!

In the next couple of posts, I’ll write up some solutions to the 2018 challenges.

My answer to question two can be found here.

Question 3

Challenge: The KringleCon Speaker Unpreparedness room is a place for frantic speakers to furiously complete their presentations. The room is protected by a door passcode. Upon entering the correct passcode, what message is presented to the speaker? For hints on achieving this objective, please visit Tangle Coalbox and help him with the Lethal ForensicELFication Cranberry Pi terminal challenge.

Solution 1: As always, when given a challenge website, it pays to just play around with it a bit. In this case, the page is fairly simple— it is a single web page that includes some JavaScript that validates the code that is provided against checkpass.php using two parameters: i and resourceId. The PHP page at https://doorpasscoden.kringlecastle.com/checkpass.php indeed loads and returns some JSON.

It appears that the actual logic to validate the passcode is contained in that PHP-file. Bruteforce is an option– four positions with four possibilities per position is 256 options, which is pretty easy.

However, we were given a hint. Tangle Coalbox, an elf in the game, provided a reference about De Bruijn Sequences. I had not heard about those, but Google had ;)

After plugging in the correct parameters into http://www.hakank.org/comb/debruijn.cgi, the keyspace was listed. After eliminating all code that were not exactly four chars long, I was left with 60 codes to test. That was almost enough to write a script that iterates over all four of them against “https://doorpasscoden.kringlecastle.com/checkpass.php?i=”, however:

  1. I needed to find a resourceId and that seemed like work, and

  2. No guarantee that there wasn’t some browser check of sorts.

60 possible keys tested manually is probably less than 5 minutes, which is less than a quick python script. Access obtained.

Solution 2: In this case, bypassing the authentication subsystem was actually unnecessary. Opening https://doorpasscoden.kringlecastle.com in Google Chrome and activating the Developer Console listed an image containing the text “Welcome unprepared speaker!” when choosing Sources > Page > doorpasscoden.kringlecastle.com > (index).

Bigger Picture: CISOs can learn a few bigger picture lessons from this challenge:

  1. Online authentication systems must use a keyspace that is large enough infeasible to test all possible combinations in a reasonable amount of time. Cryptographers call this a “cryptographically secure” system.

    In this case, there were only 256 possible combinations. Even without automation, that is easy to guess.

  2. In order to prevent somebody to quickly execute an enumeration of all keys, the system should have some form of detection mechanism. At bare minimum, the system should recognize multiple login attempts from a single IP address, login attempts for a specific user to prevent dictionary attacks, and repeated use of the same password against multiple accounts to detect password spraying.

    The latter is a bit trickier, since it will require storing passwords that are submitted to the system. If not done very carefully, that might lead to more problems than it solves.

    If repeated attempts are detected, a temporary block can be imposed.

  3. Authentication systems must log all attempts (successful and failed). At bare minimum, the log should contain a timestamp (preferably in UTC), source IP address, target username, success status, requested resource, and, possibly, some form of client identifier like a browser user agent.