In the ongoing aftermath of the devastating SolarWinds breaches, a lot of attention has focused on who did it (Russian hackers) and how they broke in (corrupting software updates from SolarWinds). While this is interesting, it’s not all that useful for security professionals trying to stop the next Remote Code Execution (RCE) attack.
Download our Technical Brief: Taxonomy of The Attack on SolarWinds and Its Supply Chain
This attack exposed a more systemic problem that will continue to plague us until we rethink our security controls. Remote Code Execution (RCE) attacks are here to stay because existing security tools are ineffective against them. The goal of most advanced attackers is to breach a datacenter via a vulnerable application, and then run their code instead of the legitimate application code. Because most of our legacy security focuses on the perimeter, hackers have become adept at mixing their malicious code with benign traffic. A vulnerable application obligingly weaponizes the malicious code in-memory.
In the case of SolarWinds, an RCE exploit (widely believed to be in the MS Exchange server) was used to infiltrate and deposit a backdoor into the well-protected SolarWinds software infrastructure, and then into the systems of thousands of users in the SolarWinds supply chain. (Please see our previous Blog Series for more details on these attack kill-chains).
The extent of the damage from the SolarWinds attacks has not been fully realized, but it is already very severe. More disturbing is that these attacks represent a colossal failure for the security industry as they easily bypassed conventional security controls in thousands of organizations and were not discovered for more than 6 months – an enormous window for motivated hackers to do damage.
RCE techniques are nearly invisible to most security tools because they are not looking in the right place, at the right time. Until that is changed, RCEs will continue to be successful – here is why:
Detecting RCEs Before Attacks = Guesswork
One class of security controls try to stop RCE attacks before malicious content from an attacker is consumed by a vulnerable application. Solutions like IPS, Web Application Firewalls, Host Intrusion Prevention, and Micro Segmentation systems, inspect incoming traffic looking for patterns that match known malicious content. If a specific attack has been seen before, signatures or rules can block them, but if the attack is new, or modified, they are out of luck. One attack type that trips these solutions without fail is Memory Deserialization. The “code” in the bad actor’s payload rarely displays a pattern because it is heavily encrypted and/or (multi)encoded.
Bottomline: without prior knowledge, these perimeter security tools must guess at what’s bad, which leads to false positives and false negatives as was the case with SolarWinds.
Detecting RCEs After Attacks = Too Little, Too Late
Another class of security controls attempts to stop the attack after the application has already processed malicious data sent by a bad actor. Tools like EDR, EPP, and HIPS, monitor running applications for indicators of compromise (IOC) – inherently after-the-fact. These solutions typically look at system call activity on each thread and match the sequence of system calls against the sequence exhibited by known malware. Once again, this detection mechanism relies on prior knowledge and pattern matching against known malware. With about 350,000 new pieces of malware discovered daily, it is reasonable to believe that many new malware have no established IOC patterns.
A more fundamental problem with these “detect and respond” tools is that they are not application aware. This means they are unable to reliably distinguish between normal application operations and malicious operations of malware. This means they must adopt a cautious wait-and-see approach - declaring something suspicious to be an attack too early disrupts business; waiting too long would mean that the attackers have likely succeeded and left. Bad actors leveraging RCE attacks can therefore remain undetected for a long time.
Bottomline: despite lots of hype, these reactive, IOC-based solutions patently failed to detect and stop the SolarWinds attacks.
Stopping RCEs During Runtime
Virsec’s approach is fundamentally different and designed to stop RCEs with ease. Rather than guessing beforehand, or looking for breadcrumbs after, Virsec maps what software applications should do at each step of the way, and instantly spot deviations immediately. Rather than trying to blacklist everything that is possibly bad, Virsec enforces good – ensuring that applications never get derailed, regardless of threats, vulnerabilities, or patch status. This is fundamentally a finite, and solvable problem.
Virsec has taken the concept of Application Control and put it on steroids. Where past tools have required tedious manual creation of allow-lists, Virsec fully automates this, identifying all acceptable files, processes, libraries, input, and memory usage. Virsec has pioneered the field of in-memory protection and can detect and stop real attacks, including RCEs, within milliseconds.
Probabilistic versus Deterministic Security
At the end of the day, speed and accuracy are essential for effective security. Most conventional tools rely on probabilistic behavioral models – trying to learn what is bad and stopping it after-the-fact – or in the SolarWinds case, never.
Virsec removes the gray area guesswork from detection, by deterministically enforcing correct execution. This black-and-white model positively identifies only real attacks, eliminating the floods of false alerts caused by guesswork. Because Virsec operates in application runtime, real attacks can be detected and reliably stopped within milliseconds, eliminating the extensive dwell times that proved so damaging in the SolarWinds attacks.