Targeting the Extended Supply Chain – a Brief Review of Stuxnet

In November, 2010 Iranian president Mahmoud Ahmadinejad announced that a “cyber weapon” had been deployed against the Natanz nuclear laboratory. Indeed, some infosec pundits subsequently referred to the attack, called “Stuxnet”, as the first true cyber weapon to be used in anger. While that may be debatable, what is not in question is the design, deployment, and ultimate toll of the Stuxnet worm. It was highly targeted, attacking a very specific range of Siemens SCADA systems, exploited 4 different Microsoft zero-day vulnerabilities, deployed a Windows root kit to hide its binaries, phoned home for instructions, and used a series of stolen code signing credentials to hide its passage as it sought out the Siemens PLCs that controlled the centrifuges at Natanz. Stuxnet was, and largely remains, the epitome of a superbly engineered cyber weapon.

A lot of virtual ink has been spilled over Stuxnet in the decade since it bit the Iranian nuclear program. It is not my intent here to rehash the story. The point of this blog entry is to take a look at how Stuxnet deployed stolen signing credentials to minimize error messages as it installed itself in systems around the globe on its long trip to Iran. As a prototypical worm Stuxnet needed to replicate and install itself around the ‘Net. For each infected machine it installed a driver which formed the launch point for it to install its libraries of code. The first thing Stuxnet did once installed was to check for the presence of a Siemens PCS 7 controller. If it did not find one, it went to sleep. If it found one, it installed a PLC root kit (another first) for persistence. All of this installing of wormy bits would have thrown up errors and requested user input if the Stuxnet binaries had not been signed by a valid code signing credential. The Stuxnet authors obviated this risk by filching legitimate signing credentials from unsuspecting (if careless) manufacturers. The target Windows systems checked the signatures on the installer(s) which validated. No user involvement, no errors in log files, no tracks, and a side door around most AV products.

As reported in Ars Technica, “One of the breakthroughs of the Stuxnet worm … was its use of legitimate digital certificates, which cryptographically vouched for the trustworthiness of the software’s publisher.” The same article continues, “The researchers said they found 189 malware samples bearing valid digital signatures that were created using compromised certificates issued by recognized certificate authorities and used to sign legitimate software.” In the case of Stuxnet, the worm’s authors got hold of code signing credentials (including the private keys; cert’s not much use without them) issued to and used by JMicron and Realtek. Both of these entities used the credentials to sign drivers for their products. The Stuxnet authors were able to use those same credentials to sign some very clever malware thus speeding its journey around the world.

This speaks directly to two of the core concerns of the PKI administrator; key management and key utilization. While certificates are public data, the private key described by a cert must not be accessible for any purpose other than signing. Knowing that your private key is not stored on disk, on backup tapes, in main memory, or anywhere other than in a specialized device is Job 1. There should be no copies anywhere other than on other specialized devices used for failover/restore. Once the signing key is secured you want a process surrounding its use to assure that only authorized users can perform operations on it. Many key management devices and systems offer functionality (e.g. smart cards with N of M quora) that work well to enforce separation of duties and multi-factor authentication. The hard part is not finding a secure keystore device and a process for controlling key access; it is actually doing it. On July 16, 2010, Verisign revoked Realtek’s compromised code signing certificate. I can imagine the weeping, wailing, and gnashing of teeth among senior IT people at Realtek that accompanied the revelation of its unwitting participation in the cybercrime of the century. No, sir, I don’t like it. Not a bit.

For more information and background on Stuxnet, the book Sandworm by Angy Greenberg is an excellent read.