Target Application: https://github.com/Yavuzlar/VulnLab/tree/main
Day 21 of breaking web applications on purpose.
Sometimes websites give you little tools.
Ping an IP. Check connectivity. Test network reachability.
Simple utility.
But today I asked myself a strange question.
What if the server doesn't just ping…
What if it executes whatever I send?
So I tried something.
🎯 The Setup
The application had a small feature called Send Ping.
You enter an IP address.
Click Ping.
The server checks if that address is reachable.
Behind the scenes, it likely runs something like:
ping <user_input>
Seems harmless.
Until you remember one thing.
Operating systems understand command separators.
For example:
; command
Which means:
"Run the previous command… then run another one."
That gave me an idea.
🧠 The Experiment
Instead of entering just an IP address…
I typed something slightly different.
127.0.0.1;id
Pause.
This tells the server:
Ping localhost.
Then run the command:
id
Which reveals the current system user.
I clicked Ping.
💣 The Result
The page responded.
But not just with ping results.
It showed something else.
uid=33(www-data) gid=33(www-data)
The server just told me exactly which user it was running as.
That means one thing.
The input wasn't just being processed.
It was being executed by the operating system.
⚡ Why This Works
The application took user input…
And directly inserted it into a system command.
Something like:
system("ping " . $ip);
Which means whatever the user types becomes part of the command.
And the operating system happily runs it.
Attackers can chain commands.
Add new commands.
Execute anything the server user is allowed to run.
🧠 Think About This
Imagine giving someone a remote control to your computer.
And saying:
"Press this button to check internet connectivity."
But the button also lets them type any command they want.
That's basically what happened here.
🔥 Why This Is Serious
If attackers can execute system commands, they can:
• Read sensitive files • Install malware • Access system configuration • Move deeper into the infrastructure • Potentially take over the entire server
All from a single input field.
🛡️ The Fix
Never pass user input directly into OS commands.
Instead:
• Validate inputs strictly (IP allowlists) • Use safe APIs instead of system commands • Escape shell arguments securely • Run services with minimal privileges
Security rule:
If user input touches the shell, attackers touch the server.
🎯 Day 21 Takeaway
Yesterday we manipulated carts.
Before that we manipulated accounts.
Today?
We talked directly to the server.
One tiny input field.
One injected character.
And suddenly…
The server started answering questions it was never supposed to.
LESS GOOO 🔥
Short Caption:
Sometimes the most dangerous bug isn't in the database… it's in the terminal.