First-Ever UEFI Rootkit Tied To Sednit APT (threatpost.com) 168
Researchers hunting cyber-espionage group Sednit (an APT also known as Sofacy, Fancy Bear and APT28) say they have discovered the first-ever instance of a rootkit targeting the Windows Unified Extensible Firmware Interface (UEFI) in successful attacks.
From a report: The discussion of Sednit was part of the 35C3 conference, and a session given by Frederic Vachon, a malware researcher at ESET who published a technical write-up on his findings earlier this fall [PDF]. During his session, Vachon said that finding a rootkit targeting a system's UEFI is significant, given that rootkit malware programs can survive on the motherboard's flash memory, giving it both persistence and stealth.
"UEFI rootkits have been researched and discussed heavily in the past few years, but sparse evidence has been presented of real campaigns actively trying to compromise systems at this level," he said. The rootkit is named LoJax. The name is a nod to the underlying code, which is a modified version of Absolute Software's LoJack recovery software for laptops. The purpose of the legitimate LoJack software is to help victims of a stolen laptop be able to access their PC without tipping off the bad guys who stole it. It hides on a system's UEFI and stealthily beacons its whereabouts back to the owner for possible physical recovery of the laptop.
"UEFI rootkits have been researched and discussed heavily in the past few years, but sparse evidence has been presented of real campaigns actively trying to compromise systems at this level," he said. The rootkit is named LoJax. The name is a nod to the underlying code, which is a modified version of Absolute Software's LoJack recovery software for laptops. The purpose of the legitimate LoJack software is to help victims of a stolen laptop be able to access their PC without tipping off the bad guys who stole it. It hides on a system's UEFI and stealthily beacons its whereabouts back to the owner for possible physical recovery of the laptop.
Phishing email or equivalent? (Score:3)
How long until this can be pushed down direct from a website?
Re: (Score:2)
How long until this can be pushed down direct from a website?
Is this even relevant? The human flaw in the security model is one that we've shown for the past 20 years can't be patched. I'm surprised anyone is looking for automated methods anymore when you can just pretend to be Paypal saying there's a problem with your account.
Re: (Score:2)
Also email is often easy to scan by AV software.
Re: (Score:2)
Also email is often easy to scan by AV software.
I think you're confused. The Email does not contain the malware. AV software does nothing to stop idiot users from taking very careful aim while shooting themselves in the foot.
Re: (Score:2)
Re: (Score:2)
That can be detected.
If you can do that you could make a shitton of money in the security game. Every security product on the market scans emails, yet phishing is still trivial and incredibly effective.
Re: (Score:2)
How long until this can be pushed down direct from a website?
Just wait for the next browser-based arbitrary code exploit. There are usually several disclosed and patched per year.
If we consider undisclosed ACEs, then it could be happening already.
APT? (Score:1)
What is an "APT" in this context? Even the original article doesn't explain it. Does nobody think about proper editing any more?
Re:APT? (Score:5, Informative)
Re: (Score:1)
UEFI is due to Intel, not MS
Re: (Score:2)
The user can swap new storage, reinstall, OS all they like.
Wonderful fun for police/gov malware and the security services.
Re: APT? (Score:2)
Re: (Score:2)
Re: APT? (Score:2)
Re: (Score:2)
Like the Linux kernel talking about DRM. Digital Rights Management or Direct Rendering Manager? Clear as mud.
Re: (Score:1)
Linux+APT. Package manager.
Rootkit+APT. Advanced persistent threat.
Address+APT. Apartment number.
This is how human beings learn meaning through context. It's a skill the few who lack it naturally pick up around second or third grade.
Re: (Score:2)
Well, you seem really apt in the matter, dear sir!
Hijack is Whack (Score:2)
Lojack got jacked by jackoffs so they can hijack you from the back without even using JTAG.
Re: (Score:1)
Get back, Jack, do it again.
Re: (Score:2)
Exactly, and worse, they smell like cigarettes and vodka.
Whatever happened to... (Score:2, Insightful)
Whatever happened to requiring the insertion of a jumper on the motherboard to update the BIOS? That would stop this thing in its tracks.
Re: (Score:3)
Re:Whatever happened to... (Score:5, Insightful)
This. Unlike old BIOS that only needed a few bytes to maintain configuration (commonly battery backed CMOS, but eeprom could be used) the latest abomination from Intel needs a full fledged read/write flash file system. To make it worse, unlike old BIOS where clearing the CMOS would recover from any mis-configuration, some implementations of EFI can be bricked.
Now, from TFA, it turns out UEFI makes a dandy platform for persistent malware.
So, NOW can we go back to BIOS and just make it unstand GPTs?
Re: (Score:2)
Re:Whatever happened to... (Score:5, Interesting)
Re: (Score:3)
> Chipset initialization has gotten too complex to fit in the 1 MB of RAM
8-bit machines only need a few KB for this. WTF are you guys doing that you need more then 1024 KB ???
Re: (Score:2)
> Chipset initialization has gotten too complex to fit in the 1 MB of RAM
8-bit machines only need a few KB for this. WTF are you guys doing that you need more then 1024 KB ???
8bit machines had CPUs where you could count the transistors by hand without making a mistake (8080 had 3500 transistors). My current CPU has over 4billion. You may have noticed computers have gotten more complex.
Re:Whatever happened to... (Score:5, Interesting)
As another (former) BIOS writer, why not pop it into flat-32 and go from there? Implementing a complex API complete with a file system seems a bit much for something that will run just long enough to call a boot loader.
IIRC, a number of BIOS do, in fact, go into flat-32 mode. The big catch to using C is not the size of the flash chip, it's the need to have space for the stack before you get memory up. That is handily solved by configuring the CPU to use it's cache as a temporary RAM long enough to get the actual RAM up.
CoreBOOT + SeaBIOS manage to be implemented mostly in C and work just fine. Most server boards still manage to implement "Legacy boot mode".
Re: (Score:2, Informative)
Because UEFI doesn't just call the bootloader. It implements stuff like Secure Boot, the ability to run platform independent expansion card firmware (EFI, which uses a virtual machine to make it CPU architecture agnostic), CPU microcode updates, reading XMP data for RAM configuration etc.
In many ways it does less than the BIOS, not bothering to do a full init on most of the hardware or provide any APIs for it, which is why boot times are better. But it does have to provide some important security functional
Re:Whatever happened to... (Score:4, Interesting)
Those functions (when wanted) should be provided by a bootloader like object that gets loaded by the BIOS. So far, the biggest use of secure boot seems to be making sure your computer doesn't do things you want it to if the *IAA don't want it to.
Meanwhile, other architectures don't use EFI and I see no signs that any want to, so that makes platform independant boot ROMS a bit pointless. If wanted, that could be bolted on as well.
Re: (Score:3)
That's basically what happens, the UEFI loads the Secure Boot module which then verifies the boot files. Obviously the Secure Boot module has to be in the UEFI where it can't be modified by malware, or it wouldn't work.
It's widely used to prevent infection by rootkit. By validating the OS boot files with a public key they can't be modified by a rootkit.
Re: (Score:3)
So why not throw the excess plumbing away and just have the BIOS call the secure boot module?
EFI isn't needed for that, it just happens to be where it was implemented.
Re: (Score:2)
Well, for example, you probably need some way to init the GPU to the point where it can provide a basic display for the OS to boot with, or display a boot menu and error messages. So you need a way to configure arbitrary GPUs, and ideally you don't want it to be like the old BIOS stuff that was just x86 code in a ROM chip. So actually you do need EFI.
Re: (Score:2)
I don't NEED EFI. Initing the video card has been happening since before the first PC.
I will concede that some sort of byte code could be a useful thing (divorced from EFI). For example, some other firmware systems used to support a FORTH interpreter. I even experimentally added one to LinuxBIOS at one time, but I ran out of time to work on it.
Re: (Score:3)
UEFI/EFI is coming to an ARM platform near you. It's needed for ARM to support server type capabilities and IIRC ARM plans to implement it across all future products to make it possible for their platform to expand into the server market.
UEFI is here to stay. Personally I'd prefer coreboot but no one supports coreboot and the manufactures don't like it because they can't brand it as easily as UEFI can be.
Re: (Score:3)
Re: Whatever happened to... (Score:5, Interesting)
Unfortunately, UEFI appears to be insecure by design. So, step one, shred UEFI and secure wipe it's source.
CoreBoot has a nice modern design that works. The only thing holding it back is lack of vendor support.
A minimalist extension of the old BIOS system to go to flat 32 bit mode ASAP, and load a bootloader the same way old BIOS does comes to mind. If necessary, expand the CMOS a bit, but under no circumstances allow it to contain code, just settings. And like the old BIOS, if the CMOS doesn't pass a checksum, write sane defaults to it. Writing to the flash should never be needed for normal operation, write should need to be enabled ONLY if a BIOS update is needed, and that should be a very rare event.
A wishlist item is that all of the "secret sauce" that requires vendor support and NDAs should be packed into one section and when it is complete, it should simply jump into a well known location to take care of loading the boot loader. Do NOT implement a memory allocator, filesystem, word processor or Eliza in BIOS. Rule 1, the system must operate normally if writing to flash is disabled.
Re: (Score:2)
Seconding the other AC, the page comes up for me. I'm still on the mailing list and it looks to be quite active.
Re: (Score:2)
Yet this is exactly what "secure boot" does -- it does not make end-users or end-owners more "secure", it constricts them. It also doesn't really prevent malware, as we've seen a few times before. The best readily available defense against malware is to run operating systems that don't drop their pants so much.
As a security professional, I am a big fan of the concept of secure boot - not necessarily current implementations. The purpose of secure boot is to give me a known secure state of the system. I want that you can't drop some shit somewhere that will run underneath my ring 0 because it gets loaded first. If the boot process can ensure that my kernel gets loaded and handed control of the system, then I can be responsible from that point on and use RBAC or SELinux or OpenBSD secure levels or whatever to stay i
Re: (Score:2)
As a security professional, I am a big fan of the concept of secure boot - not necessarily current implementations. The purpose of secure boot is to give me a known secure state of the system. I want that you can't drop some shit somewhere that will run underneath my ring 0 because it gets loaded first. If the boot process can ensure that my kernel gets loaded and handed control of the system, then I can be responsible from that point on and use RBAC or SELinux or OpenBSD secure levels or whatever to stay in control. But if some shit pre-empts me and puts itself between my kernel and the hardware, nothing I do matters.
I much prefer Coreboot over UEFI for the same reason - control.
And what exact protection does Coreboot provide that UEFI Secure Boot does not provide in this regard? If Secure Boot is properly implemented then there is no way to execute unsigned code unless someone physically flashes the chip with compromised firmware. But you could do the exact same thing with Coreboot, too. So is the advantage of Coreboot that you only trust code that you compile yourself? Because even with Coreboot you're using someone else's binaries at some point. Very few silicon vendors pro
Re: (Score:2)
So is the advantage of Coreboot that you only trust code that you compile yourself?
Yes. As I wrote, it's about control.
And even if you have 100% access to all of the code, whose compiler are you going to use? Do you trust them? Because the compiler can also inject code that could compromise your system at build time.
I'm well aware of that. Some 15 years ago I started a small security-focussed Linux distro (Nexus Linux was the name if I recall correctly) that tried to bootstrap everything from trusted sources. We never came to a first release, because it was essentially three people and the task is massive exactly for the reasons you outline. But the idea is there, with enough resources it is doable, if there were some support to pay one or two people full-time, you could build a syst
Re: (Score:2)
And what exact protection does Coreboot provide that UEFI Secure Boot does not provide in this regard?
If I may interject, the concept of secure boot only works as a security measure if the owner of the hardware is the sole owner of the key trusted to sign the bootloader and the OS. My machine, *I* sign the code I trust. MS's opinion doesn't matter. Intel's opinion doesn't matter.
Re: (Score:2)
And what exact protection does Coreboot provide that UEFI Secure Boot does not provide in this regard?
If I may interject, the concept of secure boot only works as a security measure if the owner of the hardware is the sole owner of the key trusted to sign the bootloader and the OS. My machine, *I* sign the code I trust. MS's opinion doesn't matter. Intel's opinion doesn't matter.
You are living in a different world than most people. 99% of the people in the world do not want what you want. But you’re welcome to modify your firmware to revoke Microsoft’s root of trust and inject your own. You’re already able to inject your own but I don’t think you’ll be able to get a UEFI device without Microsoft’s key unless you modify the binary or pay to have custom firmware. I am 100% certain that there are data centers who use only their own key, but they
Re: (Score:2)
A funny thing with secure boot in UEFI. Why can't the bad guy just turn it off or replace your key with his own and then sign a new corrupted bootloader?
You can check what key is installed once the system boots, but if you're unknowingly running the bad guy's patched kernel, you can't trust the results of the check.
It's turtles all the way down.
Re: (Score:2)
The purpose of unreal mode was to access more memory while still being able to quickly call real mode DOS/BIOS services and device drivers. Since in this case it is the BIOS and you have to go into protected mode to set up unreal mode, might as well just stay in protected mode and access all of memory that way.
Re: (Score:2)
Unlike old BIOS that only needed
to do very little, UEFI is complex due to the nature of increased complexity of our computer systems.
To make it worse, unlike old BIOS where clearing the CMOS would recover from any mis-configuration
"Configuration" cal also be cleared by clearing the CMOS.
some implementations of EFI can be bricked.
BIOSes could happily be bricked too. The only reason that it didn't happen more often is that Windows prevented the low level hardware access needed to write to it. Incidentally this also caused big problems for updating or recovering the system if needed.
it turns out UEFI makes a dandy platform for persistent malware.
Any platform could be used for persistent malware. The only reason the old BIOS wasn't is because
Re: (Score:3)
The correct way to protect the BIOS is a jumper that has to be set to enable writing/erasing the flash. End of story.
The old BIOS already managed to init the CPU, init the memory controller, init the memory, and provide enough setup of PCI devices to find the boot loader or jump to PXE.
I have actually written boot firmware. Most of those complex things beyond what I mentioned above are complex because they don't belong in the boot firmware at all.
Re: (Score:2)
The correct way to protect the BIOS is a jumper that has to be set to enable writing/erasing the flash. End of story.
The old BIOS already managed to init the CPU, init the memory controller, init the memory, and provide enough setup of PCI devices to find the boot loader or jump to PXE.
I have actually written boot firmware. Most of those complex things beyond what I mentioned above are complex because they don't belong in the boot firmware at all.
Yep. That's exactly what Google, Facebook, Amazon, and everyone else wants in their data centers. They want to unrack hundreds of thousands of servers to fix a critical security issue. That's exactly what every single end user wants to do, as well. Most end users aren't even sophisticated enough to know that firmware exists, let alone sophisticated enough to know that it needs to be updated. Good luck getting them to set a jumper.
I think the problem that the UEFI forum has is that so many businesses ha
Re: (Score:2)
If the BIOS contains any code that creates a security problem for a server, you've already screwed up. By the time the OS comes up, the BIOS should be a distant memory. If you need to upgrade it to support new hardware, you've already opened it up to change the hardware. If the user isn't sophisticated enough to know firmware exists, how would they ever come to the conclusion they need to update it?
You would be surprised how modular BIOS can actually be without a complex API. It starts with the CPU specific
Re: (Score:2)
If the BIOS contains any code that creates a security problem for a server, you've already screwed up.
How can the firmware not have the potential to create a security problem for the OS? The firmware hands off execution to the OS. Even if the firmware does not persist after boot it can still maliciously modify the OS. Let's suppose that the firmware needs to access the USB controller so that a keyboard can be used during boot. If there's a security hole in the USB driver then the system can be owned long before the OS ever loads. The world you are describing, where the firmware is not part of the found
Re: (Score:2)
If the firmware isn't writable, it won't get corrupted by an attacker in the first place. Making it updatable without physical intervention actually PROVIDES the attack vector that you then have to create security updates to protect.
As for a hacked USB device, it is widely believed that physical access == game over in any event.
The idea of the OS update channel being able to apply updates to the firmware is a big screaming NO! It's bad enough that the OS is changing out from under the user.
As for vendor loc
Re: (Score:2)
If the firmware isn't writable, it won't get corrupted by an attacker in the first place. Making it updatable without physical intervention actually PROVIDES the attack vector that you then have to create security updates to protect.
As for a hacked USB device, it is widely believed that physical access == game over in any event.
The firmware does NOT need to be overwritten to be attacked and exploited, even if it does not persist into runtime. It just needs an exploitable defect and someone/thing with an opportunity to exploit it. Runtime services extends the ability to exploit a firmware defect into the OS.
And I do not need physical presence to own you with a compromised USB or PciE device. I only need to sit somewhere in your supply channel. I could be a plant at the keyboard factory. I could own the warehouse that stores al
Re: (Score:2)
Those opportunities will be hard to come by if the BIOS is a distant memory by the time networking is up. The on-disk bootloader would be a much "better" target for the bad guy and offers some chance at persistence.
A USB device could be a problem if you boot from it, if the BIOS is configured to boot from USB, but EFI and/or firmware updates won't change that. PCI devices could certainly be a problem, though less so now that chipsets have an IOMMU. If the option ROM contains an exploit, again neither EFI or
Re: (Score:2)
Those opportunities will be hard to come by if the BIOS is a distant memory by the time networking is up.
That is absolutely false. If you can compromise the firmware then it does not matter what is loaded afterward, you can modify it as it is loaded or before it is loaded. Even if you boot with PXE or HTTPS the firmware still has to load the eventual image. You can have a persistent threat that does not require the flash part to be compromised as long as you have a mechanism available to launch your payload. And the fact that you think this is the epitome of the problem we are currently seeing. The people
Re: (Score:2)
That is absolutely false. If you can compromise the firmware then it does not matter what is loaded afterward, you can modify it as it is loaded or before it is loaded.
I think you missed my point. The BIOS is out of the picture by the time the network is up. It is also read only. So that's a really big IF. You'll need to be physically present to set that jumper if you want to implant an APT into the firmware..
Note that IOMMU and VT-d are not the same thing. VT-d is a way to give a real PCI device over to a VM.IOMMU includes preventing PCI cards from overflowing a memory/address space assignment at the hardware level. Likewise, the USB controller itself will enforce buffer
Re: (Score:2)
I think you missed my point. The BIOS is out of the picture by the time the network is up. It is also read only. So that's a really big IF. You'll need to be physically present to set that jumper if you want to implant an APT into the firmware..
You’ve missed the point. Whether or not your firmware is read only, if I can compromise the firmware while it is running then I own the machine. Whether it persists or not. By the time it hands off execution to your OS the entire system is untrustworthy. End of story. It doesn’t matter if the network stack is not available until next week, I owned the machine and still own it when next week rolls around.
Note that IOMMU and VT-d are not the same thing. VT-d is a way to give a real PCI device over to a VM.IOMMU includes preventing PCI cards from overflowing a memory/address space assignment at the hardware level.
And how does IOMMU work? If you’re on an Intel box it uses... VT-d. If it’s
Re: (Score:2)
If the firmware can be changed, that includes the trust DB or the code that checks the signatures.
If someone prefers convenience over security, they can set the jumper when they set up the machine. If they want a middle way, they can replace the jumper with a switch on the front panel.
You're right that most people don't care. They just turn secure boot off too since that may also be inconvenient later.
Essentially, you are advocating to open a REMOTE vulnerability just in case you want to apply a patch to cl
Re: (Score:2)
If the firmware can be changed, that includes the trust DB or the code that checks the signatures.
If firmware signatures are required then no, you cannot change the trust DB, at least not for the root of trust. And you can use the TPM and authenticated variables to protect any key that has been added by the end user. If that gets corrupted, you just drop the data and force the user to add the key again. That requires physical presence.
If someone prefers convenience over security, they can set the jumper when they set up the machine. If they want a middle way, they can replace the jumper with a switch on the front panel.
Which will result in everyone except yourself a a handful of other people leaving the jumper set. And since you seem to be against using anything like cryptographic si
Re: (Score:2)
The goalpost didn't even quiver. If the BIOS is read only in hardware, nobody's going to implant an APT in it by any means other than physically setting the write enable jumper PERIOD. Exploiting the SMM or even the ME can't change that.
Keep in mind, we're talking about the value add for writable firmware here, so the face that the OS might be corrupted after being booted (for example, through an obscure TCP stack vuln) is irrelevant since that can happen no matter what booted it.
An ME vuln CAN disable chec
Re: (Score:2)
The old BIOS already managed to init the CPU, init the memory controller, init the memory, and provide enough setup of PCI devices to find the boot loader or jump to PXE.
Yes and it did so just fine until those very processes became so complex they the didn't fit in the woefully inadequate structure BIOSes had to work with.
Computers have grown more complex. Complexity breeds complexity.
Re: (Score:2)
So what magic is it that EFI is somehow able to fit, but a BIOS supporting the old ABI just can't manage?
BIOS has been going into flat-32 mode for some time. Are you saying a 4GB address space just isn't big enough?
Re: (Score:2)
BIOS has been a mixture of incredibly and increasingly uglier hacks as it's grown beyond it's initial scope and size while maintaining backwards compatibility which made absolutely no sense on modern hardware.
You think EFI is bad? More power to you. I think the hackjobs that were BIOSes are worse. FYI the code required to initiate HyperTransport in the latest AGESA firmware from AMD is larger than the entire BIOS was pre-EFI, and that's just a small portion of getting a small part of a modern system to boot
Re: (Score:2)
I have actually disassembled BIOS before. I'm not against a massive clean-up of some of the nasty proprietary code. For example, CoreBoot + SeaBIOS is good.
Re: (Score:2)
understand
Re: (Score:2)
That would be best, yes.
Re: (Score:2)
Re: (Score:2)
Physical attestation, or just a way to check that there is a layer 8 presence, can go a long way when it comes to security. This is why Google went with a Yubikey-like setup internally, since malware would have to get the user to physically jam in their physical device and hit the button to work for every action.
I wonder how this can be done in modern times. Perhaps repurpose the "Turbo" switch into a "firmware updates allowed after next power cycle" mode, where firmware stuff can happen when the button i
Re: (Score:2)
Whatever happened to requiring the insertion of a jumper on the motherboard to update the BIOS? That would stop this thing in its tracks.
The jumper (which only a few motherboards ever featured) has been replaced with a digital signature. Secure Boot stops this thing in its track.
The summary conveniently skips arguably one of the most important takeaways from TFA:
By enabling Secure Boot, and making sure their UEFI firmware is up to date, end users can protect themselves against attack, Vachon said.
Same old mistakes, made again and again and again (Score:3)
I am really tired of everything new being broken. We do know how to do this better. Why are these severe mistakes still being made?
Re:Same old mistakes, made again and again and aga (Score:4, Funny)
Re: (Score:2)
Don't worry. AI and autonomous driving and quantum computing are right around the corner. That will fix all these issues.
No, because then the malware writers will 3D print their virus!
Re: (Score:2)
Thank you thank you thank you 110010001000 as I certainly realize you are being facetious. Good to know I'm not the only one recognizing the generally ignored via Tunnel vision AI experts of the dangers of AI tech
Re: (Score:2)
Thank you thank you thank you 110010001000 as I certainly realize you are being facetious. Good to know I'm not the only one recognizing the generally ignored via Tunnel vision AI experts of the dangers of AI tech
The dangers of AI tech are the same as the dangers of "trusting the computer". ML algorithms all have an error rate. That's part of the package. The problem is that humans don't seem to understand this. This is fixable just as people now understand that the DB might have been updated incorrectly and there might be a mistake that can be investigated.
Re: (Score:2)
Well, autonomous driving may be real and fix it. If I get run over, I do not have to deal with this crap anymore!
Re: (Score:2)
Re: (Score:2, Troll)
Because NEW is seen as a virtue in itself. Rather than just make a needed improvement to old, we throw away the years of debugging and testing and jump into making something NEW. Often the argument is that the NEW can be much simpler. Alas, then a zillion corner cases pop up that explain well why OLD was as complex as it was. But now we have NEW, so OLD must go!
So here we are with NEW and decades less debugging and testing behind it, no discernible benefit over OLD, and bugs are coming out of the wood work.
Re: (Score:2)
From my POV and experience, the tech industry is slowly crashing as the fails are increasing in numbers. And like cooking a frog, turning up teh heat slowley, so the tech industry is like the frog cooking itself.
Re: (Score:2)
The frog stuff is a weird myth, not a real thing.
Re: (Score:2)
Re: (Score:2)
The frog stuff is a weird myth, not a real thing.
That the story you're repeating claims to be based on something real is part of the myth, as with most myths.
The frog stuff is a weird myth, not a real thing.
Re: (Score:2)
It is true. Demand legacy software support. Go stable, go old.
Re:Same old mistakes, made again and again and aga (Score:4, Interesting)
Money. To a lot of companies, the top brass feels that security gives zero return to them, so they skimp as much as possible on it. In fact, the faster they can rush a product out the door, no matter how many odious show-stopping bugs, the better.
I wish we had something like Underwriter's Laboratories, except for computer product security, and security in the correct ways, as most companies only focus on security against the intended user, so a broken device can't be reflashed with custom firmware and made useful again. Or perhaps, take that one step further and go with a Sold Secure like system, where products are white-box tested, black box tested, source code is audited, chip supplies are audited, and so on. Of course, the downside here is regulatory capture, but if this is a multinational organization with people who are not beholden to one country, this could be an acceptable solution.
Until this, or some regulatory system is in place, these compromises will only happen more often, as one attack based on UEFI allows others to happen, and we have only seen the start persistant threats. Things like ransomware that quietly encrypts files via a transparant driver, so even backups have the files encrypted, then a certain date elapses, and the decryption keys are chucked, all drives are ATA locked and the machine puts up a message demanding whatever currency is in fashion (Bitcoins, e-Gold, etc.)
Re: (Score:2)
"... Because we need everything to be new & better & faster with "more connections" so we can keep collecting fees for the new exciting version xyz.12b23 and keep our income coming in ... "
It is a crock. We don't need more than a few standard features to run business.
Ever heard of the Rube Golberg OS, aka Windows?
windows lock in is not what we need or apple store (Score:2)
windows lock in is not what we need or apple storage lock in where you pay a lot more then other systems to have the storage locked to the MB.
Re: (Score:3)
Re: (Score:3)
Actually things are much, much better than they used to be.
This attack requires the user to first compromise the OS in order to attack the UEFI firmware, so they need multiple unpatched vulnerabilities. Realistically that means either tricking the user into running some malware or getting through the web browser, the web browser's sandbox, the OS sandbox, the OS user level protections, the OS kernel security protections and finally attacking the particular UEFI implementation being used.
Compare to back in t
The state of IT is a tragedy (Score:5, Insightful)
Anyone with a working brain can see that non-removable persistent storage on the mainboard, that can be written from inside a running OS and only be inspected under the control of the software in that storage, is an extraordinarily stupid mistake. Then there are a variety of "management" systems (SMM, IME, ...) which also evade inspection and have full access to everything. The most trustworthy computers these days are small embedded processors (but not phones!). Desktop systems and laptops can practically not be secured. If there is a possibility of a hack, there is no reliable way to restore the system to a safe state.
Re: (Score:2)
Most microcomputers have had some kind of non-volatile storage since the dawn of time. Some of the 8 bit machines didn't, but even early PCs had a real-time clock and battery backed boot settings RAM.
Of course back then there was no access control at all, every app could access the hardware directly.
Think about how long UEFI has been around and how long it has taken to find an exploit. It's really not that badly designed at all, at least not from a security perspective. Note that enabling Secure Boot mitiga
Re: (Score:2)
but even early PCs had a real-time clock and battery backed boot settings RAM.
Not my early PC. My first PC was an IBM 5150 (aka "PC-1") and I had to have a RTC on an expansion card because it didn't have one onboard. That expansion card also had 384kB of RAM. Installed in an XT, it would get you up to 1MB. In a PC, it would get you to 448kB. And you had to run a special command to get/set the RTC, naturally.
Re: (Score:2)
Mine was an Amstrad PC1512. The RTC was built in, but needed 4x AA batteries for some reason. It was a weird but generally decent machine.
Re: (Score:2)
Most microcomputers have had some kind of non-volatile storage since the dawn of time. Some of the 8 bit machines didn't, but even early PCs had a real-time clock and battery backed boot settings RAM.
Of course back then there was no access control at all, every app could access the hardware directly.
Think about how long UEFI has been around and how long it has taken to find an exploit. It's really not that badly designed at all, at least not from a security perspective. Note that enabling Secure Boot mitigates the attack entirely.
It has taken this long because there were so many easier targets, not because the implementation by any vendor was especially well implemented from a security standpoint. Firmware has plenty of security problems and the industry is working to make it better. The UEFI forum has been considering security for some time, and I think that the specification covers *most* of the problems that any firmware can be susceptible to. However, the physical root of trust does not provide any sort of protection against
UEFI and persistent code (Score:3, Insightful)
So UEFI allows persistent code to exist in it from a 3rd party for example these laptop security/tracking apps? Who didn't think this would eventually be abused by malware or some 3 letter agency?
What's even better than the malware back in the day that would attempt to modify known BIOS code, or maybe brick a BIOS it didn't know? A known documented API into UEFI that allows for "sanctioned" persistent code! yay!
UEFI and IME sounds like a 3 letter agencies wet dream.
Re: (Score:2)
So UEFI allows persistent code to exist in it from a 3rd party for example these laptop security/tracking apps? Who didn't think this would eventually be abused by malware or some 3 letter agency?
What's even better than the malware back in the day that would attempt to modify known BIOS code, or maybe brick a BIOS it didn't know? A known documented API into UEFI that allows for "sanctioned" persistent code! yay!
UEFI and IME sounds like a 3 letter agencies wet dream.
No, it does not allow persistent code to exist any more so than any other firmware does. In fact, if you implement the UEFI specification and enable secure boot, this attack is impossible. Even if someone is able to add the payload to your flash file system, the firmware will detect the unsigned code and not load the module. The only way to prevent this kind of attack is to use a ROM. The problem with using a ROM is that any security issue that is found is entirely impossible to mitigate without replaci
Wait wasn't UEFI supposed to protect us? (Score:1)
Of course, silly me -- UEFI was never about protecting people's OSes from viruses, as originally claimed -- it was about enabling big vendors like Microsoft to be gatekeepers of what OSes we can install on *our* hardware; and adding lots of yummy complexity in which to hide backdoors for spooks.
By enabling Secure Boot ... (Score:3)
By enabling Secure Boot, and making sure their UEFI firmware is up to date, end users can protect themselves against attack, Vachon said.
This rootkit is *NOT* a bypass of secure boot. If UEFI Secure Boot is enabled, unsigned UEFI modules cannot be installed into the UEFI firmware configuration.
We've seen BIOS rootkits before. This is just an UEFI version of the same concept, except UEFI Secure Boot does exactly what it is supposed to do: Prevent unauthorized updating of the firmware.
Complete video of talk (Score:3)
Re: (Score:2)
Bringing you September's news, today!
+1
Re: (Score:2)
Re: (Score:3)
A jumper on the board would do that, and restrict upgrades to people who know at least the basics of hardware maintenance.
The firmware is right at the root of your trusted computing base. If you require opening up the case and moving a jumper in every machine to push out an update, then most people are never going to do it. This means that, if there's a security vulnerability then it will never be patched for 95% of users. Given that BIOS vendors are responsible for some of the worst code in production, which is often able to be attacked over the network or via USB, do you really think that this would improve security?
Re: (Score:2)
Most people only have the one, so "every machine" equals "one machine".
No, one machine per person equals a number machines equal to the number of people, not one.
Most people only have the one, so "every machine" equals "one machine".
No it isn't. Now, BIOS updates are pushed out as part of Windows Update for the majority of computer users. Apple pushes out UEFI updates as part of macOS updates, and I believe a couple of Linux vendors do so as well.