Do you want to know what Remote Code Execution is and what steps to take to prevent vulnerabilities in your application?
To understand how forms, query components, and even cookies can make your application vulnerable to attack, let’s first look at what server-side is and how Remote Code Execution can be an exploited vulnerability along server-side.
So if you want to understand more about RCE and how to make your applications safer through a Shift-Left approach, keep reading this article!
Here are some tips to minimize attacks exposure and making software less vulnerable from development.
You can also listen to the audio version of this article:
Remote Code Execution vs. XSS
Before we get into the topic of this article, let’s make a point.
This is one of the first texts we are going to publish explaining some of the vulnerabilities we find most easily on the web, what their impacts are, and how we can take basic actions to stop exploiting those vulnerabilities.
In this first article, we will explain a little about RCE or Remote Code Execution.
It is important to make it clear that RCE is different from the XSS vulnerability found in OWASP Top 10, even though it is also a code injection vulnerability.
The basic difference is that RCE is a vulnerability that exploits a server-side fragility, meaning that the code sent will be executed on the server-side.
In XSS, for example, the code used exploits a client-side weakness, usually using the user’s browser to return the desired data or information.
But we have to remember that both vulnerabilities are dangerous and bring to the application framework a number of risks, as we will detail below. Check it out!
What is Remote Code Execution?
As we commented above, RCE, or Remote Code Execution, is exploiting an application weakness that allows attackers to send malicious code to be executed.
For this, it uses application language and server-side exploit.
Basically, any application that does not properly handle the data it enters will end up being vulnerable to this type of attack.
With the number of web applications we have today, it is not surprising that this kind of application ends up being the attackers’ favorite target.
How does Remote Code Execution work?
As we mentioned earlier, Remote Code Execution is a server-side exploited vulnerability, known as server-side.
However, in order to say that an application can be considered vulnerable to CERs, two basic conditions must be identified – both described in more detail in CWE-94 and CWE-95.
In general, CWE-94 describes that during the construction of software, it depends totally or partially on the input of data.
Even though data entry is a fundamental part of the software, it does not properly perform actions that could counteract the arbitrary use of malicious code.
While CWE-94 talks about the need to validate input code and data in an application, CWE-95 addresses the need to handle code syntax entries before they are processed in a dynamic evaluation call.
How the attackers act
But we have to imagine that an RCE refers not only to entering data and codes through a form, for example.
In addition to forms, attackers can use query components to perform CER attacks – or cookies or file uploads to the application.
The fact is that the vast majority of these media are not under the control of the developer.
What is in control of the developer is the introduction of validation mechanisms of both data and parameters sent to the application.
However, even knowing the need for input data validation, many developers overlook this fact and leave their applications vulnerable.
Then the application uses this data that has not been validated, making it vulnerable.
This vulnerability is often exploited by inappropriate use of functions such as eval in PHP – or other equivalent functions in other languages - and of course the concatenation of user-submitted strings.
If malicious code sent by the attacker is processed by the server, the attack is confirmed and the attacker will have server-side access to the language interpreter used by the application.
Then, if this application has access to system calls, an attacker could scale this vulnerability to execute a command on the server itself, now allowing it to inject commands during the attack.
How can Remote Code Execution be correct?
A vulnerability correction such as RCE is basically the same as other vulnerabilities in this category.
A code built, validated and tested during this period, is more likely to be free of this type of vulnerability.
However, some points need to be noted so that we may have a lower chance of exposure to vulnerabilities.
1. Validation and sanitization of entries
If your application should only receive one data type in a given field, why not limit the expected data to this field?
This is one of the most basic actions that can be implemented that can solve many problems.
Still regarding validation, look for special characters, symbols and characters used by the language used in the application as well as the operating system that supports the application.
2. Treat all data as unreliable
Since the developer has no control over user-entered data, the interaction field should always be treated as unreliable.
That is, every time there is an operation where the user can enter any source in the application, that source must be rigidly validated.
This allows you to filter the data sent to the system so that it is exactly as expected, avoiding possible errors and attacks.
3. Test and validate your code
Build, on the development mat, a process that ensures your code is validated at various times – not just at the end.
The constant validation of the code ensures that its security is tested at various times of development, thus allowing faults to be more easily identified.
4. Limit access to the interpreter
When setting up your server, ensure that access to the interpreter is limited and that the user has privileges just to perform the task they need for their application.
This way, the chances of a malicious user being able to access other areas are reduced.
Be Cautious – Always
This is a short list of tasks that can be done to minimize the possibility of vulnerabilities that could allow RCE to run.
However, we cannot determine a finite list, these are just some basic actions that should be performed, but should in no way account for the full range of tests.
The purpose of this article was to simplify the presentation of the RCE, so that it can be understood by those who work with security teams, but who do not have much technical knowledge.
And even those who have a greater understanding of the subject – such as developers, for example – can also benefit from this article to remind you what to do to keep applications safer.
We hope that in this way we can contribute to a better vision of AppSec for everyone.
