Slashdot Mirror
Security Industry Incapable of Finding Firmware Attackers
New submitter BIOS4breakfast writes "Research presented at CanSecWest has shown that despite the fact that we know that firmware attackers, in the form of the NSA, definitely exist, there is still a wide gap between the attackers' ability to infect firmware, and the industry's ability to detect their presence. The researchers from MITRE and Intel showed attacks on UEFI SecureBoot, the BIOS itself, and BIOS forensics software. Although they also released detection systems for supporting more research and for trustworthy BIOS capture, the real question is: when is this going to stop being the domain of research and when are security companies going to get serious about protecting against attacks at this level?"
Wrong. All an infected BIOS call needs to do is launch a process that will keep running and do its damndest when the system is up.
Excuse me, but please get off my Pennisetum Clandestinum, eh!
So... open source everything, that anyone can compile to executable. Then focus on obfuscated code, about the only avenue left for malicious code. It only takes one major manufacturer to publicly announce that "we're publishing our code so that it can be verified, unlike our competitors" for it to spread to the competitors.
What you CAN do is exploit an otherwise secure OS so that you CAN do those things in spite of OS-level security methods.
I miss the days of needing a move a jumper in order to flash the system ROM. I've seen plenty of gaudy 'overlocking' boards with push-buttons on the motherboard itself for various esoteric functions. A toggle-switch for BIOS-write-enable would be a relatively cheap addition, and manufacturers can market the board with some extra security buzzwords.
I can remember when there was a jumper on the motherboard that had to be shifted before it was possible to flash the firmware. If all motherboards had that, the only way an attacker could get malware into the BIOS (or whatever other firmware they wanted to target) would be by tricking the user into changing the jumper. Not only that, many of the users who'd be foolish enough to fall for that kind of trick wouldn't have the confidence to open up their box and play with the hardware. Not all, of course, but then, no security measure is 100% effective.
Good, inexpensive web hosting
Nice try, but it runs in ring 0, so it can jump into the kernel anywhere it wants.
Most bioses now have a complete TCP/IP stack for things like ipmi. Keylogging only requires a few simple routines to do as well; plenty of room to implement that in current flash chips on main boards.
Hiding in firmware makes you resilient and virtually undetectable on the "normal storage". A rudimentary base to pull next stage software in that will "bootstrap" the full malware once the OS installed is all that is needed. The full malware can be fragmented and re-use existing binaries so it won't be detected. You need a trusted platform and guaranteed "safe" steps to be able to reasonably trust your computer and when firmware contains holes or malicious code, there are plenty of people that don't work for the NSA that can actually build a competent attack for that.
I was promised a flying car. Where is my flying car?
Actually most BIOS (legacy or UEFI) have a network stack of some sort in order to support PXE boot. Recall that the PoC BIOS malware Rakshasa (https://media.blackhat.com/bh-us-12/Briefings/Brossard/BH_US_12_Brossard_Backdoor_Hacking_Slides.pdf) used the open source SeaBIOS and iPXE network stacks to perform networking from the BIOS. And here's a talk where some McAfee and Intel folks talked about how keylogging can be done from UEFI thanks to function pointer hooking (http://intelstudios.edgesuite.net/idf/2012/sf/aep/EFIS003/EFIS003.html I couldn't find the slides, just video) And you seem to have missed the point about spammers != state-sponsored attackers who clearly find attacking at this level plenty practical.
They're never going to fix this. It isn't just a matter of publishing source code, it affects the hardware too. It needs hardware protection on the flash, for example, so that you can control, at a hardware level (eg by a button on the device) whether the flash is writable.
But by now, all of the manufacturers are so infiltrated by other agencies, the NSA, foreign governments, and business interests (having the user in control of their own security directly contradicts the aims of DRM, not to mention marketing companies); this all conspires against ever having any security over your own firmware.
Build it yourself is probably the best bet. And the nice thing is that this is becoming more practical. The biggest problem is that there is no way to verify the hardware at the chip level, but with careful design it is possible to get reasonably good security without 100% trust in all of the individual components.
But for the overwhelming majority of people, who are not motivated or able to build their own, their tech is doomed to be compromised. I don't think there is anything that can be done about that. It is a political issue, rather than technical. And in all "democracies" that I can think of, the political will is against it.
Would that include "attacks" that allow OSs other than the officially state-approved and certificate-signed ones to be booted. Like that hacker-prone and highly illegal "Linux" thing I've been hearing about? I'm glad that researchers are protecting us against such flim-flammery and obviously dangerous stuff.
There is really no way for any code running on top of another layer to verify that lower layer's integrity - it has to rely on what is reported and a malicious BIOS or UEFI layer can simply just lie to it. Hell, it's possible for a low-level hypervisor to run another, clean, BIOS/UEFI and simply virtualize every piece of hardware in the box. Likewise, it can block visibility of any traffic going in and out that it desires. This type of security has to happen at the network level instead - something outside of the device has to detect the suspicious traffic that such an attack must generate in order to be useful. That in turn requires that the networking gear has to be trustworthy and not itself owned by the attacker or have any backdoors installed at the factory (or chip maker, or etc etc).
t we know that firmware attackers, in the form of the NSA, definitely exist, there is still a wide gap between the attackers' ability to infect firmware, and the industry's ability to detect their presence.
I bet the NSA can give a lot of incentives to companies not to look for or remove firmware back-doors - or even to introduce them. This could be carrots (lucrative contracts or info on what overseas competition is doing) or sticks (not getting the government contract or the CIO's wife finding out what he said in those phone-calls to his secretary).
Which means basically when they start intercepting hardware between the manufacturer and the user, security becomes an impossible mind fuck. Once it all shifted to firmware and hardware hacks the security game is over. Parallel networks where the inside network is fully air gapped from outside networks and the building itself is secured from wireless communications. Basically all internet function are done on disposable net books, this more for typical businesses rather than internet business. Apparently Russian security has gone back to typewriters and hard copy for the most secure documents, actual physical penetration is required. With the NSA continuing to fuck around with security, how long will it be before banks go back to manual systems and internet banking becomes a memory.
Chaos - everything, everywhere, everywhen
You're conflating a lot of things.
-Secure boot is a UEFI protocol not a Windows 8 feature
-UEFI secure boot is part of Windows 8 secured boot architecture
-Secure boot doesn’t “lock out” operating system loaders, but is a policy that allows firmware to validate authenticity of components
-OEMs have the ability to customize their firmware to meet the needs of their customers by customizing the level of certificate and policy management on their platform
-Microsoft does not mandate or control the settings on PC firmware that control or enable secured boot from any operating system other than Windows
Above is from http://blogs.msdn.com/b/b8/arc... with some modifications.
In the Intel reference UEFI implementation I have used, I could easily add and remove keys and customize it to implement the trust policy I wanted. This is up to your OEM to implement these features, nothing to do with Microsoft. For their certification program, Microsoft *requires* that SecureBoot is disableable and that the secureboot policy (list of trusted signatures) is customizable by a physically-present user. People whining that they can't install Linux on their systems because of Microsoft have no idea what they are talking about.
The problem is, firmware is *tiny*. There is only so much it can be capable of. No matter how much ingenuity the attackers will put into its programming, the attack won't be able to survive aggressive threat mitigation actions such as airgapping the computer. Even recording and monitoring all the incoming and outgoing network traffic and using the computer in a sufficiently restricted way would at least tell you if something is going on. It's like with submarines, they're only stealthy until they pump out a torpedo. If you're actually wary of what can happen with your machine or network, it would be a suicidal mission for the firmware to actually do anything detectable.
Ezekiel 23:20
Have you seen newer motherboards? They have 16mb+ of flash for the BIOS.
Oodles of room to do fun stuff in.
And they are all infested with UEFI, the worst malware foisted upon the general public in decades.
Sig Battery depleted. Reverting to safe mode.
At least one of the systems I've owned in the past required a jumper to be set before BIOS could be written to/flashed/modified.
I thought that was a boon and would certainly defeat any nefarious flashing. Something like that should be standard.