[Cryptography] This is why we have Stuxnet

Peter Gutmann pgut001 at cs.auckland.ac.nz
Mon Mar 21 01:59:26 EDT 2016

I usually do embedded cross-development under Linux, typically with some
hacked-up ancient version of gcc and obtuse command-line utilities that fail
with cryptic error messages until you've spent several hours hacking around
with them.  This time though I had to use Windows because getting the drivers
going under Linux just wasn't working.  So I go to the web site of the $20B
global hardware vendor that makes this stuff and download their SDK tools.

  "We've detected that you've got A/V running.  You should disable this in
  order to run our tools.  Are you sure you want to continue?".

Yeah, I'm not doing that, so I click continue.

  DISABLE IT.  Waiting for A/V to be disabled".

OK, so I'll disable A/V.  At which point Windows goes to about Defcon 2 and
starts screaming about the imminent collapse of civilisation, but I don't have
any choice.

So the install starts, except it won't install in $Program_Files because that
has, you know, security applied to it.  It wants to create its own public
directory off $SystemRoot and install to that.

OK, so I'll allow it to do that.

Now Windows Firewall is throwing up warnings about tclsh groping around on the
Internet (they install a complete Cygwin environment, presumably because their
Windows SDK is all scripted in Tcl).  So I allow that, and various other
things that I get warnings about.

It then proceeds to download and install a 2-year-old version of Java, which
apparently is needed by their SDK.

After that, it reaches out to about a hundred-odd HTTP URLs, downloads binary
blobs from them, and installs them.  I tried setting up a tunnel to an HTTPS
equivalent but it only does HTTP.

Finally, it's finished.  The app starts up and requests elevation to
Administrator.  Then it starts grabbing more binary blobs from HTTP URLs and
installing them.

All that was just from watching what was happening, I didn't do any further
checking to see what other horrors lurked beneath the surface, but given what
I'd seen so far it was bound to be pretty bad.

I think we need to treat any embedded device developed via this vendor as pre-
compromised.  And that includes the aerospace and military ones.


More information about the cryptography mailing list