SCADA networks have been targeted by the Stuxnet malware that exploits a 0-day Windows vulnerability, as well as a hard-coded database password. The details of this issue paint a picture of security controls new and old, and give some hints about how we might expect these controls to affect us over time and whether they can evolve to meet new challenges. For starters, signed code may not be all that it’s cracked up to be.
A perfect storm, or a well-planned attack?
Several factors in this attack indicate that it was carefully targeted at a specific operating environment, but some even seemed designed to inhibit remediation and response:
- The 0-day vulnerability that implanted the malicious Stuxnet drivers relies upon a flaw in how Microsoft handles icons for .lnk files. But the flaw requires the attacker to reference code in a known location, and to execute it the user must display the malicious .lnk file’s icon. This was easily accomplished by putting the malicious code alongside the .lnk on a USB drive, which users would certainly browse once they plugged it into a machine.
- Because the .lnk vulnerability is a flaw in legitimate functionality for displaying Control Panel icons, the workarounds currently available from Microsoft rely on disabling the display of icons for shortcuts, which can severely degrade the usefulness of the graphical interface. For the time being, this workaround might be passed over by sites that fear the degradation in user experience is more harmful than a potential malware infection.
- Further complicating things, the Stuxnet malware relies in part upon a hard-coded authentication in Siemens database backends. These default credentials must remain in place, according to Siemens officials, or else the SCADA systems will not interoperate. Unfortunately, those same credentials provide operating system access and can be a conduit for malcode or other intrusions.
- Symantec has posted information that suggests this malware was searching for specific file types for design documents from the same Siemens systems that were targeted.
- Other reports note that in addition to malware, SCADA operators’ responses were inhibited because community support mailling lists were undergoing denial of service attacks. So not only were the attackers familiar with system weaknesses of particular SCADA installations, they might also have benefited from this reduced ability for site operators to communicate security issues.
SCADA operators were certainly at a disadvantage against their attackers. Each of these factors bought the attackers more time or slowed effective response. All of these factors could be coincidental and the attackers could have stumbled onto some significant luck, or they could reflect the diligent planning and execution of a determined adversary.
Blurring the lines of trust
Stuxnet’s malcode further complicated responders’ efforts because it was loaded into the system through a driver that was cryptographically signed with a legitimate hardware company’s driver signing certificate. In response to this outbreak, Microsoft and Verisign worked with Realtek and JMicron Technologies, the companies whose signing certificates were used, to have those signing certificates revoked.
Starting with Windows Vista and Windows Server 2008, Microsoft introduced driver signing requirements to enforce trust relationships between kernel-level code and the publishers of that code. According to the details of those requirements, “Components must be signed by a certificate that Windows “trusts” as described in the white papers on this site.” However, there are various layers in that trust model, and simply revoking a certificate does not eliminate all trust for code signed by that certificate.
Let’s look at what has happened when Microsoft revoked certificates in the past. A few years back, a tool called Atsiv was released to allow unsigned drivers to be loaded in protected kernels (Vista x64 at the time), allowing older drivers from now-defunct companies, for example, to load in newer operating systems. Not only did Microsoft revoke Atsiv’s signing certificate, they placed the certificate from DENWP ATSIV (aka Vista Pwned) in the revocation list for the Kernel Mode Code Signing (KMCS) system, which would prevent Atsiv-signed libraries from loading into the kernel. This is an important distinction between what Microsoft did for Stuxnet’s malicious libraries, and the reasons in part may have to do with the repercussions.
So what does a revocation of the Realtek and JMicron certificates do? It will prevent any code signed after the revocation date from being accepted by the kernel. This means that the attackers who compromised those signing certificates cannot use them to legitimately sign new malcode variants. But without an entry in the KMCS revocation list, the current Stuxnet code will continue to run, install, etc. on existing systems. Why? Because if the Realtek and JMicron certificates were added to the KMCS revocation list, then existing legitimate drivers for all of their hardware would also fail to load, potentially creating a bigger problem than this malware. When Microsoft made the decision to add Atsiv’s certificate to the KMCS revocation list, a single utility library was signed with that unwanted certificate, removing the potential for any collateral damage. But without such an entry, any driver signed before the date of certificate revocation still bears a certain level of trust—which would include any variants of these malicious drivers that the compromisers of the Realtek or JMicron certificates could have signed before that revocation date.
Exploiting foundational trusts
While the world waits for an official patch from Microsoft to correct the .lnk flaw, it’s less clear what the long-term solution will be for end-users. Certainly another 0-day vector could exploit the same hard-coded passwords to gain entry to sensitive information on Siemens systems. Likewise, some other compromised signing certificate could be leveraged to mark more malware as trusted for Microsoft users. Both Microsoft and Siemens had the ability to stop the spread of malware, but the potential repercussions of suggesting these strong responses (adding compromised certs to the KMCS revocation list, or advocating database password changes) tied their hands. But make no mistake, Microsoft and Siemens are not alone in having these kinds of deeply-embedded trusts.
If these foundational trusts cannot be revoked, they provide significant cover for miscreants to operate under. While these may be the appropriate risk decisions for their respective decision makers, users that rely on them must be able to trust that the keys (in this case the signing certificates or passwords) can be adequately defended. In fact any time a trust relationship that allows this level of access is created, it must be protected with the highest levels of security. And even still, many organizations will need to design defenses in spite of the shortcomings these trusts entail.