Supply Chain Attack: NPM Library Used By Facebook And Others Was Compromised

ua-parser-js compromised

Here at Hackaday we love the good kinds of hacks, but now and then we need to bring up a less good kind. Today it was learned that the NPM package ua-parser-js was compromised, and any software using it as a library may have become victim of a supply chain attack. What is ua-parser-js and why does any of this matter?

In the early days of computing, programmers would write every bit of code they used themselves. Larger teams would work together to develop larger code bases, but it was all done in-house. These days software developers don’t write every piece of code. Instead they use libraries of code supplied by others.

For better or worse, repositories of code are now available to do even the smallest of functions so that a developer doesn’t have to write the function from scratch. One such registry is npm (Node Package Manager), who organize a collection of contributed libraries written in JavaScript. One only need to use npm to include a library in their code, and all of the functions of that code are available to the developer. One such example is ua-parser-js which is a User Agent Parser written in JavaScript. This library makes it easy for developers to find out the type of device and software being used to access a web page.

On October 22 2021, the developer of ua-parser-js found that attackers had uploaded a version of his software that contained malware for both Linux and Windows computers. The malicious versions were found to steal data (including passwords and Chrome cookies, perhaps much more) from computers or run a crypto-currency miner. This prompted GitHub to issue a Critical Severity Security Advisory.

What makes this compromise so dangerous is that ua-parser-js is considered to be part of a supply chain, and has been adopted even by Facebook for use in some of its customer facing software. The developer of ua-parser-js has already secured his GitHub account and uploaded new versions of the package that are clean. If you have any software that uses this library, make sure you’ve got the latest version!

Of course this is by no means a unique occurrence. Last month Maya Posch dug into growing issues that come from some flaws of trust in package management systems. The art for that article is a house of cards, an apt metaphor for a system that is only as stable as the security of each and every package being built upon.

26 thoughts on “Supply Chain Attack: NPM Library Used By Facebook And Others Was Compromised

    1. You’re just validating their success by squandering your own time and resources. They will just move on to their next target and ignore you or block you, they have firewalls too. Besides all that youd also be breaking the law. Two wrongs don’t make a right.

      This needs to be handled by people who have guns and arrest warrants and handcuffs. Its terrorism and the perps should be stuffed into a deep dark hole. If blowing up a bridge is terrorism then this is also terrorism.

      1. Maybe fake data and false shares (deception) can be a new kind of Gun? and perhaps DDOS warrants can become a thing (permission for authorities to DDOS back!) In this case blowing up a bridge is a bad analogy – as that still hurts people. But Cyber weapons and cyber “destruction” is quite a bit different.

    1. Correct. Only really minimal system can be properly audited and fully certified re security. Anything else is just not going to work.

      Every program running is a security risk.

  1. The only thing that surprises me is that this doesn’t happen a lot more often.

    As for ‘the early days…’ – some of us still work that way exactly because of these sorts of security risks.

  2. “Any computer that has this package installed or running should be considered fully compromised.” So basically if had it on my server, I would have to do a clean reinstall and if somebody used it in their web app that I accessed, my password for that site is probably compromised. 7.8 million weekly downloads of that library. The attackers hit the jackpot.

  3. There should be a death penalty for propagators of viruses, trojans, spyware and malware.

    The only problem is google is the #1 source for viruses, trojans, spyware and malware.

    1. 2FA can actually end up in worse security though – because its 2FA its ‘safe’ so the human doesn’t think about how stupid it is to make that 2nd factor x in this case, or use the same 2nd factor for everything so if that is compromised everything else might be (or at least easily be) too…

      Not saying 2FA is bad as a concept, just it isn’t magically better than simply having a good long complex password that changes regularly etc, you still have to use it correctly…

      1. It absolutely IS magically better than having a good, long complex password that changes regularly.
        1. Changing a password regularly doesn’t do much. It only helps in the unlikely event that attackers steal your password without you knowing AND it takes them a long time to exploit it.
        2. 2FA magically makes everything better, because it does loads to help against attacks that don’t care about your password length – phishing, keyloggers, etc. And before you say that you don’t open suspicious emails – NOBODY is fully immune to phishing. I work a student job for a university IT department and the phishing attempts I’ve seen are absolutely spectacular.
        3. Choosing a long, complex password and changing it regularly is almost always worse for security, because few people can actually remember that many passwords and change them that often. Imposing such restrictions leads to people slipping and reusing passwords, using common substitutions, etc.

        1. That is what offline password managers are for! Or in XKCD method memorable but PITA to crack passwords like ‘CorrectHorseBatteryStaple’ – long doesn’t have to be hard to remember, I saw that XKCD a grand total or once (most likely – I do sometimes hit random a few times), sometime around the day it came out, but its fun and memorable as an idea so it sticks well….

          Nothing is immune to compromise, and doing a simple password system right, protects against most things very well, doing 2FA badly – which most 2FA really is, being on the smartphone all your other secrets are on, along with god knows what other applications and your password might well even be cached on!!! for instance really isn’t secure at all either – it just has different weakest links!

          Also your password should not be the keys to everything, so all they can do if they manage to crack or log a password is try that password against everywhere else and find you don’t reuse your passwords on top of access whatever that is, and smart attackers are not going to trash whatever they get access to as soon as they do, as they will hope you use the now compromised system to give them more clues to breaking into your juicer targets, and that is where changing passwords regularly enough helps – it cuts down on the window they have access to keep snooping for more.

  4. “The developer of ua-parser-js has already secured his GitHub account and uploaded new versions of the package that are clean. ”

    And of course, why wasn’t it secured before? Makes one wonder if security is being taught in schools to budding programmers?

    1. You know… the current recommendation is to “not reinvent the wheel” (specially for security related matters), developers are advised to rely on libraries written by other, more experienced developers and reviewed by the community.

      The problem is that popular libraries are frequently written by regular or even below average developers and earn their popularity due to a easy to find name.
      Also people look at 5M/week download rate and assume that “someone surely reviewed it”.

      1. Forgot to mention…

        Due to javascript lack of a standard framework and the bare-bones nature of what is available by default to the language, you can easily import 1 dependency and have 10 sub-dependencies each with their own sub-dependencies injected into your code base.

        This matroska of dependencies obfuscates what you are importing and makes it nearly impossible to do a complete review on modern, popular javascript frameworks or toolkits

        Even if today you review every single dependency, tomorrow one of the dozens, sometimes even hundreds of libraries in your project will get an updated version, possible with new dependencies or different versions of the same dependencies and you will have to validate everything again.

        Example of this madness: is-even (178,327 downloads/week) depends on is-odd (432,499 downloads/week) depends on is-number (53,385,654 downloads/week)

        I am not even joking, is-number is a real library, not a function of the language nor part of the basic framework/toolkit for the language

    2. Your front door was locked, but I walked up and opened it – maybe I’m lockpickinglaywer, or maybe I just duplicated your key. I then edited your diary, switched the sofa cushions around and replaced your dairy and meat with vegan ‘replacements’, of course when you notice you are going to change the lock, maybe add a second and ‘secure’ your house again…

      Doesn’t mean it wasn’t ‘secure’ before, as it was supposed to be – Just somebody in this story me, figured out a way to get in that didn’t immediately scream somebody broke in, so for those few days/ weeks/ months before somebody noticed I was getting away with it – and anybody that then read your diary, sat on their spot on the sofa, ate your dairy would find a surprise…

      Security most likely is taught, but no matter how secure something is supposed to be somebody determined enough will be able to find the right combination of lock picking tools – be they hardware, software or social engineering to get in eventually… Which is why you should change your passwords etc often, so any compromises of one section of your security hopefully doesn’t last long enough for them to breach all the others.. But nobody does that for something like a Github account – its recoverable, your older code will still be there, and you probably have it all stored locally and being tech savvy backed up too…

      1. “But nobody does that for something like a Github account – its recoverable, your older code will still be there, and you probably have it all stored locally and being tech savvy backed up too…”

        One very important reason for a Githubber to do so. If my house is compromised I’m the only one that suffers. If a Github account is compromised… well we have the lead story.

        1. Didn’t say they shouldn’t just that nobody does, as the cost to them in hassle dealing with paranoid level security is at a continuing high level vs no cost at all if they don’t. Why care about the inconvenience to those built off the same code base and have pulled in the poisoned update – if you are getting paid a fortune to provide a critical service the hassle of high security is perhaps worth it, when you just made a library everyone is using and nobody is paying you, you have more important things to do in your life than waste hundreds of man hours a year changing passwords, and dealign with multi-factor authentication for something that is effectively a hobby…

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.