NSA's BIOS Backdoor a.k.a. God Mode Malware
resources.infosecinstitute.com
resources.infosecinstitute.com
https://sites.google.com/site/pinczakko/nsa-bios-backdoor-a-...
It took a while to find the original, it's a PDF rather than a web page and it was plagiarized within days of being published, google picked up on the plagiarized copy before it ever saw the original by the looks of it.
BIOS/UEFI Security Researcher InfoSec Institute June 2012 – Present (2 years 3 months)
Plus the OP's article was published before that PDF (January Vs. Feb).
As in the NSA literally going after foreign businesses and then turning around, and giving that information 1:1 to US corporations. That should be a pretty big scandal considering how much the US prides itself on being a capitalist market (i.e. survival of the fitness, not best politically connected).
But the US has a long history of this, and frankly at least they stopped starting wars in South American on the behest of US businesses so that's something...
Anyway, so that's why I think you're not hearing too much about that scandal - it comes as no shock to anyone it affects.
Another "tamper detection" idea, if you're OK with using proprietary BIOS and/or Coreboot isn't supported, is to add a small piece of code to the existing BIOS that simply hashes the ROM contents and prints out a human-readable string to the boot screen based on that. If it goes missing or changes, then you can suspect something happened. Of course, the trick is to not have everyone doing this with the same code, or backdoors will just detect and spoof it. I modded the BIOS of an old machine I have to do this, it prints out "Customised by {my handle}".
Long enough to see the POST screen where I put the message:
Award Modular BIOS v4.51PG ==Customised by XXXXXXXX==
is pretty hard to not notice, especially if it suddenly changed back to string in the OEM BIOS. The code I inserted basically computes my string by "encrypting" the original string with some constants derived from the whole BIOS image, so if the BIOS was only partially modified it turns into rubbish, and if it was replaced, then the string reverts to the original one. The point is that the BIOS on that machine is globally unique, has a feature that I can easily identify, and would be difficult if not impossible to forge by an attacker with only the OEM BIOS. I came up with this shortly after the infamous CIH virus emerged.Ditto for the NSA trying to flash a backdoored Coreboot: they would have to know exactly the customisations I made to my BIOS to replicate them, and if they did, then I'm probably pwned anyway. Backdoors in an offboard option ROM would certainly avoid modifying the BIOS, but I guess a similar mechanism could be used to customise one to easily detect its modification.
And in this case the malware is lurking in the RAID cards expansion ROM, so you wouldn't even notice a change at boot anyway.
Possibly, this could even be chained into the background of the main OS load sequence, such that you see something like a Perlin-style colorful noise pattern during the longest part of the boot sequence. This could even hash other parts of the loader besides the BIOS, too.
The idea being that you (probably) won't notice if
801EF9B138222F39EB2907634BC7FD47F9151919
changes to 40AE7CE2796FB14526ABB92B67BC0F1423B85B96
Almost everybody would notice if the boot sequence wallpaper that you've seen for months/yearshttp://cs263.markaoyama.com/img/p5_abs_perlin_5_gens.PNG
changes into
http://cs263.markaoyama.com/img/p5_perlin_5_gen.PNG
(images taken from a very brief GIS of random Perlin noise articles)
There are many alternatives. The key here is to engage the human visual system. Proof of why this work: the popularity of font-lock-mode.
[1] http://superuser.com/questions/22535/what-is-randomart-produ...
It does create another level of protection for the user, and another hurdle for the attacker, but it still requires user diligence.
Also, see my response to halfcat in a neighboring post.
Already looks fun, yet image magic depixelizer makes it awesome. I think once converted to custom tag it may gain adoption <fingerprint>05:1e:1e:c1:ac:b9:d1:1c:6a:60:ce:0f:77:6c:78:47</fingerprint>
In my IT experience, anything requiring manual human checking basically doesn't get done after the first handful of iterations. If it needs to be reliable, it needs to be automated. My best guess is, you can install a package from Dell to enable BIOS info to be pulled via WMI (Dell OMCI I think). You can set all of your BIOS asset tags to some unique value (per machine) and if it changes, your monitoring software will see it and alert you. I'm not sure how easy this would be to spoof though. It might be trivial.
Fortunately, most of the models they mention have been out of warranty for some years now, and most businesses choose to upgrade to a supported model. For businesses who chose not to upgrade to supported models, it's usually a reflection of the immature management in charge of the business, meaning they make poor decisions in many areas, so a BIOS hack is way down the list of potential problems for them.
I fully agree - that why I like this idea; it doesn't rely on humans actively doing something, and instead engages the subconscious. Because our brain is constantly making predictions about everything we perceive, we tend to notice (without trying) if something subtly violates those predictions. We see this effect when people describe how they felt something was "off" or "wrong" before some big event. They probably did see something important, but not enough to recognize it or parse it consciously.
Engaging the warning system that our fight-or-flight reflexes - which is very effective at processing visual sense input - is probably one of the more practical ways of getting past in this "humans won't bother" category.
Also, a visual-hash isn't really trying to be perfect anyway. It's just a trick that would be very easy to implement. It won't get anywhere close to catching all attacks. It would probably catch more than our current strategy of doing nothing. When you start from 0, any improvement helps. The only reason not to do this kind of scheme would be if it raised the costs, but I doubt that would be a problem given how much headroom we have in modern hardware.
I haven't looked into the relationship Chromebooks have with Coreboot: supposedly, Chromebooks use Coreboot, but how is it possible that they restrict the usage of OS to a signed one: do Chromebooks use modified Coreboot? And why is some models' status listed as "Unknown" in Supported Motherboards list?
So, I would love to use Coreboot and would actually consider going into some reasonable trouble to make it work on my hardware (including actually picking hardware that it supports), but I really don't see how it would be usable even for an enthusiast, and I don't see the situation changing anytime soon.
https://chromium.googlesource.com/chromiumos/third_party/cor...
Most of the Chromebook/box devices have a physical write-protect that can be removed allowing re-flashing with modified firmware.
For ARM Chromebooks the situation is more complicated - coreboot's ARM support was developed by the Chromebook firmware developers but it seems they missed a deadline or two (no surprise with an architecture bringup), so some of those devices ship with u-boot while coreboot does have support for them.
I understand it means that to the best of Coreboot developers' knowledge (and who knows better than them, right?) noone ever tried to run open-source builds of Coreboot on these models. Consequently, it is overwhelmingly likely that Coreboot (the open-source version that we have access to, not the one in the Googleplex) won't work. Am I mistaken?
I considered using C720 Chromebook with open-source Coreboot, but, alas, it says "Unknown" for it, too.
http://johnlewis.ie/ provides non-Google coreboot images for many Chromebooks. They claim having tested each of their binaries and from looking at the support forums, they have a fair share of users.
Also, the "Googleplex version" of coreboot can be found at https://chromium-review.googlesource.com/#/q/project:chromiu... (though it can be hard to pinpoint any given released firmware to a concrete commit there - they're working on it)
Who is this John Lewis guy and why isn't his work the part of the official Coreboot images?
John's images are kind of a coreboot distribution, as is libreboot (http://www.libreboot.org/)
As for the "Supported Motherboards" list, it's automatically generated from reports that are sent in through a tool. Google doesn't do that (yet?), so they're not listed as supported. Still better than our old, manually maintained list, that got stale fast (with false positives, which are much more annoying from a support standpoint than false negatives)
- A piece of hardware under the user's control that provides cyptographically secure key material that allows the BIOS to boot.
- Attestation by the booted thing that it is intact and untampered with.
Both of these need to be inspectable by the user. For the former you can use a dongle with a key on it, and this is probably testably secure by an end-user (we can talk about trusting silicon and your tools, but if you use multiple platforms and toolsets for verification that's probably pretty reasonable).
Knowing that the "enemy side" (the BIOS) hasn't been suborned is pretty hard and requires hardware-level support that you're not going to see outside of video game consoles.
For the truly paranoid, your best bet is to use a computer that has no physically attached peripherals that you can't monitor (e.g., USB). So, USB-attached network adapters and so forth.
This stuff is hard.
I wonder how many exploits the Five Eyes have for Tahoe-LAFS running on LVM disks. I'm betting on very few.
Or is there solid evidence that these countries aren't engaging in the same stuff as the NSA?
Do you disagree that he made the right decision?
Is there solid evidence that these countries are engaging in the same stuff as the NSA?
I have never heard of a similar public leaker from Russia or China (I imagine those people just quickly get disappeared).
As for BRICS country spying, we have some very solid evidence that China is engaging in cyber espionage of both US military and corporate targets.
PS. I am not arguing that they should not be in jail. Just that NSA used semi-legal (waterboarding!=torture kind) methods to obtain initial leads.
I don't think so.
How likely is it that China spying on you will actually impact your life, if you're living somewhere in the US or Europe?
Compare this to How likely is it that the US spying on you will actually impact your life, if you're living somewhere in the US or Europe...
I mean sure, this may be a relevant consideration for actual terrorists, but hardly for "regular" people that are more concerned about mundane details like their unhealthy dietary habbits being leaked to insurance companies, or their downloading of youtube videos being leaked to copyright holders.
[1] http://money.cnn.com/2014/05/20/news/china-espionage-busines... [2] http://www.theguardian.com/world/2013/sep/09/nsa-spying-braz...
But, I think you're right, you're unlikely to be caught in dragnet-style surveillance by the Five Eyes nations, but this style of attack sounds like it has to be targeted.
How exactly did you do this? Obviously the company assembling the pieces (like CPUs and chipsets) into the final PC isn't really the issue, but rather the companies producing those pieces - and virtually none of them are outside the US, seeing as how there's only Intel (and maybe AMD).
Your idea sounds good, and I'd like to adopt it, but I just don't see how, with x86 hardware.
Then again, maybe this'll be a major selling point for ARM-based Servers and Desktops at some point in the future? :x
The desktops are all arm-based thin clients running X servers with all apps hosted remotely. If a device fails, plug in another one and keep working.
Richard Stallman abandoned Five Eyes-based chipsets for the same reason, long before I ever did. We should look to him more for inspiration on how to remain free during these draconian times.
If you think that because you are running less popular hardware, that the NSA wouldn't bother obtaining exploits for them, you may be right. In that case, though, you're simply making a popularity trade-off. (And it is a trade-off, more popular hardware is more popular for a reason.)
Both the RK3xxx and A23 chips are fully supported in Linux 3.16, so I see no trade-off. Just low wattage and a bit of peace of mind that my government has to custom-tailor exploits for me and my companies, which isn't very cost-effective. :-)
But that jumper cost money, and perhaps more importantly confused half the sysadmins and users out there. So the jumper is gone. Any program that knows the magic output sequence can overwrite the firmware. We're relying on security through obscurity to save us.
And if I'm Dell, I'm thinking: Hey, what about HP? What about IBM? Why single me out? Most if not all of these computers are vulnerable to similar attacks.
http://www.absolute.com/en/partners/bios-compatibility.aspx
It's capable of phoning home, deleting or replacing files on the operating system and wiping out the system. It can persist across re installations of support operating systems. When combined with AMT features it can permanently brick the device as well.
because even a rudimentary NTFS driver would require at least several tens of kilobytes of space when compressed
The Computrace option ROM is a little over 20KB (compressed), yet it contains much of the functionality of the NSA backdoor described in the article - including write-support drivers for FAT/FAT32/NTFS.
http://securelist.com/analysis/publications/58278/absolute-c...
So the reason for using the RAID controller's option ROM may be for stealth instead of size restrictions, and it also means that, if the NSA can tell Absolute what to do, they already have a BIOS-level backdoor into nearly everyone's machines.