Call us today on: +44 (0)203 88 020 88
SecureTeamSecureTeamSecureTeamSecureTeam
  • Home
  • Our Services
    • Infrastructure Testing
      • Internal Network Penetration Test
      • External Network Penetration Test
      • Vulnerability Assessment
    • Web Application Penetration Test
    • Configuration Review
      • Windows Build Review
    • Information Assurance
      • ISO 27001 Gap Analysis
    • Cyber Essentials Certification
  • News
  • Articles
  • About
    • About SecureTeam
    • Cookie Policy
    • Privacy Notice
    • Website Terms & Conditions
    • White-Label Consultancy
    • Jobs
  • Contact Us

Articles

Home  >  Articles  >  Web Applications  >  What are software supply chain attacks?
NextPrevious

What are software supply chain attacks?

Articles, Web Applications | 18 July, 2019 | 0

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.

 

 

Subscribe to our monthly cybersecurity newsletter
Stay up-to-date with the very latest cybersecurity news & technical articles delivered straight to your inbox
We hate spam as much as you do. We will never give your email address out to any third-party.
formjacking, penetration testing, supply chain attacks, web applications

Related Post

  • website testing

    What are Formjacking attacks ?

    By Mark Faithfull

    Formjacking is a type of cyber attack that can be used by an attacker to steal sensitive information that is entered by website users through forms.  Most usually this type of attack targets ecommerce sites toRead more

  • The risks of nation state actors to your business

    By Mark Faithfull

    Reading about the latest hacks by alleged nation state sponsored groups from China or Russia may make for interesting lunchtime reading.  But do these groups pose a real threat to the typical business?  Many securityRead more

  • Avast breached via insecure VPN profile

    By Mark Faithfull

    Anti-virus company Avast has revealed they were breached over several months, after identifying the suspicious activity on their network on 23rd September according to a blog post by their CISO.  Avast think their CCleaner softwareRead more

  • The most common causes of CVE

    2019 CWE Top 25 Most Dangerous Software Errors

    By Mark Faithfull

    The CWE top 25 is a list of the most common software defects that give rise to CVE being reported. Mitre, the organisation behind the Common Vulnerabilities and Exposures database, has scanned some 25,000 CVERead more

  • Webmin utility compromised with deliberate RCE

    By Mark Faithfull

    Webmin, the web-based interface for system administration for Unix and Linux, had a remote code execution vulnerability deliberately introduced into its source code in April 2018.  It was only publicised in August 2019 when aRead more

NextPrevious

Recent Posts

  • VNC Vulnerabilities patched
  • Integer overflow flaw hits HP SSD
  • The people are the problem
  • Critical Oracle EBS vulnerabilities remain unpatched
  • Windows 7 and Server 2008 support ends January

Tags

blockchain Bluetooth Botnet Chrome Cisco CREST cyber crime cyber essentials cyber security cyber security news Data Protection Dell DNS Ethereum Exchange Server exim formjacking GDPR Hadoop Intel Linux Meltdown microsoft Mirai OpenOffice patching PDF penetration testing phishing ransomware RDP Row Hammer security breach security testing Spectre supply chain attacks Sysinternals Tomcat TPM UK Law VNC vulnerability management web applications web browsers wireless

Archives

  • December 2019
  • November 2019
  • October 2019
  • September 2019
  • August 2019
  • July 2019
  • June 2019
  • May 2019
  • April 2019
  • March 2019
  • February 2019
  • January 2019
  • December 2018
  • November 2018
  • July 2018
  • June 2018
  • April 2018
  • January 2018
  • October 2017
BCS Cyber Essentials Cyber Essentials Cyber Essentials PLUS
information. secured.
  • Home
  • Our Services
    • Infrastructure Testing
      • Internal Network Penetration Test
      • External Network Penetration Test
      • Vulnerability Assessment
    • Web Application Penetration Test
    • Configuration Review
      • Windows Build Review
    • Information Assurance
      • ISO 27001 Gap Analysis
    • Cyber Essentials Certification
  • News
  • Articles
  • About
    • About SecureTeam
    • Cookie Policy
    • Privacy Notice
    • Website Terms & Conditions
    • White-Label Consultancy
    • Jobs
  • Contact Us
SecureTeam
SecureTeam use cookies on this website to ensure that we give you the best experience possible. If you continue to use our site we will assume that you are happy with cookies being used.OkRead more