A mighty fortress is our PKI, Part II

[Peter Gutmann]

Have you ever wondered what would happen if malware started appearing that was
authenticated by signing keys belonging to major hardware or software vendors?
Over the last week or two we've had a chance to find out:

One of the scariest scenarios for code signing is when the malware authors
manage to get their hands on a legitimate developer's code-signing key.  Since
many development shops see the signing process as nothing more than an
annoying speedbump that stands in the way of application deployment, not
helped by the fact that code-signing tools like Windows SignTool and Unix' GPG
are hard to use and poorly integrated into the development process, developers
have generally used the most expedient means possible to sign their code, with
signing keys left unprotected or with easy-to-guess passwords ("password" is a
favourite in web advice columns that give examples of how to do code signing),
or passwords hard-coded into the scripts that are needed in order to integrate
the signing into the build process.  Combine this with the existence of entire
families of malware such as Adrenalin, Nuklus/Apophis, Ursnif, and Zeus, with
key-stealing functionality and it's inevitable that legitimate code-signing
keys will end up in the hands of malware authors.

The most serious case of this occurred in mid-2010 when malware signed with a
key belonging to the major semiconductor manufacturer Realtek started to
appear ["Rootkit.TmpHider", discussion thread, 12 July 2010,
http://www.wilderssecurity.com/showthread.php?p=1712134.]["Signed Malware Used
Valid Realtek Certificate", Lucian Constantin, 16 July 2010,
http://news.softpedia.com/news/Signed-Malware-Used-Valid-Realtek-
Certificate-147942.shtml.].  Although PKI dogma states that a certificate
belonging to such a key should be immediately revoked, the fact that vast
numbers of Realtek drivers had already been signed by it and could now no
longer be installed without unsigned-driver warnings or, in the case of 64-bit
Windows, used at all, would no doubt have given both Realtek and the issuing
CA cause for concern.  After several days the certificate was revoked
["VeriSign working to mitigate Stuxnet digital signature theft", Steve Ragan,
21 July 2010,
http://www.thetechherald.com/article.php/201029/5921/VeriSign-working-to-
mitigate-Stuxnet-digital-signature-theft.], although the CA had to wait until
the story started to appear in news reports before they became aware of the
need for the revocation.  The decision to revoke the certificate was probably
influenced by a combination of the fact that the majority of users will simply
click through a driver install warning and that the hit-and-miss nature of
revocation checking meant that many systems would keep on using the
certificate regardless (if the certificate had only been used to sign 32-bit
code so that the worst that could happen was a warning dialog on install for
users to click past then this would have made the decision to revoke even
easier).  In any case since antivirus vendors had added the malware signature
to their scanners as soon as it was discovered, the revocation likely had
little actual effect in protecting users from harm.

A few days later a new version of the malware appeared, this time signed with
a key from another semiconductor manufacturer, JMicron ["Win32/Stuxnet Signed
Binaries", Pierre-Marc Bureau, 19 July 2010,
http://blog.eset.com/2010/07/19/win32stuxnet-signed-binaries.]["Another Signed
Stuxnet Binary", Sean Sullivan, 20 July 2010,
http://www.f-secure.com/weblog/archives/00001993.html.]["New Stuxnet-Related
Malware Signed Using Certificate from JMicron", Lucian Constantin, 20 July
2010,
http://news.softpedia.com/news/New-Stuxnet-Related-Malware-Signed-Using-
Certificate-from-JMicron-148213.shtml.].  Making the debacle even more
entertaining was the fact that one of the principal systems targeted by the
malware is a Siemens SCADA (industrial control) system that uses a hardcoded
password "2WSXcder" that can't be changed because doing so causes the system
to stop working ["Siemens warns users: Don't change passwords after worm
attack", Robert McMillan, 20 July 2010,
http://www.infoworld.com/d/security-central/siemens-warns-users-dont-change-
passwords-after-worm-attack-915.] and that had been circulating on the
Internet for years, including being posted to a Siemens online forum in Russia
["SCADA System.s Hard-Coded Password Circulated Online for Years", Kim Zetter,
19 July 2010, http://www.wired.com/threatlevel/2010/07/siemens-scada/.] and
online lists of default passwords ["default password list",
http://www.defaultpassword.com/?action=dpl&char=s.] (the reason for this poor
level of security is that SCADA systems rate availability above everything
else, so that anything that affects, or potentially affects, security is
strongly avoided.  In addition SCADA systems often use thoroughly out-of-date
hardware and software that no-one wants to change for fear of breaking things
and for which there's no way to schedule downtime even if someone did decide
to take the momentous step of upgrading them, and that are administered by
control engineers rather than computer geeks, none of which create an
environment that's conducive to strong security, or often any, security).

General questions:

- How many 64-bit systems would the revocation have potentially bricked?
  (JMicron make drive controllers, being unable to load the driver for your
  storage device could be... fatal).

- If the sig-check fails for a critical system component, what does Windows
  do?  That is, the driver itself is OK (the hash verifies) but the signature
  can't be verified, do you boot with the unverified driver or brick the
  machine?

- Were the keys only used to sign 32-bit drivers, or 64-bit ones as well?

- PKI dogma doesn't even consider availability issues but expects the
  straightforward execution of the condition "problem -> revoke cert".  For a
  situation like this, particularly if the cert was used to sign 64-bit
  drivers, I wouldn't have revoked because the global damage caused by that is
  potentially much larger than the relatively small-scale damage caused by the
  malware.  So alongside "too big to fail" we now have "too widely-used to
  revoke".  Is anyone running x64 Windows with revocation checking enabled and
  drivers signed by the Realtek or JMicron certs?

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com