This Week In Security: NPM Vandalism, Simulating Reboots, And More

We’ve covered quite a few stories about malware sneaking into NPM and other JavaScript repositories. This is a bit different. This time, a JS programmer vandalized his own packages. It’s not even malware, perhaps we should call it protestware? The two packages, colors and faker are both popular, with a combined weekly download of nearly 23 million. Their author, [Marak] added a breaking update to each of them. These libraries now print a header of LIBERTY LIBERTY LIBERTY, and then either random characters, or very poor ASCII art. It’s been confirmed that this wasn’t an outside attacker, but [Marak] breaking his own projects on purpose. Why?

It seems like this story starts back in late 2020, when [Marak] lost quite a bit in a fire, and had to ask for money on Twitter. Edit: Thanks to commenter [Jack Dansen] for pointing out an important detail that was missing. Marak was charged for reckless endangerment, and was suspected for possible terrorism aspirations, as bomb-making materials were found in his burned-out apartment. Two weeks later, he tweeted that billions were being made off open source devs’ work, citing a FAANG leak. FAANG is a reference to the big five American tech companies: Facebook, Apple, Amazon, Netflix, and Google. The same day, he opened an issue on Github for faker.js, throwing down an ultimatum: “Take this as an opportunity to send me a six figure yearly contract or fork the project and have someone else work on it.”

Respectfully, I am no longer going to support Fortune 500s ( and other smaller sized companies ) with my free work. There isn't much else to say. Take this as an opportunity to send me a six figure yearly contract or fork the project and have someone else work on it.

If you find yourself feeling sorry for [Marak], there’s a wrinkle left to turn. He hasn’t committed code to colors.js since February 2018. Another developer, [DABH] has been doing maintenance since then, up until the vandalism happened. All told, it’s a mess. Both projects on NPM have been reverted to their unmolested releases, and will likely be pivoted to official forks of the projects.

Simulated Reboots

The common wisdom is that while there are multiple iOS malware kits, produced by the likes of of NSO group, that malware can’t actually defeat Apple’s secure boot, so a phone reboot is enough to “uninstall” it. The problem with this is obvious once you hear it: You’re trusting a compromised device to actually perform a clean reboot. Researchers at ZecOps have demonstrated the ability to interrupt the reboot process in what they’re calling NoReboot. Their code hooks into the shutdown function, and instead kills the user interface. Once the power button is pressed again, the boot animation is shown, and finally a handy system command reboots userspace. Watch the demo embedded below.

No problem, right? Just use the hardware force restart function. Volume up, volume down, then hold the power button til you get the Apple logo. How long do you hold it? Until the logo shows up — right, it’s trivial to fake a forced reboot before the real one happens. OK, so to know you get a true reboot you just pull the battery… Oh.

via The Record.

Microsoft Hacks MacOS

MacOS has a feature called Transparency, Consent, and Control (TCC) that handles permissions for individual apps. This system prevents the calculator application from accessing the system’s webcam, for instance. The settings are stored in a database stored in the home directory, with strict controls preventing apps from modifying it directly. Microsoft has announced the Powerdir vulnerability, which combines a couple quirks to overcome the protection. The exploit is simple: Create a fake TCC database, and then change the user’s home directory so that spoofed database is now the active one. It’s a little more complicated than that, because a random app really shouldn’t be able to remap the home directory.

They found two techniques to make the remap work. First is the directory services binaries, dsexport and dsimport. While changing the home directory directly requires root access, this export/import dance can be done as an unprivileged user. The second technique is to provide a malicious bundle to the configd binary, which does a code-injection attack. It’s interesting to see Microsoft continue to do security research targeting MacOS. Their motivation might be less than noble, but it really does help keep all our devices more secure.

QNAP and UPnP

We’ve covered quite a few NAS vulnerabilities over the years, and I’ve noted several times that it really isn’t wise to expose appliances like this to the internet. One of the suggested explanations was UPnP, and today we have some official confirmation that this is indeed part of the problem. In a new advisory, QNAP officially recommends turning off UPnP in QNAP devices. It seems like this should have been recommended quite some time back, or better yet, these devices shipped with UPnP disabled by default. I would go a step further, and suggest turning the feature off in your router, too, unless you know that you actually need it for something.

If You Get a USB Drive in the Mail…

For goodness sake, don’t plug it in! It seems that a few companies didn’t get that memo, as there has been a successful ransomware campaign by FIN7 using just this approach. The trick is that they include an official looking letter, and maybe a gift card, tempting the receiver to plug in the USB drive to claim their loyalty reward. A 2020 campaign from the same group impersonated Best Buy, where this one claims to be from either Amazon or HHS.

You may have gathered that these flash drives are more than just flash storage. In fact, they seem to be BadUSB devices — small chips that register as HID devices and send keystrokes to the computer. Once plugged in, they open Powershell and run a malicious script, giving remote access to the attackers. If you receive one of these, or a similar attack, call the FBI or your local equivalent. Reports from companies and individuals is what leads to warning like this one.

Notable Updates

The first round of Android updates for this year is out, and there’s one standout issue, affecting a plethora of devices sporting the Qualcomm Snapdragon. CVE-2021-30285 is a critical rated vulnerability in Qualcomm’s closed source software. It’s called an “Improper Input Validation in Kernel”, but appears to be a memory management problem in the Qualcomm hypervisor. It’s rated a 9.3 on the CVSS scale, but no other details are available at this time.

VMWare’s virtualization products have been patched against CVE-2021-22045, a heap-overflow vulnerability in their virtual CD-ROM device code. Exploitation could result in a VM escape and arbitrary code run on the machine hypervisor, a worst-case scenario for VM operators. The flaw rates a 7.7, and thankfully there must be a CD image actively attached to the machine, so the workaround is pretty easy — just remove the CD drive or image.

33 thoughts on “This Week In Security: NPM Vandalism, Simulating Reboots, And More

    1. That should work from my understanding of it, however if it looks like its rebooted can you be sure even then? (For instance perhaps the system timer can be manipulated so it does the fake reboot graphic twice so you think its really done the safe full shutdown but in fact the count never reached far enough)

      Seems to me like this is perhaps the greatest argument for phones becoming more like normal computers where you can (if you know how) flash bios and data chips manually and non-destructively pretty trivially – BRING BACK THE TINY LAPTOP SCREWS! Oh and give us all the bios type details so we can flash our own etc…

      The only bit in a phone it makes any sense to lock down and be awkward about is the cellular networking stuff – and that is mostly just for legal reasons, as if you go an manually set it to frequency not in use in your area etc it doesn’t work properly for you anyway, and with the limited power available isn’t going to be that effective as a malicious jamming device, so there is no reason for a user to do so (and of course if they are broadcasting in the wrong bands etc its not actually hard to track the signal when it does cause trouble.).

      1. The reason we don’t have tiny screws and removable batteries in phones is waterproofing.
        Given how few of us would want to replace the bios chip in our phones, that seems a bad idea. I love that I’ve not had to flash a bios in over 20 years. If I want to flash a chip, I dig out an ESP32 or arduino.

        1. Waterproofing with screws involved isn’t at all challenging, its been a solved problem for a very very long time. At least for the sort of waterproofing your day to day personal electronics need, most of us are not sports divers etc..

          1. Many fob watches were waterproof and that was in the days when waterproof meant that water didn’t get into them.

            For those who haven’t heard of a fob watch … it’s a watch that is so old that you have never heard of it.

        2. Are we all divers?
          All other phones with screws and removable batteries were splash resistant which was enough for the broad audience, because not all of us are fisherman or divers.
          The main reason is: It’s cheaper!
          You don’t want to pay for software updates on older models? Simple solution: Make them unusable after a couple of years. This way you can save money on software updates on older hardware and the people buy a new product after a couple of years. It’s a win win for the cellphone companies.

          I used my old phone for over 10years. I flashed it with a new Firmware and kept it updated. The only reason I bought a new one was: The RAM-Chips on the mainboard were fright after the extensive use over a decade.

          Search online for “Agbogbloshie E-Waste” and see were your cool waterproof cellphone will end up and than think again if you really really need a waterproof phone.

  1. I’ll say it: I don’t blame the developer. I blame NPM which uses such an insecure method to update packages and the users who blindly pull code from github. Just about every Linux distro recognized this problem early on and have their own repos which do track upstream but don’t blindly pull from them.

  2. One related point to keep in mind is that after you put your code in those sites, the code belongs to them, and is not yours anymore. They can do whatever they deem fit with your code, even kicking you out of the site ( as was the case with this guy ) .

    1. github have suspended his account, thereby blocking access to all his other projects. So the guy suffered a fire, is next to homeless, nearly broke, goes a bit mad, and now has to create a new github account to fork access his own public code repositories.

      I feel bad for the guy, but I also do not like how github has reacted.

      1. Maybe I did not understand correctly what you meant, but I believe that instead of “but” it should be written “and”.

        I feel sorry for the guy, and at thte same time, I believe the project belongs to him. If he decides to change it, or delete it, is entirely right. The way things are happening, since this is not the first time that github has reinstated some software when they believe the owner did something against their interestes, is that after you use their site, and put your code ther, “all of your code belongs to them”.

        Of course, the guy could just have changed deeply the interfaces of his library, or changed the function namas, and be like apple or Microsoft and saying it is because of “reasons”. Then nobody could blame him. But we would not get to see the fireforks … :)

        1. He can remove his project, but he can’t stop others from distributing the code under the permissive license he released it under. If he wanted to, he could change the license, but anyone could fork an older version if they wanted. It wouldn’t be the first time this happened.

          In practice, changing the license would be a bit more difficult if there are other contributors, but even large projects have gone through the process successfully.

  3. The initial story is missing an important point. Marak was charged with starting the fire and having explosive devices. They guy is pretty unstable. I would also contest that this isn’t malware. It was designed to break third-party software. It would have been more reasonable, though I would argue still inappropriate, to have the package print a message about supporting opensource or whatever, but his code infinitely looped and in one case printed garbage to the console, thus intentionally breaking any software using his code.

  4. Feel rather sorry for the Dev, but at the same time if you are not actively working on one of them anymore its poor form to vandilise that one for attention, while you are working on and supporting it you have a point if the giants are making heaps and not paying for your work at all, but years later…

    Really the big tech giants should be actively supporting all such work – we used x,y,z in our products that made us a fortune, end of each year divide a fraction of that horde out among all the projects they are leveraging – its investing in better products so better sales, happier customers etc on the cheap to do it that way – you have no contracts, employment laws, HR staff or development costs for the vast number of opensource devs making your stuff better for you, probably beneficial on taxes too…

    1. “Really the big tech giants should be actively supporting all such work…”

      And people shouldn’t be pirating content, but hey free is free. If people really want others to behave a certain way, they’re going to have to do something stronger than finger-waving. Oh, like say, you’re going to heck if you don’t behave right. It’s worked so far. ;-)

  5. I wonder if the reason MS is scrutinizing MacOS so closely might be because they are working on MacOS compatibility in Windows? Soon you will be able to run Windows with a Linux box, Android box and a Mac box – they are half way there already.

  6. I am really disappointed in the article about [Marak]. Personally I know absolutely nothing about the person.

    In my country and I assume in Merica, a person has the right to trial by jury before you start insinuating criminal offenses on them.

    The linking to an article that presented numerous completely speculative opinions from people who themselves admit they barely even know the person as though it supports accusation of criminality is in very poor taste indeed.

    As for the *suggestion* about chemicals and bomb making equipment, well most of us hackers keep a range of chemicals that could easily be mistaken for “bomb making” chemicals. And the suggestion of bomb making equipment from authorities – well have a look at this – https://hackaday.com/2015/09/15/9th-grader-arrested-searched-for-building-a-clock/ – and then tell me you immediately trust all the assessments of the authorities. If that’s not enough, go find some drones at Gatwick.

    I think this column should stay on subject with security. Leave the speculation (with regard to individuals and alleged crimes) to all the trash websites that we here don’t read. Sure, if it goes to court and he/she is found guilty then you can mention it but how much does it really have to do with security anyway.

    1. It’s all about licensing. You can make it free for private use, yet paid for commercial use. It’s hard to enforce yourself, but most companies I worked for are willing to pay for those licenses. They want a commercial contract to have some warranties about it.

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.