Day 024 #FromZeroToHacker – Command Injection

Time to open terminals in other’s machines with Command Injection and wreak havoc!

Another #FromZeroToHacker challenge.

Table of contents
Introduction
What I have learnt today?
Stats
Resources

What is Command Injection?

Command injection is the abuse of an application’s behaviour to execute commands on the system by using the same privileges that the application is running with. If we manage to perform a command injection with the user tom, the commands will be executed under the tom user.

It is also known as RCE (Remote Code Execution), as the attacker executes payloads without direct access to the machine itself (via an interactive shell).

It is also known as RCE because of the ability to remote execute code within the application. It is a good goal for an attacker to achieve RCE, as it means it can read system or user files, data, etc.

Discovering Command Injection

This vulnerability exists because applications often use functions in programming languages such as PHP, Python, NodeJS, etc. to pass data and make system calls on the machine.

Let’s see one code snippet:

PHP code

You can read the code, but basically, this application gets the ‘title’ string from the user, search a database (a .txt file in this example) and displays if it is within the file or not.

An attacker could abuse this application by injecting their own commands, using the text passed to send a command to read more sensible data.

Exploiting Command Injection

Applications that use user input can often be used with malicious intent. For example, the shell operators ;, & and & will combine two or more system commands and execute them both (You can learn more about Linux in previous lessons).

Command injection can be detected in two ways:

  1. Blind command injection, where there is no direct output from the application, and we have to investigate the behaviours of the application to determine if we are successful.
  2. Verbose command injection, where there is direct feedback from the application. If we run a command, we can see the result in the application.

Detecting blind command injection

Blind command injection is where there is no output visible after we execute a command, and the application outputs no message.

We need a way to tell us that the command has been successful, so we can, for example, introduce some time delay (with ping or sleep).

Another method to detect them is by forcing some output. This can be done by using redirection operators (>). For example, we can tell the web application to execute commands that output a text, and then redirect the text to a file.

Remember that you know all of these commands and more because you already watched my Linux Fundamentals series.

Testing blind command injection is hard and complicated because requires a bit of experimentation and there is no roadmap that works for all the machines and applications.

Luckily, we have the curl command, as it can deliver data to and from an application with our payload. For example:

curl http://vulnerable.app/process.php%3Fsearch%3DThe%20Beatles%3B%20whoami

Detecting Verbose Command Injection

This is the easiest method, as the application gives you direct feedback on what’s happening. For example, using ping or whoami directly displays the result on the web application.

Useful OS-neutral payloads are whoami (See the current user) or ping (Hangs the application X seconds). Linux has ls (lists the content of the current directory), sleep (similar to ping) and nc (Spawns a reverse shell, letting us navigate around the target machine). Windows has dir(the Windows version of ls) and timeout(similar to ping).

Remediating Command Injection

Despite what we saw, this type of attack can be prevented. From minimal use of (potentially) dangerous functions or libraries to filtering input.

Sanitasing (or removing) vulnerable functions, input sanitasion from the user, etc are great ways to protect our application, but still, we can bypass filters by learning and then abusing the logic behind an application. For example, one application may strip out quotation marks, but we can use the hexadecimal value to achieve the same result.

Skipping sanitasion

Example

We have a web application that tests the availability of a device by entering its IP address in a field.

Command Injection #1

If we send the ls command, we get nothing:

Command Injection #2

Is all lost? No. As we saw, we can concatenate a series of commands to be executed. This application is waiting for an IP to do something in the background. What would happen if we give them the IP and a command that should execute after?

Command Injection #3

Cool, let’s see what we can do with it:

Command Injection #4

Nice! We know the current user. But let’s be a bit nasty:

Command Injection #5

You should know what this means 🙂

Summary

Time for a recap. We have learned about:

  • How to discover the command injection vulnerability
  • How to test and exploit this vulnerability using payloads designed for different operating systems
  • How to prevent this vulnerability in an application

Stats

From 154.560th to 150.868th. Still in the top 8% in TryHackMe!

Here is also the Skill Matrix:

Skill matrix

Resources

Path: Web Fundamentals

Introduction to Web Hacking

TryHackMe: Command Injection

Other resources

Video: Command Injection | Complete Guide
Video: Command Injection Attack | Demo