ABSTRACT
In this article we will review what supply chain attacks are, how they evolved, and how we ended up with SUNBURST, a supply chain attack targeting the famous monitoring platform SolarWinds Orion. We will also discuss how this advanced adversary evaded common detection capabilities, and how you can determine if you have been affected by this attack. It further provides some recommendations on how to deal with these types of attacks in the future, using commonly known principles and available technologies.
Introduction
Supply chain attacks—attacks against the supply or value chain of an organization in order to gain access to a downstream target—often sound like stories of targeted attacks that only occur against government agencies in Hollywood movies. In reality, while these attacks involve a high degree of planning and sophistication, they can have a devastating real-world impact on organizations in the blast radius of the original compromise, like the case of the recent SolarWinds attacks.
In general, we differentiate between two major types of attacks focusing on an organization’s supply or value chain.
“Island hopping” attacks target potentially vulnerable partners or elements in the value chain with potential privileged access to the actual target network. Derived from the island hopping strategy of the United States in the Pacific campaign in WW2, this type of attack may include multiple vulnerable elements in order to gain access to the actual target of the attack. We have seen these types of attacks with prominent targets in the retail industry, which involved suppliers as the initial entry point, and also in plenty of other industries in similar forms.
“Supply chain” attacks are slightly different, as they seek to exploit the trust relationship established from legitimate products used in normal business operations. These types of attacks seek to gain unauthorized access to a target organization by implanting backdoors into products used by the target organization—most commonly via delivery of automated patches or software updates. Such attacks have also been observed targeting technology companies, including antivirus vendors or makers of network security equipment, but are surely not limited to such companies due to the wealth of other potential high-value targets.
Both of these types of attacks might target more than one organization, and the objective might be to gain access or to collect information on whole industries or widespread organizations or individuals. At the same time, organizations that are simply used as one of these islands can also incur massive reputational and business damages, while not even being the actual target of such a campaign.
The evolution of supply chain attacks
As news broke in 2013 and 2014 about attacks against Target and Home Depot, organizations worldwide started evaluating their value chain and its data interconnectivity. These attacks were the description of island hopping attacks, performed through suppliers by cybercriminals to harvest payment card information at a large scale.
Data interconnectivity between companies allows organizations to implement highly efficient processes: from design, to prototyping, to manufacturing, to logistics, to just-in-time delivery to the end customer. While these tightly interwoven connections help companies save billions of dollars through increased efficiency and bring innovation to market at unprecedented speeds, the attacks of the early 2010s reminded organizations of the attack surface such connectivity provides to adversaries.
As a result, security professionals started viewing business partners that require their process automation to be connected to their networks with the same distrust as any other anonymous connection. This shift led to increased security awareness and additional controls to monitor interconnectivity; increasingly, security certifications such as ISO 27001 (which in its annex 15 specifically calls out the security evaluation of vendors in the value chain) were required of such partners before a connection between networks was established.
Most of these island hopping attacks rely on the presence of authorized access, or an exploitable vulnerability in the form of a software weakness or misconfiguration in systems. As organizations become more diligent and disciplined about patching existing systems, applying best practice configurations, and segmenting their networks, it becomes less easy for adversaries to find exploitable weaknesses than it used to be.
In 2015, allegations surfaced of a secret backdoor in the Secure Shell (SSH) authentication mechanism of Juniper’s JunOS. This attack, implanted by an unknown threat actor into the equipment of a prominent U.S.-based network security equipment manufacturer, may have been in place for years. During that same year, a suspected backdoor embedded in a popular antivirus product was involved in a high-profile leak of highly classified information of the National Security Agency. While largely unnoticed to the broad public, the news about these types of backdoors put many security professionals on high alert, as such attacks exploit the trust we put in the integrity and inherent security of such technologies.
The supply chain attack involving SolarWinds Orion in late 2020 only marks the latest example of this type of attack.
A Solar Storm
Much has been written about the supply chain attack involving the backdoor dubbed "SUNBURST" within the SolarWinds Orion platform. Rather than dissecting the technical details yet again, it is important to take a look at what companies should do to identify whether they were affected and what the next steps should be.
Who is affected?
The easiest ways to identify whether you were affected as an organization is to identify if one of the compromised SolarWinds Orion products and versions is being used in your environment (read our blog). To maintain operational security, in their efforts to remain undetected, the adversary in this specific attack appears to have only used the backdoor in SolarWinds Orion in cases where the target environment appeared of specific interest. Whether access was attempted and obtained can only be determined by analyzing network activity to some extent.
This is because the campaign was suspected to have started on or before March 2020 and did not involve any known indicators of compromise. Due to the sheer volume of data involved, many organizations do not keep access logs long enough to determine whether or not a successful compromise occurred.
Did protections fail?
Detecting the SUNBURST backdoor implanted in SolarWinds Orion is difficult to accomplish with existing automated capabilities, even ones designed for identifying previously unknown threats such as malware sandboxes.
This difficulty is due to a list of factors that showcase the extreme care the adversaries took to hide their tracks. The backdoor was delivered through a legitimate software update to a known monitoring and management tool. It also required the software update containing the backdoor to be successfully installed, which required specific software components to already be present on the target system.
Most sandboxes use operating system versions commonly found on endpoint systems, and only include a list of common applications to mimic an end-user system. Even after the installation of the backdoor, the adversary took precautionary steps to avert detection in a sandbox environment—for example, by waiting days before for any callback to the command-and-control infrastructure, as well as verifying if the software was running in a lab vs. production environment.
The best opportunity to detect this backdoor and its activity would have been to closely monitor abnormal network activity from the SolarWinds Orion platform as it started to phone home. However, in this case, the actor took care to avoid tipping off the usual signals we are well prepared to detect. For example, the command-and-control infrastructure was set up in the countries of the victims, rather than geos we are trained to view with suspicion. Furthermore, to ensure that connections to a newly registered domain did not tip off security operators, the command-and-control domain used was registered well ahead of time, months prior to the suspected start of the campaign. Finally, the adversary included naming conventions of the targeted organizations into the DNS names of the command-and-control infrastructure to mislead security operators into dismissing any potential suspicion as a false-positive finding.
After the initial compromise, the adversary used well-known tools and techniques to harvest admin credentials, establish persistence, and gain remote access to the compromised system. Such activity could have been detected by most endpoint detection and response (EDR) products by monitoring system activity on affected systems. However, in many cases, EDR products are not deployed to server systems, and more attention is paid to endpoints.
In short, detection of this specific backdoor implanted in legitimate software was incredibly difficult to accomplish, although far from impossible.
Protecting against supply chain attacks
The big question is: how can we address the supply chain as a potential threat vector moving forward? While protecting from backdoors or vulnerabilities introduced into trusted software or components by malicious third parties is a difficult undertaking, some of the same principles that helped to defend against island hopping attacks can be applied here as well.
Minimal access required
In the case of attacks against the technologies we use to run our businesses, the basic concepts of a zero trust architecture can provide an effective defensive layer to significantly limit the impact of “trojanized” technologies.
If adversaries successfully implant a backdoor into software or hardware that is connected to our networks, or even part of the network fabric, they still require access beyond the component, and will only have as much access to the environment as the component itself. Therefore, restricting inbound and outbound component access to the minimum of what is absolutely required to function limits adversaries’ abilities to exploit their position, potentially dramatically.
For this purpose, it is important to analyze any solution not only for the access and privileges it requires to function, but also to who requires access to specific functions within it. For example, any server application that is trying to establish a connection to an internet-facing resource should only be allowed to do so for very specific documented and expected use cases, such as connecting to update servers or network time servers, etc. At the same time, every solution needs to be analyzed and assessed for exactly the access the solution itself requires to function. For example, if a monitoring solution is put in place, it might not require privileges to write or make changes to any system. It might even only need read access to a very specific service or set of data, rather than to the system as a whole.
Strong authentication and monitoring
Finally, a careful assessment of who requires what level of access to an application or system, and how such access can and should be secured, needs to be performed. Such an assessment will provide the access controls that ultimately limit an adversary’s ability to reach and use potentially “trojanized” technology and to move laterally. For example, systems that rely on privileged access to other systems and components in a given environment by definition present high-value targets. Access to these network components or systems should require multifactor authentication for any administrative access, which in itself should be granted on an as-needed basis.
The usefulness of the measures described here are in no way limited to what we have observed over the past month surrounding the SolarWinds breach. In particular, limiting access to and from the SolarWinds Orion Platform, and requiring strong authentication to access, could have made it significantly more difficult for the adversary to exploit and gain access to the environment, while making it easier to detect activity that was not expected. After all, the discovery of this attack started with the detection of a suspicious logon event using stolen credentials.
Trusted but verified vendors
Depending on the type of service or industry, different available certifications of cybersecurity practices can help organizations assess how well solution providers are equipped to detect, prevent, and deter unauthorized access or modifications to their data, products, and services. The most prominent of these certifications is likely ISO/IEC 27001, as it asserts that a company not only follows and adheres to security practices that ensure confidentiality, integrity, and availability, but also makes these aspects a responsibility of top management.
Therefore, the first strategy to prevent supply chain attacks is to carefully assess and monitor how your organization’s vendors implement and follow security practices. For example, ISO/IEC 27001 annex 5 specifically calls out such a review of an organization's supply chain.
A variety of cybersecurity audits are available to provide certifications for companies attesting to secure system architectures, implementation of security and response processes, and adherence to general security best practices. For example, security certifications for cloud service providers are available and should be mandatory before using such services, with the most prominent example being the SOC 2 certification family. This certification expands the concepts of ISO/IEC 27001 by requiring organizations to implement specific technical and procedural safeguards to guarantee not only availability and integrity of the service provided, but also the security of customer and user-specific data. Another prominent industry-specific example of certifications for cloud service providers is FedRAMP, with its different impact levels, required by the U.S. government.
These are just some examples in a long list of certifications that exist, with many specific to industries and geographic areas.
Conclusion
SOLARSTORM surely presents a somewhat rare event, simply because of the amount of planning, the careful execution, and the attention paid to cleaning up. However, the impact it had upon affected organizations is not something that should be ignored as a once-in-a-lifetime event.
Security teams do have the means and capabilities at their disposal to not only detect such attacks earlier than in this case, but also to minimize their impact by limiting the adversary’s ability to establish a foothold and move laterally across the environment.
Aside from monitoring the activity of and on systems and applications that do have privileged access or contain sensitive information, specific access controls can help compartmentalize high-value systems.
Access controls and restrictions for such high-value targets can be implemented by applying the concepts of a strict zero trust architecture:
- Restrict access for outbound traffic from the system or application to the minimum list of applications and resources required to perform its function, as documented by the vendor.
- Restrict local access of the applications to the minimum required set of privileges, as documented by the vendor.
- Restrict access to the application or system to only those users that need such access, require multifactor authentication, and limit the permission such users have on the system to the minimum required to perform their intended tasks.
In a cloud world, in which the internet continues to replace the local network, applying traditional network security paradigms is a losing proposition. As we continue to use the cloud to enable a mobile workforce and a distributed enterprise, security professionals need to rethink their approach to securing the organizations they work in. Such a world needs to be secured in a cloud-native way, with cloud-enabled security capabilities and a strict zero trust architecture.
