Happy New Year to you all!

Here is the writeup for the Christmas Challenge we made to add a bit of fun during the holidays.
Let’s start with an nmap scan on the hostname to check what ports are open and what services are running.

The nmap results show that there is an SSH service (OpenSSH 9.7p1) running on port 22 and Apache httpd 2.4.62 running on ports 31337 and 51337. At this point, SSH is of no interest to us, so let’s take a closer look at the websites hosted on these ports.
Upon inspecting the site hosted on port 31337, we are greeted with what appears to be a flag: SCRGN{f1r57_0f_m4ny_4nd_175_f4kЗ}

However, this flag is fake—the first of many we planted throughout the challenge for fun and to add a bit of an emotional rollercoaster for participants.
It’s worth mentioning that we won’t be discussing all the fake flags found in the challenge. What you need to know about them is something we announced during the challenge: “If it’s f4k3, don’t hit the br4k3.”
After conducting some directory fuzzing on this site, nothing interesting comes up. With no further leads here, we move on to explore the site hosted on port 51337.

When visiting the site on port 51337, we find a different page that actually looks interesting. It is a login form with only a password field (no username). Brute-forcing passwords is allowed, as there is no lockout mechanism. However, after each login attempt, a message appears: “Login is temporarily disabled while the new version of the site is being deployed.”

Looking closely at the site, we also notice a small label in the bottom-right corner of the login form that says “prod”. This hints that there might be a development version of the site available. To explore this further, we decide to fire up some fuzzing to look for it.
Fuzzing for directories and files gives us nothing interesting, so we move on to enumerating some possible subdomains using ffuf with a Host header. The site christmas-challenge.secragon.com appears to be a default site, as every (almost) virtual host we try returns the same result. To handle this, we filter the results by the size of the response to identify if there are any distinct sites being served.

And we have a hit! The subdomain “dev” gives a response with a different size compared to the default site. This indicates that it is serving a unique page. However, the domain does not resolve, which means there is no public DNS record for it. To access it, we need to add an entry for it manually in /etc/hosts.
We open the site at dev.christmas-challenge.secragon.com and notice that it is almost identical to the default site. The only visible difference is that, instead of the “prod” label in the bottom right corner, it shows a label with “Version 0.0.3-dev”. When we attempt to log in, we are greeted with a new message: “Incorrect password! Try again”. 
This indicates that the password mechanism is functional in this version, unlike the default site.

Testing some common default passwords on the form yields no results, so we proceed to fuzz the site for interesting directories or files that might give us an advantage.

Running ffuf with some popular wordlists reveals two interesting files in the root directory of the site: TODO and CHANGELOG. These files might provide some useful information for further exploration.

The content of these files provides us with valuable information.
From the TODO file, we see that there are plans to disable passwords that contain “Secragon” or “secragon”. This is a common issue in many companies, and it appears that this restriction has not yet been implemented on the site.
The CHANGELOG file reveals additional details about the platform’s password policy. In the latest version (0.0.3-dev), passwords are required to contain at least one uppercase letter, one number, and one special character.
This information strongly suggests that it is more likely for a valid password to contain “Secragon” (with an uppercase “S”) than “secragon”. This provides a hint for us to focus our efforts accordingly.
Based on the hints we have found so far, we use hashcat to create a custom password list. The password list is tailored to include passwords containing “Secragon” with four additional characters. The rule specifies:

• ?d: A digit (0–9).
• ?s: A special character.

This ensures that each password ends with a combination of digits and special characters, adhering to the password policy mentioned in the CHANGELOG file.
The command we use is: hashcat --stdout -a 3 -1 ?d?s 'Secragon?1?1?1?1' > custom_password_list.txt
Once the password list is generated, we proceed to use ffuf to brute-force the login form using a previously saved login request and attempt all the generated passwords against the site.

Within seconds, we successfully hit the correct password: “Secragon@123“. Using this password, we can now log into the site and proceed with our investigation.
After logging into the site, it seems to be mostly empty, aside from yet another fake flag. The only functionality that appears to be active is the ability to change the language via the dropdown menu on the top-right corner. However, this seemingly simple feature reveals something interesting.

The lang parameter in the URL accepts a file name for the language change: under-construction.php?lang=en.html. This behavior is indicative of a classic Local File Inclusion (LFI) vulnerability. We confirm this by intercepting the request in Burp Suite and testing with /etc/passwd. Sure enough, the contents of the file are successfully retrieved, confirming the vulnerability.

Revealing the contents of /etc/passwd gives us a username: secrag0n, which we keep in mind as it may be useful later. Testing this username with the application password on SSH yields no results, so we continue exploring. The vulnerability appears to be path traversal, which allows reading files but not executing code. This means our next step is to look for interesting files on the server.
Remembering that the christmas-challenge.secragon.com site serves as the default, we decide to check the configuration for Apache virtual hosts. Reading the /etc/apache2/sites-enabled/000-default.conf file reveals the path for the production application.

From there, we navigate to the application’s files and read the validate.php file.

This confirms that login validation is indeed disabled on the production site. Interestingly, the file also contains a stored password that differs from the development one: Secragon@12345!!!.
Checking this password with the username secrag0n on SSH this time gives us a successful login, and we end up with shell access… and, of course, another fake flag.

Enumerating the box provides no valid path to proceed further. The only thing that looks interesting at this point is the greeting_card.pdf file located in the home directory. To examine it, we need to download it to our machine. However, most conventional methods for file transfer are disabled on the server. This forces us to rely on a direct method by sending the file over a raw TCP connection using the command:cat greeting_card.pdf > /dev/tcp/IP/PORT

After successfully transferring the greeting_card.pdf file to our machine, we discover that it is password-protected. This introduces yet another password mystery to solve, but it also hints at a promising outcome for the challenge.

To proceed, we use pdf2john to extract the password hash of the greeting_card.pdf file, enabling us to attempt cracking it. With the hash extracted, we run hashcat using the best64.rule and the rockyou password list for a comprehensive password-cracking attempt.

After some time, our efforts pay off, and we successfully crack the hash. The password protecting the PDF is revealed to be: happynewyear!123

Using this password, we open the greeting_card.pdf file and are greeted with a Christmas message from Secragon for the holidays. Alongside the greeting, we find the final, this time real flag of the challenge: SCRGN{kud05_4nd_h4ppy_h011d4y5}