From an attacker’s perspective, a remote code execution (RCE) vulnerability in a “workload” – typically a compute instance that runs one or more software – is the gift that keeps on giving. Once the vulnerability is exploited, the attacker can launch any malicious objective of their choosing. For example, RCE vulnerabilities were the root cause of the Hafnium and Kaseya cyber-attacks that crippled over 30,000 organizations in the US in a matter of minutes. Unfortunately, RCE vulnerabilities aren’t fading away anytime soon. Just recently, the US federal government’s Cybersecurity & Infrastructure Security Agency (CISA) warned about a critical RCE vulnerability in the popular open discussion platform, Discourse, and Microsoft announced three critical RCE vulnerabilities in its Patch Tuesday release.
Understand How Attackers Use RCE to Access Server Workloads
Most adversaries are well funded, skilled, motivated and, with an early awareness of an RCE vulnerability and a vulnerable application, can be highly effective. Once a craftily constructed payload is delivered, the application relinquishes execution control to the attacker. The first malicious action the attacker executes is a reverse shell that helps them achieve full keyboard control of the victim workload. The compromised workload now is totally at the mercy of the attacker, who can perform any malicious action of their choosing. These actions include executing ransomware, exfiltrating critical data, scraping user credentials, pivoting to adjacent workloads, performing crypto mining activities and more. There is no end to an attacker’s creativity.
Don’t Rely on Conventional Security Tools
Conventional security tools do not have enough context to protect workloads from fast-moving attacks that execute in a second or two. As a result, they are completely ineffective against RCE vulnerabilities. To successfully protect against an attack that leverages an RCE vulnerability, an effective security control must launch protection as soon as the vulnerability is exploited and much before the attacker can gain keyboard control. Failure to do so allows the creative attacker to disguise their attacks and fly under the radar. Even though conventional security tools claim to work in the application’s runtime, they can only detect attacks that exhibit patterns that attackers have abused in the past. A true runtime security control activates protection when non-developer provided (or attacker-influenced code) starts executing. Even a skilled attacker will find it extremely hard to bypass a security control that embodies true runtime protection.
Stop Execution of Attacker Influenced Code
True runtime protection requires fully mapping the software by quickly establishing how developer-provided code will execute one step at a time. When attacker-controlled code starts to execute, the enterprise must stop it instantly. Failure to do so will result in dire consequences that are controlled by the attacker. The ability to pinpoint exactly when attacker-influenced code has started running transcends known and unknown vulnerabilities, historical malicious behaviors and indicators of compromise.
Adopt True Protection
Security controls that implement true protection enforce how the application should be executing at each step and stopping what it shouldn’t be doing, and do so in real-time – before an attack happens. With true protection, attackers’ dwell time is non-existent, so threat actors never have a chance to install malware or exfiltrate data.
Conclusion
Conventional security tools cannot protect against RCE vulnerabilities. To better protect their server workloads against these attacks, organizations must understand how their software runs and have the capability to stop any digression in milliseconds regardless of threats, vulnerabilities or patch status.
