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

October 22, 2021 by Ryan Flowers 26 Comments

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.

FBI Reports On Linux Drovorub Malware

August 22, 2020 by Al Williams 26 Comments

The FBI and the NSA released a report on the Russian-based malware that attacks Linux known as Drovorub (PDF) and it is an interesting read. Drovorub uses a kernel module rootkit and allows a remote attacker to control your computer, transfer files, and forward ports. And the kernel module takes extraordinary steps to avoid detection while doing it.

What is perhaps most interesting though, is that the agencies did the leg work to track the malware to its source: the GRU — Russian intelligence. The name Drovorub translates into “woodcutter” and is apparently the name the GRU uses for the program.

A look inside the code shows it is pretty mundane. There’s a server with a JSON configuration file and a MySQL backend. It looks like any other garden-variety piece of code. To bootstrap the client, a hardcoded configuration allows the program to make contact with the server and then creates a configuration file that the kernel module actively hides. Interestingly, part of the configuration is a UUID that contains the MAC address of the server computer.

The rootkit won’t persist if you have UEFI boot fully enabled (although many Linux computers turn UEFI signing off rather than work through the steps to install an OS with it enabled). The malware is easy to spot if you dump raw information from the network, but the kernel module makes it hard to find on the local machine. It hooks many kernel functions so it can hide processes from both the ps command and the /proc filesystem. Other hooks remove file names from directory listings and also hides sockets. The paper describes how to identify the malware and they are especially interested in detection at scale — that is, if you have 1,000 Linux PCs on a network, how do you find which ones have this infection?

This is a modern spy story, but not quite what we’ve come to expect in Bond movies. “Well, Moneypenny, it appears Spectre is using the POCO library to generate UUIDs,” is hard to work into a trailer. We prefer the old days when high-tech spying meant nonlinear junction detectors, hacking Selectrics, moon probe heists, and passive bugging.

Hiding Malware, With Windows XP

May 22, 2020 by Jenny List 20 Comments

In the nearly four decades since the first PC viruses spread in the wild, malware writers have evolved some exceptionally clever ways to hide their creations from system administrators and from anti-virus writers. The researchers at Sophos have found one that conceals itself as probably the ultimate Trojan horse: it hides its tiny payload in a Windows XP installation.

The crusty Windows version is packaged up with a copy of an older version of the VirtualBox hypervisor on which to run it. A WIndows exploit allows Microsoft Installer to download the whole thing as a 122 MB installer package that hides the hypervisor and a 282 MB disk image containing Windows XP. The Ragnar Locker ransomware payload is a tiny 49 kB component of the XP image, which the infected host will run on the hypervisor unchallenged.

The Sophos analysis has a fascinating delve into some of the Windows batch file tricks it uses to probe its environment and set up the connections between host and XP, leaving us amazed at the unorthodox use of a complete Microsoft OS and that seemingly we have reached a point of system bloat at which such a large unauthorised download and the running of a complete Microsoft operating system albeit one from twenty years ago in a hypervisor can go unnoticed. Still, unlike some malware stories we’ve seen, at least this one is real.

Side-Channel Attack Turns Power Supply Into Speakers

May 11, 2020 by Dan Maloney 12 Comments

If you work in a secure facility, the chances are pretty good that any computer there is going to be stripped to the minimum complement of peripherals. After all, the fewer parts that a computer has, the fewer things that can be turned into air-gap breaching transducers, right? So no printers, no cameras, no microphones, and certainly no speakers.

Unfortunately, deleting such peripherals does you little good when [Mordechai Guri] is able to turn a computer power supply into a speaker that can exfiltrate data from air-gapped machines. In an arXiv paper (PDF link), [Guri] describes a side-channel attack of considerable deviousness and some complexity that he calls POWER-SUPPLaY. It’s a two-pronged attack with both a transmitter and receiver exploit needed to pull it off. The transmitter malware, delivered via standard methods, runs on the air-gapped machine, and controls the workload of the CPU. These changes in power usage result in vibrations in the switch-mode power supply common to most PCs, particularly in the transformers and capacitors. The resulting audio frequency signals are picked up by a malware-infected receiver on a smartphone, presumably carried by someone into the vicinity of the air-gapped machine. The data is picked up by the phone’s microphone, buffered, and exfiltrated to the attacker at a later time.

Yes, it’s complicated, requiring two exploits to install all the pieces, but under the right conditions it could be feasible. And who’s to say that the receiver malware couldn’t be replaced with the old potato chip bag exploit? Either way, we’re glad [Mordechai] and his fellow security researchers are out there finding the weak spots and challenging assumptions of what’s safe and what’s vulnerable.

Continue reading “Side-Channel Attack Turns Power Supply Into Speakers” →

Using An FPGA To Glitch The Olimex LPC-P1343

April 30, 2020 by Sharon Lin 2 Comments

After trying out hardware hacking using an FPGA to interface with target hardware, [Grazfather] was inspired to try using the iCEBreaker (one of the many hobbyist FPGAs to have recently flooded the market) to build a UART-controllable glitcher for the Olimex LPC-P1343.

FPGA Modules (The **cmd** module intercepts what the host computer sends over UART, the **resetter** holds the reset line until the target is reset, the **delay** starts counting on reset and waits for a configured number of cycles before sending its signal, the **trigger** waits for the delay to finish before telling the pulse module to send a pulse, and the **pulse** works similar to the delay module and outputs to the power multiplexer.)

When the target board boots up, the bootROM reads the flash and determines whether the UART goes to a shell and if the shell can be used to read out the flash. This is meant for developing firmware and debugging it in the bootloader, only flashing a version when the firmware is production-ready. The vulnerability is that only a specific value read from address 0x2FC and the state of a few pins can lock the bootloader in the expected way, and any other value at the address causes the bootROM to consider the device unlocked. Essentially, the mechanism is the opposite of how a lock ought to work.

The goal is to get the CPU to misread the flash at the precise moment it is meant to be reading the specific value, then jumping to the bootloader in the unlocked state. The FPGA can be used as a tool between the host machine and target board, communicating via UART. The FGPA can support configuring the delay between resetting the target board and pulsing a ‘glitch voltage’, as well as resetting the target board and activating the glitch. The primary reasons for using the FPGA over a different microcontroller are that the FPGA allows for precise timing (83.3ns precision) and removes worries about jitters (a Raspberry Pi might have side effects from OS scheduling and other processes and microcontrollers might have interrupts messing up the timing).

To simulate the various modules, [Grazfather] used Icarus Verilog as well as GTKWave to observe the waveforms generated. A separate logic analyzer observes the effects on real hardware.

With enough time, it is possible to brute force any combination of delay and width until you get a dump of the flash you’re not meant to read. You can check out how the width of the pulse gets wider until the max, when the delay is incremented and the width values are tried again.

Continue reading “Using An FPGA To Glitch The Olimex LPC-P1343” →

Source Of Evil – A Botnet Code Collection

September 9, 2018 by Sven Gregori 9 Comments

In case you’re looking for a variety of IRC client implementations, or always wondered how botnets and other malware looks on the inside, [maestron] has just the right thing for you. After years of searching and gathering the source code of hundreds of real-world botnets, he’s now published them on GitHub.

With C++ being the dominant language in the collection, you will also find sources in C, PHP, BASIC, Pascal, the occasional assembler, and even Java. And if you want to consider the psychological aspect of it, who knows, seeing their malicious creations in their rawest form might even give you a glimpse into the mind of their authors.

These sources are of course for educational purposes only, and it should go without saying that you probably wouldn’t want to experiment with them outside a controlled environment. But in case you do take a closer look at them and are someone who generally likes to get things in order, [maestron] is actually looking for ideas how to properly sort and organize the collection. And if you’re more into old school viruses, and want to see them run in a safe environment, there’s always the malware museum.

Someone Set Us Up The Compiler Bomb

June 3, 2018 by Al Williams 43 Comments

Despite the general public’s hijacking of the word “hacker,” we don’t advocate doing disruptive things. However, studying code exploits can often be useful both as an academic exercise and to understand what kind of things your systems might experience in the wild. [Code Explainer] takes apart a compiler bomb in a recent blog post.

If you haven’t heard of a compiler bomb, perhaps you’ve heard of a zip bomb. This is a small zip file that “explodes” into a very large file. A compiler bomb is a small piece of C code that will blow up a compiler — in this case, specifically, gcc. [Code Explainer] didn’t create the bomb though, that credit goes to [Digital Trauma].

Continue reading “Someone Set Us Up The Compiler Bomb” →