Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Security

Security Industry Incapable of Finding Firmware Attackers 94

Posted by Unknown Lamer from the just-use-coreboot dept.
New submitter BIOS4breakfast writes "Research presented at CanSecWest has shown that despite the fact that we know that firmware attackers, in the form of the NSA, definitely exist, there is still a wide gap between the attackers' ability to infect firmware, and the industry's ability to detect their presence. The researchers from MITRE and Intel showed attacks on UEFI SecureBoot, the BIOS itself, and BIOS forensics software. Although they also released detection systems for supporting more research and for trustworthy BIOS capture, the real question is: when is this going to stop being the domain of research and when are security companies going to get serious about protecting against attacks at this level?"
This discussion has been archived. No new comments can be posted.

Security Industry Incapable of Finding Firmware Attackers More

Security Industry Incapable of Finding Firmware Attackers

Comments Filter:

  • The thing is, while these are the hardest to fix and address of attacks, they're among the least useful for attackers. You can't spam people from BIOS. You can't really keylog and transmit over TCP from BIOS.

    The operating system is as useful to attackers as it is to us other programmers.

    • Re: (Score:3, Insightful)

      by flyingfsck ( 986395 )
      Wrong. All an infected BIOS call needs to do is launch a process that will keep running and do its damndest when the system is up.
      • The problem is, firmware is *tiny*. There is only so much it can be capable of. No matter how much ingenuity the attackers will put into its programming, the attack won't be able to survive aggressive threat mitigation actions such as airgapping the computer. Even recording and monitoring all the incoming and outgoing network traffic and using the computer in a sufficiently restricted way would at least tell you if something is going on. It's like with submarines, they're only stealthy until they pump out a

        • Have you seen newer motherboards? They have 16mb+ of flash for the BIOS.
          Oodles of room to do fun stuff in.

        • Modern motherboards (even cheap ones) can access the filesystem in BIOS.
          • That's not what I had in mind. You can't cram a strong AI system into it. Without that, the machine would have to be fully connected for the exploit to be adaptive to any possible attack mitigation technique. On its own, it can't perform miracles like adapting to software systems that didn't exist when the firmware was written (for example, a new file system, since you're mentioning that - or whole kernels, for that matter). Not without visibly breaking something.
            • And? Malware get depreciated quicker than any other type of software, due to exploited getting found and fixed. Obviously any malware targeted at firmware has an air or permanence to it, but even that will get depreciated when the hardware is replaced or firmware upgraded.

              Also worth noting is it depends on the particular device being targeted. For example, the firmware in the SCADA systems Stuxnet targeted is completely reliant on the PC connected to it. Disable the PC and you effectively disable the malwa

    • Re: (Score:1)

      by Anonymous Coward

      Yes you can.

      Especially if the system is attached to a network with a DHCP server.

      UEFI is equivalent to an OS, and is written the same way.

      BIOS is a little bit more limited - but not much. You can include a DHCP client to get a local IP number.

      • Big problem with BIOS is that it is board/chipset-specific. And very tiny. Not un-doable, but not scalable.

        These were some of the BIOS constraints that EFI/UEFI were created to surpass.

    • Re:Least interest (Score:4, Interesting)

      by EdZ ( 755139 ) on Wednesday March 19, 2014 @11:47AM (#46525177)
      What you CAN do is exploit an otherwise secure OS so that you CAN do those things in spite of OS-level security methods.

      I miss the days of needing a move a jumper in order to flash the system ROM. I've seen plenty of gaudy 'overlocking' boards with push-buttons on the motherboard itself for various esoteric functions. A toggle-switch for BIOS-write-enable would be a relatively cheap addition, and manufacturers can market the board with some extra security buzzwords.

      • Re:Least interest (Score:5, Insightful)

        by rtb61 ( 674572 ) on Wednesday March 19, 2014 @12:47PM (#46525627) Homepage

        Which means basically when they start intercepting hardware between the manufacturer and the user, security becomes an impossible mind fuck. Once it all shifted to firmware and hardware hacks the security game is over. Parallel networks where the inside network is fully air gapped from outside networks and the building itself is secured from wireless communications. Basically all internet function are done on disposable net books, this more for typical businesses rather than internet business. Apparently Russian security has gone back to typewriters and hard copy for the most secure documents, actual physical penetration is required. With the NSA continuing to fuck around with security, how long will it be before banks go back to manual systems and internet banking becomes a memory.

        • and internet banking becomes a memory.

          That depends. No level of compromising your (general purpose) computer should be able to defeat the security of your manually operated hardware token/calculator.

          • and internet banking becomes a memory.

            That depends. No level of compromising your (general purpose) computer should be able to defeat the security of your manually operated hardware token/calculator.

            Attacker has control of my computer. I read a number off my MFA device and input it into the bank's form along with my username and password.

            Now attacker has a banking session they can do whatever they want with. How has having a hardware token prevented them from attacking me?

            • No, they can't. At most they would be able to, say, view your account balance etc., but the token can be (and most of the time is) used to authenticate any transaction based on its input values (how much to transfer, where, with what payment codes etc.).

    • Re:Least interest (Score:4, Informative)

      by Anonymous Coward on Wednesday March 19, 2014 @11:48AM (#46525191)

      Nice try, but it runs in ring 0, so it can jump into the kernel anywhere it wants.

      • Nice try, but it runs in ring 0, so it can jump into the kernel anywhere it wants.

        Worse than that after boot, the BIOS runs in System Management Mode, which is delberatly designed to be non-interceptable by the OS.

    • But you can and it's useful (Score:5, Insightful)

      by dutchwhizzman ( 817898 ) on Wednesday March 19, 2014 @11:52AM (#46525225)

      Most bioses now have a complete TCP/IP stack for things like ipmi. Keylogging only requires a few simple routines to do as well; plenty of room to implement that in current flash chips on main boards.

      Hiding in firmware makes you resilient and virtually undetectable on the "normal storage". A rudimentary base to pull next stage software in that will "bootstrap" the full malware once the OS installed is all that is needed. The full malware can be fragmented and re-use existing binaries so it won't be detected. You need a trusted platform and guaranteed "safe" steps to be able to reasonably trust your computer and when firmware contains holes or malicious code, there are plenty of people that don't work for the NSA that can actually build a competent attack for that.

      • Re: (Score:2)

        by Kremmy ( 793693 )
        Most BIOSes + NICs have that little PXE booting stack hanging out in the option ROM. It's really not that farfetched by any means.

    • Re: (Score:2)

      by mlts ( 1038732 )

      On some machines, they have out of band management features, even dedicated NICs for this purpose. Get full access to a BIOS, and the machine can easily have a functioning IP stack and be at the control of an attacker even if the machine has no OS present.

      Another item would be a flashable BIOS like a security issue with some Apple keyboards. Nothing beats using the keyboard controller itself for a keylogger.

    • Actually most BIOS (legacy or UEFI) have a network stack of some sort in order to support PXE boot. Recall that the PoC BIOS malware Rakshasa (https://media.blackhat.com/bh-us-12/Briefings/Brossard/BH_US_12_Brossard_Backdoor_Hacking_Slides.pdf) used the open source SeaBIOS and iPXE network stacks to perform networking from the BIOS. And here's a talk where some McAfee and Intel folks talked about how keylogging can be done from UEFI thanks to function pointer hooking (http://intelstudios.edgesuite.net/idf/

    • Re: (Score:2)

      by Kremmy ( 793693 )
      The vast, vast majority of personal computer units with integrated LAN cards happen to have network boot capability built in. It's been there since before they were an integrated component, even. Intel and Realtek make most of the ethernet chipsets I see around, and they both use a pretty bog standard PXE network booting stack. BIOS hackers would be acutely aware of it, I wouldn't be surprised if that's been exploited in some strikingly silly manner and used for this kind of thing.
    • BIOS malware can install System Management Mode code that logs keystrokes. Please read: http://www.phrack.com/issues.h... [phrack.com] http://www.eecs.ucf.edu/~czou/... [ucf.edu]

  • Because you know, if it isn't secure, then it's not firm.

  • A good start would be a list of hardware vendors that sell equipment that have hardware jumpers or switches that write protect the BIOS and other flash devices.
    • While hobbiests who use custom motherboards are familiar with write protect jumpers, they are going the way of the dodo. They've been all but phased out on OEM laptops, and are going that way on desktops too.

      The important write protects are whether the BIOS configures itself as locked or not after it's booted far enough to determine there are no BIOS updates pending. You can check if your BIOS is open or closed to attackers by running Copernicus [mitre.org] or Chipsec [github.com].

  • Duh, what should we do? (Score:3)

    by DriveDog ( 822962 ) on Wednesday March 19, 2014 @11:47AM (#46525171)
    So... open source everything, that anyone can compile to executable. Then focus on obfuscated code, about the only avenue left for malicious code. It only takes one major manufacturer to publicly announce that "we're publishing our code so that it can be verified, unlike our competitors" for it to spread to the competitors.

    • It only takes one major manufacturer to publicly announce that "we're publishing our code so that it can be verified, unlike our competitors" for it to spread to the competitors.

      OEM1 releases full source
      OEM2 fires all BIOS developers and leeches off OEM1
      OEM1 has the privilege of maintaining a BIOS development workforce for the benefit of their competitors

      Though maybe that would work as a feint to eventually put competitors at a disadvantage ;-)

      Also, believe it or not, OEMs and places like AMI, Phoenix, etc do actually try to add features down at the firmware level that their competitors don't have, to differentiate themselves and hopefully get a few more sales. E.g. recall th

      • Yep, that's why everyone just uses Windows now, since it's freely available thanks to Microsoft releasing the full source code in their Shared Source program. When that happened, other companies just took it and sold it as their own.

        Oh wait, that never happened.

    • Re: (Score:2)

      by gtall ( 79522 )

      Nah, competitors will steal your code and put you out of business. And publishing your code is more or less meaningless unless there's a legion of qualified people willing to examine it. And why would they do that? What's in it for them? Aside from a few big FOSS projects (Linux, et. al.), the only people looking at your code are either miscreants, your competitors, or your country's competitors.

      Joe Sixpack: I wanna buy a router for my XP machines.
      Eve Clerk: Well, here's a Cisco router, it works well. And h

  • Use a jumper (Score:4, Funny)

    by techno-vampire ( 666512 ) on Wednesday March 19, 2014 @11:48AM (#46525187) Homepage
    I can remember when there was a jumper on the motherboard that had to be shifted before it was possible to flash the firmware. If all motherboards had that, the only way an attacker could get malware into the BIOS (or whatever other firmware they wanted to target) would be by tricking the user into changing the jumper. Not only that, many of the users who'd be foolish enough to fall for that kind of trick wouldn't have the confidence to open up their box and play with the hardware. Not all, of course, but then, no security measure is 100% effective.

    • While I am not an expert, I don't believe that we're just talking about reflashing here. It is possible that the firmware relied on to perform operating system functions in exploited all the way back in user-space. Some program gets some arguments from somewhere that get passed on to the kernel level, the kernel then passes that to the hardware and voila, exploited.

      • No, what you're thinking of is drivers. Firmware [wikipedia.org] is held in non-volatile memory and executed there so that it's ready to be used the moment the device is turned on, and so that it can't easily be modified.

        • And what do the drivers communicate with? The firmware.

          Your normal device will provide a memory mapped structure to the device where values are read and stored. They use IOCTLs to command the hardware usually through interrupts. The Firmware has the corresponding data structure on its side. I'm not an expert but I have written a kernel driver or two, but not recently.

          • And what do the drivers communicate with? The firmware.

            Well yes, of course. However, drivers tend to be OS specific, and can be reloaded fairly easily if infected. TFA is talking about getting malware into the firmware, which has to be OS agnostic and is somewhat harder to disinfect.
      • Yeah that's basically right. UEFI specifies the need for the storage of non-volatile variables for some configuration or metadata (which can be modified from admin userland as you said). All of the BIOSes I've seen have used the flash chip itself to store this data, therefore the chip must be modifiable and a jumper would not work with these designs. There are mechanisms that can be used to allow writability of certain regions of the chip, but often they are not used. Even when they are used, there are

    • Re: (Score:2)

      by mlts ( 1038732 )

      I remember that as well. Yes, it is easier to just double-click a program and have it flash a BIOS... but it is nice to have security not just relying on 1-2 crypto signatures which might be compromised.

      If not a hardware jumper, perhaps a dedicated mode in firmware where the machine needs rebooted to. Then a UEFI application can be run for the actual BIOS upgrade where it would display the would-be firmware's cryptographic hash (preferably both SHA-3 and MD5), check and display signatures, then either hav

  • They're not. (Score:3)

    by IWannaBeAnAC ( 653701 ) on Wednesday March 19, 2014 @11:58AM (#46525255)

    They're never going to fix this. It isn't just a matter of publishing source code, it affects the hardware too. It needs hardware protection on the flash, for example, so that you can control, at a hardware level (eg by a button on the device) whether the flash is writable.

    But by now, all of the manufacturers are so infiltrated by other agencies, the NSA, foreign governments, and business interests (having the user in control of their own security directly contradicts the aims of DRM, not to mention marketing companies); this all conspires against ever having any security over your own firmware.

    Build it yourself is probably the best bet. And the nice thing is that this is becoming more practical. The biggest problem is that there is no way to verify the hardware at the chip level, but with careful design it is possible to get reasonably good security without 100% trust in all of the individual components.

    But for the overwhelming majority of people, who are not motivated or able to build their own, their tech is doomed to be compromised. I don't think there is anything that can be done about that. It is a political issue, rather than technical. And in all "democracies" that I can think of, the political will is against it.

    • There are foundation technologies to address this - Intel Trusted Execution Technology (TXT) and Trusted Platform Modules (TPMs). You can take measurements with TXT and store them securely in TPMs. Attesting remotely will tell you whether or not you have a good/valid/trusted system that has good/valid/trusted measurements from the TPM. This is not a lost cause, and there are companies out there taking advantage of TXT & TPMs to establish trust. This can shrink the perimeter down to the CPU. If yo

  • Attacks on UEFI... (Score:4, Informative)

    by Obfuscant ( 592200 ) on Wednesday March 19, 2014 @12:00PM (#46525275)
    Would that include "attacks" that allow OSs other than the officially state-approved and certificate-signed ones to be booted. Like that hacker-prone and highly illegal "Linux" thing I've been hearing about? I'm glad that researchers are protecting us against such flim-flammery and obviously dangerous stuff.

  • Visibility (Score:3)

    by maz2331 ( 1104901 ) on Wednesday March 19, 2014 @12:16PM (#46525393)

    There is really no way for any code running on top of another layer to verify that lower layer's integrity - it has to rely on what is reported and a malicious BIOS or UEFI layer can simply just lie to it. Hell, it's possible for a low-level hypervisor to run another, clean, BIOS/UEFI and simply virtualize every piece of hardware in the box. Likewise, it can block visibility of any traffic going in and out that it desires. This type of security has to happen at the network level instead - something outside of the device has to detect the suspicious traffic that such an attack must generate in order to be useful. That in turn requires that the networking gear has to be trustworthy and not itself owned by the attacker or have any backdoors installed at the factory (or chip maker, or etc etc).

    • Re: (Score:2)

      by blueg3 ( 192743 )

      There is really no way for any code running on top of another layer to verify that lower layer's integrity - it has to rely on what is reported and a malicious BIOS or UEFI layer can simply just lie to it.

      Theoretically, yes. Practically, it's often not that easy to "just lie to it". (So, in practice, it becomes an arms race of effort just like everything else.)

      For example:

      Hell, it's possible for a low-level hypervisor to run another, clean, BIOS/UEFI and simply virtualize every piece of hardware in the box.

      That's easy to detect through timing attacks, it turns out. You would also have to be very careful to exactly replicate the behavior of the hardware you're virtualizing, or that's detectable, too.

      something outside of the device has to detect the suspicious traffic that such an attack must generate in order to be useful

      Now, talk about difficult problems! The easy part would be having trustworthy networking gear. The hard part would be that "detect the suspicious

    • You can validate the system is in a known, good state at boot-time, but that does not apply at run-time. You can use Intel Trusted Execution Technology (TXT) to measure the system is in a known, good state and store those measurements in the Trusted Platform Module (TPM). When you attest remotely, if the whitelist values do not match, you do not admit the system into your infrastructure. This approach can take measurements up to the VM-layer (hardware/firmware/BIOS/hypervisor). There are solutions to att

  • This is on the heels of an announcement by NIAP that common criteria evaluation of operating systems is too hard:
    https://www.niap-ccevs.org/Documents_and_Guidance/ccevs/GPOS%20Position%20Statement.pdf

  • incentives (Score:3)

    by Chrisq ( 894406 ) on Wednesday March 19, 2014 @12:31PM (#46525509)

    t we know that firmware attackers, in the form of the NSA, definitely exist, there is still a wide gap between the attackers' ability to infect firmware, and the industry's ability to detect their presence.

    I bet the NSA can give a lot of incentives to companies not to look for or remove firmware back-doors - or even to introduce them. This could be carrots (lucrative contracts or info on what overseas competition is doing) or sticks (not getting the government contract or the CIO's wife finding out what he said in those phone-calls to his secretary).

    • It doesn't even have to do anything sinister - just say "if you want , we need to be able to audit your source code". They find the security holes themselves, tell the vendor about one or two minor ones to hide their intentions, then use the flaws they didn't disclose to hack others. The vendor wouldn't see anything that makes the NSA look even remotely sinister. Best part is that the vendors who aim for US government contracts, particularly ones needing security audits, will be the ones aiming for other go

  • When are they going to start taking security seriously? When consumers are willing to pay more money for more secure devices. So, never.

    • Re: (Score:2)

      by Lumpy ( 12016 )

      Why do I have to pay more? I suggest they make less obscene profits and lower executive wages to cover the cost of doing business.

  • when is this going to stop being the domain of research and when are security companies going to get serious about protecting against attacks at this level?"

    As soon as someone with a powerful attorney and deep pockets gets hacked via this vector and sues the OEM into oblivion would be my guess.

  • You said they either find the firmware hackers or they don't.

    You missed the "it's a feature, not a bug" solution.

    Please go back to Logic School.

  • When is this going to stop being the domain of research and when are security companies going to get serious about protecting against attacks at this level?

    When the NSA stops paying them to ignore it.

  • they CAN deal with this. require a physical jumper on the device to be moved for firmware loading. all devices leave the factory blank and they flash their firmware in house when they arrive.

    They dont want to do that, they want the 100,000 items to ship from china and never be touched again. Boo Hoo. man up and touch every item state side to protect your products integrity.

    The CEO's bonus check would cover the required costs.

  • Just a thought: Intel and MITRE are both Rockefeller companies (the majority share holders in both Apple and Intel were originally the Rockefeller family, by way of Laurence Rockefeller, and I've yet to see anything suggesting that has changed). And, the owners of the semiconductor company (Freescale Semiconductor) well-represented on that missing Malaysian MH 370 flight are the Blackstone Group and Carlyle Group (Blackstone Group began with seed money from David Rockefeller, and its co-founder, Peter G.

  • Hardware gap (Score:3)

    by C18H27NO3 ( 1282172 ) on Wednesday March 19, 2014 @02:13PM (#46526573)
    At least one of the systems I've owned in the past required a jumper to be set before BIOS could be written to/flashed/modified.
    I thought that was a boon and would certainly defeat any nefarious flashing. Something like that should be standard.

  • Google tries to get security right for Chromebooks. A read-only portion of the firmware authenticates the read-write firmware. The read-write firmware must be signed by google. You must disassemble the machine to flash the read-only firmware.

  • I have seen some particularly nasty malware hidden in many BIOSes recently. The payload has the effect of preventing you from installing legitimate operating systems on your own computer without paying large amounts of money to an extortion operation.

    So far I have traced the perpetrators as far as Redmond, WA.

  • I have seen some particularly nasty malware hidden in many BIOSes recently. The payload has the effect of preventing you from installing legitimate operating systems on your own computer without first paying large amounts of money to a large extortion group.

    Through my research I have managed to trace the perpetrators to Redmond, WA.

Slashdot Top Deals

Put your Nose to the Grindstone! -- Amalgamated Plastic Surgeons and Toolmakers, Ltd.

Close