Skip to content

Exploit_Command_Injection.md

Latest commit

 

History

History
124 lines (78 loc) · 7.99 KB

Exploit_Command_Injection.md

File metadata and controls

124 lines (78 loc) · 7.99 KB
Raw

Exploit 3: Command Injection via Web Application

Discovery Process

Instead of performing an Nmap scan, we accessed the Metasploitable VM's web application directly.

Step_3

Identified that the web application is running on the default HTTP port (80). Upon interacting with the application, we discovered a vulnerable input field susceptible to command injection.

Exploitation:

Crafted an input to exploit the command injection vulnerability in the web application.

The goal was to inject a command that would be executed by the web server’s underlying system. We used the following input to check for command injection:

Step_4 4 Success Inject a command

This input was provided in the web application's input field, which was designed to take an IP address. The server returned the output of the whoami command, revealing that the process was running as the www-data user.

Explanation of Input:

127.0.0.1: The localhost IP address, used to test if command injection would be possible. |: The pipe character was used to chain additional commands. whoami: A command used to determine the current user.

Failed Attempts:

Before successfully exploiting the vulnerability, we made several attempts with different payloads to verify the existence of the command injection flaw. These attempts failed to return useful information or produced errors.

Attempt 1:
Tried using 127.0.0.1 && whoami:
Step_4 2 Inject a command

Expected to execute whoami along with the IP address.
Result: No output, just an error message.

Attempt 2:
Tried using 127.0.0.1; whoami:
Step_4 1 Inject a command

Used a semicolon to separate commands, hoping to inject whoami after the IP address.
Result: No useful output.

Attempt 3:
Tried using 127.0.0.1%3B%20whoami (URL encoded semicolon):
Step_4 3 Inject a command

Attempted to bypass filtering mechanisms by encoding the semicolon.
Result: Error message returned, and no successful output.

Attempt 4:
Tried using 127.0.0.1 | whoami:

This time we used the pipe (|) to chain the whoami command, which was successfully executed. Result: The command injected was successful and returned the user as www-data.

Results: The input 127.0.0.1 | whoami successfully executed the whoami command on the server, and the output revealed the user running the web server process:

Result: www-data
Step_5 1(id)

This indicates that the web application is vulnerable to command injection and that the web server is running with low privileges (www-data).

Proof of Work:

Once the command injection was successful, we were able to confirm the vulnerability by executing additional commands to gather more information about the system. For example, querying the operating system version:

Step 5 2(uname -a)

This provided detailed information about the underlying OS.

We also attempted to gather sensitive data from the system, including reading files:

Step_5 3(ls)

This resulted in displaying user information:
Step_5 4(cat)

Step 5 5(cat_hostname)

Persisting the Attack:

In order to maintain access and ensure persistence, we followed the steps to add a reverse shell that would allow us to re-enter the system if the application was restarted or the server was rebooted.

The process involved creating a reverse shell connection back to our Kali Linux system by injecting the following command:

Step_6 Persisting the attack

This command would allow a reverse shell to connect back to our Kali system, giving us access even after the web server restarts.

Reverse Shell Setup:
We initiated a listener on Kali Linux:

Step_6 1

Once the reverse shell was established, we successfully gained a bash session on the target system, which remained persistent even after reboots.

Verifying Persistence:
To verify that the reverse shell was persistent, we executed the following command to test if the reverse shell would remain after restarting the target system.

Step_6 2

The listener on Kali Linux captured the incoming connection, confirming that our reverse shell persisted.

Recommendations for Mitigation:

  1. Input Validation:

    • Ensure that user inputs are sanitized and validated before being passed to system commands.
    • Use allow-lists for expected input and reject anything outside of this scope.

  2. Use of Parameterized Queries:

    • Avoid passing user input directly to system commands or shell scripts.
    • Use parameterized queries to securely interact with the system.

  3. Limit Command Execution Privileges:

    • Ensure that any system-level commands executed by the application are done with the minimum necessary privileges.
    • Avoid running web applications with root or administrative privileges.

  4. Implement Web Application Firewalls (WAF):

    • Use a Web Application Firewall (WAF) to filter out malicious input and prevent common attack patterns such as command injection.

  5. Intrusion Detection and Prevention Systems (IDPS):

    • Deploy an Intrusion Detection/Prevention System to monitor for anomalous behaviors, such as unexpected system commands triggered via the web app.

  6. Disable Shell Access for Web Users:

    • Prevent users, especially those running web applications, from having direct access to the shell, reducing the impact of successful command injection.