1. Overview

Remote code execution (RCE) is an OWASP-recognized vulnerability that allows attackers to run malicious code on a target system remotely. It can lead to complete system compromise and data loss if left unchecked.

In this tutorial, we’ll learn the basic concept of remote code execution security vulnerability. We’ll examine the working of RCE attacks and some common practices that can potentially lead to RCE. Furthermore, we’ll learn various strategies to protect against RCE attacks. By understanding the risks of RCE, we can secure our infrastructure and data from potential threats.

2. What Is RCE?

The RCE vulnerability is performed through code injection, malicious emails or attachments, and vulnerabilities in the operating system. If implemented correctly, attackers get full access to sensitive data and can potentially spread malware to the target machine.

To perform RCE, an attacker first identifies a vulnerable module in an application. This is the part where the experience of an attacker plays a crucial role. Alternatively, they can run manual tests or use automated tools to scan for vulnerabilities. Once vulnerable code is found, they’ll use a payload to exploit it.

Let’s consider a scenario where hackers need to discover a vulnerability in a website.

Firstly, they’ll start by injecting vulnerable payload into the search bar on the website. Furthermore, they’ll craft a search query containing the malicious code and send it to the website. On receiving the search request, the server will execute the malicious code. Eventually, this allows the hacker to access the website’s database and customer information.

The hacker can then exfiltrate sensitive data, such as customer names, addresses, and credit card numbers:

search request

They can also plant malware on the website to infect more users. In this scenario, the website’s failure to properly validate user input led to the RCE vulnerability. As a result, the hacker gains unauthorized access to the system and sensitive data.

3. How Does RCE Work?

So far, we’ve got a basic understanding of RCE vulnerability. Let’s now understand the working of RCE using an example. RCE can be injected when the input fields aren’t properly sanitized or validated by the application. Consider the following PHP code for a login form:

<?php
$username = $_POST['username'];
$password = $_POST['password'];

$query = "SELECT * FROM users WHERE username='$username' AND password='$password'";
$result = mysqli_query($conn, $query);

if (mysqli_num_rows($result) > 0) {
// login successful
} else {
// login failed
}
?>

The above PHP code is a login script to verify a user’s existence with the given username and password. Consider an attacker using a malicious user input like ‘; system(‘rm -rf /’); //, then the SELECT query would look like this:

SELECT * FROM users WHERE username='''; system('rm -rf /'); //' AND password=''

The above query will delete all files, effectively compromising security. In order to avoid this type of attack, it is critical to sanitize and validate user input.

RCE can also be introduced through language interpreter vulnerabilities. For instance, if we use a PHP version with any known vulnerability, an attacker could potentially exploit that vulnerability by executing arbitrary code.

4. Different Ways to Perform RCE

Remote code evaluation and stored code evaluation are two different methods of performing RCE.

In remote code evaluation, an attacker injects malicious code into a web application. The vulnerable code can be injected through a user input field like a search bar and executed remotely. This allows the attacker to access sensitive data on the server. Alternatively, they can also send a malicious email attachment that exploits a vulnerability.

Another method to perform RCE is using Stored code evaluation. An attacker sends the malware to a system to execute it later. This malware is stored in the database without proper validation. Later, when a genuine client requests a webpage, the server pulls it from the database along with the untrusted code and executes it:

RCE

The primary difference between the two methods is the location of the injected code and when it is executed. Both methods of RCE allow an attacker to execute arbitrary code on a target system. However, the specific location and timing of the injected code differ between the two methods.

4.1. Types of Remote Code Evaluation

Depending on the location of the injected code, there can be three types of RCE attack: server-side injection, client-side injection, and shell injection.

Server-side injection attacks involve injecting vulnerable code into a web application or database in order to execute it on a server. This type of attack targets user input fields, such as a search box or login form. Applications that don’t properly validate or sanitize input are more vulnerable to server-side injection.

Client-side injection attacks inject malicious code into a client application, such as a web browser. This is done through malicious ads, emails, or websites that exploit vulnerabilities in the client’s software.

Shell injection attacks inject malicious code into a shell where the server is running. This is done through user input fields that allow command execution or through existing vulnerabilities in the operating system or network devices.

5. Prevention and Mitigation Strategies

There are several prevention and mitigation strategies that can help to protect against remote code execution (RCE) attacks.

Firstly, ensure proper validation of user input. This includes filtering out any potentially malicious characters or code and processing data only after validation:

if (preg_match('/[^a-zA-Z0-9]/', $username) || preg_match('/[^a-zA-Z0-9]/', $password))
{
    exit(); 
}

This validation uses a regular expression to allow only alphanumerics in the username and password fields. Moreover, this validation removes the possibility of exploiting the code using special characters.

There are a few more strategies to handle RCE:

  • Adhering to secure coding practices can help to reduce the risk of RCE vulnerabilities in custom code. For example, we can avoid the use of eval() and other risky functions.
  • Regularly updating software, web servers, databases, and operating systems is another good practice to avoid RCE.
  • Using secure communication protocols, such as HTTPS and SFTP, can prevent RCE attacks by encrypting data and preventing tampering.
  • Using strong passwords and implementing multifactor authentication can help to prevent RCE attacks by making it more difficult for an attacker to gain unauthorized access to systems and resources.
  • Regularly scanning for vulnerabilities can help to identify and address RCE vulnerabilities prior to exploitation.

The above steps won’t pinpoint the vulnerable code but will help in decreasing the vulnerable area in the source code.

5.1. Tools to Detect RCE

There are several tools to detect RCE vulnerabilities:

  • Vulnerability scanner tools can scan systems and networks for known vulnerabilities, including RCE vulnerabilities.
  • Application security testing tools help in testing web applications at the application level.
  • We can use network security monitoring tools to monitor network traffic for suspicious activity.
  • Security professionals can use penetration testing tools to simulate RCE attacks and test an organization’s defenses against them.

It is a good practice to regularly use these tools as part of a comprehensive vulnerability management program in order to identify and address RCE vulnerabilities timely.

6. Conclusion

In this article, we learned about the remote code execution vulnerability. It allows an attacker to execute arbitrary code on a target system remotely. Firstly, we explored different types of RCE attacks, including server-side injection attacks and client-side injection attacks.

Further, we examined the two primary methods for performing RCE: remote code evaluation and stored code evaluation. We discussed the differences between these methods and provided examples of each. Finally, we covered several prevention and mitigation strategies to protect web applications against RCE attacks.

Comments are open for 30 days after publishing a post. For any issues past this date, use the Contact form on the site.