(19-02-23) Blog 50 – RCE – What is it? and why is it dangerous?

If you’ve been following my blogs, you may have noticed that in a few of them, I mention that a particular threat actor, or malware is capable of RCE, and that it’s a hackers wet dream to be able to do so.

So in this blog, I thought I’d cover what RCE is, how it can be achieved, why its dangerous, and what you could do to stop it.

So what is RCE?

RCE stands for Remote Code Execution and its the name given to the ability of an attacker to remotely execute malicious code on a computer.

So in this sort of an attack, the threat actor is manipulating the remote machine to make it do whatever they want it to do – They are in control.

The impact of an RCE vulnerability can range from further malware execution to an attacker gaining full control over a compromised machine.

How does an attacker gain RCE?

Typically, an attacker gains RCE by exploiting a vulnerability in the target machine whereby the attacker transmits some malicious data to a remote device/software which is either not checked for validity, or is not checked sufficiently.

So, for example, if a piece of software is expecting to receive data which has a length of say 20 bytes, but instead receives 30 bytes, what does it do?

Correctly written software should check the data, see that it is oversize and “fail gracefully” – in that it should not cause an instability in the software, but return some error to the user indicating that the data is incorrect.

Types of attack

If the software however, doesn’t acknowledge that the data is too large, it might place the 1st 20 bytes in the correct place in the device memory, and the remaining 10 bytes into another area of memory. This could allow those 10 bytes to now be executed outside the normal security perimeter of the software, thus RCE has been achieved. This type of an attack would be classed as an Out-of-bounds write, or buffer overflow.

Another very common RCE attack is that of an Injection attack.

As the name suggests, this is where an attacker attempts to inject malicious data/code into a legitimate stream of data.

Whilst there are various types of injection attack, the most common type is a SQLi (SQL injection) – SQL is the Structured Query Language used by millions of database management systems to interact and manipulate databases.

In an SQLi attack, the attacker deliberately provides malformed input that causes part of their input to be interpreted as part of the SQL command. This enables an attacker to shape the commands executed on the vulnerable system or to execute arbitrary code on it.

Quite possibly the most common SQLi attack is one where the attacker tries to force a boolean TRUE statement on a SQL query.

So lets say that an attacker is faced with a pair of username / password input boxes on a web-page. The attacker knows the username, but not the password.

If the web-page is vulnerable to RCE, the attacker might try something like the following:

In the password field, the attacker has used a boolean OR statement with the value 1=1. This results in a value which is TRUE (1 does equal 1)

The SQL engine would interpret this as something like:

• Does username exist in my data table of usernames = TRUE
• Does password exist in my data table of passwords, OR does 1=1 = TRUE

Therefore, the logic of the username / password check now returns a value of TRUE for both clauses, and so allows the attacker to access the data for the username provided.

The double dash (–) at the end of the boolean statement is an example of a comment instruction. This forces the SQL engine to ignore (comment out) any additional SQL which might be in the syntax after the password field check. Different SQL engines use different comment delimiters, many use double dash, some use a hash (#).

Another common RCE attack is that which is known as a deserialization attack. This attack works by again including some form of malicious code in a stream of legitimate data being sent to a victim system.

Many systems send data to other systems as a serialized data stream as opposed to a series of individual data pieces.

For example, you might have a dataset of peoples name, age, etc. Each data item is a separate entity which you could string together (serialize) to send over a network.

At the receiving and, the data is serialized back to its original structure

If the deserialization module is vulnerable to RCE, then an attacker could change the data in the serialized stream to contain malicious code, which when deserialized could cause the system to become unstable, or allow the attacker to gain unauthorised access.

Suppose you have a Python application that deserializes user input from an external source using the pickle module. The application includes a Person class with a name field that is set via the deserialized data. Here’s what the Person class might look like:

import pickle

class Person
     def __init__(self)
           self.name = None

    def setName(self, name):
           self.name = name

Now suppose an attacker intercepts the transmitted pickled data for a Person object and modifies it to include a malicious payload, such as a serialized instance of the subprocess.Popen class. Here’s what the modified pickled data might look like:

b'\x80\x04\x95>\x00\x00\x00\x00\x00\x00\x00\x8c\x08__main__\x94\x8c\x06Person\x94\x93\x94)\x81\x94}\x94(\x8c\x04name\x94\x8c\x05alice\x94\x8c\x06__setstate__\x94\x8c\x08builtins\x94\x8c\x07getattr\x94\x93\x94\x8c\x0esubprocess\x94\x8c\x05Popen\x94\x93\x94\x8c\x08__init__\x94\x93\x94\x8c\x08__dict__\x94\x8c\x01*\x94\x8c\x0f\x08\x01\x01\x01\x01\x01\x01\x08\x94\x8c\x08__weakref__\x94\x8c\x01)\x94ub.'

When the application unpickles this data to create a Person object, it will also execute the attacker’s payload, which creates a new process and executes a command on the system. Here’s what the attacker’s payload might look like:

import subprocess

class Malicious:
    def __reduce__(self):
        return (subprocess.Popen, (['touch', '/tmp/pwned'],))

In this example, the attack has created a new file called pwned in the /tmp folder, but it could be much worse!

The danger

From the examples above, it should be fairly plain to see the dangers of a system being vulnerable to RCE, but to explain further, the main issues with RCE are:

• Initial Compromise: RCE attacks are commonly used to gain an initial foothold on a device to install malware or achieve other goals.
• Information disclosure: RCE attacks can be used to install data-stealing malware or to directly execute commands that exfiltrate data from the vulnerable device.
• Denial of Service: An RCE vulnerability allows an attacker to run code on the victim system which could allow them to disrupt the operations of this or other applications on the system.
• Cryptomining: RCE vulnerabilities are commonly exploited to deploy and execute cryptomining malware on vulnerable devices.
• Ransomware: RCE vulnerabilities can also be used to deploy and execute ransomware on a vulnerable device.

How to stay safe

As I have detailed in this blog, RCE attacks take advantage of a range of vulnerabilities in victim systems, making it difficult to protect against them with just one approach.

Therefore, multiple strategies must be employed to minimise the risks of being targeted with an RCE attack. Some best practices for detecting and mitigating RCE attacks include:

• Input Sanitization: As seen, RCE attacks commonly take advantage of injection and deserialization vulnerabilities. Validating any form of user input before processing it via an application helps to prevent many types of RCE attacks.
• Secure Memory Management: Out-of-bounds write attacks (A.K.A. buffer overflows) are common ways to achieve RCE. Applications should be tested to detect buffer overflow and other vulnerabilities to detect and remediate these errors.
• Traffic Inspection: RCE attacks typically occur over a network with an attacker exploiting vulnerable code and using it to gain initial access to systems. An organisation should deploy network security solutions that can block attempted exploitation of vulnerable applications.
• Access Control: An RCE attack often provides an attacker with a foothold on the victim network. By implementing network segmentation, access management, and a zero trust security strategy, an organisation can limit an attacker’s ability to pivot through the network.