SolarWinds Attack Gives Rise to New Runtime Security Models

Overview

A group that calls itself “Cozy Bear” gained access to government and private companies, including top security product firms, using a compromised update to SolarWinds' Orion software. This attack was so large it was deemed a “Grave Risk to Cyber Security.” 

Analyzing the attack, there are three important highlights worth diving into a little deeper:

1. The sever impact that software supply chain attacks may bring to your doorstep.
2. The effort and sophistication attackers put into maintaining a low footprint and avoiding detection by behavioral monitoring tools.
3. The fact that even though the attackers had their code signed and in the system, they still inserted additional tools into the environment, using file-less malware.

Software Supply Chain as a Critical Link

One of the critical elements of this attack, and what made it so hard to identify, is the fact that a big part of the malicious code, which contained a backdoor, was digitally signed. It allowed the attacker to communicate with third-party servers which they controlled.

While breaching the SolarWinds software pipeline was a targeted, highly planned effort, “approved” malicious code can easily get into any system. In fact, an absolute majority of software deployed by almost anybody somewhere in the supply chain – open source, reference implementation of sophisticated/regulated algorithms, third-party software products, “copy and paste” code examples from Stack Overflow – all have the potential to open a backdoor into any organization. Over half of the DockerHub images – the biggest supply chain in the world – have critical vulnerabilities in them. It is no longer a question of “if”, but “when” some of them will appear in your environment and will be exploited.

With the reality being that “approved” malicious code is bound to happen, the next important question is how do you detect and prevent the usage of that code and the penetration of your organization's security? This is where runtime prevention and detection tools come into play, but attackers have learned how to fool many of those systems.

Attackers Going Under the Traditional Security Radars

Most if not all of the existing runtime malware prevention tools are based on either a blacklist approach – in which they look for specific signatures of known malicious binaries, or behavioral analysis – looking for abnormal behavior in the environment - detecting it, and alerting on it. None of these were equipped to handle an attack of this type.

As it was published, the attackers used a malware type that had never been seen before and used extreme caution not to get noticed by monitoring tools. They kept a low profile and made sure to “stay under the radar.” They laid dormant for over two weeks, used credentials to perform lateral movements through legitimate remote access points, and used a lightweight malware dropper which was loaded directly to memory, leaving no traces on the disk.

With such an effort to lay low, and such technological sophistication to add malicious code under the radar, it is becoming clear that a new line of defense is a must. A line of defense that is not dependent on establishing normal behavior baselines or continuously scanning and updating based on blacklists. For example, all tools have now added the signature of this malicious code to their blacklist, but isn’t it too late?

Vulnerabilities vs. Exploits

A critical observation to make about this attack is that even though the attackers already had a digitally signed backdoor, they still needed to bring additional malicious code into the environment.

The backdoor was a pretty big chunk of code and contained several C2 (command and control) functions compiled as part of the legitimate product. And yet, even this unusually big backdoor had no means to spread and perform sophisticated injection and theft scenarios. It required a post-deployment file-less malware (FireEye called it TEARDROP).

It is thought that TEARDROP deployed a version of the Cobalt Strike BEACON payload, a penetration testing tool made for red teams that can also be used by attackers.

This fact is critical since it is true to almost any attack and most of other backdoor cases. They look like tiny innocent coding oversights – basically, like any other vulnerabilities created as an honest mistake. From this point on, intentional backdoors and incidental vulnerabilities are used in very similar ways. Both are utilized to bring real malicious code – the exploit – into the target environment and perform the actual attack.

All exploits, just like the SolarWinds one, masquerade their traffic and file system usage behind legitimate protocols and short lifecycle temporary files, so they cannot be identified by existing anomaly detection tools.

Understanding the nature of such attacks, and that attackers must add their tools to the environment, may bring about new prevention and detection methods focusing on identifying exactly that – a foreign, unauthorized code artifact running in memory. Such detection is a line of defense that will deterministically identify the attacks.

Run-Time In-Memory Protection Capabilities and Ongoing Integrity Validation

A former NSA hacker and founder of the security consulting firm TrustedSec, David Kennedy states in his interview that developers must start thinking about protection of their code integrity at all times – including the integrity of the code in use. If malicious code is injected, which is a common denominator in an absolute majority of attacks, it should break the code integrity and generate an alert with all the necessary detection, remediation, and subsequent forensic analysis.

There are different memory protection solutions that are intended to stop these level of attacks. Ranging from Moving Target Defense based capabilities to ongoing memory scanning and analysis. These technologies can act as a deterministic last line of defense capturing the exact intrusion moment, regardless of the tools and backdoors used to deliver it.

The idea behind runtime software integrity validation is designed to identify any unsigned or compromised code right in the executable process memory, whether it has a corresponding file footprint or not. These technologies would authenticate the software configuration parameters and execution conditions such as privileges, system capabilities, and security properties (ASLR, DEP, etc.).

Conclusions

In order to combat the futuristic attack landscape, security professionals should make sure to cover the major attack vectors and realize that runtime security tools are not all born the same. A combination of behavioral analysis tools, blacklisting, and in-memory active protection should be used to prevent attacks by the next generation of cyber hackers.