Remote code execution (RCE)
What is an RCE attack?
An intrusion by remote code execution (RCE) occurs when an adversary is unauthorized to illicit access and control a device or server. Most of the time malware is used to take over the system.
What does RCE mean?
RCE refers to the mechanism by which a network flaw is abused by an agent to execute arbitrary code on a targeted device or machine.
How does RCE work?
Most, if not all, of the known RCE vulnerabilities, have a small number of underlying causes.
1. Dynamic code execution
Dynamic code execution tends to be the most common attack vector leading to RCE. Most programming languages have some way to generate code with code and execute it on the spot. This is a very powerful concept that helps solve many complex problems. However, a malicious third party can easily abuse it to gain RCE capabilities.
Often, the code generated at runtime is based on some user input. More often than not, the code includes that input in some form. A malicious actor, realizing that the dynamic code generation will make use of a given input, could provide valid code as an input to attack your application. If the user inputs are not vetted, then that code will be executed on the target machine.
Broadly speaking, dynamic code execution causes two major classes of RCE vulnerabilities: direct and indirect.
2. Direct
In the case of direct dynamic code execution, the malicious actor is aware that their input would be used in code generation.
3. Deserialization
Deserialization is a very good example of this scenario. Seemingly no dynamic code generation should happen on deserialization. That is actually the case when the serialized object contains only data fields of primitive types or other objects of that kind. Things get more complicated, however, when the methods/functions of an object are serialized. Deserialization then will usually include some form of dynamic code generation.
You might think that dynamic languages are the only place where function serialization makes sense. The problem will be of limited scope then. But it’s a useful scenario in static languages, too. It’s somewhat harder to achieve in a static language but by far not impossible.
Quite often, the implementation consists of deserialization-generated proxy objects/functions. Generating objects/functions at runtime is a case of dynamic code generation. So, if the data to be deserialized originates from a request made by a remote machine, a malicious actor could modify it. Carefully crafted serialized code snippets can be injected that trick the dynamic code generation to execute them when invoked as part of the deserialization.
4. Software design flaws
Software design flaws are a type of memory safety vulnerability where there’s a design error in some underlying component. More often than not, that would be a compiler, interpreter, or virtual machine, or potentially the operating system kernel or libraries. There are a number of different flaws that belong to this class. We’re going to take a more detailed look at what’s arguably the most common one.
How to prevent RCE attacks?
RCE attacks are very complex and network vulnerabilities have often evolved and new exploitative opportunities are generated, as recent advances in the field have been established. That said, preventive steps can be taken by organizations to protect their networks against attacks.
1.OSs and third-party software need to be updated all the time.
2. Cyber Threat Intelligence platform is a must to prevent the RCE attacks before even they occur.
3. Try to block special chars or function names.
4. Use safe practices for secure file uploads.
5. Validate and sanitize user entries and inputs.
6. Limit access to the interpreter.
References:
[1] Security Advisories, Qualys
[2] 2020 Vulnerability Statistics Report, Edgescan
[3] Exposed Vulnerabilities and Their Impacts, Rewterz
I hope you get some insight into how RCE actually works. In the next blog, I would be giving you some tips and tricks on how you could find your next RCE bug
Thank you
