Write-Up: Desires

Author: 0xtor4sec | Date: Apr 15, 2025 | Read time: 3 min

Hi everyone,

I found this challenge particularly interesting and decided to document my methodology, including my trial-and-error process and the solution.

Visiting the website, we encounter a login portal. Given the “medium” difficulty rating, I chose not to attempt brute-force techniques.

We are provided with a ZIP file containing the server’s infrastructure. Inside the views directory, there are five HTML files. Among these, admin.html clearly stands out as our target.

Reviewing the main.go file reveals the server handles these routes:

/register
/login
/user/upload
/user/admin

Naturally, accessing /user/admin directly returns a “403 — Unauthorized” response.

From the main.go code, it’s clear that /user/admin is protected by the DesireEnigma function, which only renders admin.html and displays the flag (stored as an environment variable) if the user is authenticated as “admin.”

Next, we examine the /user/upload page. File upload functionalities are often vulnerable, making them a priority in pentesting. To access this feature, we first register as a new user.

Inspecting Developer Tools’ storage tab shows that two cookies are set: session and username.

Attempting to upload a simple evil.txt file results in the following error:

format unrecognized by filename: uploads/4d18fg30-e290-642e-b250-66d66e644ft8.txt

This indicates the filename is changed to a UUID, and the server expects specific file formats based on extensions.

Revisiting main.go, the UploadEnigma function handles uploads. It verifies user authentication, retrieves the uploaded file from the “archive” form field, renames it with a UUID preserving its extension, and saves it in the uploads/ directory before extracting its contents into /files/<username>/.

Initially, it seems possible to upload a reverse shell and execute it via /files/<username>/<filename>. However, random UUID filenames make predicting the exact filename impossible, preventing straightforward exploitation.

Analyzing further, the archive extraction is handled by a third-party library specified in http.go: github.com/mholt/archiver/v3. The project is deprecated, and examining this library’s GitHub issues reveals vulnerability CVE-2024–0406 — a “Zip Slip” path traversal vulnerability.

Researching “Zip Slip” vulnerabilities, we understand this flaw allows writing files outside the intended extraction directory. Here is an example exploit script: https://github.com/walidpyh/CVE-2024-0406-POC/blob/main/script.py.

Next, analyzing sessions.go, we observe the CreateSession function writes session files at:

/tmp/sessions/<username>/<sessionID>

The sessionID is a SHA256 hash of the current Unix timestamp, generated in LoginHandler:

sessionID := fmt.Sprintf("%x", sha256.Sum256([]byte(strconv.FormatInt(time.Now().Unix(), 10))))

Therefore, session IDs are predictable. This offers a potential attack vector by uploading a file with a predicted sessionID using Zip Slip, then authenticating as admin at the exact predicted time.

However, a direct login would overwrite our malicious session file upon successful authentication. Inspecting LoginHandler function again, we notice the session ID is set prior to verifying credentials. Crucially, the session file is only created if authentication succeeds.

Let’s exploit this logic:

1. Register as a regular user and obtain the session cookie.
2. Predict a session_id for a future login attempt based on timestamp.
3. Craft a malicious TAR file exploiting CVE-2024–0406 containing the predicted session_id and admin privileges.
4. Upload this TAR file using our registered user.
5. Wait for the exact predicted timestamp and intentionally log in with an incorrect password, triggering session initialization without overwriting the malicious session.
6. Access /user/admin using the predicted session cookie.

To summarize discovered vulnerabilities:

• Zip Slip (CVE-2024–0406): Allows arbitrary file creation or overwriting outside the intended directory. Enabled uploading malicious session files granting admin privileges.
• Predictable Session IDs: Session IDs derived from timestamps. Allowed crafting a session file synchronized with a future login attempt.
• Authentication Logic Flaw: Session ID is set before verifying credentials, yet session file creation only occurs after successful authentication. Enabled activating the malicious session without overwriting by intentionally providing incorrect credentials.

Our approach effectively exploited these combined vulnerabilities to obtain admin access and retrieve the flag.

Thank you for reading !

“Don't listen to the person who has all the answers. Listen to the person who has the questions.”