Discussion in industry forums made me realize that not all of my presentation at WeissCon was properly understood – perhaps for the simple reason that talking about two completely different subjects in one talk can be difficult to follow. Because the subject is important, let’s go back to the basics.
During the second part of my talk, dedicated to low-key attacks against industrial controllers, I explained two lethal attacks that require zero insider knowledge. The first had been published earlier in this blog as the 14-byte time bomb. The discussion in SCADASEC assumes that it would be required to compromise the OS kernel of the controller, and to disable the cycle time monitor executive (inaccurately identified as OB35, in reality it would be OB80). Both assertions are wrong. Let’s start with the latter because it is easier to explain. Getting OB1 into a tight loop doesn’t trigger a cycle time exception because the operation block finishes well in time. If the attacker would want to add code that is heavy on CPU performance, as in the case of Stuxnet’s 417 code, he would simply disable cycle time monitoring by loading a BE directive to OB80, as demonstrated by exploit code in the wild.
The real problem with the 14-byte time bomb is not the four lines of exploit code as explained at WeissCon. This was just to make the point that no insider knowledge is required and any process can be targeted by a payload like this. The real problem is how easy it is to inject rogue code onto a controller, as demonstrated by Stuxnet. For obvious reasons we did not detail in our blog post (and neither did I in my WeissCon talk) how this is done. The point to be made was that any hacker with enough time to spare can learn how this can be achieved by studying Stuxnet, or by simply playing around long enough with the vendor’s engineering software and Wireshark. No need to p0wn the kernel. It’s all about understanding the proprietary protocol of the engineering software. All of this can be crafted into a Metasploit module and can be released on the Internet.
The other attack that I discussed focused on how to kill a controller with one legitimate command, and what the corresponding source code for Metasploit looks like. The point was: It looks short, very short. Too short. It’s way too easy. While having the same effect as the 14-byte time bomb, it isn’t time-triggered and requires online access to the target controllers. However, it is a reliable attack because it uses a legitimate command — that should never have been implemented in the protocol in the first place.
Are both vulnerabilities hard or impossible to fix? Not at all, and this is what everybody discussing DHS’ new look at vulnerabilities should know. Simply disabling the DELE command for operation blocks in the engineering protocol would result in a nuisance for a handful of control system engineers who feel that the command speeds their development process by an hour. Actually this vulnerability is easier to fix than a buffer overflow hidden somewhere deep in code. — The best solution for the vulnerability of code injection has been discussed in this blog several times, it is digitally signed ladder logic. This can be done with existing controller hardware. The Rockwell guys explained at WeissCon their first and promising steps into this direction. LL integrity checking will slow down the LL load process a couple of seconds. Just seconds delay for an engineer, but a product generation’s leap forward for the industry.
Ralph Langner