Submitted by The U.S. National Security Agency has figured out how to hide spying software deep within hard drives made by Western Digital, Seagate, Toshiba and other top manufacturers, giving the agency the means to eavesdrop on the majority of the world’s computers, according to cyber researchers and former operatives.
That long-sought and closely guarded ability was part of a cluster of spying programs discovered by Kaspersky Lab, the Moscow-based security software maker that has exposed a series of Western cyberespionage operations.
All the articles I’ve found about this are all this kind of high-flying fluff and don’t actually delve into the actual technical details, like e.g. how does it infect the system from the drive and what does it do after the infection, how does it infect the drive in the first place and could the OS do anything to prevent or at least hamper the progress of something like this.
We may guess that this endeavour – http://spritesmods.com/?art=hddhack – from two years ago has strong relevance to NSA techniques.
So far, this is the best document I’ve seen so far:
https://securelist.com/files/2015/02/Equation_group_questions_and_an…
Hi WereCatf. As I said when the UEFI issue surfaced: First in the stack Owns the stack. Where can I locate the stack? Everywhere you like [even the microcode].
Known or suspected many years. You have to take into account the actual cold East-West relationship as a reason for this news being actually ‘news’.
Network Risks are pandemic or epidemic in nature and have to be assessed in a ‘presto’ and proportionate form not always according to local and international laws approved in the slow and regular way.
Now -as a citizen of one of the affected countries- I am very sad at the confirmation of this very long time suspicion.
Firmware has been and is going to be a very bad idea, anyway.
WereCatf,
Just speculating, but it would make sense that the drive is substituting a trojan payload to replace a legitimate payload. It could be something obvious like a bootloader, or maybe something like DLL/EXE/CMD files, or even configuration files/registry keys. In theory many kinds of substitutions would be possible with a sufficiently powerful controller. Our HD’s are already packed with plenty of ram – 32-64MB are common.
Given that commercially available SD cards like the Toshiba FlashAir and EyeFi are already known to be capable of reverse engineer the FAT file system on the fly inside a running host to transmit the content over WiFi without any host coordination, something like this could also be possible inside a HD (minus the WiFi obviously).
So for a hypothetical attack on windows:
A user runs any EXE application, the HD substitutes a trojan, which windows loads and executes as the user. This trojan establishes a covert communication channel with the infected HD (simply by reading/writing completely “innocuous” user files). Now, with a side channel access to the raw disk, the userspace application can subvert operating system protections to change system files, read/modify administrator security keys, etc. And it can also establish control channels over the internet.
With raw disk access, many variations of privilege escalation become possible. On linux for example, the setid bit could be set on the directory entry for “xargs”, thereby allowing unprivileged users to run commands as root.
I think these kinds of attacks would be more successful if specifically targeted. A generic multi-platform exploit would be more difficult, but not inconceivable. It could detect the signatures for MacOS/Windows/Linux/etc binaries and substitute the corresponding payloads.
Simple solution, store your OS and data encrypted on the storage.
The question is: how to bootstrap that process.
You can’t read the code for decrypting from the storage device.
So you would need to make that part of the firmware.
So you’d probably need to use Coreboot and include a minimal Linux kernel which asks for the key or whatever method you’d use.
Don’t forget to have a hardware switch to disable updating of your firmware.
I’ve not seen anyone build this though. 🙁
Lennie,
I think that might do the trick, although if the encryption keys are saved on the hard disk in a standardized way, it might still be vulnerable (I’d need to research this more).
This may be getting far fetched, but at least in theory it could substitute the entire hard disk with another bootable image. This could run a Virtual Machine wrapper, booting up the original encrypted OS under control of the trojan.
http://www.blackhat.com/presentations/bh-europe-07/Bing/Presentatio…
Someone will probably say secure boot is designed to protect from bootup modifications, however it’s effectiveness depends on the trustworthiness of the system manufacturers/microsoft in possession of the root keys. If they have transferred the keys or signed code for the NSA (man on the inside, secret court order, etc), then it negates the protection.
I’ve wanted to tinker with Coreboot for many years, but I was always afraid of bricking my mainboards. Anyone here have experience with it?
No, you don’t save the encryption keys on the storage device.
My suggestion was to include decryption code in the firmware image and let the user provide the decryption key. But how you would provide that key to the computer without talking to any firmware is a bit of a question. Because for example most keyboard are USB-devices with firmware.
Only if the decryption/encryption code doesn’t add a meta-data to the data (like cryptography signed hashes) so it can be verified if the data was modified or if that meta-data is not properly checked.
Edited 2015-02-18 21:10 UTC
Lennie,
The key is in what form? A USB thumbdrive?
We’d need to store the key _somewhere_ (even if it requires a password). Entering a password adds some security, but it will never contain enough entropy on it’s own to generate, say a 256 bit AES key. The trouble with passwords is that the goal of convenience (short passwords) is diametrically opposed to security (long passwords). Another problem is that if we require unattended boot, then we can’t really password encrypt the files needed to boot.
I concede if we are willing to implement a custom firmware, we could engineer whatever checks we wanted to thwart this kind of HD attack. Still, it would be a fairly uncommon thing to do.
What you do is create a passphrase like with a Bitcoin/Crypto Currency ‘Brain Wallet’:
https://brainwallet.github.io/
Don’t know if they did the same with the brain wallet, but you usually also use a Key derivation function: https://en.wikipedia.org/wiki/Key_derivation_function
Lennie,
Well, the problem is not algorithmic, it’s one of entropy. Computers get faster/more scalable at brute forcing human passwords than most humans get at remembering stronger passwords. It’s a fundamental problem because even the strongest crypto algorithms will fail without sufficient entropy.
So technically even though we can use a key derivation function to generate a AES256 key from a typical password with maybe 40bits of entropy (*1), the resulting encryption is not going to be all that secure from brute force attacks. A determined adversary would likely be able to crack it, if not using their own equipment, then maybe on something like amazon EC2.
*1 Here’s a neat tool to give a rough/simplistic idea of password entropy:
http://rumkin.com/tools/password/passchk.php
Edited 2015-02-19 01:42 UTC
So I entered some silly passprase and got:
Length: 31
Strength: Strong – This password is typically good enough to safely guard sensitive information like financial records.
Entropy: 118.5 bits
Charset Size: 27 characters
_____
The key derivation function won’t make the entropy any better.
But it will slow down (maybe deter) a brute force attack. Because what usually happends with a key derivation function it’s a function which is applied a 1000 times.
This means, password or in this case passphrase guessing will take a 1000 times longer.
Now you can easily parallelize this, but when you need to get a 1000 times more EC2 time, it’s going to cost more too.
Lennie,
Well, if you really do use 31 character passwords for your logins then good for you! I’ll admit that 31 character passwords is very good (much more so if those characters were random and not part of a phrase).
That’s merely an impediment, it’s not going to make the difference between the system remaining secure or being cracked. Dedicated attackers would have access to much faster cracking machines built with massively parallel CUDA cards (supported by EC2) or even hardware ASICs. For the NSA, I wouldn’t be surprised if they have contracted with a fab like intel to produce chips that do nothing more than calculate tens of thousands of hash rounds in parallel. A cluster of such chips would be extremely effective at cracking many common password hashes.
Never the less, if your goal is to make the costs of breaking it as expensive as possible, then you should be looking exclusively at memory hard hashes rather than merely increasing iterations:
https://password-hashing.net/submissions/specs/Yarn-v2.pdf
Edited 2015-02-19 15:14 UTC
Yes, you are right. Memory hard is a good idea.
Anyway, to get back to one of my original comments:
I’ve never seen anyone build such a machine.
So basically, as the security experts:
I assume every machine I work with is already compromised.
Which is just a sad state of affairs.
Lennie,
A bit tangential, but bitcoin has created a market for these kinds of brute force hashing machines.
http://bitcoinexaminer.org/7-awesome-asic-bitcoin-miners/
I know the feeling.
No, I didn’t mean a cracking machine. I mean a machine properly set up with all the data and program code on the storage properly encrypted.
Where is he to feel upset about this anti-competitive behavior ?
Enjoying the information flow and probably watching sports on the side. Either that or touring the world on tax payer money like he always does.
The US certainly likes to meddle doesn’t it..
I find all these revelations about the US/NSA/FBI/CIA interesting and disturbing in equal measure but what I’d really like to know more about is the UK’s GCHQ activities. It’s been stated many times that they make the NSA look like kindergartners.
Clearly they are more better at what they do, because no information about they do has been leaked. 😉
Just stunned, I say. I’m sure they they must have spit their 200 proof Vodka all over my Social Security/Credit Card Number with the utter shock of it.
Edited 2015-02-18 13:20 UTC
Such eloquence
Yeah, sorry, I’m just not feeling the outrage. Kapersky’s hands are hardly clean given his/its cozy relationship with Putin. Kapersky is an ex-KGB officer with ties to Russia’s Federal Security Services. I wonder how much of Russia’s cyber-espionage Kapersky has exposed? Any guesses? The NSA is no saint, but neither is Kapersky.
Yet another batch of malware from well-known terrorist organization. Apparently most of exploits they use are already well-know, and some vulnerabilities were already patched. As always, clear rules help mitigating risks:
1. Don’t install Java in security-sensitive operations.
2. Don’t expect any level of security on Windows.
Kaspersky’s report suggests that OSX users might be vulnerable as well (based on user-agents of victims in intercepted connections).
All in all this news is merely a confirmation of long-suspected issue. It’s a shame we don’t have any control over our own hardware yet.
Don’t use Windows is facile, stupid advice. We’ve had enough OS X and Linux vulnerabilities lately to know that anyone dedicated – and the NSA is certainly dedicated – will find exploits in any system.
Java isn’t as bad as it’s made out to be either. You’ve got a tradeoff – Java lets you’re browser do a lot more than HTML could, but that extra power comes with extra risk. Is it worth it? In a lot of cases no, but that’s not the fault of Java – it’s the fault of people using the wrong solution for their problems.
Same as Flash. It’s foolish to use Flash for advertisements when there are much simpler, safer ways to do that, but that is not a flaw in Flash itself.
Sure. But they mostly focus one one particular system, and not without a reason: selection of Windows exploits will penetrate more targets, at least due to Windows market share.
It’s long since I’ve seen in-browser Java applet that did something more advanced then off-the-shelf web app. And if an application has to do something more advanced, it may as well be native application. At least it may avoid whole lot of security and usability issues, which dominate each and every java applet.
Edited 2015-02-18 19:37 UTC
ddc_,
The NSA aren’t like normal hackers though, it’s targets may not correspond to market share. It’s very possible (maybe even likely) that linux targets are more valuable to the NSA than windows ones because of it’s more data centric server roles.
In any case, I think it would be wise to assume that the NSA has root kits for all popular operating systems, they just tweak it to use the platform specific exploits Du Jour.
I only know of one Java-applet I’ve run in the last couple of years on my home computer:
http://netalyzr.icsi.berkeley.edu/
Which can test your Internet connection if certain applications are blocked or trottled by your provider or something is misconfiguration.
It does this by creating tcp-connections and sending UDP packets by itself and getting direct access to statistics.
This is clearly something which was never part of the normal Web API, so that is why Java applet it used.
And that would be best served by ordinary desktop application. There’s nothing in the task that could possibly require runninf the app as in-browser applet, or using java.
They wanted something which is easy to use by the user (because they want even ‘normal people’ to run it and sent the URL of the report to someone more knowledgeable).
So they went with a Java-applet.
You can also download it and run on on your desktop though.
They choose Java to make sure it’s platform independent.
I still see no reason to believe that Java was appropriate here. I see no big difference between requiring user to install software and requiring user to install runtime.
Ironically, to date I used only one Java application that could run on both Windows and Linux without modification (it had problems on several other platforms though).
They application was build more than 5 years ago I believe. So at the time more people already had Java installed.
You should always look at decisions people made within the context they were made in.
Not saying it was a great idea, but I can see why they made the choice.
But hey, I’m a pretty big proponent of cross-platform supporting technologies.
For example I was just playing an old DOS-game in a DOS-emulator ported to Javascript/asm.js: https://archive.org/details/msdos_Wolfenstein_3D_1992 on a Chromebook with ARM-processor and with Firefox/Linux desktop installed. 😉
I’m waiting for the Windows 3.11 port to become public as well: http://ascii.textfiles.com/archives/4546
Those kind of thing makes me excite, that there is nothing to install, because everyone already has a browser. ‘it just works’. Maybe I’m not an average user of computers though. 😉
Edited 2015-02-18 23:55 UTC
This argument is fallacious as it implies that all systems are equal. I could use the same argument with scientific theories. If you look hard enough you will find anomalies in all scientific theories – for example Ptolemy’s geocentric model and Quantum mechanics, therefore not using Ptolemy’s geocentric model is facile as they are both equal. Obviously they are not, in the same way as Windows 98 and OpenBSD are not equally exploitable.
Yes they can, but the open nature of the code means that it can be more easily be investigated and audited. These issues more easily resolved, in comparison with closed source systems. As I’m using Science as an analogy, mistakes were made in Western and Soviet genetics; however, fixing Lysenkoism took at lot longer and killed a lot more people than similar mistakes in the West, because the western system was much more open and therefore receptive to criticism.
The OpenBSD approach with no closed sourced software even in device driver code begins to seem entirely rational rather than just ideological.
You can get the same from GPL fanatical Linux distos. I prefer to install the “nonfree” drivers on Debian though, better to have a working system.
The malware isn’t in the drivers, it’s in firmware that’s built into to the hard drives. No matter what OS or applications you use, the drive’s firmware is the same.
And even if Seagate (for example) released the source code to their firmware, how would you know whether your hard drive actually contained that open source firmware, or whether your drive had been intercepted by the NSA who replaced the factory firmware with their own?
Open source is hardly a defense if enough developers become corrupted. It’d work a little better with OpenBSD’s strict code review policies than it would in a Linux distro, but things like this could still go undetected for a while with the right programmer in the right place.
Bad things can still happen, even to OpenBSD.
http://www.linuxjournal.com/content/allegations-openbsd-backdoors-m…
Can we just not dig up this bullshit attention seeing attempt from the past that would be just great.
The article implies that firmware source codes would need to be leaked in order for someone to add malware, but that’s not true at all.
Hackers attack proprietary code all the time without the benefit of source code. Even a hard disk which is not vulnerable can be reprogrammed with malicious firmware. So, the NSA certainly can and probably does produce firmware trojans without source code.
Note, they did not exploit firmware – they ammended it so that it reliably and transparently infects host. It is possible, but really much more difficult.
And another point: normally vendor provide barely enough storage for the firmware, and the number of vendors whose devices were compromised suggests that the infected firmware was the product of collaboration.
ddc_,
Yes, I agree.
Regarding firmware size, I honestly don’t think that would be a big issue on a device with perhaps several gigabytes of spare administrative disk sectors that normally remains inaccessible to the host OS. That’s plenty of room to hide a nefarious payload. The firmware wouldn’t need to hold the payload itself.
I disagree that number of compromised device vendors “suggests collaboration”, merely that there was strong motivation on the part of the NSA. We know they have the resources.
That’s one possibility. Here’s another:
Assuming the firmware is stored a separate RAM chip, the NSA could simply replace the factory RAM with their own.
Or they could remove some factory feature from the firmware to make space for new commands.
Is the hard drive’s “firmware” located on the drive’s main discs, or is it a separate chip of RAM somewhere on the unit?
Bobthearch,
Great question, and I wasn’t 100% certain either, but according to this the firmware is loaded into a chip on the Disk’s PCB, while the defective sector list and SMART data is on the platters.
http://www.tomshardware.com/answers/id-2241815/question-bios-origin…
Edited 2015-02-18 20:23 UTC
A follow-up question:
If you “flashed” the hard drive’s firmware, would that remove the offending/spying malware?
I suppose that’s more of a thinking-out-loud question rather than a technical question since the handful of people who know the answer probably won’t say.
Flashing it (via ATA interface) may or may not remove the malware.
It’s the same as it was for the ‘bad USB’ case: as the malware can affect the HDD controller, it can deny the flash operation to erase the portion on memory where it got installed or bluntly fake the update and report “all updated!”
You probably would need to remove the flash chip, put it on a programmer tool and flash it that way to be reasonably sure that every previous traces of the malware.