DEV Community: Sonatype

A peek inside the “fallguys” malware that steals your browsing data and gaming IMs

Ax Sharma — Thu, 03 Sep 2020 09:18:13 +0000

This weekend a report emerged of mysterious npm malware stealing sensitive information from Discord apps and web browsers installed on a user’s machine.

The malicious component called “fallguys” lived on npm downloads impersonating an API for the widely popular video game, Fall Guys: Ultimate Knockout. Its actual purpose, however, was rather sinister.

As first reported by ZDNet and analyzed by the npm security team, the component when included in your development builds would run alongside your program, and access the following files:

/AppData/Local/Google/Chrome/User\x20Data/Default/Local\x20Storage/leveldb
/AppData/Roaming/Opera\x20Software/Opera\x20Stable/Local\x20Storage/leveldb
/AppData/Local/Yandex/YandexBrowser/User\x20Data/Default/Local\x20Storage/leveldb
/AppData/Local/BraveSoftware/Brave-Browser/User\x20Data/Default/Local\x20Storage/leveldb
/AppData/Roaming/discord/Local\x20Storage/leveldb

The file list comprises the local storage leveldb files of different web browsers, such as Chrome, Opera, Yandex, and Brave, along with any locally installed Discord apps.

LevelDB is a key-value storage format mainly used by web browsers to store data especially that relates to a user’s web browsing sessions.

The “fallguys” component would pry on these files and upload them to a third-party Discord server, e.g. via webhooks.

A peek inside npm “fallguys”

Npm removed the malicious package, but fortunately we retain a copy of all components in a secure archive, so the Sonatype Security Research team was able to quickly analyze the malware. In fact, we got this into our data well before the news broke so Nexus users are safe!

In this Nexus Intelligence Insights post, we share a first look inside “fallguys”.

Vulnerability identifier: sonatype-2020-0774

Vulnerability type: Embedded Malicious Code

Impacted package: fallguys as formerly present in npm downloads

CVSS 3.1 Severity Metrics: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

CVSS3.1 Score: 10 (Critical)

While “fallguys” package was likely created with malicious intent from the beginning, the package exhibits outright suspicious behavior in version 1.0.6.

There are three files found in version 1.0.6. One is a README which touts the malware being a *Fall Guys *game API to gain some trust from the user and the other two files include the application manifest (“package.json”), and the main “index.js”.

The README.MD file present in“fallguys” npm malware (Image source: Sonatype)

The manifest reveals nothing out of the blue, but in “index.js” we see a whole lot going on:

The very first constant “_0x13e5” is a cryptic array containing different strings and locations of multiple “leveldb” files the malware would eventually begin reading. This is all part of the obfuscation process, to jam different strings the application would need into a single array and read from this array.

For example, on line 30, the variable assignment obtains a value from this very “_0x13e5” array at an obfuscated subscript address “_0xe64ed6” (15093462).

There is also mention of strings such as “username”, “email”, “phone”, “Token grabber”, etc. but their purpose doesn’t become immediately obvious to an analyst.

Obfuscated code in index.js file of “fallguys” with Discord webhooks (Spread out by us to make it more legible; Image source: Sonatype)

On line 37, we see the “webhook” variable containing the URL to the attacker’s Discord app which is where data read from the “leveldb” files we list above, would be posted to:

var webhook = 'https://discordapp[.]com/api/webhooks/746189410042904617/RQVJEOhzAblK5FlkQ-WIXkWfKfg5BFCdsjTeVueAIrVLaQMTvHgbuhuqFafPZYHfwnEq'

At the time of writing, our tests confirm the webhook endpoint is no longer responsive and was likely brought down by Discord:

Discord webhook where “fallguys” malware would post sensitive information to

The “send” function also has a nested JSON object which appears to contain the profile metadata with bits such as the author name, avatar thumbnail, username, email, etc.

The “send” function within the malicious “fallguys” component (Image source: Sonatype)

Mostly your browser data, nothing else

In an age where adversaries find innovative ways to pollute the software supply chain via attacks such as Octopus Scanner, or leverage typosquatting techniques to mine Bitcoins, it is certainly odd for malware to exclusively target browser data stores and Discord files without touching more sensitive areas of a system.

“The malicious package appears to have been performing some sort of reconnaissance, gathering data on victims, and trying to assess what sites the infected developers were accessing, before delivering more targeted code via an update to the package later down the road,” states the ZDNet report.

Thankfully, this malware was caught early and has only been downloaded around 300 times. However, we may not always be so lucky.

Our New Normal

According to our 2020 State of the Software Supply Chain report, next-generation software supply chain “attacks” are far more sinister because bad actors are no longer waiting for public vulnerability disclosures. Instead, they are taking the initiative and actively injecting malicious code into open source projects that feed the global supply chain.

By shifting their focus “upstream,” such as with open-source malware in “fallguys,” bad actors can infect a single component, which will then be distributed “downstream” using legitimate software workflows and update mechanisms.

Our 2020 report also shows that this is happening at a rapidly increased rate. In fact, there was a 430% increase in next-generation software supply chain attacks over the past year. Keeping this in mind, it is virtually impossible to manually chase and keep track of such components.

Sonatype’s world-class security research data, combined with our automated malware detection technology safeguards your developers, customers, and software supply chain from infections like these.

DevOps-native organizations with the ability to continuously deploy software releases have an automation advantage that allows them to stay one step ahead of malicious intent. Sonatype Nexus customers were notified of sonatype-2020-0774 within hours of the discovery, and their development teams automatically received instructions on how to remediate the risk. Their browsing history and gaming IMs are safe.

If you're not a Sonatype customer and want to find out if your code is vulnerable, you can use Sonatype's free Nexus Vulnerability Scanner to find out quickly.

Visit the Nexus Intelligence Insights page for a deep dive into other vulnerabilities like this one or subscribe to automatically receive Nexus Intelligence Insights hot off the press.

Secure Your Golang Projects Using Nancy

Dan Rollo — Mon, 13 Apr 2020 20:36:43 +0000

Who is Nancy?

Nancy is a command line application, written in Golang by the Golang community and sponsored by Sonatype. It uses Sonatype’s OSS Index to check your dependencies for publicly filed vulnerabilities.

You can get more information about Nancy by going to the GitHub repository for it at:
https://github.com/sonatype-nexus-community/nancy or on https://pkg.go.dev/github.com/sonatype-nexus-community/nancy?tab=doc

Why would I use Nancy?

Nancy can take dependency results from your go mod powered or dep powered projects and scan them for vulnerabilities. This is quite handy, as you’ll see that vulnerabilities pop up in libraries, like golang/x/crypto:

https://ossindex.sonatype.org/component/pkg:golang/golang.org/x/crypto@v0.0.0-20190227175134-215aa809caaf

Vulnerabilities in these third party or even standard lib libraries (x/crypto is a part of Golang itself!) can sneak up on you, if, for example, you are using a framework that uses them, or using them directly yourself. It’s never a good feeling getting pwned because of someone else’s code, and Nancy is here to help you!

How do I use Nancy?

Nancy is quite easy to use, and the Community/Sonatype have gone to great lengths to make it as easy as possible.

Installing Nancy

Nancy is distributed as an executable built with Golang and each executable is available on it’s release from multiple repositories:
GitHub

https://github.com/sonatype-nexus-community/nancy/releases

Docker

For ease of use a Docker image has been created, as well as a homebrew tap for OS X users that love brew!

To run it with Docker one need only follow the instructions available here: https://github.com/sonatype-nexus-community/nancy#docker-usage or for ease of use in this post:

go list -m all | docker run -i sonatypecommunity/nancy:latest

Homebrew

To install with homebrew, instructions are available here: https://github.com/sonatype-nexus-community/nancy#homebrew-usage, and for ease of use, here you go:

brew tap sonatype-nexus-community/homebrew-nancy-tap
brew install nancy

Ok I installed it, now what!?

For a go mod powered project, one need only do:

go list -m all | nancy

For a dep powered project:

nancy /path/to/your/Gopkg.lock

The beauty of Nancy is Nancy tries to meet you where you are. It cares about securing all projects. If you use a package manager that it doesn’t support, it is Open Source and the community is more than willing to help you change that!

What do results look like?

If you run Nancy and find nothing wrong with your dependencies you’ll see something akin to the following:

Nancy will exit with a zero code in this case, and all is good in the world!

If Nancy finds a vulnerability in one of your dependencies it will exit with a non zero code, allowing you to use Nancy as a tool in your CI/CD process, and fail builds, if you’d like.

Output when it finds a vulnerability looks like:

You are given the information on what the vulnerability is, and how to get more info on the OSS Index site about it!

What do I do if the vulnerability doesn’t apply to me?

Since Nancy is checking the dependencies for vulnerabilities, sometimes you’ll run into one where you are not using the affected code path. The community has built functionality to let you exclude the vulnerability from being reported.

The information on how to do this is available here: https://github.com/sonatype-nexus-community/nancy#exclude-vulnerabilities and for ease of use:

nancy -exclude-vulnerability CVE-789,bcb0c38d-0d35-44ee-b7a7-8f77183d1ae2

You can also use an exclusion file to keep better track of them and avoid passing in long lists via the command line. The default file name, if you check this in to your repo, would be: .nancy-ignore and an example looks like this:

# This vulnerability is coming from package xyz, we are ok with this for now
CVN-111 
CVN-123 # Mitigated the risk of this since we only use one method in this package and the affected code doesn't matter
CVN-543

If you want to temporarily exclude a vulnerability, the community has provided functionality for that as well:

CVN-111 until=2021-01-01
CVN-543 until=2018-02-12 #Waiting on release from third party. Should be out before this date but gives us a little time to fix it.

This can be handy if you are waiting for the upstream library to get fixed, and want to just exclude the vulnerability until a new version has been released, or just a specific time frame to remind yourself.

I love this! How do I use Nancy in CI/CD so that it runs for everything on my repo?

We got you, fam!

You can take a look at how we have used Nancy in CI/CD at the following repo: https://github.com/sonatype-nexus-community/intentionally-vulnerable-golang-project

There are examples for TravisCI and CircleCI.

There are also BitBucket pipes for Nancy, and community willing GitHub actions :)

What else?

Nancy works with Sonatype’s OSS Index by default, but also will work with Nexus Lifecycle, for improved policy driven auditing. You can get information on that here: https://github.com/sonatype-nexus-community/nancy#nexus-iq-server-options

A couple notes:

OSS Index usage is prone to rate limiting, the community goes out of their way to make sure you won’t run into this however, Nancy caches results from OSS Index for a period of 12 hours, ensuring that you only run checks against dependencies you change the version for, or results that have expired from it’s cache.

OSS Index account registration

If you register for Sonatype’s OSS Index, your rate limiting gets substantially upgraded which can be very nice if you are using Nancy in a CI/CD pipeline.

You can register for a free OSS Index account here: https://ossindex.sonatype.org/user/register

To see how to use your new registered user with Nancy, check out this portion of Nancy’s documentation. If you are reading along in this post, it’s pretty easy:

nancy config

From there decide on if you are setting OSS Index or Nexus IQ Server config, and Nancy will save it for you.

NOTE: A good portion of the OSS Index tools (jake, AuditJS, chelsea, etc…) will pick up this config if you set it once, allowing all of the tools you use to benefit from this!

Feedback

If you end up using Nancy, the community and Sonatype would love to hear your feedback, we actively work on this project, and we love to help the Golang community shift security further left!

If you run into an issue with Nancy, go ahead and file an issue on the GitHub repo, here: https://github.com/sonatype-nexus-community/nancy/issues

If you’d like to give us just general feedback, reach out to me! You can leave a comment on this article or reach out otherwise.

I want to work on this too!

Nancy is open source, and we love getting new contributors. Interested in working on Nancy with the community? Pop in to their gitter: https://gitter.im/sonatype-nexus-community/nancy or just send us a PR. Nancy is powered by community contributors, and we are all very proud of their contributions that make this tool even better!

Thanks for reading this article, and we hope you get a ton of value out of using Nancy!

Ryan Lockard Names the Seven Deadly Sins of DevSecOps

Katie McCaskey — Thu, 02 Apr 2020 13:45:00 +0000

_ Editor's Note: _ Ryan's story is included in "Epic Failures in DevSecOps, Volume 2", available for free download.

"It is said in Roman Catholicism that each of the seven deadly sins is uniquely bad. Any time one of these sins are committed, we must confess them and do all that we can to not transgress again. Applying the DevSecOps context, each of the failures discussed in this chapter are an opportunity to reflect, inspect and improve our own DevSecOps practices every day." -- Ryan Lockard, Epic Failures in DevSecOps, Chapter 7.

Watch his interview with host Justin Miller, on the Sonatype blog

SAML/SSO Authentication and Conan in Nexus Repository 3.22

Katie McCaskey — Wed, 01 Apr 2020 19:16:54 +0000

By Brent Kostak

Introducing the release of Nexus Repository 3.22. Our product teams are excited to announce SAML/SSO authentication for Nexus Repository Pro. In addition to SAML/SSO, this release includes proxy support for Conan native format in both Nexus Repository Pro users and our free version, Nexus Repository OSS. Conan is the decentralized, portable, and extensible package manager for C/C++ projects.

Amidst much anticipation, Nexus Repository Pro now provides users the ability to authenticate with Security Assertion Markup Language (SAML) identity providers. Using SAML, users can now experience single sign-on (SSO) when logging into the Nexus ecosystem. In the reading ahead, we will ‘pop the hood’ on SAML to learn how it works with Nexus Repository Pro, what benefits users can gain setting up the SAML integration, and key highlights for both Nexus Repository admins and developers.

Read more on the Sonatype blog

Developers Gain Contextual Feedback with Automated Pull Request Commenting

Katie McCaskey — Tue, 31 Mar 2020 15:14:09 +0000

At Sonatype, we work continuously to increase awareness of open source risk, and decrease the time it takes you to make your applications safe. It is our never ending quest to shift security left. We’ve rolled out even more granular and automated policy feedback with pull request comments directly in GitHub.

Developers need to know where potential policy violations or security vulnerabilities are introduced so that they can address and fix the issues efficiently and effectively. This reduces time to remediation and minimizes manual work. Our new PR commenting feature for GitHub notifies a developer when the code they commit introduces risk or breaks a build, and why.

Read more on the Sonatype blog

Department of Defense DevSecOps Journey

Katie McCaskey — Mon, 30 Mar 2020 14:15:25 +0000

By Sylvia Fronczak

_ Editors Note: _ We recently discussed why the federal government should adopt DevSecOps. Here, a look at DevSecOps efforts at the Department of Defense presented at All Day DevOps. Sign up now for the upcoming All Day DevOps | Spring Break Edition happening April 17.

The U.S. Department of Defense (DoD) has a unique DevSecOps journey, and we'll discuss that today thanks to a presentation by Hasan Yasar and Nicolas Chaillan (@NicolasChaillan).

But first, here’s some background on the DoD.

The DoD depends on software, but it doesn’t always control development. Instead, they must maintain software written elsewhere. Difficulties arise when the entire lifecycle is out of their hands.

Read more on the Sonatype blog

Sonatype Nexus Repository 3.20 Installation, Admin Login, and Port Change [VIDEO]

Katie McCaskey — Fri, 27 Mar 2020 13:45:00 +0000

There are often times in agile teams where DevOps is constrained by bandwidth.

This tutorial is aimed at developers to help them get things up and running without hassle. This will give them confidence to try out things on a working instance rather than just learning theory.

Watch the video at the Sonatype blog

Nexus Vulnerability Scanner: Getting Started with Vulnerability Analysis

Katie McCaskey — Thu, 26 Mar 2020 13:45:00 +0000

As a developer, you know the importance of building a robust application. With cyberattacks increasing every day, you should make sure your application is safe from the attacks and isn’t vulnerable.

To assess your application for security and to help you find vulnerabilities in your application so you can fix them, Nexus Vulnerability Scanner would be of great help!

So, in this post, I’ll be telling you what this tool is and how to use it.

Read more on the Sonatype blog

Top 6 Reasons the Time is Now for DevSecOps in the Federal Government

Katie McCaskey — Wed, 25 Mar 2020 13:45:00 +0000

Underpinning all modern technology - software and hardware - is a supply chain. However, even as “software eats the world,” or we could argue “ate the world,” there is still too little understanding of the software supply chain, with continued focus on hardware. The reality, however, is that software is much easier to pollute than hardware. While there has been an increase in awareness around the need for a coordinated application security strategy, the federal government has historically focused on playing strong defense, putting up walls at the perimeter, and at the end of the digital supply chain.

It’s time to shift more security resources further left. In this way, the government can play better offense at the beginning of the digital supply chain so that federal agencies can better protect themselves and the American citizenry.

Microsoft Acquires npm

Katie McCaskey — Mon, 16 Mar 2020 19:44:03 +0000

Today, news broke that GitHub and its parent company Microsoft, acquired npm and its public repository of open source JavaScript packages.

Sonatype CTO Brian Fox shares his reaction in this post, Microsoft Acquires npm: A Healthy Move for Critical Public Infrastructure.

npm audit vs auditjs

Mike Hoskins — Wed, 11 Mar 2020 23:32:37 +0000

[Full disclosure: I work for Sonatype, the company who offers OSS Index and AuditJS as free tools. We do this to give back to the OpenSource community, help raise awareness through easier access to security data, and garner interest in the extended feature set of commercial DevSecOps tooling we provide.]

Awhile back I wrote a blog post after a colleague shared a new JavaScript auditing tool called AuditJS. I wanted to update that based on more time with the tool, particularly since a new version was recently released!

AuditJS is a free tool leveraging Sonatype's OSS Index. OSSI exposes a ReST API aggregating several security vulnerability feeds including CVE, CWE and NVD. OSSI continues to evolve by adding more data sources and benefits from ongoing curation of existing feeds. The effort required to mine so much data is conveniently abstracted away as it should be by a good tool -- setup AuditJS to reap the benefits!

The 4.x release brought a lot of bug fixes and usability enhancements based on community feedback... Installation is quick and easy, if you want to run AuditJS as a NPM script just npm i auditjs -D to get started. I prefer running it via npx auditjs ossi.

You can use it as a one-off CLI or easily integrate with your CI/CD pipelines. It's possible to integrate with the commercial IQ Server (benefits from additional curation including both human and machine intelligence), but it is completely free to use with OSSI. You might want to register for a free account, but even that is not required. The one benefit of an account is removing the rate-limit which can affect larger projects. I haven't hit rate-limit issues in my typically-sized NodeJS projects. You can even submit vulnerability reports via an awesome Git-based process.

Let's see what it looks like, and talk about a couple things which might surprise you when comparing to npm audit:

➜ npx auditjs ossi
 ________   ___  ___   ________   ___   _________       ___   ________
|\   __  \ |\  \|\  \ |\   ___ \ |\  \ |\___   ___\    |\  \ |\   ____\
\ \  \|\  \\ \  \\\  \\ \  \_|\ \\ \  \\|___ \  \_|    \ \  \\ \  \___|_
 \ \   __  \\ \  \\\  \\ \  \ \\ \\ \  \    \ \  \   __ \ \  \\ \_____  \
  \ \  \ \  \\ \  \\\  \\ \  \_\\ \\ \  \    \ \  \ |\  \\_\  \\|____|\  \
   \ \__\ \__\\ \_______\\ \_______\\ \__\    \ \__\\ \________\ ____\_\  \
    \|__|\|__| \|_______| \|_______| \|__|     \|__| \|________||\_________\
                                                                \|_________|

  _      _                       _   _
 /_)    /_`_  _  _ _/_   _  _   (/  /_`_._  _   _/ _
/_)/_/ ._//_// //_|/ /_//_//_' (_X /  ///_'/ //_/_\
   _/                _//

  AuditJS version: 4.0.10

✔ Starting application
✔ Getting coordinates for Sonatype OSS Index
✔ Auditing your application with Sonatype OSS Index
✔ Submitting coordinates to Sonatype OSS Index
✔ Reticulating splines
✔ Removing whitelisted vulnerabilities

  Sonabot here, beep boop beep boop, here are your Sonatype OSS Index results:
  Total dependencies audited: 224

[1/224] - pkg:npm/@nodelib/fs.scandir@2.1.3 - No vulnerabilities found!
[2/224] - pkg:npm/@nodelib/fs.stat@2.0.3 - No vulnerabilities found!
[3/224] - pkg:npm/@nodelib/fs.walk@1.2.4 - No vulnerabilities found!
[4/224] - pkg:npm/@sendgrid/client@6.5.3 - No vulnerabilities found!
[5/224] - pkg:npm/@sendgrid/helpers@6.5.3 - No vulnerabilities found!
[6/224] - pkg:npm/@sendgrid/mail@6.5.4 - No vulnerabilities found!
[7/224] - pkg:npm/@testim/chrome-version@1.0.7 - No vulnerabilities found!
[8/224] - pkg:npm/@types/caseless@0.12.2 - No vulnerabilities found!
[9/224] - pkg:npm/@types/events@3.0.0 - No vulnerabilities found!

# Result list trimmed...

Dependency lists can obviously be long in NodeJS projects (understatement of the decade?), but the important thing is the reference to Sonatype's OSS Index (yay it's working!) as well as the ability to whitelist.

Let's say you are alerted about a vulnerability, but know it doesn’t affect you because you aren’t using the vulnerable method -- you can whitelist that! Just pass in a whitelist file containing the OSS Index IDs (the only required field, but you can add others for clarity):

➜ cat my-whitelist.json
{
  "ignore": [
    { "id": "long-oss-index-guid", "reason": "I accept the risk!" },
    { "id": "another-oss-index-guid", "reason": "We totally got this!" }
  ]
}

➜ npx auditjs ossi --whitelist my-whitelist.json

The ideal is obviously to fix all the things, but this puts control in the hands of the developer and is especially useful in larger projects or CI/CD pipelines where the risk of lower severity issues is understood and potentially annoying people or breaking builds while waiting on upstream fixes.

The other thing I want to call out is the dependency count. Above we see 224 dependencies were audited. By default, AuditJS only scans production dependencies. This is similar to --only=prod with NPM, but for AuditJS we need --dev to force scanning everything. Let's compare:

# Could also use some --json | jq fu!
➜ npx auditjs ossi 2>&1|grep -e '^\['|wc
     224    1568   14428

➜ npx auditjs ossi --dev 2>&1|grep -e '^\['|wc
     885    6195   58537

# Nothing too crazy here:
➜ jq .devDependencies <package.json
{
  "acorn": "^7.1.1",
  "acorn-jsx": "^5.2.0",
  "ajv": "^6.12.0",
  "auditjs": "^4.0.10",
  "eslint": "^6.8.0",
  "eslint-config-airbnb": "^18.0.1",
  "eslint-config-airbnb-base": "^14.0.0",
  "eslint-config-prettier": "^6.10.0",
  "eslint-plugin-import": "^2.20.1",
  "eslint-plugin-jsx-a11y": "^6.2.3",
  "eslint-plugin-node": "^11.0.0",
  "eslint-plugin-prettier": "^3.1.2",
  "eslint-plugin-promise": "^4.2.1",
  "eslint-plugin-react": "^7.19.0",
  "eslint-plugin-react-hooks": "^2.5.0",
  "jest": "^25.1.0",
  "nodemon": "^2.0.2",
  "prettier": "^1.19.1",
  "supertest": "^4.0.2"
}

Even a modest set of devDependencies requires a lot of additional scanning (~75% more in this case). AuditJS scans production dependencies by default, as these are what will get shipped with your built product, making it easier to understand the risk profile. You can add devDependencies in if you want!

Aside from scanning behavior, another place AuditJS attempts to be more efficient is in reporting. NPM will often over-inflate vulnerability reports (to be fair, we might call this erring on the side of caution). Often, with NPM, you'll see output similar to the following:

➜ npm audit

...

added 1405 packages from 1327 contributors and audited 896097 packages in 26.484s
found 18 moderate severity vulnerabilities

896,097 packages?!? Or is it 1405? What gives -- I don't write efficient code (I likes me some cowsay), but I don't see that much stuff in node_packages...

Let's break that down:

➜ npm ls --parseable | wc
    1057    1057   88307

➜ npm ls --parseable --only=prod | wc
     231     231   18007

231 is a lot closer to AuditJS' default behavior... Where did those extra packages come from? The devil is in the details, and this can lead to confusion when comparing tools... AuditJS de-dupes, so you still get warned about any critical vulnerabilities despite potentially looking like it did less work. Here's an example of how NPM reports on the same package multiple times:

➜ npm ls --parseable|grep -E 'ms$'
src/thing/node_modules/log4js/node_modules/ms
src/thing/node_modules/streamroller/node_modules/ms
src/thing/node_modules/rewire/node_modules/ms
src/thing/node_modules/eslint/node_modules/ms
src/thing/node_modules/ms
src/thing/node_modules/send/node_modules/debug/node_modules/ms
src/thing/node_modules/send/node_modules/ms
...

ms is indeed used in all these different places, but in total only three versions of it exist in my project. AuditJS only reports on the distinct coordinates it finds (2.0.0, 2.1.1, 2.1.2), whereas npm ls (and the associated npm audit commands) count multiple times if something is duplicated.

In the arms race that is security, it's nice to see new tools which help developers stay ahead of the bad guys are rapidly evolving. For your next JavaScript project, take a moment to test drive some npm audit alternatives!

Nexus Intelligence Insights: What's in a Ghostcat? CVE-2020-1938 Apache Tomcat - Local File Inclusion Potentially Leads to RCE

Katie McCaskey — Mon, 09 Mar 2020 13:45:00 +0000

By Ax Sharma

For this month’s Nexus Intelligence Insights, let’s dive deep into the popular Ghostcat vulnerability making headlines recently.

This vulnerability deserves attention as it impacts the widely used Apache Tomcat web server, has at least 5 exploits publicly available on GitHub and ExploitDB, and has a rather simple, yet overlooked, root cause. In fact,no version of Tomcat released in the last 13 years is immune to Ghostcat, unless properly patched.

The vulnerability, left unresolved, could pave an easy way for attackers to access arbitrary files on the server. The files may very well divulge sensitive information such as proprietary source code, stored passwords, API tokens, etc. More advanced PoCs can let malicious actors cause even further damage by remotely executing code on the system and planting backdoors, if they are able to get their hands on juicy bits of information.

What’s more? “Mass scanning activity targeting this vulnerability has already begun,” according to Bad Packets and evident from Shodan, thereby prompting immediate attention and a speedy remediation of this issue.