Cybercriminals use a range of strategies to target vulnerable systems – and remote code execution (RCE) attacks are one of the most common strategies. Indeed, according to the 2020 Global Threat Intelligence Report from NTT, RCE attacks were the most common attack technique observed – followed by injection attacks.
The appeal is simple and clear: with RCE, a malevolent attacker located anywhere in the world can attack your systems – no matter where in the world you are.
RCE facilitates an arm’s length attack that can allow the attacker to get away unharmed – while your operations, data and business suffers irreparable harm.
In this article we outline what a remote code execution attack is, point to some of the most pertinent real-life examples of remote execution attacks, and outline the best practices your organization should adhere to in order to prevent a successful RCE attack.
Contents:
- What exactly is a remote code execution attack?
- How does an RCE attack compare with an ACE attack?
- Common types of RCE attacks
- The goals of RCE attacks
- Cryptomining – a key driver behind RCE attacks
- Examples of noteworthy RCE attacks
- Best practices to protect yourself against an RCE attack
- Why patching matters
- RCE attacks are highly prevalent – and prevention is key
What exactly is a remote code execution attack?
The clue is in the language: a remote execution attack involves code executed on your server by a remote attacker. In other words, an attacker uses a vulnerability to access and execute commands on your device or your server no matter where in the world you are located – or where in the world the attacker is located.
RCE attacks vary in shape and form. An attacker can simply execute malicious code on your machine to achieve a specific purpose, but an RCE attack can also mean that an attacker takes full and complete control of your device – including accessing applications and services using elevated privileges.
In general, RCE attacks depends on exploiting some sort of vulnerability. It could be a weakness in network defenses, a security hole in one of your applications – or an operating system vulnerability that’s not been patched.
How does an RCE attack compare with an ACE attack?
As a sidenote, RCE attacks are a subset of what’s called an arbitrary code execution (ACE) attack. Like RCE attacks, in the case of an ACE attack, the attacker executes their choice of arbitrary commands on your computing equipment without your permission – and with nefarious goals. Of course, the difference between an ACE attack and an RCE attack is that, in the case of an RCE attack, the perpetrator is remotely located – whereas the attacker behind an ACE attack may be on your premises.
Common types of RCE attacks
To give you an idea of the broad reach – and broad dangers posed by remote execution attacks we’ll outline some of the common RCE attack vectors. All of these attacks depend on a specific vulnerability, and in each scenario, the attacker has the goal to obtain unauthorized access to your systems. There are three typical attack formats:
Deserialization attacks
Data serialization is where complex data structures e.g. fields and objects are translated into a flatter data structure that can be sent in a simple sequential data stream. This data stream needs to be restored – and that process is called deserialization. It is at this stage that an attacker can intervene as the deserialization process can lead to the accidental execution of binary code. Attackers try to modify the serialized data and thereby insert code into the altered data objects.
Buffer overflow attack
A common strategy that is by no means unique to remote attacks is the buffer overflow attack. Here, an attacker exploits a vulnerability that allows it to overwrite data held in memory. It can do so in order to crash simple devices such as network controllers, to destroy data on a machine, or indeed to insert malevolent code into a machine – which in turn enables the attacker to mount an RCE attack.
Type confusion attack
When a piece of code does not take action to verify the integrity of an object that is passed to it there is a risk that it will create type confusion. Type confusion is dangerous because it allows an attacker to sneak in code that can execute arbitrary commands – simply by creating a mismatch in object types.
The goals of RCE attacks
Just like any unauthorized access to your systems, the goals behind RCE attacks vary widely. The motivations for RCE attacks will depend on your field of business, your clients – and the data that you hold. An attack could aim to accomplish any of the following:
- Infiltrate and monitor. Attackers can simply use RCE attacks to gain a presence inside of your network, for corporate espionage for example. RCE could be the first step in a wider attack – and indeed act as a way to ensure ongoing monitoring of your operations.
- Steal data. RCE attacks could open the door to installing further code, which in turn can lead to data transmission. Starting with an RCE attack, a cybercriminal can build up control of your computing resources to eventually siphon off large amounts of data.
- Disruption. Attackers can use an RCE vulnerability to enter your systems to disrupt it – a simple buffer overflow attack, for example, can significantly disrupt your operations. As a result, remote attackers can attain their goals by ensuring that your online presence is offline – or by causing another disturbance that inconveniences or costs you or your customers.
However, there is one goal that drives a large number of security breaches – and which is, arguably, responsible for the high prevalence of RCE attacks out there in the field.
Cryptomining – a key driver behind RCE attacks
A 2018 survey by cybersecurity firm Imperva contained a stunning result. According to Imperva’s research, almost 90% of all RCE attacks were motivated by one single goal: the installation and execution of cryptomining software on the victim’s hardware.
Why would criminals go to this much trouble to install cryptomining software on your systems? Simply put, cryptomining can deliver big profits – if you have the required computing resources to dedicate to mining cryptocurrency.
With RCE attacks, criminals try to exploit your computing resources in order to solve sufficient cryptography problems to profitably mine cryptocurrency – without paying for electricity, hardware resources, and the like.
At first glance, you may wonder why you should be so worried about someone using your computing resources to solve mathematical problems – but there are a few points to keep in mind. First, RCE-enabled cryptomining can cost you dearly in terms of power consumption and hardware wear.
Next, any unauthorized software on your systems can lead to a further, wider breach – and indeed, compliance breaches. You simply cannot allow criminal actors to execute unknown, unauthorized code on your systems – no matter how innocent the code may appear to be.
Examples of noteworthy RCE attacks
RCE attacks are so commonplace, pervasive, and widespread that it’s difficult to choose amongst the countless examples affecting everything from front-end software to server infrastructure. Let’s take a look at a few examples just to illustrate how widespread RCE attacks really are.
First, take the popular communications platform Discord. In October 2020, a security researcher found an RCE vulnerability in the platform’s desktop app. It wasn’t the most glaring vulnerability, as the researcher had to string together three vulnerabilities to execute the remote code in the Discord app, but the RCE vulnerability was nonetheless real – potentially affecting more than 100 million active Discord users.
Another common communications platform, vBulletin, suffered an RCE bug which was called “ridiculously easy to exploit”. According to Bleeping Computer, the exploit relies on just one line of code – and affects a bulletin used by big names ranging from Sony and Steam right through to Pearl Jam and NASA. The repercussions were real: just after the zero-day exploit was published, attacks started almost straight away – affecting even vBulletin’s forum at the time.
The examples are countless. Take the SMBGhost RCE vulnerability. In June 2020, a proof-of-concept was released that showed how a critical RCE hack could lead to a large number of attacks – according to the FBI. Microsoft has, however, released a fix for this vulnerability – but patching is, of course, not always consistently applied – a point we’ll return to in the next section.
These are just three examples of widespread RCE vulnerabilities that are out there in the wild. The examples simply keep rolling in every day – just look at the list of RCE attacks that continuously present on The Daily Swig.
Best practices to protect yourself against an RCE attack
You simply don’t know whether an attacker is targeting your systems because they’re after cryptomining computing resources, or for a much more serious purpose. Either way, you must take the necessary preventative measures that ensure you’re at minimal risk of a cyberattack – including an RCE attack. Here are a few key steps:
- Early alerts and monitoring. It may not be possible to always prevent an RCE attack, but early alert systems can tip you off to a security breach in situ – or to a situation where a successful attack has led to ongoing execution of illicit code. Similarly, a monitoring system can help you identify odd behavior that points to a compromised server.
- Firewalls and other security software. Deploy tools that can prevent common automated attacks: consider a website application firewall (WAF), for example. Likewise, deploy and run vulnerability scanning tools and penetration testing tools to help identify where a RCE attack may take place so that you can fix the vulnerability before it is too late.
- Build a response plan. It is challenging to avoid an RCE attack 100% of the time – even the tightest of security measures may be compromised. Plan for that event – construct a response plan that can help your organization to rapidly end an attack, and to quickly recover from the possible aftermath.
All of the above points matter, but there is arguably a key policy that can do more than any other policy or action to keep your computing operations safe from a remote attack.
Why patching matters
RCE attacks commonly exploit known security vulnerabilities. These known vulnerabilities are typically fixed by the software vendor – via a software patch. That’s all fine, but the problem with patches is that a patch needs to be applied.
You, the operator of computing resources, must regularly apply patches to your hardware and software resources to ensure that known vulnerabilities cannot be exploited. It seems common sense, but as it turns out consistent patching is not as easy as it seems at first glance.
The difficulty with consistently patching may explain why, according to CSO Online, 60% of breaches involve the exploitation of a vulnerability that has an effective patch – but where the patch was not applied.
Timely and consistent patching isn’t easy. It’s resource-intensive, and disruptive as patching often requires restarts that lead to downtime. That said, there are effective tools that can help.
As just one example, consider KernelCare – our automated patching tool that keeps Linux servers safe and secure from common vulnerabilities – without requiring server restarts, and the downtime that comes with it.
RCE attacks are highly prevalent – and prevention is key
There’s little question that an RCE attack can lead to severe outcomes. From an expensive, resource-draining crypto miner presence, right through to data theft and business-critical downtime. RCE attacks are commonplace too, by no means a rare event that happens only to the unlucky.
Your organization must therefore be aware of RCE attacks – and strongly guard against these attacks. We mentioned a few tips above, but the most critical aspect you should take care of is patching.
KernelCare can help keep your Linux workloads safe from RCE attacks – by automating patching, and by eliminating server restarts. Find out more about KernelCare here.
