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” →

This USB Drive Will Self-Destruct After Ruining Your Computer

January 19, 2018 by Dan Maloney 35 Comments

Who would have thought that you could light up pyrotechnics on USB power? This USB keystroke injector that blows up after it’s used proves the concept.

Fully aware that this is one of those “just because you can doesn’t mean you should” projects, [MG] takes pains to point out that his danger dongle is just for dramatic effect, like a prop for a movie or the stage. In fact, he purposely withholds details on the pyrotechnics and concentrates on the keystroke injection aspect, potentially nasty enough by itself, as well as the dongle’s universal payload launching features. We’re a little bummed, because the confetti explosion (spoiler!) was pretty neat.

The device is just an ATtiny85 and a few passives stuffed into an old USB drive shell, along with a MOSFET to trigger the payload. If you eschew the explosives, the payload could be anything that will fit in the case. [MG] suggests that if you want to prank someone, an obnoxious siren might be a better way to teach your mark a lesson about plugging in strange USB drives.

While this isn’t the most dangerous thing you can do with a USB port, it could be right up there with that rash of USB killer dongles from a year or so ago. All of these devices are fun “what ifs”, but using them on anything but your own computers is not cool and possibly dangerous. Watching the smoke pour out of a USB socket definitely drives home the point that you shouldn’t plug in that thumbdrive that you found in the bathroom at work, though.

Continue reading “This USB Drive Will Self-Destruct After Ruining Your Computer” →