Software Supply chain attacks – do you know what you are importing?
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 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.
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 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.