Security Industry Incapable of Finding Firmware Attackers 94
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?"
Least interest (Score:1)
The thing is, while these are the hardest to fix and address of attacks, they're among the least useful for attackers. You can't spam people from BIOS. You can't really keylog and transmit over TCP from BIOS.
The operating system is as useful to attackers as it is to us other programmers.
Re: (Score:3, Insightful)
Re: (Score:3)
Re: (Score:2)
Have you seen newer motherboards? They have 16mb+ of flash for the BIOS.
Oodles of room to do fun stuff in.
Re:Least interest (Score:4, Funny)
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.
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
Also worth noting is it depends on the particular device being targeted. For example, the firmware in the SCADA systems Stuxnet targeted is completely reliant on the PC connected to it. Disable the PC and you effectively disable the malwa
Re: (Score:1)
Yes you can.
Especially if the system is attached to a network with a DHCP server.
UEFI is equivalent to an OS, and is written the same way.
BIOS is a little bit more limited - but not much. You can include a DHCP client to get a local IP number.
Re: (Score:2)
Big problem with BIOS is that it is board/chipset-specific. And very tiny. Not un-doable, but not scalable.
These were some of the BIOS constraints that EFI/UEFI were created to surpass.
Re:Least interest (Score:4, Interesting)
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.
Re:Least interest (Score:5, Insightful)
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.
Re: (Score:2)
and internet banking becomes a memory.
That depends. No level of compromising your (general purpose) computer should be able to defeat the security of your manually operated hardware token/calculator.
Re: (Score:2)
and internet banking becomes a memory.
That depends. No level of compromising your (general purpose) computer should be able to defeat the security of your manually operated hardware token/calculator.
Attacker has control of my computer. I read a number off my MFA device and input it into the bank's form along with my username and password.
Now attacker has a banking session they can do whatever they want with. How has having a hardware token prevented them from attacking me?
Re: (Score:2)
Re:Least interest (Score:4, Informative)
Nice try, but it runs in ring 0, so it can jump into the kernel anywhere it wants.
Re: (Score:2)
Seconded. Hear, hear!
Re: (Score:1)
Nice try, but it runs in ring 0, so it can jump into the kernel anywhere it wants.
Worse than that after boot, the BIOS runs in System Management Mode, which is delberatly designed to be non-interceptable by the OS.
Re: (Score:2)
The NSA implant known as SOUFLETROUGH allegedly uses SMM and is even referenced on the SMM page on Wikipedia [wikipedia.org].
Re: (Score:2)
Re: (Score:2)
The BIOS has bare back access to the hardware. Why cant it log the keyboard and dump it out the Ethernet? Why cant it access the ram directly?
The term you were looking for is "bare metal".
Bare back is something totally different.
Re: (Score:2)
Then there are remte admin tools such as Intel AMT (Score:2)
The BIOS has bare back access to the hardware. Why cant it log the keyboard and dump it out the Ethernet? Why cant it access the ram directly?
Built-in threats include more than just BIOS. At least one, and probably most, chip makers build in backdoors that do exactly what you describe, and much more. It's built right into the silicon, too.
Modern laptops and desktops come with remote administration tools built into the chips on the board. (The vendors tout this as a feature, simplifying administration of a
But you can and it's useful (Score:5, Insightful)
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.
Re: (Score:2)
Re: (Score:2)
On some machines, they have out of band management features, even dedicated NICs for this purpose. Get full access to a BIOS, and the machine can easily have a functioning IP stack and be at the control of an attacker even if the machine has no OS present.
Another item would be a flashable BIOS like a security issue with some Apple keyboards. Nothing beats using the keyboard controller itself for a keylogger.
Re: (Score:2)
Re: (Score:2)
Re: Very wrong (Score:1)
Re: Least interest (Score:1)
So we should call it 'infirmware' ? (Score:1)
Because you know, if it isn't secure, then it's not firm.
Re: (Score:2)
.... then it's not firm.
No, it's too easy ...
write protect (Score:2)
Re: (Score:1)
The important write protects are whether the BIOS configures itself as locked or not after it's booted far enough to determine there are no BIOS updates pending. You can check if your BIOS is open or closed to attackers by running Copernicus [mitre.org] or Chipsec [github.com].
Duh, what should we do? (Score:3)
Re:Duh, what should we do? (Score:4, Interesting)
You know who reviews open source code seriously? Fucking nobody.
Oh, I dunno 'bout dat. I recall a few years ago, getting an informative email from one of djb's folks, telling me how to exploit an open-source program that I was using in the software behind a web site that I was responsible for. I ran their test, dug into the code and fixed the problem (and several similar problems in other parts of the code), and sent them a nice letter thanking them for their help. I also forwarded their email and my patches to the author of the program, but I didn't hear back from him.
This only fails to qualify as "seriously" if you dismiss all of academia as not serious. In reality, that's where you'll find most of the people who take security seriously. You don't much find them in "industry" (as the summary puts it), for management reasons that are well-understood by pretty much anyone who has ever tried to get security problems fixed in a corporate-management environment.
Re: (Score:2)
You know who reviews open source code seriously?
Fucking nobody.
What!? You call the NSA "fucking nobody"? Maybe nobody will fuck them, but that's different...
Re: (Score:1)
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.
OEM1 releases full source
OEM2 fires all BIOS developers and leeches off OEM1
OEM1 has the privilege of maintaining a BIOS development workforce for the benefit of their competitors
Though maybe that would work as a feint to eventually put competitors at a disadvantage ;-)
Also, believe it or not, OEMs and places like AMI, Phoenix, etc do actually try to add features down at the firmware level that their competitors don't have, to differentiate themselves and hopefully get a few more sales. E.g. recall th
Re: (Score:2)
Yep, that's why everyone just uses Windows now, since it's freely available thanks to Microsoft releasing the full source code in their Shared Source program. When that happened, other companies just took it and sold it as their own.
Oh wait, that never happened.
Re: (Score:2)
Nah, competitors will steal your code and put you out of business. And publishing your code is more or less meaningless unless there's a legion of qualified people willing to examine it. And why would they do that? What's in it for them? Aside from a few big FOSS projects (Linux, et. al.), the only people looking at your code are either miscreants, your competitors, or your country's competitors.
Joe Sixpack: I wanna buy a router for my XP machines.
Eve Clerk: Well, here's a Cisco router, it works well. And h
Use a jumper (Score:4, Funny)
Re: (Score:3)
While I am not an expert, I don't believe that we're just talking about reflashing here. It is possible that the firmware relied on to perform operating system functions in exploited all the way back in user-space. Some program gets some arguments from somewhere that get passed on to the kernel level, the kernel then passes that to the hardware and voila, exploited.
Re: (Score:2)
Re: (Score:2)
And what do the drivers communicate with? The firmware.
Your normal device will provide a memory mapped structure to the device where values are read and stored. They use IOCTLs to command the hardware usually through interrupts. The Firmware has the corresponding data structure on its side. I'm not an expert but I have written a kernel driver or two, but not recently.
Re: (Score:3)
Well yes, of course. However, drivers tend to be OS specific, and can be reloaded fairly easily if infected. TFA is talking about getting malware into the firmware, which has to be OS agnostic and is somewhat harder to disinfect.
Re: (Score:1)
Re: (Score:2)
I remember that as well. Yes, it is easier to just double-click a program and have it flash a BIOS... but it is nice to have security not just relying on 1-2 crypto signatures which might be compromised.
If not a hardware jumper, perhaps a dedicated mode in firmware where the machine needs rebooted to. Then a UEFI application can be run for the actual BIOS upgrade where it would display the would-be firmware's cryptographic hash (preferably both SHA-3 and MD5), check and display signatures, then either hav
They're not. (Score:3)
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.
Re: (Score:2)
Having a physical read-write switch does not prevent BIOS updates, you simply turn it off when you are going to do a legitimate upgrade, and then turn it back on afterwards. It just prevents BIOS updates from being installed stealthily from a distance.
Re: (Score:1)
Attacks on UEFI... (Score:4, Informative)
Re: SecureBOOT not secure (Score:2)
-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
Visibility (Score:3)
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).
Re: (Score:2)
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.
Theoretically, yes. Practically, it's often not that easy to "just lie to it". (So, in practice, it becomes an arms race of effort just like everything else.)
For example:
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.
That's easy to detect through timing attacks, it turns out. You would also have to be very careful to exactly replicate the behavior of the hardware you're virtualizing, or that's detectable, too.
something outside of the device has to detect the suspicious traffic that such an attack must generate in order to be useful
Now, talk about difficult problems! The easy part would be having trustworthy networking gear. The hard part would be that "detect the suspicious
Re: (Score:1)
OS is too hard also (Score:1)
This is on the heels of an announcement by NIAP that common criteria evaluation of operating systems is too hard:
https://www.niap-ccevs.org/Documents_and_Guidance/ccevs/GPOS%20Position%20Statement.pdf
incentives (Score:3)
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).
Re: (Score:2)
It doesn't even have to do anything sinister - just say "if you want , we need to be able to audit your source code". They find the security holes themselves, tell the vendor about one or two minor ones to hide their intentions, then use the flaws they didn't disclose to hack others. The vendor wouldn't see anything that makes the NSA look even remotely sinister. Best part is that the vendors who aim for US government contracts, particularly ones needing security audits, will be the ones aiming for other go
When are security companies going to get serious? (Score:2)
When the kickbacks dry up.
When? Well, never. (Score:2)
Re: (Score:2)
Why do I have to pay more? I suggest they make less obscene profits and lower executive wages to cover the cost of doing business.
Re: (Score:2)
Can you point me to a signed firmware image which is in a known, good state? One that has been properly independently audited by someone who can be reasonably assumed to not be under the influence of the NSA?
When? (Score:2)
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?"
As soon as someone with a powerful attorney and deep pockets gets hacked via this vector and sues the OEM into oblivion would be my guess.
There is no Binary choice (Score:1)
You said they either find the firmware hackers or they don't.
You missed the "it's a feature, not a bug" solution.
Please go back to Logic School.
obvious answer is obvious (Score:2)
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?
When the NSA stops paying them to ignore it.
The industry is full of shit. (Score:2)
they CAN deal with this. require a physical jumper on the device to be moved for firmware loading. all devices leave the factory blank and they flash their firmware in house when they arrive.
They dont want to do that, they want the 100,000 items to ship from china and never be touched again. Boo Hoo. man up and touch every item state side to protect your products integrity.
The CEO's bonus check would cover the required costs.
Comment on this story... (Score:2)
Hardware gap (Score:3)
I thought that was a boon and would certainly defeat any nefarious flashing. Something like that should be standard.
Chromebooks (Score:1)
Google tries to get security right for Chromebooks. A read-only portion of the firmware authenticates the read-write firmware. The read-write firmware must be signed by google. You must disassemble the machine to flash the read-only firmware.
I can tell you where they are (Score:1)
I have seen some particularly nasty malware hidden in many BIOSes recently. The payload has the effect of preventing you from installing legitimate operating systems on your own computer without paying large amounts of money to an extortion operation.
So far I have traced the perpetrators as far as Redmond, WA.
I know where they are (Score:2)
I have seen some particularly nasty malware hidden in many BIOSes recently. The payload has the effect of preventing you from installing legitimate operating systems on your own computer without first paying large amounts of money to a large extortion group.
Through my research I have managed to trace the perpetrators to Redmond, WA.