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.
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.
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.
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.
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.
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].
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.
At this year’s BlackHat Asia security conference, researchers from Cylance disclosed two potentially fatal flaws in the UEFI firmware of Gigabyte BRIX small computers which allow a would-be attacker unfettered low-level access to the computer.
Gigabyte has been working on a fix since the start of 2017. Gigabyte are preparing to release firmware updates as a matter of urgency to only one of the affected models — GB-BSi7H-6500 (firmware vF6), while leaving the — GB-BXi7-5775 (firmware vF2) unpatched as it has reached it’s end of life. We understand that support can’t last forever, but if you sell products with such a big fault from the factory, it might be worth it to fix the problem and keep your reputation.
The two vulnerabilities that have been discovered seem like a massive oversight from Gigabyte, They didn’t enable write protection for their UEFI (CVE-2017-3197), and seem to have thrown cryptography out of the window when it comes to signing their UEFI files (CVE-2017-3198). The latter vulnerability is partly due to not verifying a checksum or using HTTPS in the firmware update process, instead using its insecure sibling HTTP. CERT has issued an official vulnerability note (VU#507496) for both flaws.
Attackers may exploit the vulnerabilities to execute unsigned code in System Management Mode (SMM), planting whatever malware they like into the low level workings of the computer. Cylance explain a possible scenario as follows:
The attacker gains user-mode execution through an application vulnerability such as a browser exploit or a malicious Word document with an embedded script. From there, the attacker elevates his privileges by exploiting the kernel or a kernel module such as Capcom.sys to execute code in ring 0. A vulnerable SMI handler allows the attacker to execute code in SMM mode (ring -2) where he finally can bypass any write protection mechanisms and install a backdoor into the system’s firmware.
With all this said, it does raise some interesting opportunities for the hacker community. We wonder if anyone will come up with a custom UEFI for the Brix since Gigabyte left the keys in the door.