Remote Code Execution (RCE) attacks explained

RCE attacks explained

Remote code execution (RCE) is more of a category of attacks than a single defined attack. Remote code execution can have many faces, in that the term applies to many different kinds of attacks. However, on a basic level, all of the attacks that can be subsumed under the RCE umbrella share a commonality: RCE attacks are all achieved by exploiting vulnerabilities in the configuration of remote computers/servers in order to run arbitrary code on the target system.

If an attacker can pull that off, the consequences can be more than significant. Having the server execute arbitrary code (i.e., code supplied by the attacker) could enable the attacker to steal confidential information, modify or destroy files, perform a distributed denial of service (DDoS) attack, or worse yet, actually take over the entire system.

So the issue clearly merits some attention.

Vulnerabilities required

For an attacker to pull off a remote code execution attack, the target system must have a pre-existing vulnerability for the attacker to exploit. Various vulnerabilities could open the door to a RCE attack – too many to name. However, the following types of vulnerabilities are the most commonly used to perpetrate RCE attacks.

Unsanitized user input

If your web site/application allows for user input without having proper sanitizing measures in place, you’re opening the door to all sorts of unintended behavior on behalf of your server, such as arbitrary code execution. Don’t trust user input – ever. This point also ties in to type confusion, explained below.

Broken authentication

This first vulnerability is a bit obvious, but if care isn’t taken to configure authentication mechanisms correctly, the consequences could be disastrous. In fact, this vulnerability ranks second in OWASP’s vulnerability top ten list – it’s a doozy.

If your web site/application’s authentication and session management functions are incorrectly implemented, attackers could compromise passwords, keys, or session tokens. They could also attempt to exploit other vulnerabilities in the application in order to assume other users’ identities with potentially sensitive permissions. Once the attacker is in, they could execute arbitrary code and possibly take over your server with the proper permissions.

Poor access control

Access control lists (ACL) limit the permissions of your users to only those that are necessary for them to complete their work. Without properly segmented permissions, if an attacker hijacks a user account that has root privileges because of poorly implemented access control, the damage the attacker could do is considerable. Conversely, if an attacker compromises a user account with limited permissions, the damage the attacker can do is limited to the permissions they have. They may still be able to cause you trouble, but much less than is they had escalated or root privileges.

Buffer overflows

Software is typically programmed to use buffers. In the world of programming, a buffer is a fixed amount of physical memory (RAM) that’s used to store temporary information until it’s needed or moved to another location. Because the buffer constitutes a fixed amount of RAM, bounds-checking measures need to be written into the code to ensure that the buffer’s capacity is not exceeded. If no bounds-checking measures are present (that’s the vulnerability), the amount of data written to the buffer can exceed its capacity. When that happens, the overflowing data will overwrite the legitimate data of neighboring buffers. Buffer overflows can destroy essential data, crash the system, and overwrite memory locations with arbitrary code (malware) that the system later executes.

Type confusion

Another commonly exploited vulnerability is type confusion. In software, whenever part of the program passes an object (a file, a string, a link, etc.) over to another part of the program, the object type needs to be checked, so the program knows what to do with it and how. However, if this check is not written into the code, it becomes possible to leverage this oversight to exploit the system. By writing an object to memory as one ‘type pointer’ (let’s say A) and then reading it as another ‘type pointer’ (let’s say B), an attacker could trick the system into executing arbitrary code. If proper checks were in place, pointer type A could not be read as pointer type B, and the malicious code would not run.

Deserialization manipulation

Whenever an object is passed from one part of the program to another, that object must first be serialized (i.e., converted into binary). Once the serialized object arrives at its destination, it needs to be deserialized (converted back into the original object). Attackers can exploit the deserialization process to produce anomalous objects that can manipulate the system to execute unintended commands.

How do remote code execution attacks work?

Any online attack in which an attacker remotely executes code on your system can be considered a remote code execution attack. So there’s no playbook example. And while the common vulnerabilities listed above are the most frequently exploited for entry, any attack that remotely executes code on a system can be considered a remote execution attack, regardless of how the attacker got in.

Nonetheless, the general steps look like this:

The attacker scans machines over the internet for known vulnerabilities that may open the door to an attack.
Once a suitable vulnerability is found, the attacker exploits it for entry and access.
Once the attacker is in, they execute malicious code on the system to wreak the typical havoc: steal information, encrypt or destroy files, alter permissions, download more malware, etc., based on the vulnerabilities found, the state of the compromised machine (security patches applied or not, for example), and the tools available to the attacker.

The malicious code execution is typically achieved through the use of bash scripts and terminal commands. The attacker feeds the code into a vulnerable app that executes it (or makes a call to the kernel to execute it).

Remote code execution attack examples

Some of the most well-known online attacks come in the form of RCE attacks. Let’s look at some examples.

WannaCry

On May 12, 2017, it was revealed that hundreds of thousands of computers worldwide were infected by the WannaCry ransomware. Ransomware typically encrypts the files on the infected computer, locking out the users, and demands a ransom payment in exchange for decrypting the files.

WannaCry itself allows for remote code execution. An attacker needs to send a specially crafted message\ to a Samba server (SMB) – a protocol used for sharing access to files, printers, and other resources on a network. If the Samba server is vulnerable, the attacker gains access to the system.

The attacker scans the internet for vulnerable SMB ports and uses one of the alleged U.S. National Security Agency (NSA) spying tools called “EternalBlue,” which can detect the vulnerability in Microsoft’s SMB protocol. Once the SMB vulnerability is confirmed, the attacker would use another NSA spying tool called DoublePulsar to install the WannaCry ransomware on the compromised machine.

EternalBlue and DoublePulsar were leaked in April 2017 by a group of hackers going by the name of the Shadow Brokers. Microsoft fixed the security vulnerabilities exposed by Shadow Brokers in March 2017. However, it was reported that between late April and early May 2017, EternalBlue and DoublePulsar had infected more than 148,000 computers. And many of the compromised machines were servers, which, once infected, could infect the client machines connected to the infected servers.

A disastrous attack, to be sure.

Some notable organizations that were infected with the WannaCry malware include Britain’s National Health Service (NHS), Spain’s telecommunications giant, Telefonica, and Germany’s train network, Deutsche Bahn.

Western Digital My Cloud NAS vulnerabilities

Western Digital My Cloud NAS vulnerabilities would allow an attacker to perform several remote code execution attacks, such as compromising the data stored on the system, or enabling an attacker to download malware on the device, such as ransomware, cryptominers, or botnets. We reveal more about the five critical vulnerabilities affecting Western Digital My Cloud NAS devices in our full article.

Windows 10 HtmlHelper vulnerability

Windows Help files carry the .chm extension. Whenever you click a .chm file, a small program called HtmlHelper opens the .chm file and displays it in a window for you to read. As it turns out, researchers from Comparitech discovered that HtmlHelper contains multiple vulnerabilities and even bypasses many of Windows10’s security policies. This means that HtmlHelper can be tricked into opening compromised .chm files, which can lead to a RCE attack.

Zoom RCE vulnerabilities

More recently, Zoom, the popular video conferencing service, was found to be vulnerable to a remote code execution attack. The attack was demonstrated at this year’s Pwn2Own event, a white hat zero-day bug-hunting competition organized by the Zero Day Initiative. The purpose of the event is to make the world of software more secure by proactively finding bugs and disclosing them to vendors to be patched.

This particular attack reportedly exploits three vulnerabilities in order to perpetrate the RCE attack. But the details of the inner workings of the attack were not disclosed. In the demonstration, the attacker calls the victim, waits a little bit, and then is able to execute arbitrary code, as evidenced by the attacker launching the victim’s calculator application. If the attacker could launch the calculator, they likely could have launched any other application, such as a shell, and issue arbitrary commands.

How to protect against RCE attacks

Remote code execution attacks are complex because the mode of entry isn’t fixed. RCE attacks are a category of attacks rather than specific attacks that follow a playbook. And new vulnerabilities and exploits surface every day. So defense against RCE attacks is a bit of a cat and mouse game.

However, there are two measures that every organization should follow in order to give you better odds of avoiding RCE attacks.

Always keep your operating system and your third-party software up-to-date

As mentioned above, vulnerabilities crop up every day – count on it. The best way to minimize your chances of falling victim to a RCE attack is to update all of your software as soon as vendors make the patches available. Keeping your software up-to-date may well save you from a RCE attack. Old and patched vulnerabilities are still used in the wild for years after patches have been issued. That’s because hackers know that the timely patching of software is difficult for commercial organizations and that because of that, many organizations have “lazy” update practices. So attackers will still attempt attacks with outdated vulnerabilities, just in case. If your software hasn’t been patched, you’ll quickly wish you had.

Why is timely patching difficult for commercial organizations? For one, it’s resource-intensive. Patching software sometimes means that certain functions are deprecated, so you need a workaround prior to updating. Updating one piece of software might break interoperability with other pieces of critical software, which will also require workarounds. So many organizations will wait as long as possible before patching their systems to avoid breaking their pipelines.

Another reason for the difficulty is that updating a system typically requires a restart of the system, which leads to downtime and loss of money. Still, it’s not the first measure on our list for nothing, and a RCE attack is likely to cost you more than an hour or two of downtime. Keeping your software up-to-date, while not a guarantee that you’ll be RCE-free, is the most important step you can take in terms of defense.

Use buffer overflow protection

Buffer overflow protection consists of multiple measures written into the server software to detect buffer overflows and prevent them from becoming serious security vulnerabilities. Buffer overflow protection typically adds a canary value (a known but random integer) to stack-allocated. If the canary value is overwritten, it means that a buffer preceding it in memory has been overflowed. By verifying the canary value, you can detect buffer overflows, terminate the affected program, and prevent an attacker from exploiting it.

Sanitize user input

Consider all user input to be untrusted. Unsanitized user input can lead to RCE attacks. Treat input from authenticated users, internal users, and public users the same way: don’t trust it, sanitize it.

Properly configure your user authentication mechanisms

You can have a ton of security cameras and motion detectors in your home. But if your front door is unlocked, bad guys can still get in. User authentication mechanisms are your first line of defense in keeping the bad guys out. Take the time to configure them properly.

Use a firewall

Just like your personal computer should be running a firewall, consider installing a website application firewall (WAF) for your web site/application. It may help you prevent common automated attacks.

Use access control lists (ACL)

Access control lists limit the permissions of your users. The limits on your users’ permissions may well limit what an attacker can do if they manage to compromise one of your users’ accounts. Take the time to properly configure ACLs for your organization and use them.

Use proper threat/intrusion detection software

On top of keeping your software updated, you should also use threat detection software. A good threat detection application could make all the difference in the world. Threat detection software can scan incoming traffic, detect suspicious behavior and intrusion attempts, among other things. It can also immediately block a suspicious host immediately upon detection – which can be a true lifesaver.

A threat detection application won’t necessarily save you from every RCE attack attempt. However, these applications will alert you that something may be up much sooner than if you aren’t using one. The faster you get into damage control mode, the better it will be for your organization.

There are many different threat detection applications out there. Some are proprietary, while others are open-source. There are too many to list, but two well-known open-source options are Snort and Suricata. But regardless of which threat detection application you choose, it will enhance your web site/application’s security – especially if you have a lot of traffic moving in and out.

Have a response plan

Prepare for such an eventuality. In the event that your organization is hit with a RCE attack, being prepared can significantly reduce the scope of the attack, end the attack sooner, and cut down your recovery time.

Conclusion

So that was our crash course on remote code execution attacks (RCE). There’s no fixed set of instructions to defend against these types of attacks beyond what you should be doing anyway. The points of entry could be almost anything. And, as new vulnerabilities and hacker tools come to light, you’ll need to adapt. Protecting against RCE attacks is a continual and evolving process.