Let’s go ahead after all these technicalities and try to explain conceptually what Stuxnet exploits on controllers, and what that means for all of us who are somehow using such controllers, or depending on them in one or another way.
Exploits
The main thing to understand when looking at how Stuxnet takes over control is that Stuxnet doesn’t exploit bugs. It exploits legitimate product features of modern controllers which can be found in more than one brand of controller. In detail:
Exploit A: Code injection on controllers
How it works: Inserting rogue code at the beginning of an operation block (OB). Rogue code is called before execution of legitimate code. Rogue code may decide whether to pass execution on to legitimate code or not. Rogue code may implement specific functionality for pinpoint attacks, using insider knowledge as in Stuxnet, or it may also just randomly cause trouble by manipulating outputs, timing behavior etc., without insider knowledge.
Exploited vulnerabilities: Calling functions from the driver DLL that is used both by WinCC and Simatic Manager to talk to controllers. Note: This attack vector can be used without the applications mentioned being installed, by simply using a pirated DLL, or by implementing a custom driver that attacks networked controllers directly. Basic development tools to aid in the development are in the wild.
Exploit B: Hidden output manipulations on controllers via man-in-the-middle attack
How it works: Disable automatic process image updates by configuration change in system data block, intercept physical inputs, write fake input signals to input process image. Can be used by injected rogue code or by disgruntled insiders with access to project files. Note: Translate “output” with “behavior of pumps, valves, mixers, boilers, burners, drives, robots, etc.”
If you compare this to the much-discussed zero-day vulnerabilities that Stuxnet exploits on Windows PCs, you will notice major differences both in potential impact and mitigation opportunities.
Impact
Controller exploits affect physical processes and may lead to physical damage. No matter what you do on a computer, you only mess with information. On a controller, you mess with energy and material. In the case of safety systems, you may even mess with life and limb. As we have argued before, the impact of Stuxnet is even bigger than a bunker buster.
If you followed the US Senate’s hearing on the impact of Stuxnet on critical infrastructure protection, you will probably remember Sean McGurk telling the Senate that the affected products had a market share of 7% in the US. Many people who were watching the hearing may have thought: No big deal, 7% of little grey boxes that nobody seems to use in their households, so what. The picture might have changed if Senator Lieberman had followed up with the question: How many of our power plants are equipped with the exact same products in critical position, such as turbine control? How many million households were affected if these power plants were successfully attacked by Stuxnet-like malware?
Mitigation
Millions of people who follow the Stuxnet saga are under the misleading impression that the Iranians just forgot to install proper anti-virus on their controllers, or were sloppy on patching their controllers. Millions of people do not know, and cannot understand, that controllers just do not have anti-virus, and that the vulnerabilities exploited by Stuxnet cannot be “patched”. Certainly it is not easy to understand, but still it remains fact. Even more people believe that once we have updated AV signatures on our PCs, including those in the power plants, the threat is gone. Wrong, since the Windows part of Stuxnet is only the delivery mechanism, and not the warhead. The warhead may be delivered by many other means, including other/new dropper malware for which the target system has no AV signature.
We all are used to vulnerabilities on our PCs and have learned to live with them. We are used to apply vendor security patches to deal with the problem, and then the problem is gone. Not so on controllers. What is exploited by Stuxnet are not “bugs”, or software defects. Believe it or not, but we’re talking about regular product features that you find in the majority of these systems, regardless of vendor. Changing these features would lead to version conflicts and incompatibilities. Besides, few people have an idea how long it will take to change firmware versions in all, or even most of the millions of controllers that are affected – it will take many years. Even the first-response mitigation methods that we have suggested on Sep 17 take many months to implement.
And this is why we have a real big problem, since copycat attacks must be expected before we get these vulnerabilities fixed in the majority of systems. Chances are such copycats won’t use project names with biblical references, such as Myrtus/Esther, but with references to the Quran.