mobile applications implemented with Java, and even entire operating systems themselves, may contain weaknesses that open the door to the unauthorized execution of code. Beyond these direct entry points, other flaws can also enable attackers to run malicious instructions. For instance, buffer overruns in languages like C or C++ can let adversaries execute harmful code. Likewise, when programs improperly handle serialized data, it may be possible for attackers to embed instructions that are carried out as soon as the data is processed. Cases have been reported where attackers use SQL injection or cross-site scripting (XSS) vulnerabilities to execute unauthorized code remotely.
In certain situations, remote code execution might not happen immediately. Malicious code may be stored in a configuration file and executed at a later time, possibly on multiple occasions. This is commonly known as stored remote code execution.
It’s crucial to distinguish remote code execution from operating system command injection. In RCE, the malicious payload is written in the application’s native language and runs within its execution environment. By contrast, operating system command injection empowers attackers to issue commands directly on the underlying OS. While terms like “code injection” (as referenced by CWE-94 and promoted by organizations like OWASP) may be more exact, the phrase “remote code execution” remains the term most commonly used.
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
The PHP code that’s generated would resemble this:
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.
The Method of Exploitation
An adversary can introduce harmful scripts by appending a semicolon and the malicious code to the input. The semicolon causes the eval function to treat the subsequent input as a separate PHP command. For example:
In this scenario, the eval function processes the input as:
This results in the execution of both the echo statement and the phpinfo() function, allowing the attacker to run unintended PHP commands on the server.
WannaCry Ransomware: Launched in 2017, WannaCry autonomously propagated across networks, locking up users' files and demanding payment for their release. A large number of affected devices had not received essential security updates. By early 2021, the malware continued to impact numerous organizations as it rapidly infiltrated multiple machines within interconnected systems.
Log4J Vulnerability: Log4J is a logging framework utilized to record various system activities, including errors and routine operations, aiding administrators in monitoring system behavior. In December 2021, a flaw in Log4J that allowed the insertion of malicious code into log entries was exploited by cybercriminals, enabling them to gain unauthorized remote access and control over affected computers.
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.
When managing an illustration of direct unique tribute execution, the aggressor realizes that their feedback would be utilized to produce code.
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 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 execution.
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.
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?
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 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.
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.
Let’s explore the three main categories of remote code execution methods.
Injection-Based Techniques
Malicious actors introduce harmful scripts or commands into a target environment via:
Deserialization Exploits
Attackers take advantage of weaknesses in how an application processes serialized data. By tampering with the serialized input, they can trigger the execution of harmful code when the data is deserialized.
Buffer Overflow Attacks
This type of attack happens when data is written beyond the allocated memory space of a buffer or data structure. It enables attackers to alter essential information, manipulate the program’s execution path, and run unauthorized code.
Weaknesses that permit remote code execution can profoundly affect organizations, leading to financial setbacks, damage to reputation, and compromised information security. Below are some primary consequences:
Unauthorized Entry
Malicious actors run arbitrary scripts on external systems, gaining illicit access to the organization's networks, servers, or applications. Once inside, they can:
Data Compromises
RCE flaws can lead to data leaks where sensitive information is viewed, stolen, or modified. Depending on the nature of the breached data, organizations may face:
Interrupting Essential Operations
Malicious individuals can interfere with vital applications or services by running harmful scripts that cause system crashes, leading to operational downtime and business disruptions. This results in:
Denial of Service (DoS) Exploits
Attackers may leverage RCE to initiate denial-of-service assaults, making systems unresponsive and causing:
Unauthorized Cryptocurrency Mining
Cybercriminals can install malicious code on compromised machines to operate cryptomining software without permission, leading to:
Ransomware Incidents
Ransomware locks files on compromised systems by encrypting them and demands a payment to restore access. Cybercriminals leverage remote code execution to take control, initiate the ransomware attack, and demand a ransom. A recent study by Splunk’s SURGe security research team investigated the speed at which ransomware can encrypt systems. Their conclusion: it happens more rapidly than anticipated. For additional insights, refer to their blog or the complete research findings.
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.
There is a reason for attackers to utilize RCE vulnerability. If theengagement is a penetration test, finding RCE is crucial to the company, sinceit can lead to many other vulnerabilities or security problems. If the companyis being attacked by black-hat hacker and he manages to find and exploit RCE,this puts the company at great risk for losing integrity and confidentiality. Exploiting RCE is one of the worst scenarios a company can face. Thus, even inisolated environments, RCE vulnerabilities are counted as “CRITICAL” 99% of thetime, since once inside (isolated or not), an attacker could escape and attack the internal networks.
RCE could lead to fatal outcomes at times, and the world has witnessed the same quite several times. Here, we enlist 5 latest examples where cybercriminals could benefit from finding an RCE loophole and abuse the victim sites or end-users.
Found in Log4J Shell, the problem initiated a chain reaction. What it means is – 45105 and 45046 were the 2 new vulnerabilities found due to the 44228 loophole. The issue persisted in Apache and penetrated through various versions of Log4j. As Log4j is a Java Library, log4j was being used in millions of applications, so the vulnerability got a way to them too.
Utilizing this loophole, threat actors were able to remotely execute their code without the need for authentication. It just required the creation of a fake LDAP server to make things work for the malicious code. The process of exploitation was simple and quick, so many people took advantage of it, and the world’s top web services were the victims.
This loophole was out in Apple’s operating systems and affected various Apple devices and users around the world. Cybercriminals were able to run malicious payloads on any compromised device with the help of an externally-controlled URL. Be it iOS, macOS, Safari, or watchOS, all major Apple OSs were affected.
This issue affected MS Windows and was caused by a loophole in NFS version 3 – a communication protocol variant we all know about. Exploiting this vulnerability, attackers could use a compromised NFS server connection to forward a payload and run it on the unsecured endpoint as they prefer.
The vulnerability made a big impact on WordPress security and changed how it used to be. 8942 was found in WordPress 5.0.0 in 2019. Using it, hackers could add malicious code to the target site’s WordPress directory via an image containing PHP code as its Exif meta-data. Later, they could execute the code and affect the victim site.
The famous Microsoft Excel RCE loophole was able to lead malicious actors to enable malware for the compromised computer. Not only could attackers control the victim device fully through it, but they could also end the actual user’s admin rights. So, from changing, adding, deleting, and shifting data or applications, there was nothing impossible for hackers utilizing this vulnerability.
The most effective strategy for uncovering RCE flaws varies depending on whether they are already recognized or still undiscovered.
If your organization relies solely on commercial or open-source applications without developing proprietary software, determining the specific version of each system or application you utilize might be sufficient. If the identified version is known to have RCE vulnerabilities, it indicates that your software could be at risk. You can determine the version either through manual inspection or by utilizing appropriate security tools, such as software composition analysis (SCA) platforms for web applications or network scanning tools for interconnected systems and software.
For organizations that create their own software or aim to discover potentially undisclosed RCE vulnerabilities (zero-days) in existing applications, it is essential to confirm the presence of these flaws by successfully exploiting them. This can be done through manual penetration testing conducted by security professionals or by using automated vulnerability scanning tools that can actively exploit web-based weaknesses. Examples of such tools include Invicti and Acunetix by Invicti. It is recommended to employ this method even when dealing with known vulnerabilities to ensure comprehensive security.
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:
To safeguard against RCE assaults, implement the following strategies:
Ensure that all data provided by users is thoroughly checked and sanitized before being processed by the system.
Turn off unnecessary features and services. Regularly update all software components, including libraries and frameworks, to their latest versions.
Deploy tools that monitor application behavior in real-time, detecting and blocking suspicious or harmful activities as they occur.
Use systems that oversee network traffic to identify and respond to potential RCE attempts by recognizing patterns or signatures associated with known exploits.
Consistently update operating systems, applications, and other software components to patch security vulnerabilities and reduce the risk of exploitation.
Regularly review access to systems and confidential data. Perform audits to verify that permissions are correctly assigned and match each user's role and duties.
Implement secure coding practices and rigorously check input data to ensure it stays within the allocated memory boundaries, preventing unauthorized code execution.
Apply security-focused practices during development, including thorough input validation, data cleansing, and effective error handling, to reduce potential vulnerabilities.
Grant users and systems only the minimum permissions required for their functions to limit damage in case of a breach.
Employ tools that monitor network activity to detect and block malicious traffic while safeguarding web applications by thoroughly examining HTTP requests.
Consistently carry out security assessments, examine application code, and utilize automated scanning tools to proactively discover and rectify potential vulnerabilities.
Manage which applications and processes are permitted to run on your systems by maintaining lists of approved (allowlists) and forbidden (blocklists) software.
Engage in systematic testing to uncover and fix vulnerabilities before they can be exploited by attackers.
Analyze data flows for unusual patterns or connections to known malicious sources, indicating potential RCE attempts.
Configure firewalls to control the flow of network traffic, enforcing predefined security policies to prevent unauthorized access and deter malicious actions.
By implementing these measures, organizations can significantly reduce the risk of remote code execution attacks and enhance their overall security posture.
In web development, nearly every major programming language offers capabilities to execute code dynamically during runtime. Utilizing these execution functions within web applications can create opportunities for server-side remote code execution vulnerabilities. For instance, functions like eval in PHP and JavaScript serve this purpose.
When developers permit functions such as eval to handle input that hasn't been properly sanitized, it opens the door for malicious actors to embed and run their own code through user-supplied data. Potential sources of such manipulable inputs include information entered through web forms, data within HTTP headers, files uploaded by users, or even altered cookie values.
By failing to cleanse these inputs, applications become susceptible to attacks where harmful code is injected and executed on the server, leading to unauthorized access, data breaches, and other security compromises.
The most reliable method to guard against RCE flaws in web-based software is to refrain from utilizing programming features and methods that are vulnerable to remote code execution when handling untrusted input. A common example of such a feature is the eval function found in languages like PHP and JavaScript.
In scenarios where the use of functions like eval is unavoidable due to application requirements, and they must process input originating from users (whether directly or indirectly), it is essential to recognize and accept the inherent risk of RCE vulnerabilities. Even with stringent measures to cleanse and validate inputs, determined attackers may still find ways to bypass these defenses.
Although completely eliminating RCE risks in these situations is not feasible, the potential for attacks can be significantly reduced, and their impact lessened by implementing robust validation and purification of both incoming and outgoing data. This should be based on allowing only known safe inputs (whitelisting) rather than trying to block malicious ones (blacklisting), thereby enhancing the overall security of the application.
Wallarm offers comprehensive protection against Remote Code Execution threats by integrating advanced security measures directly into your web applications. Utilizing Wallarm’s intelligent security platform, organizations can automatically detect and block malicious attempts to execute unauthorized code on their servers. The platform leverages machine learning and behavioral analysis to identify suspicious activities in real-time, ensuring that even sophisticated RCE attacks are thwarted before they can cause harm.
Additionally, Wallarm provides continuous monitoring and automated vulnerability assessments, allowing businesses to stay ahead of potential exploits by promptly identifying and addressing weaknesses in their applications. With its seamless integration into existing development workflows, Wallarm not only enhances security but also supports agile development practices without compromising on protection.
By deploying Wallarm, organizations can achieve a robust security posture that minimizes the risk of RCE vulnerabilities, safeguards critical data, and maintains the integrity of their digital infrastructure. Wallarm’s proactive approach to threat detection and mitigation ensures that businesses are well-equipped to defend against evolving cyber threats, ultimately preserving their reputation and operational continuity.
What constitutes a remote code execution vulnerability?
A weakness that enables the execution of external code in a web application gives malicious actors the ability to run commands on the server powering that application. This risk is notably severe because it grants them a high degree of influence over the compromised environment. A notable example of such a vulnerability is Log4Shell, which exploited a defect in the Apache Log4j library. Exploiting these vulnerabilities allows attackers to control the server, enabling them to perform unauthorized actions that could lead to service interruptions, exposure of confidential data, and breaches of sensitive information.
How serious is a vulnerability that allows remote code execution?
A vulnerability that facilitates remote code execution is extremely serious due to the wide range of potential harm it can cause. Once exploited, it enables attackers to run any code or commands on the compromised server, effectively granting them complete control over the system. For instance, an attacker could utilize this flaw to install a web shell, creating a persistent access point. This access allows them to perform further malicious actions, such as exfiltrating confidential data, interrupting services, deploying additional malware, or using the server as a base to launch attacks on other systems within the network. The serious dangers posed by RCE vulnerabilities underscore the importance of implementing robust security practices to defend against and reduce the impact of such threats.
What methods are available to identify remote code execution vulnerabilities?
To successfully identify and address remote code execution vulnerabilities, it is essential to use a variety of advanced security testing techniques. One of the most effective approaches is employing Dynamic Application Security Testing (DAST) tools. These tools mimic real-world attack scenarios by interacting with active applications to identify potential RCE weaknesses. DAST tools scrutinize the behavior of applications during these simulated attacks, helping to uncover vulnerabilities that could be exploited by malicious actors. Furthermore, incorporating DAST into the continuous integration and continuous deployment (CI/CD) pipeline ensures that vulnerabilities are detected and fixed promptly throughout the development process. Combining DAST with other security measures, including routine code reviews, penetration testing, and automated tools for identifying vulnerabilities, greatly enhances the capability to uncover and address RCE vulnerabilities proactively, reducing the risk of exploitation.
Subscribe for the latest news