BlogEven though it's still too early to know the full impact of the SolarWinds SUNBURST supply chain attack due to its sheer scope, scale, and ongoing nature, it already serves as a cautionary guidepost for cybersecurity professionals to rally their organizations around going forward.
Much of the general public, along with corporate executives and board members, are now fully aware of the importance of defending against supply chain attacks, similar to how the 2014 Heartbleed bug sounded the alarm on SSL/TLS cryptographic protocol insecurities, spurring development of TLS 1.3.
In a previous blog post, I defined some common elements shared by successful supply chain attacks. This time I'll focus on how future attacks might be perpetrated and share some steps organizations can take now to defend against supply chain attacks.
How Might the Next Big Supply Chain Attack Happen?
As most security professionals know, supply chain attacks seek to gain access to protected information or damage an organization by targeting less-secure elements in the supply chain, such as third-party vendors or software. And although these attacks are nothing new for SecOps and SOC teams, the newly heightened awareness across the organization gives them the imperative to prepare for new and different types of attacks in the future. But how might that next attack be carried out and what kind of supply chain risk should we be on the lookout for?
The SolarWinds SUNBURST attack was extremely well planned and carefully executed by skilled and patient attackers with ample resources. It was a lengthy and multistep process to:
- Access the SolarWinds development servers.
- Write the source code that would obscure itself in the legitimate Orion software updates.
- Establish a covert communications channel.
- Move stealthily within the target environments to find the most valuable data.
- Exfiltrate it without detection.
However, there are many easier methods readily available for attackers to infect software supply chains, along with exploitable zero-day vulnerabilities that are continuously introduced into open source ecosystems, providing a potential attack vector. With this in mind, let's go through a few alternate methods that bad actors might employ now and in the future to effect the next big supply chain attack.
Open Source Software (OSS) Vulnerabilities
Today, many programs are built using readily available open source libraries and packages to save developers time and effort. Why reinvent the wheel, right? Most programming languages use package managers to source and update code. For example, the popular Node.js runtime engine, which runs programs written in JavaScript, utilizes node package manager (npm) to provide hundreds of thousands of free and reusable code packages.
The npm platform uses an online database to search for packages suitable for given tasks while the package manager resolves and automatically installs dependencies. Similarly, the Python programming language uses the Python Package Index (PyPI) repository to store and distribute updates to dependent programs. A report on supply chain attacks from the University of Bonn, SAP Labs, and Fraunhofer FKIE notes that "package repositories represent a reliable and scalable malware distribution channel" for attackers and that "the poor handling of arbitrary code during install yields the most used infection vector."
Additionally, OSS packages are typically built and tested by multiple globally dispersed owners and maintainers who are bound to make coding errors that can result in supply chain vulnerabilities and may not observe or implement best practices for secure programming protocols. And many of the packages themselves rely on multiple additional packages. As the University of Darmstadt warned in a recent report, "When installing an average npm package, a user implicitly trusts around 80 other packages due to transitive dependencies," and "Up to 40% of all packages rely on code known to be vulnerable."
Figure 1: Installation of popular boto3 Python SDK for AWS showing download and installation of multiple dependencies
All open source community projects are based on the underlying assumption that the vast majority of contributors will have good intentions. Most alarmingly, the report notes that "A very small number of maintainer accounts could be used to inject malicious code into the majority of all packages, a problem that has been increasing over time."
Dependency Confusion
A term freshly coined by security researcher Alex Birsan, dependency confusion can happen during library calls—a feature in many modern programming languages that allows programmers to insert dependencies on external code libraries or internal package feeds into their code. When library dependency calls aren't well defined, or the default action is too permissive or not well understood by the programmer, an organization could be vulnerable to software supply chain attacks.
For example, if a programming language specifies using the latest library version, whether it's from internal or external sources, an attacker might simply upload an infected library version of the same name but with a newer date stamp to an external repository such as GitHub. Now when the library call is made, the program will download the latest attacker-modified software to the unsuspecting server or application. This could be used to insert a remote-access Trojan, or RAT, that phones home after a period of time, similar to how the SUNBURST attack enabled command-and-control (C2) communications.
Typosquatting
Although more popularly associated with URLs that are created to mimic common typos that send web surfers to fake sites, typosquatting can also be used to mimic popular OSS package names. When a careless programmer mistypes a particular component's package name, they might be downloading malicious software.
All the attacker has to do is to guess the most popular misspellings and populate the OSS repositories with impostor packages. For example, last year a threat researcher discovered more than 400 suspect Ruby gems in a repository, one of which had been downloaded 2,100 times by developers. The package in question was named atlas-client, very close to the legitimate gem named atlas_client. Alarmingly, downloads of the illegitimate package comprised almost 30% of the total downloads of the legitimate gem.
What About Supply Chain Attacks in the Cloud?
So far, we have discussed some alternate vectors that attackers might use to infect a targeted organization's software supply chain and evade or breach perimeter defenses. Once inside the perimeter, attackers will need to visualize the internal network and environment, discover target assets, and then move laterally towards those assets to achieve their goals.
Cloud environments can differ from traditional or on-premises data center environments in the types of assets available, methods of workload deployment and updates, and native monitoring and security solutions available. Many types of attacker lateral movement and control, such as server side request forgery (SSRF) and encrypted C2 communications are equally effective for attackers in the cloud or on-premises.
However, these techniques are easily exposed using network detection and response (NDR). Security vendors must write cloud-friendly detectors to account for cloud-native services and other variances in cloud environments.
Cloud-Ready Security Controls
Here at ExtraHop, we defend organizations against attacks on cloud assets and workloads, including lateral movement techniques that can be used in supply chain attacks. For example, if an attacker were to breach the cloud perimeter and gain access to the backend of a web server, they might use that foothold to attempt lateral movement via credential harvesting with an SSRF attack on the AWS Instance Metadata Service (IMDS) proxy, attempting to access sensitive data. Here's how ExtraHop Reveal(x) 360 discovers and responds to a potential SSRF attack.
Reveal(x) can also discover supply chain attacks attempting to exploit vulnerabilities in containerized cloud environments. In such a scenario, an attacker might upload a compromised container image to a Docker image repository. Now when the cloud-based container management service reaches out for the next automatic update, it replaces the real container with the infected image. Even though the infected image looks legitimate, and is installed without incident, Reveal(x) will immediately detect this suspicious activity and trigger an alert.
Remember the boto3 Python SDK dependencies from Figure 1 above? See Figure 2 below to see what a security professional using Reveal(x) will see. Reveal(x) immediately discovers the unusual activity and generates an alert to expose potential supply chain attacks on cloud workloads. If warranted, security teams can launch a full investigation from the Reveal(x) console using built-in workflows and network metadata or full packets.
Figure 2: Reveal(x) 360 showing activity with multiple cloud servers during download and installation of boto3 dependencies
Using Reveal(x) 360 to Defend Against Supply Chain Attacks
ExtraHop Reveal(x) 360 extracts and analyzes metrics from network packets, the ground source of truth in both cloud and on-premises environments, to reveal a wealth of information including all connected devices and device types along with critical threat information and alerts on attacker lateral movements, new connections, abnormal user behavior, data breach attempts, and supply chain attacks.
Real-time access to information on advanced threats via a tool with intuitive usability and workflows helps SecOps and SOC teams to quickly discover attacks and remediate vulnerabilities. Access to 90 days of in-depth network information helps forensic investigators trace attacker movements and determine the blast radius, if any.
Reveal(x) 360 provides unified NDR capabilities across on-premises, hybrid, and multi-cloud environments. Delivered from the cloud as a true SaaS-based solution, Reveal(x) 360 offers frictionless security with simple deployment, single-console management, and no agents to slow down DevOps workflows. Security practitioners can select and deploy both on-demand and prepaid sensors with just a few clicks in the Reveal(x) 360 console to scale the benefits of NDR monitoring and security across the entire enterprise.
You can also try Reveal(x) 360 for free. See how SaaS-based Reveal(x) 360 detects threats up to 95% faster and slashes your time to respond by up to 70% with a 15-day proof of value in your AWS environment. Request your free trial today.
