More on the Stuxnet Siemens Exploit

Yesterday I guest blogged at Control Global about remediation steps for process automation networks and I’ve been thinking some more about the topic.

I suspect that while this particular attack seems to have been deliberately designed to attack specific Siemens infrastructure using known Siemens weaknesses (hard coded passwords, inappropriate admin rights etc.) there is absolutely nothing about this that means that it applies only to Siemens – indeed recent news indicates that a new payload is being delivered that may do different things.

The key here is that the payload, and new variants of the worm spread because the worm can “call home” so while the initial attack seems to have done nothing to systems that were not Siemens WinCC devices apart from spread, there is no reason to assume that this will continue. Thus, as I said in that post, and as we say repeatedly on this blog, it is critical that organizations reconsider the “default allow” rule for outbound traffic that is in probably the majority of firewalls. Sure some firewalls block traffic out except on certain ports (e.g. HTTP), force traffic to pass through proxies, or block traffic from certain core data center servers/networks but very few actually look at the destination of traffic leaving the network.

There is an argument that says that SCADA devices should never be able to connect to the Internet and this is in many cases true. However the way that buildings have been wired up and ip networks/addresses configured it can be almost impossible to tell whether the computer trying to connect to something on the Internet is in fact a piece of automation equipment or, say, the laptop of a technician who needs to download a product manual to do maintenance on the automation equipment. Best practice for IT departments is of course to separate networks for general use from those for specific critical functions and to not allow traffic from the critical networks to leave the building. However, unless these networks are blocked from communication with anything else – the “airgap” firewall – there remains the risk that these devices can be controlled by external hackers. If, for example, an engineer remotely logs into a device and controls it from his desk – something that I know happens in a number of places – then if that engineer’s desktop computer becomes controlled by the hacker the hacker has access to the devices as well, albeit indirectly.

Hence, also, another reason why relying on the fact that the current versions of a worm are specific to certain industrial devices is to allow one to be lulled into a false sense of security.

On a slightly different note. In a number of cases people have wondered why Siemens uses known default passwords. Partly this is down to the fact that the products, and the product mindset, were for a closed, secure environment without access to the Internet. Partly it is down to the fact that even the slightest change could cause something to go wrong. This also explains why patching industrial devices is something that is not done frequently. If, for example, you are controlling a process in a chemical plant, then you probably cannot reboot the computer except after a laborious shutdown sequence that takes place once a year because doing so costs millions of dollars. Moreover if the patch turns out to have (say) a memory leak that manifests itself after 200 days, you are in big trouble because on day 201 you lose control of the chemical process and that may well cause a leak, explosion, fire etc. If a system is tested with user “X” password “Y” and runs successfully without falling over for a year then why take the risk that user “Xx” or password “Zz” will work too. What happens if there is a garbage collection failure that causes a few Kb to be lost each time the device remotely logs in and which is partially dependent on password length? if your new password is longer then that might be just enough to mean that the system runs out of memory in 340 days instead of 370, and thus that it crashes on December 15th instead of making through to the scheduled reboot on Dec 27..

Putting all this together, the simplest way to minimize the risk for the current network is to stop all computers in the network from “calling home” when infected rather than just concentrating on the SCADA ones. This gives you the breathing space to consider re-engineering your network so that critical devices are more effectively isolated.

Just Another Malware Monday

Today there are, as usual, a number of active botnets, zero day exploits and purveyors of miscellaneous malware. The one that has received all the publicity is the Windows LNK file exploit which seems to be designed to attack Siemens SCADA systems. Another one that popped up  on the Shadow server listserv is a new sort of malware that packed in such a way that it is not detected by any current anti-virus program – and that will mutate easily to evade the detection algorithms of most anti-virus programs.

For a network admin or similar, both of these are nasty because the proactive workarounds to protect against both are intrusive and result in significantly degraded user experience assuming you can actually apply them to all the computers under your control.

If you are in charge of a network and aren’t a ThreatSTOP subscriber then you will probably spend a lot of time trying to figure out how serious these threats are, whether your users/servers have got infected and how to stop the inevitable “call home” from the infected computers on your network to the C&C hosts of the cyber-criminals who seeded the malware. And quite possibly you will decide that there really aren’t enough hours in the day to permit any worthwhile countermeasures and drown your sorrows in drink.

We know the feeling! But at ThreatSTOP we can solve this problem, and all our subscribers have to do is check their firewall logs to see if they have infected computers. ThreatSTOP’s ThreatList is updated every two hours with the latest list of known C&C hosts (including those involved in the above attacks) and when that list is applied to your firewall they block – and log – all attempts to contact these machines by your computers. So even if you run a factory with 5001 Siemens SCADA devices you don’t need to worry about updating the security of all of them just in case because even if they do get infected they can’t talk to the originators of the exploit so your data is safe. And if an infected computer does try to  “call home” the attempt is logged so you can go and fix it.