Hacking VaultGate: Exploiting Node.js App for Flag Capture

Understanding VaultGate and the CTF Objective

The VaultGate challenge presents a local Docker deployment of a Node.js application, accessible at http://192.168.122.1:3000. The objective for any security professional or developer participating in this Capture The Flag (CTF) exercise is to locate and extract a hidden flag, defined as CTF{vaultgate_three_paths_one_flag}. The application stack consists of Node.js with the Express framework, a SQLite database, and an integrated chatbot named VaultBot. The entire setup is designed to run within a disposable Docker container, making it a convenient target for local security testing and learning. The author's setup involves a Kali Linux VM acting as the attacker machine, connected to the target via a private network. All interactions and commands are documented via terminal screenshots, emphasizing precision and reproducibility.

The open-source nature of VaultGate, available on GitHub under the repository todorslavovv/three-paths-ctf, allows anyone to spin up their own instance for practice. This accessibility is crucial for fostering a community of security researchers and developers interested in practical exploitation techniques against modern web application stacks.

Path 1: Exploiting the Chatbot - Prompt Injection

The first path to the flag focuses on the application's integrated chatbot, VaultBot. Chatbots, especially those processing user input directly, are often susceptible to prompt injection attacks. The core idea here is to manipulate the bot's underlying instructions or context to make it reveal sensitive information it was not intended to share. In this scenario, the chatbot likely operates on a set of predefined rules or prompts that guide its responses. An attacker can attempt to craft input that bypasses these rules or tricks the bot into executing unintended commands or revealing its internal state.

A common technique for prompt injection involves using specific keywords or formatting that the bot might misinterpret as commands or as part of its own system prompt. For instance, if the bot is designed to answer questions about stored vault data, an attacker might try to inject commands that ask it to list all available data, including the flag if it's stored in a way the bot can access. This often requires understanding how the chatbot processes natural language and what its underlying Large Language Model (LLM) or rule-based system is sensitive to. The key is to find an input that makes the bot deviate from its intended conversational flow and instead output the flag.

The success of this vector hinges on the chatbot's implementation. If VaultBot directly embeds user input into its prompts to an LLM without proper sanitization or guardrails, it becomes a prime candidate for such attacks. The attacker's goal is to find the magic phrase or sequence of inputs that makes the bot disregard its safety instructions and output the flag.

Path 2: Database Interaction - SQL Injection

The second identified path leverages the application's use of SQLite. Web applications that interact with databases are frequently vulnerable to SQL injection (SQLi) if user inputs are not properly validated and parameterized. In VaultGate, the Node.js and Express backend likely interacts with the SQLite database to store and retrieve information. If any of these interactions involve directly concatenating user-provided data into SQL queries, an SQL injection vulnerability can arise.

An attacker would first need to identify input fields or parameters that are used in database queries. This could include login forms, search bars, or even API endpoints. By submitting specially crafted SQL statements as input, an attacker can manipulate the database queries executed by the application. The objective is to craft a query that bypasses authentication, extracts data from other tables, or, in this specific CTF context, retrieves the flag if it's stored within the SQLite database.

For example, a typical SQLi payload might involve appending a condition like ' OR '1'='1 to a username field to bypass authentication, or using UNION SELECT statements to extract data from unintended tables. The SQLite database, while robust, is not immune to these classic vulnerabilities. The challenge lies in identifying which specific input points are vulnerable and then crafting the precise SQL payload to exfiltrate the flag, which might be stored in a table named 'flags' or similar, or perhaps embedded within user data.