Why Software Supply Chain Attacks Are Inevitable and What You Must Do to Protect Your Applications

Most organizations have limited visibility over their software supply chain and little control of up to 95% of the software code they utilize.

With multiple code sources from multiple software vendors, the number of known and unknown vulnerabilities quickly grows beyond the capabilities of internal IT teams to find and fix. This is compounded further by the speed that organizations are deploying applications and features.

The recent Channel 9 situation (we’ll discuss this event later in greater detail) is a timely reminder for every organization to revisit ways to protect their software supply chain and, in this blog, we take a closer look at this and other recent attacks along with the tools and options needed to protect your organization.

What is the software supply chain and what are the risks?

Like any traditional supply chain, the software supply chain begins with planning and ends with delivery to the customer. Naturally there are all the processes in between, and like any other supply chain there’s a lot happening between A and B. Anything and everything that touches the code along the way has to be managed together – the original source code, binary files, code libraries, configuration files and other components. Then there are the origins of each component: who wrote the code and when it was contributed, whether it’s been reviewed for security and how, any known vulnerabilities and supported versions, etc. It’s little surprise that from all of these moving parts, significant risks emerge.

One of the biggest problems stems from the fact that an increasing amount of enterprise software is open source. In fact, industry data suggests that up to 85-97% of the code in vendor applications or tools isn’t originally written by the vendor, but rather comes from open-source code. That’s a scarily high percentage. If you’re not responsible for creating the code, it’s nearly impossible to vet the libraries, code, and everything related to the application build processes. While the final product is yours, the majority of code within the application may not be yours, and so not within your control.

Supply chain attacks are uniquely troublesome and it’s important to understand the implications this has for the security of the chain. Attackers don’t target one single network, instead, they set up shop in the one place and use it as a base to invade everything that they encounter – your suppliers, customers, vendors etc.

Recent attacks in the supply chain

Attacks are not rare and they are cropping up more and more. This can be attributed to the rise of DevOPS and agile development environments, more aggressive development cycles to support the release of new features and capabilities, and a growing reliance on third-party code inclusions in vendor applications.

As a result, attacks are increasing in frequency. Here’s a reminder of a few notable occurrences:

• Sunburst 2020 – The most recent involved hackers targeting the SolarWinds application by introducing obfuscated backdoor code in the update/patch build process.
• Kwampirs 2020– Remote Access compromise. Code was added into the medical device software build process by a disgruntled employee.
• Node.js 2020 – Open source event stream library compromised after open source maintainer changed hands.
• Apache Struts 2017 – 3rd party java library. Around for over 10 years and deployed everywhere. Bugs in the library allowed a specific injection style payload attack to allow RCE.
• NotPetya 2017 – 0-day exploit in Windows. OS Bug. The NSA knew about it for years.
• XcodeGhost 2015 – Apple Dev Conference. IDE download compromised at mirror download sites. Code injected in the compiler that inserted a backdoor in all apps compiled with the Xcode IDE. Developers will never see this.

Australian broadcaster disrupted by cyber attack

More recently, Channel Nine in Sydney claimed to be the victim of the largest attack on a media company in Australia’s history. “The technology that brings you 9 News every night is under attack by hackers”, began the ominous Channel 9 tweet, “Whether it’s criminal sabotage or the work of a foreign nation is still being investigated, but this attack could reveal a nationwide vulnerability.”.

Behind the scenes, the station was facing major IT disruptions that prevented the airing of several programs, including Weekend Today. It’s still too early to tell who was responsible for the attack or what their motivations were – investigations continue and no demands for ransom have been received. it is known that it started with internal malware (or ransomware) that quickly spread across equipment and servers, but how that malware was inserted is still under investigation. Whether it was user error via a malicious email, or the result of a compromised software supply chain component, the end result was the same.

Keeping up to date with patching is often viewed as the first step in protection, however as we all know, this doesn’t deal with zero-day attacks – the vulnerability is exploited before the vendor knows there is a problem.

The lesson here is that even if an organization has all the traditional perimeter security controls and processes, they are still unprotected against the more cunning nature of zero-day exploits. Yet, organizations must take steps to shield themselves from the dangers of open source software and supply chain attacks.

How do you protect yourself from compromised supply chain software?

The answer is not another device or patching process. The answer lies in the ability to monitor the actions and behavior of ALL your software.

Imperva Runtime Application Self Protection (RASP) is a lightweight security plugin that analyses activity within the application and blocks unwanted actions. It’s protection spans out further across runtime, servers, open-source dependencies, and third-party libraries too.

RASP allows organizations to release applications and code quickly, with the reassurance that they’re protected – they won’t have to go back and revisit issues which are usually discovered using static and dynamic code analysis tools.

RASP also provides enterprise-grade protection against zero day attacks. It does this by implementing a positive security model around the application. RASP maintains a known footprint of how the application is supposed to behave and will only allow the application to do what the application is built to do. Even if there is a backdoor in the code, it can’t be used as the exploit can’t move out of the normal footprint behavior of the application. For example, if you deploy an application with embedded malware, the malware will be prevented from sweeping the file system, making network calls or encrypting files, because RASP knows that is not the normal behavior of the application.

A release in January 2021 saw RASP expand into AWS Lambda, helping organizations gain RASP’s protection for their AWS apps as well. Again, RASP sits within a Lambda execution environment and uses the positive security model to only allow Lambda to perform only the functions it was designed to do.

While incredibly powerful, RASP isn’t the be-all and end-all for application security. It forms another layer in your security stack, acting as the last line of defense for when other solutions haven’t worked. Even when RASP has detected and alerted you to malicious behavior, it can’t remove the offending code. That software will still need to be patched at some point – RASP just buys you time to do that.

If you have questions or would like more information on RASP, contact your local Imperva security team.