RCE is one of the most devastating cyber threats and requires the urgent updating of security patches anytime a vulnerability is found that can open the door to such an attack.
Remote Code Execution (RCE) is the insertion of arbitrary code into a device or system, allowing the attacker to carry out commands and seize control.
RCE allows the attacker to raise their privileges and mask their activities as those of the admin. They can also pivot and attack other vulnerable spots within the same network and inject code to steal all types of data. RCE attacks don’t require the attacker to be anywhere near the device they’re attacking, they just need to take advantage of a memory corruption vulnerability like buffer overflow in a network connected device, be it a router, VoIP endpoint, PLC - any device that is online.
Memory vulnerabilities can be found in third party code or coding errors in the application itself or in the OS. These are the most dangerous 0-day vulnerabilities – in particular buffer overflow vulnerabilities – and malicous actors can readily exploit them with Remote Code Execution.
The potential chaos these attacks can cause is immense. Late last month, researchers from Armis announced that they had discovered 11 zero day vulnerabilities, including six critical vulnerabilities that allow RCE, in VxWorks – an OS used by more than 2 billion devices worldwide. That publication came less than two years after Armis announced the discovery of “Blueborne” a security vulnerability that could potentially make every device on the planet with Bluetooth (estimated at more than 8 billion) open to an RCE attack. And on the automotive front, in May 2018, Keen Security Lab researchers discovered 6 vulnerabilities affecting a variety of BMW vehicles that can be exploited remotely and allow an attacker to carry out RCE.
One of the most glaring real-life examples of the damage such vulnerabilities can cause is the May 2017 WannaCry ransomware attack, which crippled major international companies across the world, causing billions of dollars in losses.
How Common Are These Attacks?
A study earlier this year stated that more than 18% of high and critical vulnerabilities found in internet facing systems over a 12 month period lead to RCEs.
The issue is the criticality. Looking at the critical CVEs reported in the past 3 years for common C open source components like NTP, OpenSSL and CURL one can see that 24 of the 30 critical CVEs are memory corruption vulnerabilities that can lead to RCE.
In 2017, security researchers discovered a vulnerability in open-source server software Apache Struts that could allow attackers to remotely run code on servers that use it. This RCE led to the Equifax breach.
So while such vulnerabilities are hard to find and don’t emerge very often, when an attacker has the ability to carry out Remote Code Execution the outcomes can be severe.
What Methods Can Be Used to Reduce the RCE Risk?
RCE usually requires urgent software updates with security patches anytime a vulnerability is found that can open the door to such an attack. In Product Security, patching can be a challenge given the lengthy supply chain from the manufacturer’s production line to the enterprise network or plant production network. Updating software in IoT and IIoT might not be as easy as updating it in the traditional well-managed IT environment.
Reducing the risk of memory corruptions that lead to RCE can happen during software development and at runtime.
Ultimately the best way to find and prevent vulnerabilities is for developers to write code without vulnerabilities. Good secure coding practices provide code that is more “defensive,” meaning that is written with the assumption that the system will be attacked.
Applying development phase protection:
Static Code Analysis (SCA)
Involves the running of diagnostic tools in order to find potential vulnerabilities in the code. The diagnosis is done without executing the program, by examining non-running – “static” – source code.
Dynamic Code Analysis (DCA)
Often performed after the static stage and involves running the program in order to find any problems during program execution. Because it is performed while the program is being executed, DCA has the added advantage of allowing you to see how your code interacts with other services, databases, and servers.
Fuzzing
Also called fuzz testing, this is a form of automatic diagnostic testing that can find bugs by giving a program unexpected and invalid inputs until one of them reveals a vulnerability and/or causes a crash. Somewhat akin to “let’s throw stuff against the wall and see what sticks,” this method can be used by companies in order to find their own vulnerabilities or by hackers looking for a bug they can exploit in a program. Fuzzing programs tend to be automated and can be set to run for weeks or months at a time and can be one of the most cost-effective methods.
Code Review
Often referred to as peer review, code review involves one or more people checking a program by going through the source code in order to find vulnerabilities as well as places where the code could be improved. Though each developer is different, it’s often the case that you can miss bugs if you try to analyze too many lines of code in a single setting or if you don’t have an idea of which types of mistakes you’re looking for.
Applying runtime protection
Assuming there are still vulnerabilities in the code, even after adopting secure development practices, product security professionals advocate for introduction of runtime integrity measures.
DEP
Data Execution Prevention is a security feature that monitors the programs on a computer to ensure that they use memory correctly. Software makers release DEP-compatible versions of their programs and typically users can turn the DEP on and off at will. The feature has been in use since 2004, when the PAX project implemented it on Linux based systems.
ASLR
Address Space Layout Randomization is an OS security measure that protects against buffer overflow attacks. First introduced into the Linux kernel in 2005, ASLR randomizes the locations of components in the memory, so that attackers won’t know the address of their target. Techniques for bypassing this method were later exposed by researchers leveraging data leakage vulnerabilities to map the memory.
Stack Canary
Stack Canary is a value placed on the stack. Before any function return, the stack canary is checked and if no alteration is found, the program executes normally. If it is found to have been altered, the program execution is cancelled.
CFI
Control flow integrity (CFI) is a highly-effective, state-of-the-art technology for preventing RCE. CFI stops malware from redirecting the execution flow of a program by predefining all valid destinations and stopping attempts to divert the program flow.
Some of the leading platforms have implemented CFI protection, as can be seen with Microsoft’s Control Flow Guard and Google’s Indirect Function-Call Checks and Karamba Security XGuard for embedded devices and Linux.
“It’s always a race. For every defense, there are attackers looking for a way around it. This is the case with CFI too,” said Chief Karamba Scientist Assaf Harel, adding that CFI “these days it is considered very difficult to for trained attackers to circumvent CFI.”
Harel added that CFI, while highly effective, was until lately considered difficult to implement in resource-constrained environments. Recent implementations of this technology have overcome these limitations and are therefore effective protection against RCE.
