Software Supply chain attacks – do you know what you are importing?

Many websites and applications routinely import additional code modules from external repositories.  These could be javascript libraries for a webpage or source code for an application.

Two recent incidents illustrate the risks of supply chain attacks against the code of your applications and websites.

What is a supply chain attack?

A supply chain attack is a cyber-attack which seeks to damage or infiltrate your network by targeting less secure elements of your supply chain network.  This could include access hardware before it is delivered for installation, or tampering with source code before it is accessed by your developers or systems. Often the ‘less secure element’ is the systems of a partner, client or supplier.

Examples of supply chain attacks

In this article, we will take a detailed look at two recently reported supply chain attacks to help you identify and mitigate any similar risks in your organisation.

Attack 1: The Magecart gang has injected their payment card formjacking code into the javascript used on 17,000 websites.

Attack 2: A password strength checker gem used by Ruby applications was modified in the master repository to download and execute arbitrary code – but only when it was running in a production environment

A review of these two incidents provides an insight into the chain of vulnerabilities that allowed malicious actors to access the systems of thousands of victims.

Attack 1: Code injection into javascript libraries

Modern websites use many common javascript libraries – from large well-known projects such as React down to tools and helper scripts provided by suppliers such as marketing forms or customer support chat bots.  By way of an illustration: on a recent visit to the home page of a national newspaper’s website we counted 96 javascript files being loaded – many imported from third party domains.

To ensure rapid load times and to make it easy for many different clients to easily access the libraries, these shared javascript files are often hosted on a high speed cloud storage platform such as Amazon S3.  Since these libraries need to be accessed by a large number of clients – or even by everybody in the case of open source projects – the access controls on the repository are set to allow anyone to read the files without requiring any authentication.

In the case of the Magecart attack, the gang were able to identify many Amazon S3 buckets that had been set up with mistakes in the access controls.  In these cases, the S3 buckets had been configured to allow anyone to write to the files, as well as read them.  This made it relatively trivial for the attackers to create a script which worked its way through all the exposed javascript libraries (simply looking for a .js file extension) and add their card skimming code to the end of every file.  If the javascript library then happened to be imported into a payment page on an ecommerce site then the card data would be skimmed and sent to the criminals server.

By default Amazon S3 buckets are configured to prevent external access, so all the victims of the Magecart attack must have changed the S3 access controls settings to allow write access to their files by any unauthenticated user.  This could be an example of poor security hygiene where development and test systems were initially set up with wide open security, and the administrators forgot to lock it down when the project moved into production.  A more robust approach is to conduct development and testing with the production level security in place – which ensures both the product design and DevOps procedures are all designed to be compatible with the security environment. To be effective, security must be part of the design, not an afterthought.

Amazon offer a best practice guide to help their clients secure S3 resources.

For the victims who ended up with Magecart infected javascript libraries imported directly into their web pages, the challenge is somewhat more complicated as they are reliant on their partner to identify the infection and correct it at the source. In many cases, neither the client using the infected code nor the partner supplying it are aware that the code has been altered.

For more information about how this kind of formjacking attack works, and suggestions how to protect your systems against formjacking, refer to our article: What are Formjacking attacks.

It is operationally simpler to import third party libraries directly from the partner’s repository. Then you don’t need to worry about version control or hosting – you always end up with the latest version.  However, by doing so, you are providing a direct line into your secure processing environment to a third party and you have no control over their security capability or effectiveness.

A more secure approach is to host your own copies of every third party library in a secure cache and manage any updates through a change control process.

Attack 2: Unexpected changes to trusted source code

Developers generally do not like to keep re-inventing the wheel, so they make use of open source libraries hosted in code repositories such as GitHub or, in the case of Ruby applications: RubyGems.

One such library available in the RubyGems repository is strong_password, an entropy based password strength checker which has been downloaded almost a quarter of a million times.

Developer Tute Costa recently reported that he noticed an unexpected change in the strong_password gem when he was preparing a new version of his application and wanted to validate and import the latest versions of the third party libraries that he used. His detailed explanation is found on his blog.

In summary: he spotted an unexpected version number change with no matching change control documentation on the project’s homepage. He then examined the source code to identify what had changed and discovered several lines of code that had been inserted into the password strength checker.  The new code checked if it was running in a production environment, and then waited a random number of minutes before downloading instructions from a Pastebin account and executing them.

This vulnerability was in version 0.0.7 of strong_password and tracked by CVE-2019-13354. It is fixed in version 0.0.8 which is now available.

Tute contacted the project’s developer who then confirmed he had been locked out of the sourcecode and the changes were made without his knowledge.  It later transpired that the project’s developer had set up his repository account many years ago – long before security measures such as two factor authentication had been available and he used a long standing password which was also used on other websites.  He suspects that the hackers guessed his password in order to access the source code repository and alter the code.

In this case, the painstaking diligence of Tute Costa to validate every change in the third-party libraries he was using meant he spotted the malicious code that had been added to the strong_password gem a week earlier.

The gem was compromised by the lack of good operational security practices by the original developer who was re-using a password which was presumably compromised in another data breach and he had not activated 2-factor authentication on his account which controlled access to the source code.

How to protect your systems against web software supply chain attacks

Consider these measures which will help defend your systems against supply chain attacks against your web applications and systems:

• Review the security measures your suppliers have in place for their source code – compare them to your own – on a regular basis.
• Host third party libraries on your own server rather than importing them from the vendors server – then you can control any changes and review them before implementation.
• Implement Subresource Integrity checks to protect against unexpected modification to third party libraries used on your web pages.
• Monitor and analyse all browser and server traffic during testing to ensure no unexpected connections are being made to servers outside of your network.