Nine years ago, I created what I believe was the world’s first USB worm. By playing around with a USB thumb drive and placing a hidden file on it, I was able to make any computer in which the “infected” USB drive was plugged into automatically spread the file to the host computer, then back again when a new USB device was plugged in.
It worked in digital cameras and mobile phones. I was able to get any USB device — in fact, any removable media device — to run my worm file. I had a bunch of fun playing with it.
I reported the finding to my employer and the involved vendors; they in turn asked for my silence for a significant amount of time, so they could close the hole. I had planned on presenting my finding at a big national security conference and had to choose between earned hacker cred and public safety. I went with the latter.
Truth be told, I didn’t want to piss off this vendor because it was a possible future customer or employer. The hole was patched, and the public was none the wiser. Many years later, I was surprised to see a very similar method used in the Stuxnet malware program.
But my experience made me never trust a plugged in device again. Since then, I have never plugged in a USB device or removable media card into a computer I owned that did not originate and remain under my control. Sometimes, paranoia is appropriate.
BadUSB is a serious threat now out in the wild
That brings me to today. There’s now posted on GitHub the source code for BadUSB (not to be confused with faux malware program called BadBIOS), which makes my experiment nine years ago look like a child’s game. BadUSB is a real threat that has serious consequences for computer hardware input devices.
BadUSB writes — or overwrites — a USB device’s firmware code to carry out malicious actions. First announced in July 2014, BadUSB was discovered by a pair of computer researchers at Security Research Labs in Berlin, who then demoed their discovery at the Black Hat Conference.
The attack is feared because all the traditional methods of checking for malice on a USB storage device do not work. The malicious code is planted in the USB’s firmware, which is executed when the device is plugged into a host. The host can’t detect the firmware code, but the firmware’s code can interact with and modify software on the host computer.
The malicious firmware code could plant other malware, steal information, divert Internet traffic, and more — all while bypassing antivirus scans. The attack was considered so viable and dangerous that the researchers only demoed the exploit. In an abundance of caution, they didn’t release the proof-of-concept code or infected devices. But two other researchers reverse-engineered the exploit, created demonstration code, and released it to the world on GitHub.
Cue the drama that has already appeared on news and consumer tech sites like CNN, the Atlanta Journal-Constitution, the Register, and PC Magazine, exclaiming, “The world is going to be full of malicious USB devices!”
Why the BadUSB exploit goes way beyond USB
First, it’s important to recognize that the threat is real. USB firmware can be modified to do what the research scientists claim. Hackers all around the world are probably downloading the proof-of-concept code, making malicious USB devices, and using the proof-of-concept code as a launching point for acts far more malicious than the researchers’ test exploit.
Second, the problem isn’t limited to USB devices. In fact, USB devices are the tip of the iceberg. Any hardware device plugged into your computer with a firmware component can probably be made malicious. I’m talking FireWire devices, SCSI devices, hard drives, DMA devices, and more.
For these devices to work, their firmware has to be inserted into the host device’s memory where it is then executed — so malware can easily go along for that ride. There may be firmware devices that can’t be exploited, but I don’t know a reason why not.
Firmware is inherently nothing more than software instructions stored on silicon. At its basic level, it’s nothing but software programming. And firmware is necessary to enable the hardware device to talk to the host computer device. The device’s API specification tells the device’s programmers how to write code that makes the device work properly, but these specifications and instructions are never assembled with security in mind. Nope, they were written to get items to talk to each other (much like the Internet).
It doesn’t take many programming instructions to enable malicious activity. You can format most storage devices or “brick” a computer with a handful of directions. The smallest computer virus ever written was a mere 35 bytes in size. The payload in the GitHub proof-of-concept example is only 14K, and it includes lots of error checking and finesse coding. Believe me, 14K is tiny in today’s world of malware. It’s easy to embed and hide malware in any almost firmware controller.
In fact, there’s a very good chance that hackers and nations have long known about and used these firmware backdoors. NSA watchers have speculated at length about such devices, and these suspicions were confirmed by recently released NSA documents.
The scary truth is that hackers have been hacking firmware devices and forcing them into unauthorized actions for as long as firmware has been around.
BadUSB is the biggest threat you can be take off your panic list
The reality is you should have been at least nervous about any firmware device plugged into your computer — USB or otherwise — for a long time. I’ve been that way for nearly a decade.
Your only defense is that you plug in firmware devices from vendors you trust and keep them under your control. But how do you know the devices you’ve been plugging in haven’t been compromised en masse or haven’t been tampered with between the vendor and your computers? The leaks from Edward Snowden suggest the NSA has intercepted computers in transit to install listening devices. Surely other spies and hackers have tried the same tactics to infect components along the supply chain.
Still, you can relax.
Malicious hardware is possible, and it may be used in some limited scenarios. But it’s unlikely to be widespread. Hardware hacking isn’t easy. It’s resource-intensive. Different instruction sets are used for different chip sets. Then there’s the pesky problem of getting the intended victims to accept the malicious devices and insert it into their computers. For very high-value targets, such “Mission Impossible”-style attacks are plausible, but not so much for the average Joe.
Today’s hackers (including the spy agencies in the United States, the United Kingdom, Israel, China, Russia, France, Germany, and so on) enjoy far more success using traditional software infection methods. For example, as a hacker, you can build and use a supersophisticated and supersneaky Blue Pill hypervisor attack tool or go with a common everyday software Trojan program that has worked well for decades to hack a much larger number of people.
But suppose malicious firmware or USB devices started to appear broadly? You can bet that vendors would respond and solve the problem. BadUSB has no defense today, but it could be easily defended against in the future. After all, it’s simply software (stored in firmware), and software can defeat it. The USB standards bodies would probably update the specification to prevent such attacks, microcontroller vendors would make malice less likely to occur from firmware, and operating system vendors would probably respond even sooner.
For example, some operating system vendors now prevent DMA devices from accessing memory before a computer fully boots or before a user logs ins, solely to prevent discovered attacks coming from plugged-in DMA devices. Windows 8.1, OS X (via Open Firmware passwords), and Linux have defenses against DMA attacks, though they typically require users to enable those defenses. The same sorts of defenses will be implemented if BadUSB becomes widespread.
Don’t fear BadUSB, even if a hacker friend decides to play a trick on you using his maliciously encoded USB thumb drive. Do like me — don’t use USB devices that haven’t been under your control at all times.
Remember: If you’re worried about being hacked, be far more worried about what runs in your browser than what runs from your firmware.
View the original article here