SoylentNews is people
SoylentNews
from the false-flag-to-justify-forced-secureboot dept.
The company ESET, based in Slovakia, has announced finding the first-ever UEFI rootkit in the wild. Once infected with the malware the only option is to reflash the SPI firmware or else replace the whole motherboard.
First spotted in early 2017, LoJax is a trojaned version of a popular legitimate LoJack laptop anti-theft software from Absolute Software, which installs its agent into the system's BIOS to survive OS re-installation or drive replacement and notifies device owner of its location in case the laptop gets stolen.
According to researchers, the hackers slightly modified the LoJack software to gain its ability to overwrite UEFI module and changed the background process that communicates with Absolute Software's server to report to Fancy Bear's C&C servers.
UEFI is an overly complex replacement for BIOS, and is often conflated with one of its payloads, Restricted Boot aka Secure Boot.
(Score: 5, Insightful) by Revek on Friday September 28 2018, @07:48PM (8 children)
If the firmware gets compromised thats usually the only option. I knew eventually the uefi would fail. Its a pain in the ass is what it is.
This page was generated by a Swarm of Roaming Elephants
(Score: 2, Interesting) by TheFool on Friday September 28 2018, @08:48PM (7 children)
What's even more fun is that flashing the firmware is almost certainly going to require going through the firmware (unless you're the motherboard vendor). This one may not have guarded itself against flashing, but it theoretically could have with a bit of work.
(Score: 3, Insightful) by KilroySmith on Friday September 28 2018, @09:53PM (6 children)
Guarding against flashing is one thing, but what if it decides to instead let you THINK that the flash occurred? Spoofing the version reply to make it look like the reflash worked would be pretty simple....
(Score: 3, Interesting) by jasassin on Friday September 28 2018, @10:15PM (5 children)
The only thing I can think of would be a PC with two network cards to create a firewall and sniff the packets. Your UEFI would still be hacked, but at least you'd know. I guess you could filter the packets to the C&C. This is an insidious trojan, that as you said could be a lot worse. :(
jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
(Score: 1) by anubi on Saturday September 29 2018, @01:17AM (4 children)
Geez... Put a jumper on the motherboard.
I protect my hobbyist boards that way, so that the board won't be accidentally reprogrammed.
I understand the dilemma. I used to work around business types, and they weren't too keen on stuff like this.
There's big money to be made by selling stuff thats already compromised before the customer even sees it.
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 2) by jasassin on Saturday September 29 2018, @01:55AM
I know if I tried that I'd have one dead motherboard! (Props to you though.)
jasassin@gmail.com GPG Key ID: 0xE6462C68A9A3DB5A
(Score: 3, Touché) by Revek on Saturday September 29 2018, @03:05AM (1 child)
I know right. A jumper or switch to prevent writes to the flash. Crazy right. It would work but its crazy and all management drones know if it sounds crazy and works its not worth doing.
This page was generated by a Swarm of Roaming Elephants
(Score: 0) by Anonymous Coward on Saturday September 29 2018, @03:52AM
A switch or jumper? Are you insane, that will add an entire one-tenth of a cent to the BoM. How can the CEOs of the computer manufacturers afford another yacht each with a huge slice like that to their profit margin?
(Score: 0) by Anonymous Coward on Saturday September 29 2018, @11:52AM
A motherboard I had years ago had two jumpers. One to prevent flashing, and the other to force loading the flash from backup.
Why isn't this a standard? Because another chip on the board with a backup copy of the original flash is too expensive?
(Score: 5, Insightful) by bradley13 on Friday September 28 2018, @07:54PM (1 child)
UEFI is an overly complex replacement for BIOS,
Ridiculously complex, for something that should just in it the hardware and hand over control.
Everyone is somebody else's weirdo.
(Score: 3, Informative) by RS3 on Friday September 28 2018, @09:07PM
Spot on. Code-bloat hits at all levels. I remember when the OS made BIOS calls, the way system structure was supposed to happen. As CPU / RAM / bus speeds increased, slow BIOS ROMs were "shadowed" and cached, but were still slow, and better OS-level drivers became the norm.
(Score: 5, Insightful) by Bot on Friday September 28 2018, @08:06PM (6 children)
Another victory for the tinfoil brigade, UEFI does nothing more than adding attack surface.
Account abandoned.
(Score: 2, Informative) by TheFool on Friday September 28 2018, @08:14PM (2 children)
It does add some quality-of-life things for hardware vendors or firmware-facing OS people. But, yes, it's probably not worth the complexity.
(Score: 1, Interesting) by Anonymous Coward on Saturday September 29 2018, @09:21AM (1 child)
I repaired about 10 UEFI mainboards which had the same problem: Part of flash code literally "eaten out". And all time it was made by unplugging a running PC, just running, not updating anything. No idea why computer had to write something into flash during normal operation, but it looks really bad.
(Score: 0) by Anonymous Coward on Saturday September 29 2018, @12:01PM
What do you mean?
When I found out that Windows could now write to the BIOS I was horrified. Why would you want the OS to be able to have that level of control?
https://www.nextofwindows.com/how-to-retrieve-windows-8-oem-product-key-from-bios [nextofwindows.com]
What could possibly go wrong?
(Score: 0) by Anonymous Coward on Saturday September 29 2018, @08:34PM
"Another victory for the tinfoil brigade, UEFI does nothing more than adding attack surface."
Indeed. Is there anyone who did NOT see this coming from many miles away? Anyone???
(Score: 0) by Anonymous Coward on Sunday September 30 2018, @04:06PM (1 child)
As a thank you, you might abandon the phrase "tinfoil brigade." Warnings were clearly laid out, based on real-world experience and cogent reasoning.
(Score: 2) by Bot on Wednesday October 03 2018, @05:59PM
tinfoil division?
Account abandoned.
(Score: 5, Informative) by TheFool on Friday September 28 2018, @08:09PM (7 children)
Overly complex is an understatement. There's a full blown driver/service/app model, a priority based scheduler, GUI specification, a global key/value store, text editor, a shell, shell scripts... it's closer to a single-user OS than anything. It's well architected, or at least seemed to be when I was working with it, but so is a Rube Goldberg machine. Grab the UEFI shell and play around with it sometime if you want to see just how ridiculous the thing beneath your OS is.
That said, finding an exploit in that much code isn't too surprising, and I can't imagine vendors differ much from the Tianocore implementation so exploits should be good across huge swaths of the market. Expect to see more of these in the future. Once you've got the firmware trying to exploit the OS, things get really dicey.
(Score: 2) by JoeMerchant on Friday September 28 2018, @10:35PM (6 children)
So... does this exploit work if the UEFI is configured in "secure boot" mode?
🌻🌻 [google.com]
(Score: 2) by tibman on Friday September 28 2018, @11:00PM (5 children)
Nope : )
"Since UEFI rootkit is not properly signed, users can protect themselves against LoJax infection by enabling the Secure Boot mechanism, which makes sure that each and every component loaded by the system firmware is properly signed with a valid certificate."
SN won't survive on lurkers alone. Write comments.
(Score: 2, Insightful) by Anonymous Coward on Saturday September 29 2018, @12:46AM (2 children)
A signature that could probably be obtained by $TLA government org with an NSL to silence the vendor. So yes, only ‘bad guys’ with power.
(Score: 0) by Anonymous Coward on Saturday September 29 2018, @02:49AM (1 child)
Careful, you're not as anonymous as you might think.
(Score: 0) by Anonymous Coward on Saturday September 29 2018, @02:37PM
Sure I am.
(Score: 5, Insightful) by Whoever on Saturday September 29 2018, @03:02AM
Celebrations taking place in Redmond!
More reasons to prevent users from disabling secure boot, leading to more problems installing Linux.
(Score: 2, Interesting) by TheFool on Saturday September 29 2018, @12:13PM
Nefarious side-goals aside, this is the reason that they give on paper for secure boot. BIOS security was non-existent, so the OS had to do it - and to get to that point, you had to get pretty far into the boot process. In UEFI, everyone calls a firmware provided "please check the signature" function on the files (and it's files now, not reading blocks from disk and jumping to them) as you read them in. Much easier for the underpaid, oversees devs to maintain and understand.
The real shame is that they didn't make key management required if you support secure boot. That would have solved the whole Linux problem, and personally I think it would be cool to sign my own grub while deleting M$'s keys entirely.
(Score: 4, Funny) by All Your Lawn Are Belong To Us on Friday September 28 2018, @11:03PM (3 children)
So what we need is a Supreme Extensible Firmware Interface, which can oversee the Unified Extensible Firmware Interface which oversees your system. SEFI will be able to rebuild the UEFI when it gets corrupted.
Next year: Absolute Extensible Firmware Interface which will supervise the SEFI's oversight of UEFI.
This sig for rent.
(Score: 1, Funny) by Anonymous Coward on Saturday September 29 2018, @12:35AM (1 child)
So, it's like a pothole crew with multiple levels of supervisors?
(Score: 2) by All Your Lawn Are Belong To Us on Monday October 01 2018, @03:57PM
Exactly, except it never ends. It's Firmware Interfaces all the way down!
This sig for rent.
(Score: 3, Funny) by MostCynical on Saturday September 29 2018, @05:11AM
I see where you're going..
Universal
Supreme
Absolute
F
U
C
K
Y
E
A
H
"I guess once you start doubting, there's no end to it." -Batou, Ghost in the Shell: Stand Alone Complex
(Score: 4, Interesting) by Azuma Hazuki on Saturday September 29 2018, @01:19AM
As several other people have commented, UEFI *is* an OS and one that sits below your actual OS, i.e., has super-root access, correct? I can see this thing being engineered to pretend like it's been overwritten but actually not be if someone tries a manual flash by the usual method (boot into legacy mode with a USB stick with the firmware image on it for example). This implies needing to go to the physical level, meaning you'd have to attach pins to the chip and manually reflash it. That's beyond even my comfort zone at the moment. This is scary stuff.
I am "that girl" your mother warned you about...
(Score: 5, Interesting) by jmorris on Saturday September 29 2018, @03:09AM
Actually there are several 'root' problems here.
1. UEFI runs at ring -1 while your OS runs, it runs ACPI and other runtime services and, as this exploit demonstrates, leaves hooks open for arbitrary 3rd party code to also run in ring -1 along with it.
2. Worse still, if infection is to occur the idiots leave a door open to inject code from a running system.
3. Systems are not designed to make it easy to manually reflash them or manually verify the code in the flash chip.
The solution would be a minor rethink and retool. Standardize ACPI and get it the hell out of ring -1, either allow the OS to manage things itself or if we still don't trust Windows not to bake the chip, move to a microcontroller with limited access to anything other than power management things. Communicate with the CPU over a standard interface, serial, i2c or SPI. Don't put enough resources in the micro to permit it to host complicated malware even if somebody manages to find a way to get it in. Yes this would complicate things for software like LoJack. Time to decide which threat is more dangerous.
Then rework the BIOS. Implement two segments, a small r/w for settings and a larger one for the firmware. Give that a one way gate, once a command is sent it becomes hardware locked to read only until a power cycle. UEFI always flips the switch before passing control to an operating system. To update the firmware would then require a cold boot with a USB stick, manually entering the setup program and selecting update. Vendors prefer the ease of offering a Windows executable to update but that can never be secured. A lojack type program could still be loaded this way, but the user (or admin / OEM) would have to explicitly do it from the firmware console and combined with the fix above it would only live until control passed to the OS, still leaving a moment to ping a central server and check in.
Finally, mandate a standardized AVR/Arduino 2x3 header near the firmware. Programmers to mate with that port are widely available and would permit easy verification and reprogramming of the flash. Get really wild and add a jumper to allow power to the flash to come from the programmer so an unpowered system could be worked with.
(Score: 4, Interesting) by canopic jug on Saturday September 29 2018, @05:32AM
It seems that maybe Alfredo Ortega and Anibal Sacco covered something somewhat similar, but for BIOS instead, at Blackhat 2009 in their talk, Deactivate the Rootkit: Attacks on BIOS anti-theft technologies [blackhat.com] (warning: PDF). They refer to BIOS not UEFI, but they did their work well after the UEFI specification was released and only a few years before vendors shoehorned UEFI into their products. Joanna Rutkowska's work is also somewhat related but seems to concentrate more on the weaknesses with the extra OS running inside the CPU itself. This whole UEFI mess originates from M$ pushing, if not for UEFI itself then for bending the functional requirements until they provide a broken system just to make it harder to boot LInux. Their jihad against Free and Open Source Software is increasing the vulnerability of even the hardware itself.
Money is not free speech. Elections should not be auctions.