[Cryptography] trojans in the firmware

John Denker jsd at av8n.com
Mon Feb 16 22:06:52 EST 2015


On 02/16/2015 01:39 PM, John Young wrote:

> Kaspersky Q and A for Equation Group multiple malware program, in use
> early as 1996. NSA implicated.
> 
> <https://t.co/bByx6d25YF>https://securelist.com/files/2015/02/Equation_group_questions_and_answers.pdf
>
>  Dan Goodin: How “omnipotent” hackers tied to NSA hid for 14
> years­and were found at last
> 
> <http://t.co/0n1D05GOFN>http://ars.to/1EdOXWo

Those are well worth reading.

There are two possible interpretations of the following passage, 
where Goodin quotes Costin Raiu, director of Kaspersky Lab's
global research and analysis team:

>> "It's very dangerous and bad because once a hard drive gets infected
>> with this malicious payload it's impossible for anyone, especially an
>> antivirus [provider], to scan inside that hard drive firmware. It's
>> simply not possible to do that."

It may be not possible /at the moment/ ... but in context
Raiu seems to suggest it is not possible in principle, 
which is crazy wrong.  I say instead:

a) The disk manufacturer could allow you to read the firmware
 easily.  It's always going to be readable if somebody wants
 to go to enough trouble;  we're only arguing about the price.

b) If they don't want to make reading easy, they should
 provide /at least/ the following:
  -- the total number of times the firmware has been modified, and
  -- the current hash.  Cryptologically strong hash.


===>  Heretofore there hasn't been much market demand 
for such a feature, but that is something that can be
changed.  In particular, the Kaspersky guys, rather
than giving up, should be collaborating with the disk
vendors to come up with a workable solution.

Obviously the checksum reporting routine needs to be 
in a non-flashable part of the firmware.

OTOH, equally obviously, this may not solve the problem
if your threat model includes "interdictions", where
the opposition trojanizes your equipment while it is 
in transit from the vendor to you.

On the third hand, there are ways of defending against 
even that.  It's not particularly hard to build your own
computer from components;  Gazillions of hobbyists have
done so.  If you think you are under threat, buy the
components and test them at the component level.  For
instance, read the BIOS ROM using a ROM reader, i.e.
in a way that is not dependent on booting from that
ROM.  Note that there exist open-source BIOSes.

Ditto for the boot blocks on the disk.  It doesn't 
take a very fancy disk diagnostic to discover that 
what you are reading from block 0 isn't what you
wrote.

Then put the components together in some slightly
eccentric way.  For example, if you're doing software
RAID, it becomes very much harder for the firmware in
the disk drive to screw you over.  That's because the
drive doesn't know what you're going to do with the
bits.

===========

We need to exert serious pressure in this direction.
This isn't just about Iranian weaponeers versus the 
NSA, which is complicated by political questions
about who you think the are the bad guys.  It is also 
about bankers trying to fend off advanced persistent 
threats from bandits.  Even if you think bankers are
bad guys, the bandits are worse.

And then there is election machinery.  Vote-counting
is heavily computerized, and we reeeeally need more 
transparency and reliability at every level, from 
BIOS and disk firmware on up.



More information about the cryptography mailing list