What is RCE (Remote code execution) attack ❓ Prevention methods

7 min readOct 7, 2021

What is Remote Code Execution?

Remote Code Execution or execution, also known as Arbitrary Code Execution, is a concept that describes a form of cyberattack in which the attacker can solely command the operation of another person’s computing device or computer. RCE takes place when malicious malware is downloaded by the host. It’s a phenomenon that can affect a person regardless of the present location of his or her device.‍

What is an RCE (Remote Code Execution) attack?

Remote Code Execution is used to expose a form of vulnerability that can be exploited when user input is injected into a file or string and the entire package is run on the parser of the programming language. This is not the type of behavior that is exhibited by the developer of the web application. A Remote Code Execution Attack can lead to a full-scale attack that would compromise an entire web application and the webserver. You should also note that virtually all programming languages have different code evaluation functions.

A code evaluation may also occur if you allow user inputs to gain access to functions that are evaluating code in the same programming language. This type of measure may be purposely implemented to gain access o the mathematical functions of the programming language or by accident because the user-controlled input is designed by the developer to be inside any of these functions. It is not advisable to carry out this line of action. Many people find it malicious to even use code evaluation.

Example of Code

Let’s take a look at an example of a code evaluation attack.

It’s may seem like a better idea to have dynamically generated variable names for each user and store their registration date. This is an example of how you can do it’s done in PHP

eval(“\$$user = ‘$regdate’);
As long as the username is controlled by the user’s input, an attacker may create a name like this:
x = ‘y’;phpinfo();//

The PHP code that’s generated would resemble this:

$x = ‘y’;phpinfo();// = 2016’;

You can now see that the variable is referred to as x but has the value of y. When the attacker can assign another value to the variable, he will be able to create a new command by using a semicolon (;). He can now fill in the rest f the string. This way, he will not get any syntax errors in his work. As soon as he executes this code, the output of phpinfo would be displayed on the page. You should always remember that it is possible in PHP and other languages with features that can assess input.‍

Arranging Remote Code Execution by Origin

The majority of the distinguished RCE weaknesses are because of certain basic causes that can be followed back to its starting point. The grouping of Remote Code Execution by beginning is examined as follows.

Dynamic Code Execution

Dynamic Code Execution is by all accounts the most widely recognized basic reason that prompts a code execution assault. Many programming dialects are planned to such an extent that they can produce code with another code and execute it right away. This idea is an amazing one that handles various complex issues. Be that as it may, a malevolent assailant can control this idea to acquire RCE access and capacities.

Ordinarily, the code produced quickly depends on certain client input. Customarily, the code incorporates the information that has been remembered for a specific structure. When a malignant aggressor understands that the powerful code age will utilize certain information, it could make a substantial code as a type of access to separate the application. If the contributions of clients are not examined, the code will be executed on its objective.

At the point when you choose to look carefully, dynamic code execution is answerable for two kinds of RCE-based assaults; immediate and circuitous.

Direct

When managing an illustration of direct unique tribute execution, the aggressor realizes that their feedback would be utilized to produce code.

Indirect

In an aberrant way, it’s worried about the powerful code age with client inputs. The client input is typically subject to at least one layer. A portion of the layers might be answerable for changing the contribution before it winds up with dynamic code age. Additionally, dynamic code age might be a subsequent impact and not the immediate utilization of the info. That is the reason it may not be clear to the client that is giving the info that will fill in as a structure block in a code scrap that would be executed distantly.

Deserialization

Deserialization is an incredible guide to depict the present circumstance. No powerful code age ought to occur during deserialization. Intermittently, this is the situation that happens when the serialized object contains crude information fields or objects of a comparable sort. Things become more confounded when the elements of the article are serialized. Deserialization would likewise incorporate some degree of dynamic code age.

It might seem like powerful dialects are the only ones influenced by work serialization. Provided that this is true, the issue would be very restricted. Be that as it may, this situation is very helpful in static dialects as well. It’s harder to accomplish with the static language yet it’s certainly not feasible.

Intermittently, the execution of this idea manages deserialization-produced intermediary capacities. Age objects at runtime are just conceivable with dynamic code age. This implies that if the information that will be deserialized is made in a solicitation made distantly, a malevolent assailant could commandeer and adjust it. All around planned code bits could likewise be acquainted with stunt the powerful code age to execute the capacity when it’s incorporated as a piece of the deserialization.

Memory Safety

One more basic reason for RCE assaults identifies with memory security or API security. Memory wellbeing alludes to the counteraction of code from getting to fundamental pieces of memory that it didn’t instate. It’s ordinary to expect that a lack of memory security would result in unauthorized information access. In any case, the working framework and equipment depend on memory to store executable code. Metadata identifying with code execution is kept in the memory. Accessing this piece of the memory could prompt ACE and RCE. In this way, what are a portion of the reasons for memory wellbeing issues?

The imperfections of the product’s plan

Imperfections in the product configuration are a type of memory wellbeing weakness that happens where there’s a planning mistake in a specific hidden part. Intermittently, the shortcoming part could be a compiler, translator, virtual machine, or even the working framework portion or library. There are various blemishes in this class. A portion of the incorporate;

Buffer Overflow

Buffer overflow additionally alluded to as buffer overread, can be utilized to allude to a basic and famous method that is utilized to break memory wellbeing. This assault takes advantage of a specific plan blemish or a bug to keep in touch with the memory cells that are situated toward the finish of the memory cushion. The support would get gotten back from an authentic call to public API. Nonetheless, cradle just alludes to a starting place threat is utilized to register the actual memory locations of a specific article or program counter. Their separation from the cradle is notable or can undoubtedly be speculated. Investigating the code whenever made accessible or troubleshooting the whole program execution at runtime may end up being useful to an aggressor who needs to look into relative positions.

This implies that a cradle flood would permit the to some degree unavailable memory to be altered. The cradle might be found in the location space of one more machine and it will be changed by calling a distant API. This will make admittance to the memory of the remote machine. There are numerous approaches to utilize this sort of access in making an RCE double-dealing. There’s an overall suspicion that assuming there is a cushion flood weakness, an RCE-based assault isn’t off the cards. This implies that code proprietors are relied upon to promptly fix their support floods before an RCE assault happens.

Equipment Design Flaws

Memory wellbeing assaults can likewise be because of equipment configuration blemishes. They are not as normal as programming assaults and are much harder to recognize. Yet, this kind of assault hugely affects the framework.‍

Impacts of Remote Code Evaluation Vulnerability

An attacker who can execute a Remote Code based attack on a system successfully would be able to execute other commands by taking advantage of the programming language or web server. On many programming languages, the attacker would be able to command the system to write, read, or delete files. It may even be possible to connect to different databases with the attacked system.

Why do Attackers Launch RCE attacks?

While there is no particular reason why attackers choose to utilized RCE exploitation to attack a web application, there is no particular reason. It’s just that some malicious find it easy to take advantage of this code execution to gain access to your systems.‍

How Do You Prevent Remote Code Execution Attacks?

TO start with, you should avoid the use of user input inside evaluated code. The best option in this situation would be to completely avoid using functions such as eval. It’s considered to be a form of bad practice and can easily be avoided. It’s also recommended that you should never let a user edit the content of files that may have been parsed by the programming language in question. Often, this includes letting a user create the name and file extensions that he wants to upload or create in the web application.

These are some of the things that you should not do to avoid RCE-based attacks. They include:

Sanitizing user input. Often, this is difficult to achieve because there is a large amount of pre-installed bypasses and restrictions.
Let a user decide or create the extension or content of files to be used on the webserver. He/she has to use many safe practices when handling file uploads or risk vital information falling into the wrong hands.
Pass any user-controlled input into system callbacks or evaluation functions
Actively blacklisting any special chars or function names. This should be avoided just like sanitizing user input. But it is incredibly difficult to implement.

Originally published at https://www.wallarm.com.