Hacking Team Uses UEFI BiOS Rootkit to Keep RCS 9 Agent in Target Systems
blog.trendmicro.com
blog.trendmicro.com
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.
Bootstrapping computers is "hard" and there's a huge disincentive to breaking compatibility with operating systems' installation/bootstrapping.
I'm not sure if EFI/UEFI are ideal, but it strikes me as a net win.
That's just architecture astronauts with too much exposure to COM designing a firmware API.
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.
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)
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.
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.
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?
Directly from the source:
<!-- Get over it, this is a parody and joke -->
> 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?
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?
That's certainly how cognitive dissidence works. People will do great mental gymnastics to avoid seeing themselves as one of the bad guys.
glcd.bandcamp
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.
That is sadly wishful thinking.
These practices are well known and carried out in the open today.
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?
Remember to flash the BIOS if you've been hacked!
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.
Some motherboards even have a backup one
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.
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.
I'm fairly certain that our well being was not a high priority.
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.
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.
[1] http://www.jocm.us/index.php?m=content&c=index&a=show&catid=...
[2] http://www.wired.com/2015/02/nsa-firmware-hacking/0
[3] https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomp...
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.
http://blog.erratasec.com/2013/10/badbios-features-explained...
“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.”
http://arstechnica.com/security/2013/10/meet-badbios-the-mys...
“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.
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.
[1] https://www.blackhat.com/presentations/bh-usa-07/Heasman/Pre...
[2] https://www.blackhat.com/presentations/bh-dc-07/Heasman/Pape...
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.
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.
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.
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.
[1] http://me.bios.io/images/0/0f/Csk_lacon12_intel_amt.pdf
[2] http://theinvisiblethings.blogspot.com/2013/09/thoughts-on-i...
That's all it takes.