This is what I thought when viewing my latest computer that came with an UEFI bios. That the UEFI BIOS is to large and too complex and has way to many functions to be a BIOS device, hence a perfect place to put advanced malware.
It's like an operating system before the operating system, has its own FAT32 system partition where you can store stuff.
Also after a few years your manufacturer will stop shipping uefi BIOS updates for your computer due to their interest in selling new computers and then there will be a lurking security whole laying around.
All of this is equally possible on plain old BIOS. One way that's been done in the past is to write a small hook into the SMM handler. Don't even need to drop any malware into windows, once you're in SMM mode you are running completely outside the view of the OS, with full access to everything in memory.
Without a doubt, the classic BIOS needed improvement, but we didn't need this. The situation reminds me of IPv6, which is also grossly over-engineered.
BIOS also got very large and complex, that's why there was such need for it to be replaced. In both the case of the BIOS and the case of uEFI, it is possible to protect them from tampering or not.
A lot of what you're saying is largely FUD, since all you're doing is listing off random uEFI features and waving your hands around while implying it is "bad" and we're all doomed. But you haven't pointed out a single reason why it is worse than BIOS, in fact BIOS is even more of a "black box" in many cases and thus was even more security through obscurity.
Several uEFI implementations have a checkbox that when unchecked will simply block all updates. If you uncheck that and enable a password, many of these persistent threats are stopped in their tracks. If you know of a specific alternative vector for installation, then contact the manufacturer as a matter of security.
The only reason that uEFI malware is taking off is not because uEFI is inherently more insecure, but instead because uEFI is better documented, it is easier to get reference builds, and easier for people to learn. But, again, all you've done is exchange obscurity (BIOS) for known threats (uEFI). Either way an expert monied adversary (e.g. state security services) could launch an attack.
Systems with UEFI are more likely to also support virtual machines at the CPU level which makes it much easier to transparently slip in a layer under everything else.
Computers being more complicated has nothing to do with a dynamic module loader that is designed to be able to override installed code modules with newer versions at runtime.
That's just architecture astronauts with too much exposure to COM designing a firmware API.
Fine, but that's not what I replied to. Someone said they forgot the "B" in BIOS (with uEFI), I am saying the BIOS hasn't been close to a basic in a very long time due to the complexities of x86-like systems.
The BIOS was a giant bloated mess before uEFI. uEFI's modular design is a single attempt at keeping it simplier and removing unneeded code.
> UEFI's modular design is a single attempt at keeping it simplier and removing unneeded code.
That's why with the introduction of UEFI, flash parts finally grew in size again? (not that I complain, that's quite useful to burn coreboot + Linux on them, to have a _real_ OS around to drive the boot process)
UEFI is _much_ larger than BIOS, conceptually and in terms of code size.
It's also _much_, _much_ larger than coreboot based solutions implementing the same purpose (my tests indicate that UEFI takes 6 times the LOC over coreboot for a minimized code base that provides a boot menu and the ability to load a signed Linux kernel from disk)
> That's why with the introduction of UEFI, flash parts finally grew in size again?
Assembly programs are typically smaller than ones written in C. No surprise there.
> It's also _much_, _much_ larger than coreboot based solutions implementing the same purpose (my tests indicate that UEFI takes 6 times the LOC over coreboot for a minimized code base that provides a boot menu and the ability to load a signed Linux kernel from disk)
And does 1/6th the amount of "stuff." If you drop a bunch of uEFI features, of course you won't use as much code. Is that controversial? There's a reason CoreBoot is so infrequently used, it doesn't do many things that people take for granted with uEFI.
I disabled all capabilities that weren't required for the task, then killed all source files that weren't required for the build, in both trees. I believe it was a fair comparison.
This is the most interesting Hacking Team revelation yet.
First, a production UEFI bootkit! Yahoo! That's a milestone.
Second, fiddling with Bitcoin wallets. Between the bootkit and the Bitcoin fiddling, Hacking Team is just a small step away from a Zeus Botnet. That is, HT is hanging ten on the precipice of crime, it looks like.
Third, this line from HT CEO David Vincenzetti:
a modification of the actual Bitcoiin [sic], something different, fully traceable and supported by clearing houses and the global financial system as a whole might have a future.
If truly Vincenzetti's viewpoint, that line demonstrates a slide to authoritarianism. According to accounts, Vincenzetti was an early privacy advocate. A cypherpunk wouldn't be able to speak the phrase "fully traceable" except as an insult.
Are we seeing the result of money corrupting, or are authoritarian world views the inevitable result of working in the defense industrial complex?
Vincenzetti ends several emails with clear neo-fascist slogans ("Boia chi molla" etc). Some circles in the Italian hacking scene have long had right-wing connotations.
> are authoritarian world views the inevitable result of working in the defense industrial complex?
Is this even a question? If your livelihood depended on selling batons, you'd be extremely supportive of the police, wouldn't you?
There's involvement and then there's commitment, as the pig said to the chicken about breakfast.
I'm wondering if merely getting a job programming for a defense company leads to a moral slide into authoritarianism. You know, suppose you're doing sysadmin for HT - is that enough to start warping your view of the world?
Also there's the involvement in actions just short of creating a banking-credential-stealing botnet. False BGP announcements, sniffing for bitcoin credentials and stuff is the domain of Russian and Romanian "Bad Guys". How on earth can an employee justify doing that sort of thing?
Besides Vincenzetti being an idiot for other reasons, the idea of a traceable bitcoin isn't as bad as you make it.
Imagine if we had such a system managed by the central banks of governments in addition to their paper fiat, together with a law that makes its usage mandatory for _companies_ over a certain size.
There would be no more banks in the loop to hide shady practices, and no more room for big corporations to avoid taxes and money laundry from illegal activity, no more splitting of companies into subdivisions so that a small mailbox on some island makes billions while the rest is officially broke.
The general population would still retain their anonymous paper (which is actually anonymous, not pseudonymous like bitcoin) and if you're too lazy to do your tax report on paper and give a shit about somebody else knowing about your transactions (because lets face it, people give all their data to credit-card companies and payback bonus point systems already) you can use the digital fiat too.
no more room for big corporations to avoid taxes and money laundry from illegal activity, no more splitting of companies into subdivisions so that a small mailbox on some island makes billions while the rest is officially broke.
That is sadly wishful thinking.
These practices are well known and carried out in the open today.
Look up Computrace; it's very similar in operation but is installed by default in most BIOS' as a theft-prevention measure.
Admins managing servers can also opt to buy a server with physical BIOS write-protection, wherein the user will need to put a jumper or turn on a dip switch in order to update the BIOS.
Motherboards with hardware write-protected BIOSes were common around the turn of the century, when flash EEPROMs started replacing EPROMs for BIOS storage. Too bad the amount of tiny extra BOM cost and what seems to be increasingly buggier BIOSes that require frequent updates has made them mostly disappear...
I wonder how much the "it can always be updated later" mentality prevalent today has lead to a higher defect rate in code - it seems to me that if it's harder to change something once it's released, there is more incentive to get it right the first time. I can't remember there being any significant bugs with BIOS in the early machines I used (386/486 era) and those basically never needed to be updated; although PCs have gotten considerably more complex since, especially with things like UEFI, perhaps not all of that complexity is warranted and it wouldn't have manifested itself if BIOS' had remained difficult-to-modify?
All it takes to install a (BIOS) rootkit is root access ... In windows this means answering Yes on the question "Do you want to allow the following program to make changes to your computer".
If your system firmware has already been compromised, you cannot trust that reflashing it will bring it back to a good state. Flashing relies on assistance from the existing system firmware on modern machines.
You would have to open the machine, desolder the flash chips and re-write them in a flash programmer to get a clean slate. Or, if your adversary is very high-level, just throw the machine away, since you'll never be able to find all the places one could hide persistent malware in hardware.
Once you lose physical control of a machine, it's game over if you are concerned about hardware/firmware attacks.
Are they detached and non-writable while the primary ROM is active? I have consistently used Gigabyte boards for a decade because of the extra features that come with them, Backup BIOS being a key one — in the old days I would have to flip a jumper on the board to make the system boot from the backup, today the secondary ROM gets automatically enabled if the primary one fails to load.
I wouldn't trust the secondary flash ROM on my motherboard to protect me from APT, it's only purpose is to recover from a failed flash.
Why exactly? A lot of people's issues with uEFI seem to stem from Secure Boot (and the lack of additional CAs contained within). And while I grant that Secure Boot is problematic, uEFI is actually taking us away from black box firmware that was BIOS.
In many ways this type of stuff has always been possible, the only difference is the skill threshold has been lowered. So I guess the question is do you believe in the phase: "Ignorance is bliss?" Because that's what you're asking for, back to BIOS where these things are still readily do-able, just requires more technical skill and time.
Hey guys that BadBios is totally impossible, agreed? What a scrub, UEFI viruses are impossible. lol psychotic break amirite
I caught a message on the Windows install rebooot about "Intel AMT activated" during a clean reformat - but in BIOS it shows deactivated on reboot. Kaspersky/Malwarebytes/CCleaner shows clean on every scan for system files - I'm seriously wondering whether I need to dump this machine hardware and all. The cause for the reformat in the first place was a potential virus infection, maybe a rootkit. I didn't want to let it back on my network after I scanned a cryptolocker variant in my temp folder.
It sounds like you're saying this lends some weight to the BadBIOS theory. No, the main unbelievable feature attributed to BadBIOS is the ability to jump airgaps via ultrasonic communication, which is not mentioned in this article.
When you've got a BIOS-level rootkit, what's unbelievable about a hardware-level transmission mechanism? If an OS can load device drivers, why not an exploit toolkit?
Again, the problem with the BadBios story (?) from a security-level perspective was that it came from the head of a top-level security consultant - so it's hard to know if it's true or not, because if he was chasing at system ghosts, they were 100% feasible system ghosts, with Proof Of Concepts delivered (eg reception of ultrasonic transmission via laptop speakers [1]). At this point I do believe they were ghosts, but if you want to analyze them - posting about an actively-administered rootkit installation on your LAN on the internet was a mistake, because once detected the attackers would pull back.
And the more we learn about state-level cyberattacks, the more that potential attack rings true. It's just a question of tradeoff - do you really think that at least one party who could mount an A-grade cyberattack would do so against one of the people most likely to detect and analyze it, versus the chance to see what exists in his systems? When you get down to it, once infected you cannot trust so basic a system as a hard drive, and the NSA has attacked that firmware [2]. See: Reflections on Trusting Trust. [3] And that's about 90% of Dragos' sins right there - not trusting systems (or even components) that were exposed to unknown exploits translates as "paranoia" to the average user.
The claim of BadBIOS was that it was supposed to infect new devices through the audio channel.
While Hanspach et al demonstrate the data transmission vector, it's no infection vector.
For that, you'd need to be able to exploit the HD Audio codec (or whatever chip gets to interpret the signal) - and there are dozens of models by different vendors out there. That's a very different claim.
“Dragos believes that two infected computers can communicate with each other over the audio port in frequencies above human hearing, thus allowing an "air gapped" computer to still communicate over the Internet.”
“Ruiu said he arrived at the theory about badBIOS's high-frequency networking capability after observing encrypted data packets being sent to and from an infected laptop that had no obvious network connection with—but was in close proximity to—another badBIOS-infected computer.”
EDIT: just to be clear, I think this was some sort of mental breakdown but as Rob Graham noted none of what was described was obviously impossible – it would just have had to be executed at a higher level than we've seen before, even with something like Stuxnet, with e.g. exploits & persistent rootkits for huge ranges of hardware.
"We had an air-gapped computer that just had its [firmware] BIOS reflashed, a fresh disk drive installed, and zero data on it, installed from a Windows system CD," Ruiu said. "At one point, we were editing some of the components and our registry editor got disabled. It was like: wait a minute, how can that happen? How can the machine react and attack the software that we're using to attack it? This is an air-gapped machine and all of a sudden the search function in the registry editor stopped working when we were using it to search for their keys."
There are four claims in here:
- firmware is fresh
- OS is fresh
- system is air-gapped
- infection happened
The next two paragraphs introduce the network-over-audio theory, which requires an already-infected system (although with no causal link).
This could also be HDD firmware infection or similar, or maybe their flashing attempt was unsuccessful (when done internally, not with an external flasher, that would be reasonable).
Still, articles like this are probably the reason for people (myself included) remembering a claim that infection happened through audio channels.
BIOS is not the sum total of all firmware on a computer - for example you can write a rootkit that lives in the southbridge controller [1] [2] and [article]. And you're correct, as you note - unless you're plugged into the JTAG how do you know you actually reflashed with a clean firmware/BIOS?
It's important not to mix the sensational reporting with what Dragos actually claimed - he only claimed an audio sidechannel as an airgap jumper and/or stay-behind re-loader mechanism on previously-infected systems. Which is actually perfectly possible, especially given that many audio chipsets still have native soft-modem capability built in. Could you write a "loader" firmware virus that re-downloads a more substantial rootkit via soft-modem with an ultrasonic carrier? Well, it's not impossible...
That's generally the problem with the BadBios tale - he's a security researcher so his claim was just at the edge of possibility, but it would have to be an very sophisticated piece of work. It's more likely that the guy was jumping at shadows, but then you read stuff like the [article], which I read as implying that BIOS/firmware-level malware is starting to trickle down to small-scale private actors.
> for example you can write a rootkit that lives in the southbridge controller
Those two slides sets don't claim to have a rootkit 'in the southbridge controller'. The second speaks about Option ROMs, which are a well-known attack vector (see practically half the Thunderbolt attack concepts, the other half aiming for the DMA capabilities).
Option ROMs exist on plugin cards (which aren't southbridges) or, for built-in devices like on-board NICs, in the flash part that also hosts the PC firmware (BIOS, UEFI, coreboot, ...) - which sits behind the southbridge, not on the southbridge itself.
There's also firmware for auxiliary processors (eg. IMC or SMU in AMD chipsets), but that also sits in the main firmware flash.
The "security" processors (ME on Intel, PSP on AMD) also fetch their firmware from the main firmware flash (shared with the CPU firmware).
The location of various firmware items is pretty well-known. I'd be more worried about some extra chip (such as a discrete audio codec chip ;-) ) coming with its own rewritable flash memory. But that's unlikely for cost reasons and also not part of the discussion in security research papers, at least as far as I have seen.
I just want to second what paulmd wrote. I think the story is extremely unlikely to be true but it is almost impossible to provably clean a system compromised by a sufficiently advanced attacker.
Part of the problem was the combination of advanced claims and the breathless breaking-news pace of the discussion. I definitely remember people getting confused because the secondary or tertiary coverage had confused points like this as reporters rushed to publish and people often remember those with the same authority as primary sources.
Sure, looks cool. But if you're trying to convince anyone that BadBIOS can work as claimed, I won't be impressed until I see one system running quietnet install quietnet onto another system with a standard fresh install of Windows, Mac OS X, BSD, or Linux; using only ultrasonic communication.
Did Dragos ever claim that BadBIOS used sound as an infection mechanism rather than a side-channel for communications between systems which were already infected?
If memory serves, nothing he claimed was something that hasn't been demonstrated to be possible – only that the combination would have had to be better executed than anything we've ever seen before and, of course, the evidence never materialized. That fits with the current consensus that it was the product of some sort of mental issue – it's the superset of everything a security researcher might know to be theoretically possible.
I agree with your later comment, that it's unclear whether ultrasonic infection was actually claimed. For purposes of this thread, which started by trying to refute the position, "BadBios is totally impossible" -- the "impossible" claim the mainstream is probably referring to is infection purely by ultrasonic transmission. There's no need to prove that ultrasonic communication is plausible, or that rootkits can be installed in BIOS, EFI, harddrive controller, etc. It is impressive to see such exotic attacks actually being used, though.
No, I'm more suspicious of generic botnet/ransomware stuff. Which probably isn't anything that sophisticated.
That was yesterday. Having slept on it, I think the most likely cause is that I happened on a key combination that tries to poll status or activate AMT during POST/early boot (eg maybe something for service techs to load/auto-configure AMT off PXE or USB or something). An auto-loader for AMT wouldn't thrill me either, of course. Finding a cryptolocker installer in my Temp folder just has me running paranoid, I've never seen that particular message appear before, and it was gone before I could really get a good look.
Managed to dig up this paper on some of the potential black-hat applications of AMT [1]. Happened on another interesting one on Intel SGX [2]. It's certainly a net positive to have virtualization/sandboxing, secure enclaves, etc in our systems - but it always bugs me that they paradoxically create the potential for rootkits that are impossible to pry out once they're situated.
The idea of a platform-neutral technology that could serve as a vector for malware is a particularly disturbing one to me. Developing viruses for each individual BIOS implementation is something of a barrier to large-scale contagion of such malware, but there's probably a much smaller number of (eg) AMT or SGX versions with significant code overlap.
It's like an operating system before the operating system, has its own FAT32 system partition where you can store stuff.
Also after a few years your manufacturer will stop shipping uefi BIOS updates for your computer due to their interest in selling new computers and then there will be a lurking security whole laying around.