Persistent BIOS Rootkit Implant To Debut At CanSecWest 120
msm1267 writes Research on new BIOS vulnerabilities and a working rootkit implant will be presented on Friday at the annual CanSecWest security conference. An attacker with existing remote access on a compromised computer can use the implant to turn down existing protections in place to prevent re-flashing of the firmware, enabling the implant to be inserted and executed. The devious part of the exploit is that the researchers have found a way to insert their agent into System Management Mode, which is used by firmware and runs separately from the operating system, managing various hardware controls. System Management Mode also has access to memory, which puts supposedly secure and privacy focused operating systems such as Tails in the line of fire of the implant.
Their implant, the researchers said, is able to scrape the secret PGP key Tails uses for encrypted communication, for example. It can also steal passwords and encrypted communication. The implant survives OS re-installation and even Tails' built-in protections, including its capability of wiping RAM.
Their implant, the researchers said, is able to scrape the secret PGP key Tails uses for encrypted communication, for example. It can also steal passwords and encrypted communication. The implant survives OS re-installation and even Tails' built-in protections, including its capability of wiping RAM.
Socketed Firmware Here We Come (Score:4, Interesting)
It's getting to where you don't trust ANYTHING.
Re: (Score:1)
I just write all my secrets in a paper notebook. Let's see the NSA root that!
Re: (Score:3)
"Hey, can you hand me that wrench"
"Now, where were we, oh yeah, which is your favorite knee again?"
Re: (Score:2)
you should google it. make sure you're alone when you do.
Re: (Score:3)
Re:Socketed Firmware Here We Come (Score:4, Insightful)
You can't rootkit the boot ROM of early 8-bit computers. A simple power cycle and your computer is 100% clean.
Re: (Score:1)
You can't rootkit the boot ROM of early 32-bit computers. A simple power cycle and your computer is 100% clean.
We're not just talking about your Commodore 64. PCs ran for almost 20 years with ROM, not EEPROM.
Re: (Score:2)
We need to go back to BIOS stored in ROM.
Re:Socketed Firmware Here We Come (Score:4, Insightful)
more than that, we need open source bios, and full disclosure of ALL info about intel and amd chips.
lets just say, there are rumors about intel holding back design docs (so called 'yellow books') and you won't know ALL there is to know about your computer unless you get inside info about hidden cpu modes and such.
the chain of trust has so many broken links, we'd have to reinvent computers from the ground up, at this point, to be truly secure. sucks, huh?
Re: (Score:2)
What about starting at the beginning?
NASA still knows how many horsepower they need per rocket. Do we know how many 7400's we need to make an intel i7?
Re: (Score:2)
About 300 billion.
Re: (Score:2)
An i7 has about 730 million transistors. Assume that's equivalent to 200 million 2 input NAND gates or 50 million 7400 packages. Dissipation is 10 mW per gate, so a 7400 equivalent to an i7 would draw 500 kW, and probably could not reach 5 MHz. Low power Schottky (74LS00) and the use of packaged flipflops could cut the dissipation greatly, and packaged RAM even more. Don't get any more complex than that, or hidden modes could be designed into the chips.
Anyone care to make an estimate for vacuum tubes? Relay
Re: (Score:2)
We need to go back to BIOS stored in ROM.
No, we need a new, non-MS-tainted TPM that actually locks down the hardware layer with string cryptography that the owner of the device has the key to, not some DRM nonsense.
We also need to move beyond BIOS, one of these days, but maybe security-first this time?
Re: (Score:2)
As described you can't rootkit early PCs which still supported a rewritable Flash BIOS and had a jumper to enable the high voltage programming supply.
Re: (Score:2)
You swap it. The ROM would be in a socket.
Re: (Score:2)
Re: Socketed Firmware Here We Come (Score:1)
Re:Socketed Firmware Here We Come (Score:4, Informative)
Re:Socketed Firmware Here We Come (Score:5, Insightful)
Yeah, but it immensely complicates incident recovery. Rebuilding a compromised system isn't enough if you can't trust the BIOS anymore. It's only a matter of time before the compromised BIOS' adapt to re-compromise the new BIOS as it's written, so re-flashing the BIOS of a compromised computer isn't a good long-term fix.
Does this make a compromised computer basically a paperweight? That's going to turn IT into a really expensive scene really quickly.
Re: (Score:2)
Re: (Score:2)
Re: (Score:3)
Re: (Score:1, Insightful)
That's not new. Strictly speaking, you cannot trust anything. And less strictly, the same. People have been saying this since the 80's (or before, i'm not old enough to know that), and are usually called paranoia.
There are so many places malicious hard- and software can hide. So, unless you built your own computer with discrete components, and wrote your own software, there is almost no way you can verify everything.
BIOS malware is nothing new. We also seen that malware can hide at places you'd normally not
Re: (Score:2)
Early PCs with programmable Flash BIOSes often supported this via a jumper which was needed to enable the high voltage programming supply.
Re: (Score:1)
Re: (Score:2)
Write-protecting normal SPI BIOS chips is easy, as they have a write-protect pin. I expect that in the future, at least some board-manufacturers will add jumpers for these. Would also be good for network cards (at least Intel uses the same 4Mbit SPI flash chips found on most mainboards) and everything else that has firmware. I guess in the meantime, I will add these switches myself...
Of course the skills needed until all hardware with firmware has physical write-protect are non-trivial. Even just finding su
Re: (Score:1)
Re: (Score:2)
We desperately need unflashable firmwares (Score:5, Insightful)
I'm afraid of plugging my USB drives around, I'm using a fairly obscure UEFI/BIOS on my main computer in hopes that nobody has bothered to write an exploit for it yet.
But what I'd really like to see is a hardware protection against flashing. On USB, on hard drives, on the motherboard, on anything that could possibly be flashed. And no, cryptographically signed updates aren't going to cut it. It's more than feasibly to steal or crack weak keys.
Re:We desperately need unflashable firmwares (Score:5, Interesting)
This. Even if you can't stand to mar your product's sleek lines with a ghastly physical switch, would it be that hard to put a reed switch somewhere along the periphery of the device, so that nobody can flash the firmware unless you first put the Big Honking Update Magnet next to it?
Re:We desperately need unflashable firmwares (Score:4, Interesting)
Wouldn't it just be easier to have a dip switch and require cracking the case open to flash the bios? At least then, a switch can detect the case opening and send a signal to something or tick a counter that can be checked every once in a while easily.
A magnet would likely not provide the same level of obviousness. For instance, would you be noticed if you opened the case more easily than if you put a magnet on the side of the case? I know that as a kid, i was able to cut a small square of fridge magnet and combine it with a broken rare earth magnet and place on top of the reed switch for our security alarm so i could sneak out and back in without tripping our alarm system or having the record of my code being entered. Of course i had the benifit of being able to experiment by looking at the alarm pannel until the door read closed while it was open and testing it. But i do not think someone smarter than me with physical access couldn't do something similar with other tools availible. But magnets are common in the office (paperclip holders, speakers, phone parts) and not too dificult to conceal.
Re: (Score:2)
Two problems.
First, BIOS updates are made much more difficult with a switch - expecting a user to dig around to update is a support nightmare.
Also, that works great on desktops, but laptops are a significant seller (remember laptops started outselling desktop
Re: (Score:2)
Re: (Score:2)
I have never actually NEEDED to update the BIOS on any desktop or laptop gear. I only needed to do it once on server hardware that had just come out. If this is becoming a common end user procedure, there are larger problems.
Typically the switch or jumper not being flipped also prevents erasing the existing BIOS, so the consequence of the failure is you reboot and it's just like it was before.
The big problem happens when first, the system is badly designed for flash updates such that there isn't a second co
Re: (Score:2)
If the attacker has physical access to your machine, you're pretty much hosed.
I suggest a magnetic switch because it doesn't affect the external profile of the device. Apparently everybody has decided that physical switches are ugly and horrible. Fine; hide it internally, but still make it require a physical action on the device, so remote attackers can't flip it.
Re: (Score:2)
We have to remember that all physical access is not equal. Certainly if you had uncontrolled, unmonitored access it doesn't matter. But if your access is limited to 9-5 or whatever and people are always in the room when you are, a magnet is more viable then cracking the case open for stealth concerns.
Bur you are probably correct for the majoriy of situations.
Re: (Score:2)
Sure, that's a good point. Even if the Standard Update Magnet is a big, obvious device, you could make a Scamful Update Device that's a tiny but strong magnet designed to look like something innocuous leaning against the machine. But I still think it would be better than always-on reflashability.
Re:We desperately need unflashable firmwares (Score:5, Insightful)
What's infuriating is that USB drives used to come with hardware write switches and now you can't find them anywhere. And motherboards used to require you to move a jumper to flash the BIOS but, those are gone too. I don't know if it was cost cutting or a case of user stupidity or both but, the hardware write switch has faded into history. I'm fine with the being in a default-write setup as long as they had the option to cut it off.
Re: (Score:2)
SD card write switches don't physically interrupt the write circuit. They only provide an instruction to the card reader to not write (if that contact in the card slot is even present, which isn't always so). The implementation of write-protect is usually in software, too.
The SD card write switch is a bit like the write protect tabs on old cassette tapes: a polite request to a well behaved reader.
Re: (Score:2)
That's why you use a USB SD Card reader which honours the write protect in its hardware.
You don't use an on-board SD card reader.
Re: (Score:2)
One million pennies is $10,000 or less than the CEO spends on lunch.
Not claiming corporations aren't penny wise and pound foolish, just laying out the magnitude.
Re:We desperately need unflashable firmwares (Score:5, Informative)
Kanguru SS3â with Physical Write Protect Switch
High-Performance USB3.0 Flash Drive
http://kanguru.com/storage-acc... [kanguru.com]
I agree with you. WP should but the standard, not the esoteric.
Re: (Score:3)
What's infuriating is that USB drives used to come with hardware write switches and now you can't find them anywhere. And motherboards used to require you to move a jumper to flash the BIOS but, those are gone too. I don't know if it was cost cutting or a case of user stupidity or both but, the hardware write switch has faded into history. I'm fine with the being in a default-write setup as long as they had the option to cut it off.
A third possibility is that the NSA and their friends abroad might have pressured the manufacturers to remove these security features. The pressure might have subtle, like pointing out "good" places for cost savings.
Re: (Score:2)
What's infuriating is that USB drives used to come with hardware write switches and now you can't find them anywhere. And motherboards used to require you to move a jumper to flash the BIOS but, those are gone too. I don't know if it was cost cutting or a case of user stupidity or both but, the hardware write switch has faded into history. I'm fine with the being in a default-write setup as long as they had the option to cut it off.
A third possibility is that the NSA and their friends abroad might have pressured the manufacturers to remove these security features. The pressure might have subtle, like pointing out "good" places for cost savings.
As someone else mentioned, Kanguru has write protect (and I think a few others -- I have some drives by Imation and RiData that have the switch). But that doesn't necessarily protect you from something like badUSB, which can infect drive firmware.
Kanguru states their drive firmwares are protected with digital signatures. However, that means the firmwares are writeable under certain conditions, and we now know that certain organizations make it their job to steal the private keys of security vendors (you can
Re: (Score:2)
Christ ...we meet again. Are you like a Qubes developer or something because it's either that or you're REALLY a fanboy.
Is this what you're talking about: http://blog.invisiblethings.or... [invisiblethings.org]
It's an impressive idea, although it depends on the TPM which is not designed to be safe against physical attacks. There's no reason the implementation of that should only work with QubesOS, either, although the developers appear to be the same.
Re: (Score:2)
I'm not a developer, but I don't mind being called a fanboy for something like this.
And no, there's no reason why another OS couldn't use a TPM in the same way. Qubes seems to be the only one so far with this interesting feature.
Anti Evil Maid was designed initially for physical attacks, as the name implies. It does eliminate the 'Evil Maid' scenario if its assumed the attacker is unskilled and/or only has time to plug a USB or similar device into the computer. So it greatly reduces the opportunity for succ
Re: (Score:2)
A third possibility is that the NSA and their friends abroad might have pressured the manufacturers to remove these security features.
Which is not a possibility since my company ships hundreds of USB drives out with hardware write switches every week. They are extremely easy to find and buy.
Re: (Score:2)
A third possibility is that the NSA and their friends abroad might have pressured the manufacturers to remove these security features.
Which is not a possibility since my company ships hundreds of USB drives out with hardware write switches every week. They are extremely easy to find and buy.
Would you be kind enough to share the brand name(s) those USB drives are sold under, or some other way to identify them in the marketplace? I am assuming, of course, that the hardware write switch cannot be defeated by re-flashing the drive's firmware, or, if it can, that firmware flashing is also protected by a physical switch.
Re: We desperately need unflashable firmwares (Score:1)
Re: (Score:2)
old parallel scsi drives has write-protect jumpers.
never saw that in ide or sata, though.
and a jumper or switch is 90% of the time, just a software bit that can be read and ignored.
the wifi switches on some laptops, they don't stop rf or turn the power off to the wifi system. the 'switch' to a camera does not power it down, either.
Re: (Score:2)
What's infuriating is that USB drives used to come with hardware write switches and now you can't find them anywhere.
That's funny since a two-second Google search showed where I can find them on Amazon [amazon.com] and Newegg [newegg.com].
Re: (Score:2)
Part of the change at least for BIOSes stored in Flash EEPROM was that later Flash EEPROM memories implemented internal charge pumps so they could generate their own high voltage source for erasing and programming. Earlier ones required an external high voltage supply and it was that supply which a jumper could control.
Re: (Score:2)
Re: (Score:2)
I agree 100% that manufacturers should spend the extra ten cents to make things "writeable/flashable". Users will probably freak out that their flashes are flashing but the upgrade in security would be worth it. Dell would probably have to put a special button in the back that you have to hold down in order to get a flash through. The NSA, would, of course, intercept and flash the crap out of any computers going to "bad places" but they wouldn't flash everyone's computer. Right? Right? Right?
Software freedom for all software. (Score:3)
Firmware is software and computer users still need software freedom for all published software. This hasn't changed since Richard Stallman reached conclusions about the ethics of software over 30 years ago. Changing what device the software is loaded into or the form it takes when loaded doesn't change any of the underlying issues that all have to do with how people treat each other. This is also not an issue to be properly understood by "open source" focus on convenience, caving into business desires, or d
Amiga Clock virus.. (Score:3, Interesting)
UEFI bio is going to be a real hassle going forward, its going to be much easier to write something for this vs the older bios with all of its limitations. USB controller firmware, Bridge firmware, controller firmware, soon to be memory controller firmware like Power8, ethernet, ssd/hd firmware, and sound card firmware. There are a lot of places if you can inject your version during the download update to the customer where harm can be done.
Re: (Score:2)
We need a simpler computer system where each part only does one thing so that its code is simple enough to understand and each part communicates with the others via simple protocols instead of having everything concentrated in a single place. The hardware version of Unix, in a way.
Unfortunately it would make the computers bigger, slower and more power hungry so it's not going to happen.
Re:Amiga Clock virus.. (Score:4, Interesting)
But integrated parts means more complex firmwares which means more places to store trojans, viruses and spyware.
Think systemd.
Re: (Score:2)
This isn't anything new, Amiga in the 90's had a CMOS happy virus that used the battery power to stay in memory. It wasn't in the clock but rewrote that area of the working bios to stay resident. I remember having to take the battery out of my A500 to get rid of it, as it survived reboots and power offs.
I heard a rumor about the Amiga clock virus when I was an Amiga dealer in the 1990s. I didn't believe it, because I knew that the clock had too little RAM to hold a virus. Your description is much more believable.
New antivirus alert message - "Toss your mother.." (Score:2)
Dual Chip System solution (Score:1)
This could easily be avoided if there was a secondary boot rom that was only accessible by flipping a hardware switch. This bios would only allow the reflashing of the primary bios, and possibly wiping the harddrive. Once those steps were completed, you flip the switch back and are up and running. I've seen some enthusianst boards that came with multiple roms for overclocking. Perhaps this would be a similar system.
Re: (Score:2)
Bring the read only jumper back (Score:1)
I'd love to see some big corps (and government agency(ies)) responsible for removing this safety measure get screwed up big time because of it.
Re: (Score:2)
Not really. UEFI etc. is pretty standardised and one compromise could easily be found that affects an entire hardware architecture.
Similarly - if you DO get this malware, how do you disinfect if every machine you have requires a different tool/process to remove the malware (and maybe even a different tool for every malware / hardware combination, which would be even worse!)?
Unfortunate consequence of UEFI (Score:5, Insightful)
You can take a horse to the water ... (Score:3, Interesting)
People are just not getting it. They don't delete cookies or browser caches (I don't want to have login to facebook all the time) they send even the most personal or confidential data via unsecured email (why would somebody else read this email), they store their whole life or business data on dropbox, Google Drive or comparable services and they sync all of their cell phone content, phone numbers and contact data. It doesn't hurt if someone steals your data. You don't feel it, if a government monitors your every move. And the classic: I ain't got nothing to hide. CEOs told me: The government should be responsible to protect my data - why should I pay for it? Though they spent thousands of dollars on a state of the art security system for their offices - they don't feel it to be necessary to spend money to train their employees or to purchase technology to protect their data.
The Snowden leaks didn't help - quite the opposite happened: People are now saying: There's nothing one can do anyway. What the government wants, the government gets. Why bother to protect the data? Most people actually believe encryption to be worthless because the NSA can hack it anyway. In conclusion: I have stopped to try to convince the general population that they can have a safe(r) digital life. I am supporting those who really want to keep their data protected. So - before starting to worry about BIOS hacks - check the other 99.999% of vulnerabilities that are much easier to exploit. As usual: Just my two cents.
Re: (Score:2)
A lot of the reason people don't listen is that security professionals have done a great job of teaching everyone that increased security is synonymous with a slow, inconvenient, and unusable system. Sort of like that XKCD about password complexity points out.
Re: (Score:1)
Re: (Score:2)
.. well .. security usually adds complexity to point and click. That's just the way it is.
Yes... to a degree. The issue is that a lot of times the "experts" take it way too far to the point the system slows to an unusable crawl or needlessly hampers the user. To continue with your car analogy, it would be the equivalent of telling *everyone* that they need a car with a standard key lock, an electronic lock, and a password that must be entered before starting the engine (that requires an internet connection to authenticate and will disable the car after 2 incorrect entries). Eventually you cause
Re: (Score:1)
SMM was a very flawed idea... (Score:2)
... and those responsible for it at Intel should have been brought to book about it. There is NO good technical reason for its existence and it introduces a multitude of issues and not only security ones. eg: timing issues for realtime OS's, buggy firmware causing sudden crashes. Sure, it makes some things such as emulating hardware simpler but that is hardly a compelling reason to have this barn door of a security hole in every Intel motherboard.
We need a "pre-EUFI" unflashable firmware (Score:1)
I don't have a problem with EUFI or BIOS being flashable. But you need a non-changeable way of recovering your system to prevent "permanent" p0wnership or brickage.
A non-flashable "pre-EUFI" firmware that did nothing but check if a certain jumper pin was set and either proceed to boot to EUFI or boot to a non-flashable "EUFI re-flash loader" utility is a must for any computer that doesn't need to be "locked down" at the factory. This utility would look in a standard location - perhaps USB port 1 - for a si
Mitigations (Score:3)
Qubes OS will detect this type of attack [invisiblethings.org], and in most cases prevent it. It can also protect you against badUSB if you create a USBVM to handle the USB controllers.
Detection comes via the Anti-Evil Maid package, which uses a TPM to measure the system firmware, bootloader, kernel and hypervisor. It optionally can create a USB thumbdrive for booting Qubes in AEM mode. (AEM should *always* detect a compromised base system, but using a thumbdrive can help prevent an attack from succeeding in an 'Evil Maid' scenario.)
Qubes uses Xen, a type 1 bare-metal hypervisor with a miniscule attack surface, and uses that as a chokepoint to regulate ALL system activity (including network and graphics) in a way other OSes do not. Graphics is one of the weaknesses in VM host security that enables 'VM Breakout' escalation attacks. In using VMs for all sensitive functions, remote attacks are highly unlikely to escalate and take over the core system or firmware.
Re: (Score:1)
PS- Hi Timothy! :wave: Slashdot won't let me change my sig...... :D
Slides finally posted (Score:1)