Chimera is a Linux machine that tests a wide range of skills, from web application logic flaws and Git forensics to advanced kernel exploit crafting and timing attacks. This writeup details the single intended path from the initial foothold to root.

Phase 1: Enumeration

The first step in any penetration test is reconnaissance. We begin with only the target’s IP address. A standard nmap scan reveals only an SSH port, which is a dead end without credentials.

nmap -sC -sV 192.168.0.95

This forces us to perform a more thorough enumeration to discover hidden services. A full TCP port scan is the most effective way to achieve this.

nmap -sC -sV 192.168.0.95 -p-

Methodology: An unexpected open port is a significant finding. The next logical step was to perform a detailed service scan on this specific port to identify the running service and gather more information. Since high ports often run web services over SSL/TLS. We run a targeted service scan on port 6520 using the ssl-cert script to inspect its certificate.

nmap 192.168.0.95 -p 6520 -sV --script ssl-cert

The scan revealed that the port was running an Nginx web server over HTTPS. More importantly, the certificate’s Common Name (CN) gave the domain name for the machine. With this domain name, we could now properly access the web service. We added it to /etc/hosts file.

Phase 2: Foothold — Web Application Exploitation

Methodology: With a domain name and a web service identified, we began investigating the application. When automated tools fail, we revert to manual black-box testing, treating the application as a puzzle and forming hypotheses about its internal logic based on its responses.

Navigating to https://chimera.nyx:6520 in a web browser presented me with the “AegisGuard | Threat Analysis Portal,” a corporate-looking application for analyzing files.

Content Discovery

The first goal was to understand how the application was structured. The key to finding the path to the leaked file was to understand how the web application serves its content.

View Page Source: On the main page, I used my browser’s “View Page Source” function.
Find the Clue: In the HTML <head> section, I found a line loading the site’s stylesheet:

<link rel="stylesheet" href="/static/style.css">

3. This line was the critical clue. It directly told me that the server has a publicly accessible directory named /static, which it uses to serve files. This is where any files created by the application might appear.

Discovering the Trigger

Methodology: The application gives no explicit clues about the vulnerability, so I had to deduce it. The process isn’t guessing; it’s a logical investigation based on the application’s context.

Form a Hypothesis: The application is a “Threat Analysis Portal” that mentions a “sandbox.” Sandboxes are designed to restrict filesystem access. Therefore, a likely vulnerability would involve trying to escape or trick these filesystem restrictions. We hypothesized that the vulnerability was related to filesystem manipulation, not a standard web flaw like SQLi or XSS.
Experimentation: Based on this hypothesis, I began testing how the server responded when I attempted to upload files with specially crafted names.

Attempt to upload a file named. write_test.txt -> "Clean."

After multiple tries, we found the vulnerability trigger

Attempt to upload a file named symlink_to_ini.txt -> "Vulnerability Detected."
The goal was to read a configuration file, which often has the .ini extension. We combined “symlink” with “ini” to create the payload.

What is ini?
An INI file, short for “initialization” file, is a plain text file primarily used to store configuration settings for software applications and operating systems.

Based on the discovery of the /static directory, we can now perform another enumeration to obtain the config file. After several tries, we found our file path https://chimera.nyx:6520/static/creds.ini.

Accessing this URL revealed the contents of the Gitea service’s configuration file, app.ini

This file confirmed that a Gitea service is running and provided the domain git.chimera.nyx, which became our next pivot point. We added this new domain to the/etc/hosts file.

Phase 3: Foothold — Gitea Forensics

Methodology: Secrets are often accidentally committed to version control systems. A thorough audit of a repository’s full commit history, including old or seemingly abandoned branches, is a critical step in any application security test.

Get TirexV2’s stories in your inbox

Join Medium for free to get updates from this writer.

We now target the Gitea service at https://git.chimera.nyx:6520. We found a single public repository, aegis-appliance-kernel, owned by the user dev. Our goal was to find a secret buried in this repository’s history.

Bypassing Certificate Verification

When attempting to clone the repository, git throws a security error.

This error is an intentional security feature. The server is using a self-signed SSL certificate, and the git client correctly refuses to connect because it cannot verify the certificate's authenticity with a trusted Certificate Authority (CA). This prevents man-in-the-middle attacks. To proceed, I had to explicitly tell it git to bypass this security check for this specific operation.

Clone the Repository (with bypass):

GIT_SSL_NO_VERIFY=true git clone https://git.chimera.nyx:6520/dev/aegis-appliance-kernel.git
cd aegis-appliance-kernel

The next step was to inspect the repository for any sensitive information. A good first step is to list all the branches to see if there are any non-standard ones.

git branch -a

The name “legacy-prototype” is a huge clue for a penetration tester. Legacy code is often less secure and a common place to find hardcoded secrets or old, forgotten information. This made it our primary target for investigation. We inspected the commit history of this specific branch.

The log revealed two key commits: an initial setup followed by a commit with the message “Reverting accidental credential exposure.” This is a classic sign of a secret being mistakenly committed.

Recover the SSH Key

To get the secret, we checked out the commit before the revert to restore the state where the secret was present.

git checkout <commit_hash>
cat README.md

Phase 4: Gaining User Access

With the private key, we could finally gain shell access to the machine

chmod 600 key
ssh -i key dev@chimera.nyx

1st flag secured

Phase 5: Privilege Escalation

Methodology: Post-exploitation enumeration involves gathering detailed information about the compromised system to find a path to escalate privileges.

We found a file named .config-amd64-vanilla in the dev home directory

The file is a configuration of a specific kernel of our Linux machine

What is a vanilla file in Linux?
.config-amd64-vanilla likely refers to a configuration file or a specific build target within the context of Vanilla OS, an immutable Linux distribution based on Debian,

We checked the kernel version to see if it was vulnerable to any known exploits.

A quick search revealed that this kernel version is vulnerable to CVE-2024–1086

Understanding CVE-2024–1086

Methodology: Before using an exploit, it’s crucial to understand how it works. This helps in debugging and adapting it if necessary. The GitHub repository for the exploit provides a detailed explanation.

The vulnerability is a Use-After-Free (UAF) in the Linux kernel’s nf_tables component, which is part of the Netfilter firewall framework. The flaw can be triggered by a local, unprivileged user. By crafting a special firewall rule with a malicious "verdict," an attacker can trick the kernel into freeing a piece of memory twice (a "double free"). This memory corruption can then be leveraged to overwrite critical kernel data structures, ultimately allowing the attacker to execute code with the privileges of the root user.

kali@kali:~$ git clone https://github.com/Notselwyn/CVE-2024-1086.git
kali@kali:~$ cd CVE-2024-1086
kali@kali:~$ make

Since the target machine does not have any compiler tools installed, we had to perform a cross-compilation. We downloaded the exploit source code to our attacker machine and compiled it there.

After compiling, we needed to transfer the binary to the target. A simple Python HTTP server is a standard and effective method for this.

On our attacker machine, in the same directory as the compiled exploit:

On my attacker machine, in the same directory as the compiled exploit:

Then, on the Chimera machine, we downloaded the file using wget, made it executable and ran it

Phase 6: Root Access

Rooted.

This machine demonstrates a fantastic, realistic chain of vulnerabilities that requires patience, deduction, and a deep understanding of both application logic and low-level kernel exploitation.

I hope you enjoy it

Chimera VulNyx — Official Writeup

Discovering the Trigger

Get TirexV2’s stories in your inbox

Bypassing Certificate Verification

Understanding CVE-2024–1086