Persistent firmware backdoors possible across major hard drive brands

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On 2015-02-16, Kaspersky Lab announced[1]:
> GReAT has been able to recover two modules which allow
> reprogramming of the hard drive firmware of more than a dozen of
> the popular HDD brands. This is perhaps the most powerful tool in
> the Equation group’s arsenal and the first known malware capable of
> infecting the hard drives.
>
> By reprogramming the hard drive firmware (i.e. rewriting the hard
> drive’s operating system), the group achieves two purposes:
>
> 1. An extreme level of persistence that helps to survive disk
> formatting and OS reinstallation. If the malware gets into the
> firmware, it is available to “resurrect” itself forever. It may
> prevent the deletion of a certain disk sector or substitute it with
> a malicious one during system boot. “Another dangerous thing is
> that once the hard drive gets infected with this malicious payload,
> it is impossible to scan its firmware. To put it simply: for most
> hard drives there are functions to write into the hardware firmware
> area, but there are no functions to read it back. It means that we
> are practically blind, and cannot detect hard drives that have
> been infected by this malware” warns Costin Raiu, Director of the
> Global Research and Analysis Team at Kaspersky Lab.
>
> 2. The ability to create an invisible, persistent area hidden
> inside the hard drive. It is used to save exfiltrated information
> which can be later retrieved by the attackers. Also, in some cases
> it may help the group to crack the encryption: “Taking into account
> the fact that their GrayFish implant is active from the very boot
> of the system, they have the ability to capture the encryption
> password and save it into this hidden area,” explains Costin Raiu.

Affected HDD brands include[2] (but are probably not limited to):
* Western Digital
* Maxtor
* Seagate
* Hitachi
* Micron
* OCZ
* OWC
* Corsair
* Mushkin
* Samsung
* Toshiba

This is bad news for everyone, including Qubes users, since there's
nothing we can really do at the OS/software level to protect ourselves
from this kind of persistent HDD firmware infection (or compromised
firmware and hardware in general). Measures like AEM don't help if the
drives are already infected before we even purchase them. If we want
freedom and safety in the future, our best bet is probably to
(continue to) push for open-source firmware and hardware.


[1]http://www.kaspersky.com/about/news/virus/2015/equation-group-the-crown-creator-of-cyber-espionage
[2]https://securelist.com/files/2015/02/Equation_group_questions_and_answers.pdf
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJU41O4AAoJEJh4Btx1RPV85wcP/RK7mPG3HhdPpFt19yNTKE0c
ETJ+93S7iRg7VZV+f8okFzQWn+ER6+OY0bl2shzwBJKXhxqneVYctXBJJLGk2KLd
NuqIURNwDgISXhtjtNK2eeCRDeMdyAUtWceG+kxwZqXN8jXkZvBW0DrN7UEaPb8s
Zib8GfsqvOr1HSkw67P4z48pU7sdN7gF4rLTcA7el/JH98m0ltlIHmurbma4XLgp
RGnJSgsFwoViD4BgOHk4gmavgctoiBUgDuKjJ3O2nFaCFIlUT6hF/6TB7MsIqOZh
0OrsSr3OsXkKGlIxbjoDt4mlo7FC64diKq5JzRd9KS+68zmU9V7ocaq7ehfIJjq3
xyXX85Ly7MgREwwPf4uQEgLqNew77prG3pNYeAhBVmcsr2cJeBrpvT+i56hvTkcS
07anQjf2C2o0NW0UAqpzNTHuLhl4Jdts9ra/k6oiy05fj8EdU8WQYW4iaznEFu4V
IkYS5tF7EPjyBmtqwVuWPQMNjW5rKUOq4KRWY2fXXeV+lYExpqfuZoCh8SNE/eYz
WtTDVnxS5hTOq4Fy74GA4qpGYjYl0VhdM0EYpHBrn9xiI2HDYN6/L9R4TI+M5vCI
fF3BkjvvzJgYjBAZx133n+WWdPlyykeyQahKfHUgT0qXGN2TD6Lo8sWZE1+NBJbo
GlihcbnDLrcUtul23CrE
=ugr/
-----END PGP SIGNATURE-----

[Andrew]

Axon:

I agree with the need for open-source firmware and hardware, but Qubes
is very useful for mitigating this threat: in order to modify disk
firmware, an attacker must first escape the AppVM and get into Dom0.
Of course, NSA may very well have Xen 0days stockpiled, and they can
still subvert your system by interdicting your machine/disk in transit.

However, Qubes significantly raises the bar for successfully using this
technique, *even if* the user does not take advantage of
compartmentalization (outside that used for Dom0 disaggregation).

Andrew

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

This is true when it comes to remote attacks (e.g., over the
Internet), but there are several alternative possibilities for
compromising disk firmware:
* Some US manufacturers, being legally compelled to cooperate with
the NSA in the name of national security, install firmware with
NSA-accessible backdoors (which do not necessarily remain accessible
*only* to the NSA).
* Some non-US manufacturers are similarly compelled to cooperate with
their own governments.
* Hackers gain access to some manufacturers' internal networks and
implant hidden backdoors in firmware which gets installed in the
factory. (Or pose as potential employees and get hired; or bribe,
blackmail, or coerce high-level employees; or...)
* Trusted contributors to major open-source software projects (who
most likely do not use Qubes) get hacked, and the hackers use their
credentials to insert hidden backdoors in software updates which are
then downloaded into the dom0s of Qubes users, granting full access.
Sometimes, these are discovered a long time later. Other times,
they're never discovered. Maybe one out of a million
maximally-paranoid users reads every line of source code, understands
it all, and compiles everything themselves for every single software
update. (Even then, there's no guarantee they'll notice every backdoor.)

> Of course, NSA may very well have Xen 0days stockpiled, and they
> can still subvert your system by interdicting your machine/disk in
> transit.

Again, interdiction is not the only option. It's much more efficient
if every disk which rolls off the assembly line is already infected
(see above).

> However, Qubes significantly raises the bar for successfully using
> this technique, *even if* the user does not take advantage of
> compartmentalization (outside that used for Dom0 disaggregation).

Certainly, Qubes users are much better off when it comes to remote
attacks. My point is that we're no better off when it comes to
non-remote firmware- and hardware-based attacks, which are now a very
real threat.

> Andrew
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJU42S8AAoJEJh4Btx1RPV8D54QAOhL3yAsp0nOtxEEw3DZgGh/
ew53QgPk1TpmDjZEpPiEkzoUv0QYHNeO5NGXlrSzc0c8MtG0nM3ZexAfnH/sQw5j
lHRSpVzadxgpHuahAskkZoyUMDZ7b+Zuf9iDTTD+XxgHuc+dM61CD4ui0KgSgoj+
RUMXd8QEDMQ5Nmfg5fAFUVX2vJ3FleP01GgqiGeBs18fFZ4JhmvvNRa+WSjKC2im
JHCuNIPDPJHTVwnZBUi1+W55qcokCmKUlRZMs9wc3wmFBL3b6cD7GqkWU4B6oAwS
nis27rWw1+tcXINqPkYHydfvhMdh3fDe/OWwGKRwkI6ruhPQIpa193v2lccKJ7rq
47cOnaOsd55y2TQ2h6zoZLXt9dbbfpw5EklOyulh2VoWCqUpALGaEGEM9B/UwRbg
T6LJkUWTF8afB05ZWj1ctOUggpWvbiy1u/z84deDiNBw5Jm4YqVI02mPGsHnbgZF
xSVqECJ/O+YgjYcS+gLkeJmFBqWlZCimAhS783UX0U+c90JJvLd921qGc7F/M2fY
96+Ifx8MEG30kRHiX51uB1eXWDG/scMPn/BIvuHtMAvOifvhCtrNv6lDMsy4ZLlY
B3VWRAfhk1dbwAqAIrktJ4ZPa0U/76XfyT8f+beWxBgt7l0zez1s+t8dUNaqebHN
QAyyiD7z6B2D4atnjA9x
=YA5H
-----END PGP SIGNATURE-----

[WhonixQubes]

And no reason why other hardware components can't do the same.

So basically we are no longer using computers, but rather we now use
computers-on-top-of-computers. Where the outer-computer is what we think
we control with Qubes, etc, but the true inner-computers are the
hardware components that can independently act like root privileged
computers and directly pwn our entire system.

Great. ;(


WhonixQubes

[kerste...@gmail.com]

Hello WhonixQubes,

sure, but perhaps only the inner hardware components are essential. A disk is quite extended hardware, which could get the only job to read or write ready strong encrypted blocks. So without breaking into the core security of the system, a leak of any strong encrypted blocks will not leak the real information itself.

If the blocks are signed, so the firewall can prevent the ressource hard-disk to send not or evil encrpted OR evil signed blocks to the outer world.

But this will need something like a "crypto disk-firewall", to stop the game-over strategy of any evil persistent memory or disk.

Best Regards,
Kersten

[Axon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Indeed, having a "Storage Domain" in Qubes could mitigate these
issues. This is explained in the Qubes OS Architecture document.[1]
However, this is not currently implemented in Qubes. So, for now,
we're forced to trust at least some of our storage devices (i.e., our
main internal system drive(s), not our external (e.g., USB) drives).

[1]http://files.qubes-os.org/files/doc/arch-spec-0.3.pdf
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJU44yJAAoJEJh4Btx1RPV8hL8P/iqQ/DKoJeznDqORMoL9hz5J
HOc9HW8q31/Ith/qBMW7kWChN/8mV3yAHLza8E9KsfxHzpWgFhvrYMhyQoUgpfH+
IfGJfcGdOdXJhFsuwRcYn9iRfaUDtW2r5v0M0c9EXH48oUcdEdZdPwMlvke/e5C9
3XTv4hWRWzRSTWbOJhVV14UFWrKnUQQ5znffM0yv6XMeJnNey8CP/z0cmK/HCnin
12punB6SdiJRAD6PL/plXhJ19XbZ7ubpM2X9zbu8mguAgvOyy6ToAN9sW1/sjPbn
btS4+tNOkJcx/79STUGhjKAEUwG8YKrppCnEQb0DYjbAknxfN0UrQCVF9m0vDPOb
ubfMD5scHOTzqbKNU1V1TU24yunLW4MJNRC8MURcqg4NOIcjNC5An4+3EteZx3pb
njnzcULtSaV0XfyiQjqIAuZPN5+iAoA9KwpPQN8h6YIwgKEMoi5BTlcHN9Bz74ZX
mKvOexvP1gfpBkZ4yQ6g/1Iu8Vl3Ef6havrGnKhYCQ5TISc6z1vmQUvc9padUJWi
PL3a6ANulsXsf6kXT9lRVjXd2EvYmJ4gn3baN9MprQ5e7tMWw3Gb8mnYtua8DsgO
mJ2aOGP7LuLBq3vd1M/61dRevLFSrEriff2AED9JK16Ij2y+YRIRHmUbBEPxyk2n
OyyVsAicKLYjt7yFYMA2
=PQpe
-----END PGP SIGNATURE-----

[cprise]

That's one way to interpret the situation, but I think that's pessimistic. We are lucky these techniques were exposed before they were put into widespread use (like the NSA's out-of-control phone and Internet monitoring).

When I read the ARS article and the part about HD firmware, I thought: "Well, now the circle of trust really has whittled down to the CPU".

The fact that NSA had to resort to HD firmwares to persistently keep some systems infected means that other aspects of PC architecture present big problems for them; Apparently going after the BIOS presents a lot of problems for an attacker (such as rendering the machine unusable).

My second thought was: "Qubes is slated to have an untrusted storage domain, anyway."

[WhonixQubes]

Hi there Kersten,

Great idea. This would be really neat!

I wonder if this is like the encryption described in the Qubes
architecture spec doc, where the AppVMs and Dom0 only know the per VM
private storage keys and the hard drive is behind an untrusted Storage
Domain?

[WhonixQubes]

> --
> You received this message because you are subscribed to the Google
> Groups "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to qubes-users...@googlegroups.com.
> To post to this group, send email to qubes...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/qubes-users/54E390C7.9030308%40gmail.com
> [1].
> For more options, visit https://groups.google.com/d/optout [2].
>
>
> Links:
> ------
> [1]
> https://groups.google.com/d/msgid/qubes-users/54E390C7.9030308%40gmail.com?utm_medium=email&utm_source=footer
> [2] https://groups.google.com/d/optout


Hi cprise,

Thanks for cheering me up! :)

Yes, that perspective is a nice upside take on these situations.

I wonder if something like the following is possible, despite an
isolated Qubes storage domain...

Since the hard drive (and other devices) have their own physical
computing resources inside of them, with a firmware modification, could
they be used to do a MotS (man-on-the-side) style attack to other key
hardware components or flows in the system and strategically
record/interrupt/inject/modify other processes of the computer?

I don't know enough detail about the physical architecture of computers
to determine this, but, our individual components, like hard drives now
have non-trivial hardware resources of their own and a direct connection
into our motherboards.

A higher bar indeed, but the notion reminds me of the MotS internet
backbone packet injection attacks that are routinely being carried out
with internet traffic. But, since they can already get into and replace
hardware firmware, I'm wondering what the limits of capability are with
holding such a deep position inside of the system's hardware.


WhonixQubes