11.2: Using Other Software as Building Blocks

Last updated
Save as PDF

Page ID: 91538

$ \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } $ $ \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} $$\newcommand{\id}{\mathrm{id}}$ $ \newcommand{\Span}{\mathrm{span}}$ $ \newcommand{\kernel}{\mathrm{null}\,}$ $ \newcommand{\range}{\mathrm{range}\,}$ $ \newcommand{\RealPart}{\mathrm{Re}}$ $ \newcommand{\ImaginaryPart}{\mathrm{Im}}$ $ \newcommand{\Argument}{\mathrm{Arg}}$ $ \newcommand{\norm}[1]{\| #1 \|}$ $ \newcommand{\inner}[2]{\langle #1, #2 \rangle}$ $ \newcommand{\Span}{\mathrm{span}}$ $\newcommand{\id}{\mathrm{id}}$ $ \newcommand{\Span}{\mathrm{span}}$ $ \newcommand{\kernel}{\mathrm{null}\,}$ $ \newcommand{\range}{\mathrm{range}\,}$ $ \newcommand{\RealPart}{\mathrm{Re}}$ $ \newcommand{\ImaginaryPart}{\mathrm{Im}}$ $ \newcommand{\Argument}{\mathrm{Arg}}$ $ \newcommand{\norm}[1]{\| #1 \|}$ $ \newcommand{\inner}[2]{\langle #1, #2 \rangle}$ $ \newcommand{\Span}{\mathrm{span}}$$\newcommand{\AA}{\unicode[.8,0]{x212B}}$

Software today is often quite complex. So complex that it is nearly impossible for one organization to write all the code. Frequently developers will use smaller pieces of code as building blocks. For example, imagine a developer making an application similar to Spotify. There could be a fair amount of custom code such as user account management, storing and retrieving playlists or songs, etc... The code to take an audio file and convert it to sound is fairly low level and would have to support edge cases such as older file formats (.WAV files), support digital rights management and decompress the audio. In this case, the developer may choose to use a "library" or "package" which manages these tasks. Such a library would handle the mundane tasks such as converting the file to audio, obtaining track metadata such as title and artist from the file and similar functions.

Using these libraries has some benefits including:

Libraries are often used by multiple software and are generally tested more robustly than standalone code
Libraries preclude developers from having to deal with edge cases or areas of concern which reside outside the comfort of the developer
Popular libraries tend to have a good community following, so help is often easy to come by

Be aware that libraries can have some downsides as well.

Supply Chain Attacks

A "supply chain attack" occurs when someone knowingly supplies something with malintent in an effort to disrupt, observe or destroy a consumer upstream.

The Restaurant

Consider the case where a head chef, Addison, is expecting a food critic (Blair) at Addison's new restaurant. Sous Chef (Charlie) is jealous of Addison and knows that a bad review might end Addison's career. Charlie devises a plan: when Addison asks for sugar to make candied sauce for the vegetables, Charlie will hand Addison the salt instead.

This is a "supply chain attack" because Charlie knowingly supplies the wrong ingredient to Addison. Addison may not even realize this because the salt looks and feels like sugar. When the critic tastes the candied vegetables and realizes that they taste terrible instead of sweet, Addison will get a bad review.

In software, particularly web applications, this attack can be devastating. Most web applications these days rely on tens, hundreds or thousands of small libraries. The "NPM" packages (NPM stands for Node Package Manager) libraries - often implemented in JavaScript - are suitable both for front-end applications as well as back-end logic.

The Case of "left-pad"

In 2016, a developer removed a very small piece of code from NPM². The code was called "left-pad" and was less than 12 lines long. The package merely added spaces to the left part of a string in order to make the string a specific length. For example, this code:

leftpad("hello", 10)

Would return the string " hello" (note that the string is now 10 characters long). While this code is not complicated, it is quite useful (often used for aligning text). As such, it was used by thousands of packages. And those packages, in turn, were used by thousands more packages. All of a sudden, hundreds of thousands developers noticed that their code would not compile because left-pad was no longer found.

The developer who removed the code likely did not anticipate the scope of the problem; in response, NPM published the package again and also removed the ability for developers to delete a package under normal circumstances.

While the removal of left-pad was not intended to cause problems around the globe, it was a high profile example of just how fragile library supply chains can be.

Protestware

The Russian incursion of Ukraine in March 2022 has led to the emergence of protestware - that is, intentional poisoning of a supply chain. The first known occurrence happened in mid-March. An NPM package called node-ipc was updated to remove files from the user’s machine and replace them with an emoji of a heart (assuming the computer was geolocated in Russia or Belarus)³.

Crypto-Miners

Crime can pay! In 2021, a security research firm identified several NPM packages which secretly installed crypto mining⁴ software on developers machines.

This example is more common; that is, packages which intend to be malicious. Sometimes malware may be included in packages in order to steal credentials, compromise developers computers or initiate a ransomware campaign.

Video Players

In January 2022 Palo Alto Networks Unit 42 discovered a dangerous (and admirable!) supply-chain attack on cloud-based, customizable JavaScript video players mostly used on real estate sites. The attackers were able to access the upstream JavaScript file and include malicious skimming code. “On the next player update, the video player began

serving the malicious script to all sites that already had the player embedded⁵”. The attackers were able to abscond with names, addresses, phone numbers, and credit card information.

Okta Attack

You may never have heard of Okta before, but they are an authentication firm with 15,000 clients (including FedEx and CloudFlare) so there is a good chance you use some of their services in some capacity. In January 2022, an account take over (ATO) at one of Okta’s service providers led to downstream effects including affects for 366 of Okta’s clients⁶. This is an especially interesting case of a supply chain attack in that Okta itself is a supply chain target but their reliance on Sitel as a third-party provider resulted in the attack. It was a supply chain attack on a supply chain provider.

Whereas a supply chain attack might be characterized as “getting the keys to the kingdom”, attacking Okta and other similar providers is more like “getting keys to the factory where the keys to multiple kingdoms are made”.

Combating Supply Chain Attacks

Supply chain attacks happen all the time (MailChimp in 2022⁷, Microsoft Exchange Server in 2021⁸, SolarWinds in 2020⁹, British Airways in 2018¹⁰) but there are ways to mitigate them. While some might argue that building systems from scratch instead of relying on code reuse is the solution, the adage “Given enough eyeballs all bugs are shallow¹¹” is a potent reminder of the durability of well-vetted open-source software. One particular weakness of a home-grown solution is that the code is private and cannot be audited. For a recent example look no further than Samsung’s proprietary implementation of Android’s Trusted Execution Environment that led to vulnerabilities in 100 million smartphones¹². Or consider a (as of this writing) still persistent mishandling of account logins at Coinbase - bad actors can gain intelligence on email accounts linked to a Coinbase account, easing phishing campaigns. The issue is that a bad actor can divine email addresses with a Coinbase account and then target them. This isn’t the first time Coinbase suffered from a vulnerable design. In 2019 a data exposure revealed 3,500 plaintext passwords¹³ and in 2021 over 6,000 accounts had cryptocurrency stolen because of a flaw in the SMS account recover scheme¹⁴. While there is no evidence to support the claim that the email confirmation/denial issue is a byproduct of homegrown code, that type of mistake is indicative of amateur programming.

We have started to see attempts at securing supply chain attacks. In May 2021, Executive Order 14028 Improving the nation’s cybersecurity was given. In response, in July 2021 the National Institute of Standards and Technology (NIST), along with the Cybersecurity & Infrastructure Security Agency (CISA) and the Office of Management and Budget (OMB) released two key publications¹⁵ that are stage three of a seven stop program:

Outside of governmental involvement there are a few different private endeavors that are being rolled out. Described in more detail in the next section, GitHub’s Dependabot helps by alerting developers of supply chain threats¹⁶. Additionally, Google is creating tools and methodology to help developers verify “build provenance”. In other words, developers can be equipped with tools that will help verify that source files are not malicious or that malicious artifacts have not been injected into code. The framework that improves the integrity of development is known as Supply-chain Levels for Software Artifacts (SLSA)¹⁷. As supply chain attacks increase, tools to help combat them will also increase in efficacy and adoption.

TechRadar ran a piece in March 2022 suggesting that developers accept that fact that code reuse is inevitable so proper mechanisms to verify the code in development and distribution is a proactive way to mitigate supply chain attacks¹⁸.

Vulnerable and Outdated Components

Using libraries, packages or components from third parties can introduce security concerns. OWASP lists this as number 6 on their top 10 list¹⁹. Generally this refers to software libraries which either contain security vulnerabilities (inadvertently) or become outdated.

log4j

Just in time for Christmas in 2021, the very popular library log4j was discovered to have a remote code execution vulnerability²⁰. The vulnerability had existed for years and affected several versions of the software. When news of this vulnerability surfaced, companies around the world had to fix or update their code in order to ensure that they were not vulnerable.

openssl

The openssl library might be considered the de-facto standard for open source encryption. Providing services such as encryption, decryptions and certificate validation, it is important in nearly all manners of encryption. While it is expected that vulnerabilities exist in all software, some particularly nasty bug were found in 2003 which led to the ability to trick servers into disclosing the server's private key²¹.

The way to mitigate such an attack is to keep libraries up to date. This can be an automated process. For example, GitHub provides the use of "dependabot²²", which was originally released in 2020 as a way to automate dependencies with security issues²³, the most recent version released in April 2022 notifies software authors when libraries are available which address vulnerabilities²⁴. The dependabot can also offer to patch software with the latest version.

WinRAR

Even software as innocuous as compression software can be problematic. In 2019, researchers found an error with WinRAR that let attackers gain full control over a user’s computer²⁵! Issues like this can be especially insidious because users have an implicit belief that popular utilities should be relatively safe (and for 19 years, WinRAR was safe). But the most pernicious part of this story is that WinRAR does not have an automatic update feature - so unless everyday users get their daily news from cybersecurity outlets, there is a good chance people are unaware of the issue (or that the issue can be fixed with a simple update).

Routers

We see the no-automatic-updates problem often in home routers as well. Though the latest trend in home routers do a much better job of updating automatically, for a long time that was not the case. And the percentage of average users that ventured into their router to manually check for updates and install any updates that exist is probably very low. This problem is even worse when companies are aware that their products are susceptible to attacks and won’t even release updates. This happened in late 2021 when Cisco informed users of remote attack that gave unauthenticated attackers the ability to execute arbitrary code on the target device²⁶.

Dependency Confusion

Another fascinating attack was discovered by ethical hacker Alex Birsan in February 2021 (he reportedly made roughly $130,00 in bug bounties for this discovery). Dubbed dependency confusion, the hack was simple. In fact, it did not even require malicious injections; rather his hack leveraged poor design for software development processes. The oversimplified explanation is simple²⁷:

Companies have private code repositories that other code relies on
Birsan found those repository names in code that was published
Birsan then publicly published his own code with the same repository name
Companies’ development tools defaulted to the public repository when given the option
Birsan pwned many companies including Apply, Microsoft, and Shopify

As a reminder to cybersecurity professionals - when a vulnerability is published, fix any liabilities in your organization. In the wake of Birsan’s post, copycats of his attack targeted several companies (including Amazon, Slack, Zillow, and Lyft) by poisoning public repos that were relied on²⁸.

But this isn’t the only threat based on a model of developing using repositories. A similar attack, repo jacking, requires more malicious energy. If an attacker knows what GitHub repositories a company relies on, that hacker can monitor the dependent repositories. If the owner of the repository changes their username, the hacker can swoop in, create an account with that username, and then publish their own code²⁹.