JavaScript supply chain issues

April 4, 2022  |  Mike Klepper

In open source we trust

JavaScript code—used in 98% of all global websites–is a notable contributor to the ongoing software supply chain attack problems. In fact, vulnerable or malicious JavaScript is likely responsible for a sizable portion of the increase in attacks during 2021. With much of the JavaScript code that drives websites originating from open-source libraries, organizations need to understand how open source contributes to the JavaScript supply chain issues, and what they need to do to protect their business and their customers.

What’s going on with the supply chain?

Often called one of the most insidious and dangerous forms of hacking, software supply chain attacks can devastate businesses. In addition to the immediate effects of an attack, such as operational delays, system infiltration, and the theft of sensitive credentials or customer data, the long-term consequences can be significant. Regulatory fines, compliance concerns, reputation damage, attacks on connected businesses, and lost customers are often the consequences of a supply chain attack.

Software supply chain attacks currently dominate the headlines, with recent industry research reporting a 300% increase in 2021. The research found that threat actors tend to focus on open source vulnerabilities and code integrity issues to deliver attacks. In addition, researchers discovered a low level of security across software development environments, with every company examined having vulnerabilities and misconfigurations.

Another industry report discovered a 650% increase over the course of one year in supply chain attacks aimed at upstream public repositories, the objective being to implant malware directly into open source projects to infiltrate the commercial supply chain.

A common thread in all of this is JavaScript—an inherently insecure coding language and one that is often found in open source projects.

Open-source JavaScript: A focal point for attack

Why the software supply chain has become a focal point for threat actors is a question on quite a few minds. The answer comes down to what is easy and most profitable. Software is imperfect. Vulnerabilities and flaws make it ripe for attack. And a connected supply chain ensures a large attack surface. Add to this is the prevalent use of the JavaScript programming language and open-source JavaScript libraries, which often contain flawed and sometimes malicious–third- or fourth-party code, and businesses become ground zero for JavaScript supply chain attacks.

JavaScript serves as one of the core technologies used to build web applications and websites. As mentioned previously, over 98% of websites use it for client-side web page behavioral elements. Additionally, 80% of websites use open-source or a third-party JavaScript library as part of their web application. The Stack Overflow 2021 Developer Survey found that JavaScript remains the most popular programming language with 65% of professional developers using it. Unfortunately, JavaScript wasn’t built with security in mind, making it extremely vulnerable to attack. JavaScript allows threat actors to deliver malicious scripts to run on both the front end and the back end of a system, affecting businesses, employees, and customers alike.

In addition, because there is little to no oversight in open-source libraries, vulnerabilities and malicious scripts can often lay unnoticed for months or even years.

The security firm WhiteSource recently highlighted the problems with open-source libraries and JavaScript, identifying more than 1,300 malicious packages in the most commonly downloaded JavaScript package repository.

What do JavaScript supply chain attacks look like?

As we mentioned earlier, JavaScript was not built with security in mind. Since there are no security permissions built into the JS framework, it is difficult to keep JavaScript code safe from attack. The most common JavaScript security vulnerabilities include:

  • Source code vulnerabilities
  • Input validation
  • Reliance on client-side validation
  • Unintended script execution
  • Session data exposure
  • Unintentional user activity

JavaScript supply chain attacks can take on one of three different forms: attacking the developer directly; embedding the attack on the back end; or embedding the attack on the front end.

Let’s play attack the developer!

The recent news of malicious activity found in npm, the most popular JavaScript package manager, made international headlines. These JavaScript package managers are designed to help developers automate any dependencies associated with a development project. Package managers enable automatic installation of new packages or an update to existing packages with a single command. They’re hugely popular, with new package managers released often, making them difficult to monitor. Since npm is open source, anyone can submit JavaScript packages, even bad actors who intentionally include malicious scripts in their packages.

The thing about package managers is that they install files directly on the developer’s machine, which means threat actors can get almost instant access to a developer’s device and possibly the entire system and network. According to WhiteSource, the organization that discovered the malicious npm packages, much of the malicious activity involved embedding malicious files on developer machines to engage in the ‘reconnaissance’ phase of an attack (based on the MITRE ATT&CK Framework), that is, active or passive information gathering. Researchers also discovered that 14% of the packages were designed to steal sensitive information, such as credentials.

Researchers found that threat actors designed these malicious packages to make them look legitimate, by using the names of well-known and popular npm packages, and then emulating source code. Malicious files observed in the study included obfuscated JavaScript and binaries hidden as JavaScript components.

The researchers in the WhiteSource study also found that in some instances, once the developers downloaded the files, one of the binaries would download a third-party file designed to interact with the Windows Registry to collect system and configuration information. The malicious file would also try to establish a connection with a remote host to enable remote code execution (RCE). The fake JavaScript files also included examples of Cobalt Strike, a tool used during Red Teams and penetration testing to facilitate an attack. According to researchers, the ultimate goal of this malicious software appeared to be cryptocurrency mining directly on the developer machine.

While threat actors did not appear to target specific industries or companies, they did design malicious packages to target certain systems. Researchers also discovered malicious JavaScript packages that used typosquatting, dependency confusion, code obfuscation, and other types of attack techniques.

Back-end JavaScript threats

JavaScript frameworks commonly used for server-side development, or the back end of a web application, are also highly susceptible to attack. As we mentioned earlier, JavaScript wasn’t built with security in mind making it an easy target. Any vulnerabilities in back-end JavaScript source code means threat actors have an easy way to infiltrate systems, install malicious files, and execute attacks. Risks include security misconfigurations, which can enable access to the back end; insecure back-end application design; vulnerable or outdated components; and server-side request forgery (SSRF). Examples of threats include SQL injection for back-end database manipulation, SSRF, and cross-site scripting (XSS).  

Front-end JavaScript threats

The front-end, or “client-side” code is executed within the browser which often lacks the same rigorous security controls that protect the back end of web applications. This makes vulnerable code on the client-side even more deadly due to the lack of visibility and control most organizations don’t have in place today. Since many web applications are written in JavaScript and operate on the client side, web users—such as bank or e-commerce customers—become vulnerable to attacks like Magecart, e-skimming, side loading, cross-site scripting (XSS), and formjacking.

Protect the complete attack surface with these three key steps

To fully manage the risk against breaches and attacks, companies must simultaneously protect both the client side and back end of their application portfolios. This includes anything accessed by the developer, anything written in JavaScript on the back end, and web assets that the customer can see (e.g., text and images) and interact with.

One of the most important actions ​​any business can take is protecting their customers from JavaScript threats. Unfortunately, because of the sophisticated and subtle nature of these attacks, they can be hard to detect until it’s too late. To ensure that businesses are offering a safe and secure digital experience, they must be diligent about securing their website and web applications from dangerous client-side JavaScript attacks.

To protect the client-side attack surface, businesses should apply these three best practices:

  • Review third-party code during software development: Third-party JavaScript is a great way to avoid the time and money associated with developing your own code, but third-party scripts can also contain vulnerabilities or intentional malicious content. Always inspect third- and fourth-party additions for vulnerabilities.
  • Perform automated client-side attack surface monitoring: Inspection activities are critical, but also time consuming if you don’t have an automated solution to review JavaScript code. A purpose-built solution, like Feroot’s Inspector offered in AT&T Managed Vulnerability Program’s Client-side Security Solution, that automates the process can be a fast and easy way to identify malicious script activity.
  • Identify software supply chain risks: Assess and know what third-party code is being used across your web application’s client-side.

Improve your JavaScript supply chain security

JavaScript carries risk. The only way to avoid your business and your customers becoming victims of a JavaScript attack is to apply JavaScript security best practices to your website and web application development process.

The services offered by AT&T’s Managed Vulnerability Program (MVP) allow the MVP team to inspect and monitor customer web applications for malicious JavaScript code that could jeopardize customer and organization security.

AT&T is helping customers strengthen their cybersecurity posture and increase their cyber resiliency by enabling organizations to align cyber risks to business goals, meet compliance and regulatory demands, achieve business outcomes, and be prepared to protect an ever-evolving IT ecosystem.

To learn more about JavaScript security, check out Feroot’s comprehensive Education Center to read more on terminologies, technologies, and threats.

Share this with others

Get price Free trial