dark mode light mode Search Archivos descargables

What is RCE (Remote Code Execution)?

Like its name very well says, Remote Code Execution (also known as Remote Code Evaluation) is a vulnerability that allows attackers to access a third party’s systems and read or delete their contents, make changes, or otherwise take advantage of their computers by running code on them – regardless of where they are physically located.

Essentially, by having an app or server that are vulnerable to RCE you’re giving an attacker not only access to your server and a whole lot of data stored on it, but also the ability to use it for malicious purposes, such as attacking other systems with it.

How are RCEs exploited?

RCEs can be exploited when user input is executed by the programming language’s parser. This means that user input is read as part of the code, and executed as such. Although this is generally considered bad practice, it is sometimes done intentionally by developers to allow users to access certain functions of the programming language. 

When done unintentionally, it usually means that a user’s input was not expected inside the functions that open up the RCE vulnerability.

Other types of attacks, however, can also facilitate executing code remotely on a vulnerable server. One such type of attack could be a Local File Inclusion. Local file inclusions can be achieved when files are included in an insecure manner and, for example, allow users to upload files that are then executed by the server. Imagine a site that takes a full path in a URL parameter in order to display a file. A malicious user could potentially upload a web shell, and just by entering the URL where their file was uploaded, have access to the server.

It’s by gaining access through that LFI that they could then look through the server’s content to find somewhere where user input can be taken advantage of to run a command and exploit an RCE.

So how can RCEs be prevented?

The rule of thumb to avoid RCEs is to not use user input inside evaluated code. If possible, avoid eval functions at all cost. Also try to not let users change the content or extension of files that can be parsed by the programming language. You will most likely find a different way to achieve the same results you would doing these two things, but avoid using bad practices.