Supply chain attacks: Mitigation and protection

In software development, a supply chain attack is typically performed by inserting malicious code into a code dependency or third-party service integration. Unlike typical cyber attacks, supply chain attacks provide two major advantages to attackers.

Firstly, a single supply chain attack can target multiple companies at once (since multiple companies use the same code dependencies and third-party scripts); as such, the potential return of investment of the attack is higher. Secondly, and unlike common cyber attacks, supply chain attacks can remain undetected by perimeter defenses, as they are often initiated by a change to a component of the system which is trusted by default; then, an approved delivery mechanism such as a software update delivers the supply chain attack without arising any suspicion by network defenders.

In 2018, supply chain attacks became a common occurrence in headlines after successfully attacking high-profile companies.

Magecart

Magecart is a designation broadly applied to several groups of cybercriminals that, as early as 2015, have been injecting digital credit card skimmers on e-commerce websites. These credit card skimmers have successfully stolen details of at least 420,000 credit cards in 2018 – this just represents the publicly available numbers for the Ticketmaster and British Airways attacks.

Magecart’s attack on British Airways was a highly selective one. The group clearly identified the company as the target, setting up the malicious code in a way that targeted the British Airways payment page. The attack took place through a modified version of the Modernizr JavaScript library, which was being loaded as a script from the baggage claim information page.

The compromised script included malicious code that actively listens for events that happen on the page and triggers an action whenever credit card details are submitted (event hijacking). As so, Magecart was able to intercept this credit card data that users were inputting in the checkout pages and send it to the attackers’ servers. In total, at least 380,000 British Airways customers were affected by the attack.

While the British Airways attacks is one of Magecart’s largest to date, the groups’ modus operandi is more frequently to launch a broader attack that is able to infect as many websites as possible. This attack relies on exploiting third parties that are loaded directly into e-commerce websites. When a third-party script becomes compromised, the malicious code immediately starts being served to affected websites’ end users. Analyses of some past Magecart attacks highlight this broad nature by looking at the malicious code itself:

if ((new RegExp('onepage|checkout|onestep',
'gi')).test(window.location)) {
skimmer.send();
}

By using a regex check, the skimmer will activate in web pages for which the URL path matches usual keywords for payment pages (onepage, checkout, onestep). Besides this, it grabs information inserted in any input fields (and not a specific field). As so, it’s entirely more likely that the attack will be able to target a great number of websites that process credit card payments.

The Ticketmaster data breach of June 2018 was achieved by this approach. Magecart compromised two third-party scripts — SociaPlus and Inbenta — and, among the many websites it infected, this resulted in a massive attack to Ticketmaster that remained undetected for over 2 months and affected 40,000 customers. According to RiskIQ, this specific Magecart approach has likely victimized over 100,000 websites.

Mitigation

The Supply Chain Attacks and Resiliency Mitigations report by the MITRE Corporation identifies several high-level cyber resiliency techniques for mitigating cyber attacks. First and foremost, it’s vital that security professionals and management understand that mitigating supply chain attacks requires a security-in-depth approach. There must be awareness that investing resources on periphery defenses alone is not a suitable approach.

There is often a misconception that SAST (Static Application Security Testing) is a suitable approach to prevent supply chain attacks. However, these attacks exploit weaknesses and introduce malicious logic into existing code. As this is not a vulnerability, it remains undetected by SAST. Taking into account that supply chain attacks frequently operate through changes that are manifested on the client-side, investing in client-side security becomes a key step of the process.

JavaScript protection and webpage monitoring

Application shielding solutions provide a holistic client-side approach to meet the mitigations outlined by MITRE. If we consider the cyber attack lifecycle, we notice that the attack process begins with a “Recon” phase, where attackers gather as much information as possible about possible vulnerabilities to exploit.

By using JavaScript protection techniques such as obfuscation, the cost of reverse-engineering attempts is driven up to a point where they become uneconomical. This is a general practice and even an OWASP recommendation that should be enabled for JavaScript-based applications, whether they are running on a mobile device, web browser, or server-side. Additional protective layers should be added on top of this, such as locking the application’s code to specific environments (domains, OSes, browsers, and time periods) and providing the code with self-defending capabilities — effectively blocking attackers from debugging the code in a Recon attempt.

This code protection solution should be applied in a polymorphic fashion. This means that each new version of the protected code will be entirely different from the previous one, which goes in line with the deception, diversity, and unpredictability recommendations by MITRE. Moving beyond the recon stage, mitigating supply chain attacks during runtime can also be achieved with using the appropriate solution. For example, a client-side threat monitoring solution that detects any tampering to the DOM that occurs during runtime, independently of its delivery mechanism.

In the current panorama of application security, there’s no infallible way of being sure malicious code or markup isn’t injected into companies’ applications. The next best thing is to gain visibility about injections and be able to react in real-time. Past supply chain attacks have one common metric that contributed to their magnitude: the very long time from attack to detection. If you can detect supply chain attacks in real-time, you enable companies to react instantly and mitigate them before any serious damage occurs.

Limit third-party scripts and code dependencies

It’s unfeasible to advise a scenario where companies should stop using third-party code altogether, even if it would mean effectively preventing supply chain attacks. As it stands, the next best option is to limit this use.

Software development teams must consider a “lean” approach in terms of code dependencies: keeping those which are vital to the application and can’t be developed and maintained in-house, and discarding the ones which bring little value and/or can be kept internally. The same goes for the third-party scripts that are loaded on the application. These are not required for the application to operate and represent add-ons to access tools and services such as analytics or ads. Companies must ensure that their applications aren’t leniently integrating unnecessary, risky, or deprecated scripts. Each extra code dependency or external script must be seen as a substantial increase to the application’s attack surface.

Assess third-party suppliers’ security level

At the end of the day, code dependencies and third-party scripts will keep prevailing, even with a “lean” approach as advised before. As it stands, organizations can still have some control over minimizing these risks. From the perspective of using third-party scripts, companies should assess the security level of third-party suppliers during the procurement phase on the following dimensions:

• JavaScript code security — the third-party supplier should have in place a solution that protects the JavaScript code, mitigating reserve-engineering and counterfeit code. This goes in line with MITRE’s recommendations for deception and substantiated integrity.
• JavaScript code polymorphism — in line with the JavaScript code protection outlined above, the supplier should also be able to guarantee that this code is polymorphic, i.e., taking different forms for each new build. This ultimately helps increase the redundancy of the script, as well as ensure its unpredictability, two other MITRE recommendations.
• Subresource integrity — the supplier should provide the SRI token, enabling the procuring company to use SRI to ensure the integrity of loaded scripts.
• Content security policy — by having a CSP in place, the supplier increases the security of its own platform, by limiting the external sources to which they can send/receive content.

Use Subresource Integrity (SRI)

Adding Subresource Integrity (SRI) attributes to the script elements loading the external scripts can provide some degree of protection against supply chain attacks. By checking the file integrity, the application does not load scripts whose integrity check differs from the original, trusted script. As so, malicious scripts won’t be loaded from third parties. If we frame this to the supply chain attacks that originate from a third-party script, we’re led to the conclusion that the third-party scripts would not load from the minute they became compromised.

However, SRI comes with a major pitfall: it’s notably complex to apply to dynamic code. And, as you may expect, most of these third-party script providers (e.g. Google Analytics) keep improving their services, which results in frequent changes to script itself. Adapting SRI to match this dynamic nature can be burdensome and, if SRI isn’t properly set up, it can block a perfectly safe third-party script when it receives a much-needed update.

A multi-layered mitigation approach

All of the mitigation strategies presented in this article go a long way towards mitigating supply chain attacks. However, an effective means of mitigation requires an approach that leverages most of these strategies with a combination of SRI, limitation of external sources and proper supplier assessment.

By pursuing this security-in-depth approach, companies can ensure that they gain total visibility and control over the client-side of their applications. This effectively translates to being able to prevent user data exfiltration and its ensuing liabilities.