Tofinosecurity.com uses cookies for analytics and functionality purposes.
To change your cookie settings or find out more, click here.
If you continue browsing our website or close this banner, you accept these cookies.

Search form

menu-bar

Home>Blog>Stuxnet Lesson: Is SCADA/Control Field Device Firmware the Next Malware Target?

Stuxnet Lesson: Is SCADA/Control Field Device Firmware the Next Malware Target?

Submitted by rahulsebos on Tue, 2011-01-04 13:55

In the post-Stuxnet cyber security world, many vendors are actively thinking about protective measures that could prevent a similar attack on industrial systems.

Such measures could be implemented at the PC-level, the PLC-level, or even the Profibus or device-level. They could include methods such as antivirus-scanners, firewalls, patch management, password policies, USB usage policies, code integrity checkers, etc. However, all of these measures are ones that are implemented at the highest levels of an industrial system.

Protecting the Low Levels of an Industrial System

What about protection at the lowest levels, for example the frequency converters targeted by Stuxnet? The firmware in these devices was not modified by Stuxnet; the drives just did what they were told to do by the PLCs, which in the case of Stuxnet, resulted in significant havoc.

Could Stuxnet have also done its job by directly modifying the Vacon frequency converter firmware? Technically, yes. Practically, no.

Today, device firmware cannot be modified via Profibus access, but only by direct physical access to the frequency converter firmware itself. For example, a laptop with an RS232-link and a vendor-supplied programming or "flashing" tool. Clearly, this is not practical for a virus, and in the Stuxnet case, it offered a very high level of protection.

How different would the situation be if there was a way to modify the frequency converter's firmware via Profibus? In this case Stuxnet could have been designed to create havoc in the frequency converters directly, instead of reprogramming them via the PLC. The PLC would remain unmodified, leaving no trace of any malicious activity. Then the drives would have behaved ‘erratically’ at certain moments, for no apparent reason.

The Challenges of Creating and Detecting Low Level Firmware Changes

To make modifications directly to the frequency converter firmware the Stuxnet authors would have required the supplier's source code (reverse engineering is also possible, much more work - but not impossible).

As access would likely not be given by the vendor, the only way forward for a virus writer is using clandestine ways of obtaining the source code. Difficult, but not impossible - remember that Stuxnet used stolen certificates from two Taiwanese companies; why not steal source code?

Do you remember "Operation Aurora", the virus that specifically targeted source code repositories? I have long wondered why someone would need someone's source code; except for the obvious reason (commercial espionage); other uses come to mind now.

The virus author would then modify the source code to exhibit its malicious behavior at certain moments. The virus would then spread as Stuxnet did, infect the PLC, have the PLC download the new firmware to all frequency converters, clean itself from the PLC again, and then just wait for the frequency converters to act erratically from time to time.

Since there is no way to look into the drives' firmware, it is very, very difficult to find out what is going wrong and why.In practice, this is only possible with vendor supplied technical expertise (including software and debugging tools), and even then it is almost impossible to find the cause.

Stuxnet targeted several hundred frequency converters. Debugging them could only be done one at a time, unless one is willing to spend lavishly on debugging equipment for each and every device. Assuming you have limited debugging tools, the likelihood that you would be on the right frequency converter at the right moment would be slim!

Embedded devices are the ultimate hide-out for industrial viruses since their presence would be virtually undetectable.

Currently, the accepted way of upgrading firmware in a fieldbus device is to have physical access to it - usually using a RS232 or USB-link to a laptop and a dedicated firmware download tool provided by the vendor. Firmware upgrades with a fieldbus are possible - in fact, I have used this functionality for over a decade now on products from various suppliers. But not all suppliers of industrial equipment support this.

With the advance of industrial Ethernet, firmware downloads via Ethernet will become more common and physical access to the device will no longer be required. This removes one existing layer of defence against industrial viruses.

Nobody has ever done all this before, but this does not mean it is impossible. Stuxnet showed us that virus authors can go a long way to achieve a goal. In the past, industrial embedded devices have been protected simply because the technology did not allow automated updates of firmware. Our defences are diminished, not improved, with new industrial Ethernet technology and automated updates.

If plants want to take advantage of the standardization benefits of using Ethernet technology, thus making embedded devices more vulnerable to Stuxnet-like viruses, then cyber security must expand from the PC domain to include the industrial and embedded world. Until then, ensuring that embedded control devices require physical access for all firmware updates is an important level of defence.