Hardware exploits may be a sign of threats to come

Normally I spend most of my time telling readers to concentrate on the biggest security threats. Hardware threats are less likely, but every once in a while, one emerges that’s worth serious discussion, such as the recent Rowhammer vulnerability.

Rowhammer would be huge, even if we were merely talking about a software bug. But in this case, it’s hardware, which means it won’t be easy to fix.

In a nutshell, the aptly named Rowhammer, discovered by the Google Project Zero team, involves writing and rewriting bits of memory in the same locations, causing the bits to leak from one area of memory to another, bypassing most, if not all, protections currently offered by your operating system. According to the team’s post, some types of memory may be resistant to these types of attacks, but they have been able to successfully escalate privileges. It appears to work in at least some virtualized environments even better.

Should you be concerned about Rowhammer?

Yes, but I see it as more of a canary in the coalmine rather than a specific threat, for a few reasons. First, so far, it’s a privilege escalation exploit. These are interesting, but it’s the first-order, initial exploits that go viral (so to speak). Bad guys want to run code that quickly gets them past all defensive barriers. They don’t want to spend CPU cycles chaining exploits together to get to an ultimate objective. That’s for Pwn2Own contests.

Second, the bad guys aren’t too experienced at the moment with hardware exploits. They don’t need to be. The software-based tools they’re using are exploiting hundreds of millions of computers and devices just fine. Why work harder when what you’re using is working great?

Nonetheless, I don’t think most defenders spend enough time focusing on hardware exploits — they should. It’s likely hardware-based exploits will become more common in the future, especially as the Internet of things becomes a reality. Perhaps I can’t exploit your refrigerator because the limited OS it’s running doesn’t have enough code to be useful in an exploit, but bad DRAM is bad DRAM no matter where it’s used.

The worrisome part of hardware-based exploits is that the holes are harder to plug. In general, you should consider hardware and firmware as buggy and exploitable as software, but more difficult to patch, if it can be patched at all.

A great example of this is the BadUSB vulnerability. Researchers found out that most USB chip sets will run untrusted code whenever a maliciously created USB drive is inserted into a USB port. It gets past OS and antimalware software without a problem. Designs detailing how to create a malicious USB drive are all over the Internet. A child could build one.

Your defense? Basically, there is no defense. The only thing that can protect you against BadUSB is to prevent people people insert untrusted and unverified USB drives into your computers.

It isn’t like hardware bugs and possible attacks are anything new. If you have a piece of hardware that runs code, it likely has bugs, and those bugs are likely exploitable. Intel and AMD chip sets always ship with bugs, some of which become well-known and exploitable. Hardware running firmware is probably the weakest link. I can’t think of a piece of hardware with firmware that isn’t exploitable. Firmware writers do a horrible job at building security into their designs and firmware code.

I’m not talking obscure items that no one uses. Sometimes it’s the most popular goods used by everyone — here’s a recent bug related to Apple firmware. Or visit this list of hundreds of bugs to exploit based on hardware/firmware implementations from Cisco, Nokia, Ricoh, and every wireless router you’ve ever used.

RAM is often the target. The Google Project Zero team offered several previous examples of similar success, including demonstrations from 2003.

A PC memory’s data permanence issue led to successful attacks against popular encryption software, which proved you could literally freeze RAM chips with compressed air, move those chips to another computer, and access previously protected memory areas. Attackers were quick to demonstrate attacks using Fireware and DMA hardware. And let’s not forget NSA and state-sanctioned attacks, which always seem to target firmware to get around pesky OS and AV protections.

There’s no reason to worry yourself sick over hardware-based attacks in the wild. So far, they’ve been fairly rare and had limit impact on most companies. But you should be aware of their existence and start planning for them.

First, make sure to update your patch management plans to include hardware. Most companies I visit patch operating-level items well, are very hit-and-miss on third-party software, and don’t address hardware or firmware patches at all. A few companies I’ve worked with make sure every product they install has the latest code, but they don’t check it again afterward.

It also means that your inventory tracking programs need to cover hardware components and firmware versions, if they don’t already do so. The security defenders should look out for and monitor hardware bug reports, as well as determine the ultimate risk to the computers and devices under their control.

Some hardware issues should turn into action plans. For example, I know many companies who aggressively switched to BIOS and firmware versions that supported far more secure BIOS updating. I also know a few companies that updated their HP JetDirect print server cards when vulnerabilities surfaced. But most companies didn’t.

Most companies are barely aware that hardware attacks exist. They simply don’t focus on it. But when you begin to look closely at the problem, it’s a little scary — there are so many hardware devices in the average company running with exploitable code. It’s like this secondary world that gets ignored because right now the hackers, for the most part, are ignoring it.

Although hardware-based attacks are fairly rare, I’m not exaggerating when I say it’s easier to take down a company for an extended period of time by attacking its hardware rather than its software. One, we plan for all the time; the other, for the most part, isn’t even on the radar.