Reader Comments: 07-19-10 SCADA Trojan

PCM left a response to yesterday’s blog posting about the Siemens SCADA Trojan. PCM noted:

“And what is Siemens doing about the hard coded database password issue? THAT is the real problem, not the Microsoft 0-day...”

Actually, as I pointed out in the original blog posting from last week, there are three components of the Trojan, now named the ‘Stuxnet worm’, that make it work so well; the new Microsoft vulnerability, a trusted security signature and the Siemens password. Last week the initial response from both Microsoft and Siemens was to point fingers at the other’s part of the problem. That, now at least, seems to have changed; both seem to be responding to their part of the problem. Well, as PCM points out, Siemens seems to be working on methods to deal with the Stuxnet, but they have not publicly addressed the hardwired password issue. From various discussions going on around the net it seems that for some reason Siemens hardwired in a set of passwords into this SCADA system. They don’t seem to be used in the way a normal password is used to allow a user to sign into a system. Instead it appears to be used to allow a piece of software to verify that it is authorized to be run on the system. It seems to me (and remember I am not a software engineer, just an old rooky programmer) that this type of password has to be hard wired into the program. Allowing someone to change or shutdown the password would destroy the capability of the program to recognize new code or separate programs that are necessary to the operation of the complex system. This means that the agency employing this type of hard-wired password-based authentication system must provide nearly absolute security to protect the identity of the password. It would even be smart to keep the fact of existence of such a password very closely held. Unfortunately neither seems to have been well done in this case (an article at PCWorld.com notes that the password was disclosed on the web in 2008). Any security expert would respond to that last comment with a sigh and ‘No DUH’; providing absolute protection for anything is just not possible. There are other methods of providing this type of internal verification. They too are subject to compromise. Some, however, are easier to fix after a situation like this arises. It will be interesting to see how long it takes Siemens to come up with a patch to fix this problem, though ‘patch’ probably is an inadequate word to describe the complexity of the software change that will be needed to eliminate this hole. ICS-CERT Response Meanwhile, go read the PCWorld.com article. It provides some updated information and a good explanation of what is known to date. They also mention that DHS ICS-CERT has responded to this situation with an alert (ICS-ALERT-10-196-01) but noted that “the information is not publicly available”. I understand that the ICS-CERT has a Vulnerability Disclosure Policy, but that is supposed to prevent the spread of a previously unidentified vulnerability until the vendor has a chance to correct the problem. That hardly applies here; word about the vulnerability is fully in the public domain. NOTE: While I was getting ready to post this I got another Reader Comment on the same subject from Andrew Ginter, a well known SCADA Security Blogger. Andrew wrote:

“The ICS CERT released an advisory on the malware dated today, July 20. You can find it at: http://www.us-cert.gov/control_systems/pdf/ICSA-10-201-01%20-%20USB%20Malware%20Targeting%20Siemens%20Control%20Software.pdf”

In any case, SCADA systems have now officially joined the target community. Anyone who thought that SCADA was just ‘too complex’ to attack had better re-examine their reasoning. System owners really need to paint a bulls-eye on the case of their SCADA server to remind them that they are a target and need to be prepared to actively defend their systems.