Challenge description

Welcome to slurm's official website, here you're going to learn a lot of new reasons to drink slurm. And please don't ask about our secret recipe... some secrets must remain secrets.

Site: http://slurm.challs.open.ecsc2024.it

Table of contents

• Preliminary analysis
• Further analysis
• Exploitation

Preliminary analysis

The challenge's source code consists of a frontend and a backend. At a glance, the frontend doesn't seem to be of interest.

The application allows users to view existing "marketing materials" and upload their own.

Upon inspecting the backend, the flag can be found in the environment variable FLAG and in one of the initial marketing materials.

Further inspection reveals that there are checks in place to prevent the "Super secret recipe" from being read by the user.

Based on these observations, it seems like the flag can be retrieved by either bypassing the check for the recipe or by extracting the environment variable.

Further analysis

The user can perform the following operations:

• List files and their associated metadata
• Get file by ID
• Upload a file (with and without an ID)
• Check a file's integrity

The file operations can be a potential attack vector if the restrictions are not properly put in place. Recall that the flag can also be found in the environment variables, and it can often be found in the file system somewhere (for example, /proc/self/environ on Linux).

As mentioned in the previous section, there are checks in place to prevent the user from directly reading the secret file. In the get_file route handler, there are checks in place to:

1. Prevent the user from reading the secret file by ID
2. Prevent the user from reading any file which has the secret file name in their file name

The second check is interesting as it indicates that it may be possible to read an arbritary file. It can also be observed that the files' metadata seem to be stored in a MongoDB collection.

The application delegates file operations to the FileMetadata class as shown above. This makes it interesting to investigate and figure out if proper security measures are put in place.

The constructor has a few string length checks, but nothing particularly interesting.

The write method forbids path traversal and content larger than 200 B. However, the database operation is not transactional and the operation is performed before the checks are called. This means that the user can potentially insert a file metadata to the database despite it not being compliant with the checks.

The file upload route allows a user to upload files without other restrictions than the ones already mentioned, except the fact that the initial files cannot be overriden.

The application's Dockerfile reveals that all files are included in the image, as shown by the COPY directive in line 11.

The provided handout contains a backend.env file, which is used to provide environment variables in the Docker Compose file. This means that the environment variables can potentially be extracted from a "normal file" on the filesystem.

Exploitation

Exploitation steps:

1. Create a file with a predefined ID that points to the file containing the environment variables in the container (/app/backend.env)
2. Retrieve the file

The first step will "fail" with internal server error due to the checks, but the database entry has already been created, which is what's needed for the second step.

Solve Script (bash):

url="http://slurm.challs.open.ecsc2024.it/api/v1/files/$(uuidgen)"
curl -X PUT -H "Content-Type: application/json" "$url" --data-raw '{"filename":"../app/backend.env","description":"a","author":"challenger","content":"a"}'
curl "$url" | grep FLAG

Running the solve script will immediately retrieve the flag: