Forget the users, the threat starts in the software supply chain

While every corporate network large and small tries hard to implement security policies to ensure users are only able to work with legitimate applications and data services -- when the core software supply chain itself is compromised, then the threats themselves gain a new level of legitimacy. Users are often troublesome, but the threats can start in the pipe itself.

supply chain / virtual network of connections

Users are reckless, every software engineer knows that. Perhaps nowhere are users more reckless than in zones of the corporate network where security breaches can be opened through contact with malware, or when system vulnerabilities are unwittingly exposed.

When using their own Bring Your Own Device (BYOD) device and even when using approved and apparently locked-down corporate devices, users seem to have a god-given ability to open unnecessary macros in documents, to click malicious links, to circumvent company policy by installing ‘shadow IT’, or to really go to town and start plugging in external USB drives into every available orifice they can find.

But as headless as the most chicken-like user can be, the source and fuel for threats is not always down to the non-technical employees in an organization; sometimes, the source of the issue is the software itself.

A crack in system-level DNA

One way software supply chain attacks occur is when a perpetrator is able to access the software systems used by a business via malware installed on a vulnerability – technically speaking, defined as an ‘exploitable weakness’ – in the software of a trusted third-party partner or provider. Exploitable weaknesses can occur at any phase of the software lifecycle; and while they most often happen as a result of poor quality development and update practices, they can also be the result of ‘purposeful’ insertion of malicious code.

In a world where we are all trying to move to autonomous infrastructure tools capable of performing updates, maintenance, upgrades, patches etc. without the need for a network engineer to always be physically present, when there is a design flaw in automated build and installation tools, then we’re looking at a crack in the very DNA of the organization’s software system and its wider lifecycle.

Content Marketing Manager at open source security and license compliance management platform company WhiteSource is Julie Peterson. Explaining the mechanics of a software supply chain attack, Peterson says that malicious actors infiltrate a legitimate application then change source code and hide malware in build and update processes with the intention of distributing that malware downstream automatically to a wider audience.

“In this type of attack, the original victim is not the final target, but rather a stepping stone to many other potential networks. The trusted vendor is unaware that they are sending malicious code to their customers,” said Peterson, in a descriptive analysis blog. “These types of attacks work because they occur when users update software built by a vendor that they already have a relationship with and trust. When malicious code is installed on the target organization’s site, it runs with the same permissions as the trusted application.”

The 2020 attack on SolarWinds’ Orion platform was a software supply chain attack. WhiteSource’s Peterson also explained how the outer labeling and packaging of files and dependencies can give rise to supply chain attacks. She likens this technique to a shopper visiting their supermarket and grabbing a box of Fruit Loops, only to find that the goods inside contain organic heavy-bran gut-shifting muesli.

Overdependence on dependencies

A dependency-related software supply chain ‘test’ attack was carried out in February 2021 by ethical hacker Alex Birsan who detailed his tactics in a personally written explanation.

We know that programmers use ‘coupled’ dependency relationships when coding, where one module or routine of software will rely upon another, usually for a fairly central and important part of its operation. Birsan noticed that a PayPal system used a mix of public and private npm (Node Package Manager) packages. He uploaded malicious public code renamed to look like it had the same label as private package code to see if he could outsmart the system.

It turns out that this technique not only worked, it also showed that this type of software would automatically upload packages (whether public or private) simply on the basis of whether they had higher version numbers to make them look more up to date. 

“Some programming languages, like Python, come with an easy, more or less official method of installing dependencies for your projects. These installers are usually tied to public code repositories where anyone can freely upload code packages for others to use. When downloading and using a package from any of these sources, you are essentially trusting its publisher to run code on your machine,” said Birsan, who questioned whether we are putting too much blind trust down inside the pipe of the software supply chain.

Director of Value Chain Security at software quality company Synopsys Emile Monette explains that (with reference to all of the above examples) SolarWinds exposed what is clearly a soft target for would-be attackers. He says that this is because many software providers do not routinely verify the integrity of the libraries their code is dependent on.

“This problem is perhaps more acute and visible in open source libraries, but it may also be a significant issue with any commercial third party or other commercial code repositories,” said Monette. “Software providers should take note and take steps to ensure they are relying on code libraries that have been regularly scanned for known weaknesses and vulnerabilities. Further, when a weakness or vulnerability is found, should take prompt action to remediate.”

The state of state-sponsored attacks

The fact is, organizations need to work with security practices that deliver objective evidence that the company itself and its suppliers are taking appropriate care of information assets. Synopsys’ Monette suggests that, from his point of view, the world can expect more of this kind of vulnerability to surface.

“With trade wars heating up, the potential exists that we’ll see an increase in state-sponsored supply chain attacks aimed at the West and its allies’ defense industries and the commercial technology companies that supply it. These attackers will be very well resourced and will actively target weak links in the supply chain to gain access to business partners and customers in the defense and technology industries seeking to obtain scientific, technical and business information,” said Monette.

It appears clear that we need to deal with vendor code that has been rushed to market, without enough security constraints being considered. There is perhaps a false sense of assurance that, when applying patches from vendors, that they will assure complete security, too. Good security isn’t just patches - it’s a process. This is the mantra offered by Sree Sakamuri is his capacity as senior solutions architect, Oracle, at Spinnaker Support, a provider of third-party support, managed services and consulting.

“There are three major tactics that we can use here. The first is visibility – knowing exactly what is attached to a stack, how it’s set up, where it is, and where it’s from. Once we have that map, the second step is hardening. Whitelisting IPs, restricting access and culling any software or systems that aren’t quite right. The third step is to be prepared to adapt and stay a step ahead,” advises Sakamuri.

Sakamuri further reminds us that every vulnerability falls under a category; whether it’s gaining elevated privileges or information disclosure. They are either CWEs – Common Weakness Enumerations – or CVEs – Common Vulnerabilities and Exposures. “By putting in measures to block CWEs you’re effectively limiting those supply chain attacks as well,” he concluded.

If we accept that software vulnerabilities are not just down to haphazard users laying ‘sausage finger’ clicks over suspect links, macros and doom-laden portals, then we can perhaps think about software engineering at a higher, but also crucially, a deeper level that takes into account the ingredients we’re putting into the mix from a core code level.

Then, perhaps then, we can sit back and enjoy our breakfasts and get on with our day. Wait, hang on - I thought I ordered Froot Loops!?