Remote code execution, that is also known as arbitrary code execution vulnerability is one of the most dangerous vulnerabilities. If a publicly accessible website is affected by this security issue, this could lead to a total takeover of the system. As a result, data confidentiality, integrity, and availability might be affected.
One of the biggest RCE vulnerabilities recently, is a Log4j 0-day vulnerability. This shows how disastrous remote code execution vulnerability could be if detected in a component used by many software products. Soon after PoC was published, mass scanning of the internet was happening with intention to take over the systems. Even to this day not all systems are patched.
Table of Contents
What is the Remote Code Execution (RCE)?
RCE is a vulnerability, that allows an attacker to execute code remotely, over the internet. This can be done by exploiting vulnerability, found on publicly available website.
There are different ways how an attacker could execute code remotely when he is engaging with a web application:
- By arbitrary file upload. Let’s say, there is a basic functionality – user can upload avatar to his profile. The problem with this is that there is no validation for the files that are being uploaded. So, instead of the .jpg, .png, or any other image format, .sh, or .php file can be uploaded. This might not be that easy as this sounds, because usually there is some kind of validation. But if the validation is not secure enough, it can be exploited. After the file is uploaded, every time a user visits his profile, server executes the uploaded malicious code. However, the website has to interpret the code as such, other way the file even if opened, will not result in command execution.
- By code injection. This happens when application built with languages such as PHP, Java, Ruby, Python, or any similar, does not validate the passed parameters.
Let’s overview how does the exploitation of RCE looks in the practice.
First step of the RCE exploitation is to find a vulnerable functionality. This can be done either by manually analyzing the application (which can be a really a hard task to do) and trying to identify vulnerable functions. As an alternative, system can be scanned with vulnerability scanner, and if a vulnerable component is found, a public exploit used for the purpose. However, for automatic tool will perform worse on custom software. You can use scanner such as Burp Suite for Remote Code Execution vulnerabilities.
Let’s use an example of the DVWA (Dam Vulnerable Application) Command Injection vulnerability to illustrate a vulnerability leading to the RCE.
The application has implemented functionality of performing a ping command to entered IP address. But we found out that it is vulnerable – we can use || operator and attach our own command, that will be executed.
So, we can craft our own payload. Let’s say in this case we use pwd command, which is basic Unix operating system command, that prints the current working directory. Firstly, we provide a parameter that system expects – an IP address. But as there is no validation for special characters, we can add OR operator and inject our own commands. As a result, the payload with malicious code will be executed on the server. As we can create payload according to our needs, we could also easily steal system passwords, or establish reverse shell.
This illustrates how the code can be executed on a web application. However, keep in mind that RCE affects not only websites – desktop applications can also be impacted.
Biggest Bug Bounties for the Remote Code Execution Vulnerability
If you are bug bounty hunter, you might be wondering how big is the remote code execution bug bounty. There are various bug bounty programs where the companies gives a permission for every interested security researcher to hack their systems. If a vulnerability is found, the researcher reports it to the owners. After the triage process, if the vulnerability is confirmed, researched is compensated. Sometimes it just might be a “thank you” (if it is a government’s bug bounty program), it might be SWAG, or it might be the money. And when we are talking about serious vulnerabilities, such as RCE, the money can be big. Let’s see what are the amounts the security researchers are awarded with.
This information might also be relevant if you are a business owner who is thinking of implementing vulnerability disclosure program.
This data is taken from the Hackerone activity board (“Hacktivity”).
Exposed Kubernetes API – RCE/Exposed Creds
Reported to: Snapchat
Report date: 2018-12-05
Bounty paid: 25 000 USD
RCE via Npm Misconfig
Reported to: Paypal
Report date: 2020-07-16
Bounty paid: 30 000 USD
RCE in “Playstation Now” Application
Reported to: PlayStation
Report date: 2020-05-13
Bounty paid: 15 000 USD
RCE on TikTok for Android Application
Reported to: TikTok
Report date: 2020-12-23
Bounty paid: 11 214 USD
RCE in CS:GO
Reported to: Valve
Report date: 2021-05-27
Bounty paid: 9 000 USD
RCE on Build Server
Reported to: Yelp
Report date: 2020-07-29
Bounty paid: 15 000 USD
RCE via Npm Misconfig
Reported to: Uber
Report date: 2020-10-13
Bounty paid: 9 000 USD
Pre-auth RCE on Twitter VPN
Reported to: Twitter
Report date: 2019-05-28
Bounty paid: 20 160 USD
How to Find Remote Code Execution Vulnerability?
Knowing how to test for a remote code execution would help you to understand how you are vulnerable and how you can prevent such attack from occurring. As this is a very serious vulnerability (remote code execution usually gets CVSS score starting from 8.0 and going up to 10.0), it has to be taken seriously.
If you are a developer, having the skills to identify RCE will help you to evaluate what functions of your technical solution are vulnerable. Such exercise will help you to find critical vulnerabilities before releasing the application publicly.
In order to find RCE, you should use automatic tools.
Finding 0-day vulnerability of RCE manually is in principle very hard. Using automatic scanners and script makes all the tedious work for you. Scanners, such as OWASP ZAP, or commercial Netsparker, will help you to identify vulnerable components or functions.
If we are talking about older software products versions, there is a chance that it might have an official RCE CVE. CVE (common vulnerabilities and exposures) contains all the officially recognized publicly disclosed vulnerabilities. Firstly, you should use tools, such as nmap to identify services. Nmap scripts might help you to find out if the service is vulnerable. In case you found such one, you might use tools, such as Metasploit to exploit it.
How to Prevent RCE from Happening
In order to protect systems from RCE, good practices should be kept in mind:
- Keep your software up to date and install patches as soon as they are released
- Sanitize user input – good validation will prevent you from many potential vulnerabilities
- Use dedicated user on a server to run a system. You should create service account for the webserver. Such user shouldn’t have full system rights, as if RCE is exploited, attacker will be able to make anything to your system
- Use security mechanisms, such as WAF. This will at least slow down the attacker from scanning your system. And at the best case, it will completely prevent from exploiting vulnerabilities. Such tools might also alert you about anomalous activity
And if you are bug bounty hunter, all these things will help you to understand the context of the vulnerability, and potential impact.
Conclusion
Remote code execution is a vulnerability that can be disastrous. If you are system owner, you should take all the steps in order to prevent it. And if you are a bug bounty hunter, this is a vulnerability that companies pays a lot for. If you have the skills to find it, you will get awarded well in terms of monetary value and self-fulfillment as remote code execution, that was found in a system of one of the big companies, is something to be proud of.
Highly passionate about cyber security (penetration testing, bug bounty hunting, cybersecurity in general), and blogging. I am experienced in vulnerability assessments, penetration testing, various security audits, had worked with various clients, most of them were in finance sector.
CompTIA Security+, CEH, CEH Practical, CEH Master, and OSCP certified.