# Lab Assignment Write-up (ArabSecOps)
Here is the assignment:
#### Phase 0: Figuring Out the Attack Flow
The assignment requires chaining SQLi, XSS, and privilege escalation. The most challenging part was making the jump to a working shell on the server. I decided on a four-step chain:
**The Plan (Thought Process):**
1. **SQLi Bypass:** I'll bypass the login screen. I made sure to configure the database so the first vulnerable login lands me on a **low-privilege user** (`user` or `guest`)—I didn't want instant admin! This forces the next step.
2. **XSS to Admin:** Once I have the low-privilege account, I'll submit a malicious XSS payload through the user search bar. Since I set up a simulated admin bot that checks the logs, the payload will fire when the admin visits their dashboard, giving me **Admin access**.
3. **SSTI for Reverse Shell (The RCE Jump):** As the Admin, I gain access to the administrative "command" console. This endpoint is vulnerable to **SSTI** because it processes user input as a Jinja template. I chose SSTI as the path to RCE because it fits the Flask environment better than traditional command injection. The SSTI payload will force the server to execute a command, giving me a **reverse shell back to my attacker machine**.
4. **Final Root Escalation:** The reverse shell lands me on the web server user (`alice`). Then, I'll use a system misconfiguration on the Ubuntu VM to fully take over the machine and get **root**.
#### Phase 1 : building the website
I used Flask to build the corporate portal and added the necessary flaws. Claude did most of the work but i had to fix some things.
1. **The Vulnerabilities:**\
**SQL :**
* The `username` and `password` values come **directly from user input**.
* Python **f-strings** are used to insert raw values into the SQL query.
* There is **no input validation** or prepared statements.
* An attacker can inject `' OR '1'='1` or more complex SQL payloads to bypass login.
**XSS :**
* User input (search queries) is inserted into `search_logs` table.
* Admin views those logs via this block of code.
* The logs are rendered directly into HTML with:
```
{{ log }}
```
(no sanitization, no escaping)
* Any malicious JavaScript payload stored in the DB **executes in admin's browser**.
**SSTI:**
* This code takes **untrusted user input** (stored in the variable `template`) and passes it directly into `render_template_string()`, which uses the **Jinja2 template engine** to interpret and render templates.
* Since no sanitization or filtering is applied, any user-supplied input is evaluated as a Jinja2 expression.
This results in a **Server-Side Template Injection (SSTI)** vulnerability and can be used as (RCE) to get a reverse shell.
1. **Refining the Vulnerabilities:**
* **SQLi Fix:** I fixed the database user order so exploiting the login only gives me the standard user account first.
* **XSS Target:** I set up the environment with a simulated admin who checks the search logs (where the XSS payload is stored).
* **Cookie Security:** I decided to make the session cookies secure! This was a deliberate choice for the lab: I used a **randomly generated 32-byte key**. This shows defense-in-depth and forces the attacker to focus on the application flaws (SQLi, XSS, SSTI) instead of just forging a cookie.
2. **Summary:** The website is working, and the chain from **SQLi** ---> **XSS** ---> **Admin Privileges** ---> **SSTI** is now ready.
#### Phase 2: Host Privilege Escalation
The final stage details how to move from the RCE (which lands on user `alice`) to the ultimate goal: root access.
1. **Vulnerability Creation:** To make privilege escalation possible for the user `alice` (the user running the web server), I modified the `sudoers` file.
2. **The Rule:** I made it so that `alice` can run `nano` with `sudo` privileges without being asked for a password.
3. **Exploitation:** Once the reverse shell is established (Step 3 in Phase 0), I am user `alice`. I can then run `sudo nano /etc/sudoers`. Since `nano` is running as **root**, I will edit the file to add a new rule: `alice ALL=(ALL) NOPASSWD: ALL`. This grants the **alice** user unlimited passwordless `sudo` rights for all commands, effectively giving me persistent **root access** for the entire operating system.
```yaml
Type: Deliberately vulnerable web application (CTF-style VM)
Operating System: Linux-based (Ubuntu)
Web Server: Python Flask development server
Backend Language: Python 3
Database: SQLite (corporate.db)
Authentication Mechanism: Cookie-based session using Flask session
Roles: User & Admin
```
---
# 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:
```
GET https://mistx0.gitbook.io/mistx0/write-ups/lab-assignment-write-up-arabsecops.md?ask=
```
The question should be specific, self-contained, and written in natural language.
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.