"Proactive security scanning of code is a must" – JAXenter

JAXenter: Hi Chris, thanks for taking the time to answer our questions. Can you tell us about the UA-Parser-JS NPM Open Source library hack? What happened and how many people were affected?

Chris Eng: UA-Parser-JS is a popular open source library that performs a simple but useful function it determines the browser, engine, operating system, CPU, and device type by inspecting the User-Agent header sent by the end users web browser. The library is downloaded millions of times per week and is used by projects at major enterprises including Facebook, Amazon, Google, and Microsoft.

For a 4-hour period on Friday, October 22, the library contained malicious code that would infect devices with cryptominers and password-stealing malware. When a compromised package is installed on a users device, a script will check the operating system of the device and launch a Linux shell script or Windows batch file, resulting in attempting to steal passwords stored on the device. Cryptominers are also being deployed in a similar way.

Any project using ua-parser-js that performed an automated build during this 4-hour window would be potentially impacted. Additionally, if a developer manually downloaded the infected library during that time frame and introduced it into a new or existing project, they would be affected as well. Its unclear at this time how many downstream users were impacted by the malware.

SEE ALSO: Legacy systems contain outdated hardware & software that is often difficult to replace

JAXenter: What was the response to the attack and how was it fixed?

Chris Eng: The owner of NPM, GitHub, was quick to act. They removed the compromised packages and issued security advisory for those using the affected versions. The package maintainer also quickly released patches so that any projects configured to pull down the most recent version of the library would receive a clean copy. Users have been advised to upgrade to newer versions of the library, as well as check their systems for compromise, with a full list of indicators of compromise being shared.

JAXenter: How likely is it that another malicious package will be spread in a similar manner and what potential harm could it cause?

Chris Eng: Very likely. Its not the first time weve seen a supply chain attack, and it wont be the last. Threat actors, like the ones from this incident, could introduce any sort of malicious code. The outcome could be even worse if the library developers were less active, or if the injected code were stealthier for example, if it had introduced a subtle vulnerability in the library that could be exploited later.

JAXenter: What are the unique security concerns that come with open source software?

Chris Eng: We often assume security has been considered by the developers behind an open source library, but thats not always the case. Developers publishing open source code may not have taken security into account at all. And these libraries are being updated all the time, sometimes with fixes to issues, and other times with more vulnerabilities added in. Proactive security scanning of code is a must when we cant ensure the software is taking security into account in development.

Seven of every 10 applications use at least one flawed open source library with a vulnerability, according to research from ESG last year. Despite the prevalence of vulnerabilities in open source code, organizations continue to use these libraries without much regard for security. Veracodes State of Software Security (SoSS) v11: Open Source edition from earlier this year found that nearly 80% of the time, third-party libraries are never updated once they are added to a code base.

A great example of the potential harm these malicious open source packages can bring is the 2017 Equifax hack. Failing to update vulnerable open source libraries was one of the contributing factors in that breach, which compromised social security numbers and other PII for over 143 million people.

JAXenter: Of course, we shouldnt trust packages based merely on their number of downloads. So, what can we do to boost our open source security practices to avoid malicious code?

Chris Eng: For starters, we need to improve upon that stat that nearly 80% of third party libraries are never updated after they are added. Regularly updating open source software allows for new versions with security patches to replace the older versions with exploitable vulnerabilities.

Removing vulnerable code is as much a cultural issue as a technology issue though. Leadership needs to carve out time for developers to scan their software for vulnerabilities before deployment and take action to remediate the findings. Usually there is an emphasis on pushing out new features as quickly as possible, without factoring in the risk associated with new vulnerabilities, not to mention existing security debt.

We need to add early and recurring security scanning for open source code into the day-to-day operations of DevSecOps. Additionally, teams should proactively scan after deployment as well, since new vulnerabilities in open source libraries are discovered all the time.

SEE ALSO: wasmCloud allows us to rethink the cloud as just a stop on the way

JAXenter: How dependable are security scanning tools? Should we spend more time analyzing manually, or is human error more of an issue?

Chris Eng: Security scanning tools are a must-have for todays enterprises. There are far too many vulnerabilities in software to rely on a manual approach. Security scanning tools have the ability to automatically identify both first-party and third-party software vulnerabilities. Enterprises should invest in scanners that take into account business objectives, levels of risk for each vulnerability, and flaws that can be fixed the fastest to create a clear path forward for remediation. Ideally, the best scanners will provide these results, quickly, automatically, and holistically across the entire software lifecycle.

JAXenter: And finally, whats in your essential security toolkit?

Chris Eng: Lots of things, but lets focus on this particular incident. All of this likely began with the takeover of a developer account. Control of the account allowed the threat actor to inject malicious code which then propagated to projects using the library. Im willing to bet that the compromised developer account was not using multi-factor authentication (MFA) and was being protected only by a password. And that password was likely compromised either via a phishing attack, or as a result of an unrelated breach where the developer had re-used a common password. Had the developer enabled MFA on their npm account, this attack probably never would have happened.

For organizations building software with open source libraries, a Software Composition Analysis (SCA) tool is key. Being able to quickly identify which of your projects used this vulnerable library either directly or transitively (i.e. using a different library which depends on the vulnerable library) is an important first step in understanding your organizations exposure to an incident like this.

See the original post here:

"Proactive security scanning of code is a must" - JAXenter