Some new developments in the Siemens SCADA trojan story…
It turns out that the trojan uses a well known default password to log in to the backend MySQL database used by Siemens’ software but Siemens has told users of the software (factories, power plants and the like) NOT to change the database password, as doing so would cause the software to stop working. A fix is forthcoming, but plant operators are likely to have an anxious few days (?) until a solution is available.
A second version of the trojan program has been detected on the Interwebs. The new variant seems to also be targeting SCADA systems and is also signed with a code certificate (this time from Taiwan based JMicron Technology Corp, which has offices in the same location as the firm whose cert was appropriated for the first version of the worm).
The whole default password thing is just plain embarrassing… this is a problem from another era, which should be an unpleasant memory by now. It seems like it would be easy to eliminate this problem programmatically by creating a unique database password (derived from the license key and a secret, maybe?) by default when the software is installed. Or at least require the installing user to enter a password during installation. SCADA systems control the technological backbone of our civilization (power, water, sewage, manufacturing) and deserve better security than this.
As far as the underlying vulnerability used to spread the Stuxnet code, we are still at risk – a patch has not been released by Microsoft yet, and while the major anti virus vendors have released signatures which detect the SCADA worm, it is only a matter of time before we start seeing other, new malware using this vector to spread. It seems like using a Group Policy Object to prevent executables launching from drives other than C might be the best way to protect your networks for the time being.
Stay tuned…
RSS - Posts