Introduction

The Czar is impressed with the Volgi’s story regarding the StuxNet virus, although it sounds like StuxNet is more of a trojan horse.

(If readers want the best dope on high-end information security, as always your man is Borepatch himself, whom the Gormogons use for Castle data security, which is probably why ‘Puter’s unable to keep using his old password of p00p. Anyway, it will be interesting to read Borepatch’s take on this story.)

As always, the Czar is skeptical. Nowhere are there any reports that the Bûshehr facility has in fact been compromised in anyway. The comments in the article appear to agree that it is feasible that Bûshehr is or was the target, but the author seems to be pressing home the possibility while the experts quoted do not. Certainly we have detected nothing of the sort at the Castle.

Why It May Be False

But there are some questions lurking in the Czar’s brain. The article is presenting this as a form of cyber-security issue, as if the trojan horse is being spread through the internet like a common virus or a worm. And this is likely not the case: we are not talking about a computer in room 1211 being infected, and now, Hollywood-like, the computer is taking over the entire facility and self-destructing. This actually is not possible except perhaps in badly designed, and very small, facilities.

You see, home computers and business computers use common protocols, commands, software, and so on that are designed to make getting onto the internet as well as using applications on them quite easy. As a result, you have two weaknesses to exploit: the way people get onto the Web, and the fact that applications use common means to share information. So it is a comparative snap to upload a virus through an easy back door, and then have the virus run amok through a system designed for easy use.

How Control Systems Work

Not so much with industrial automation and control systems. Here is how these systems really work. You but a device, say a welding robot, from a manufacturer. It has manufacturer-specific and model-specific capabilities. What does the robot do? Nothing, out of the box. A programmer has to come in and write a lot of code that tells that particular robot what to do. But that isn’t enough: you need a control processor (which is a box-like computer) to store those codes.

So, at 9:00am Monday morning, the control processor tells your Yaskawa Motoman EA1400s to start up, run through their self-diagnostics, and report any problems back. No problems? Good: now check to see if there is a device on the conveyor belt in front of you. There is? Is it aligned? It is? Good: apply a fusion weld at the following coordinates.

And so on. Each set of instructions is unique. Oh, and if you have different Motomans doing different tasks, you have different commands to offer to each, meaning you need to assign a unique address to each robot. For example, EA1400 at address 23, execute instruction 5631. EA1400 at address 24, execute instruction 5644…and so on, for each unique robot you have.

One more thing: that only works for Yaskawa Motoman EA1400s. If you have a Motoman UP6, you have a different set of instructions, since no two models necessarily work exactly the same way. And on top of that, if you have a Panasonic VR-016Gii robot, you have a completely different set of instructions because no two manufacturers use exactly the same code protocols.

If you have ever tried to reprogram a universal remote control at home because you bought a new television—you have an idea. And televisions basically work the same. Imagine a factory full of robots, each of which can do about anything you want, with no idea of what you want to do! Naturally, you wind up with millions of lines of code, all being handled by a control processor.

The Czar, of course, does not mean to suggest that one control processor can work an entire factory. Typically, you have a series of control processors, each controlling different functions. Each assembly line probably has its own, and you have multiple assembly lines for all your products.

Okay, you get the idea. An industrial application has a lot of control processors executing a vast amount of code.

Why It Would Be Tough

But these are closed systems: they may communicate by an Ethernet network, but this only passes along encoded serial or SNMP information. They are not connected to the internet, and the only time you even look at the uncompiled code is when you are making updates or changes. To do this, you run a test code on a development computer (which is not necessarily hooked up to anything), compile code into machine language, save it to a memory stick, and then insert the memory stick into the USB port on the control processor. The processor uploads the code, checks its validity, and then reboots. The new system is up and running.

So your StuxNet trojan horse has a monumental task ahead of itself. It somehow has to be inserted into a control system, be accepted by the compiler software as legitimate code, save it into a format the processor understands, and then somehow know what manufacturer, model, and address the device has.

Okay, the first step is easy. If you can develop such a code, you simply store it onto a memory stick. An operative drops the memory stick on some developer’s desk, and he later grabs it thinking it’s there for his use. Done.

The second step is much harder. How do you know which control processor is going to be used? You really do not. You might say, if your intended target is a nuclear facility, that they are using one of seven different kinds. But then you have to know which software version each is using. That is not impossible, but the evidence shows that all sorts of industrial systems are being affected, not just nuclear facilities.

And even if you guess right, and figure that out, you still have to know which of the millions of different systems were purchased, what model numbers they were, and what software versions are loaded into the machine’s memory. That is a tough prediction.

So tough in fact, that it is improbable. Maybe impossible: you would need so much inside information that it becomes easier to bribe a contractor to upload very specific code into the system and have it self-destruct that way. Using a hit-and-run trojan horse is ridiculously complicated and expensive.

And How You Could Do It

Or is it? Indeed, there could be an easy way to do this. Indeed, the DoD and the industrial security business have anticipated such a possibility for many years.

You see, there is so much complexity in even a basic control system these days that no human understands all of it. Indeed, your cell phone probably contains more lines of code than a nuclear facility’s control systems combined.

This is so true that no individual programmer can understand it, let alone keep track of it. So decades ago, programmers began to switch toward modular programming. Instead of writing one massive program that contains all the instructions, you break it into smaller chunks that are easier to manage. If you were programming a cell phone, you might divide these modules up into big functions: one program to access the cell network. Another to access a switch. Another to receive a call. One to dial. One to hang up. One to redial a number. And so on. You identify all the major functions of any phone, and then divide and conquer.

This proves to be a smart idea: if you get the functions basically right, two things happen: you can identify and fix bugs faster (one bad chunk of code no longer crashes the whole system), and you can reuse code from model to model. Your new phone needs a better way to access the cell network? No problem: you change that chunk of code, but reuse all the old ones.

And what happened over the last decade or so was that certain people got really good at writing software code for these modules…to the point that a programmer might sell his code to other companies. If you are designing a new type of phone—to stick with this analogy—you have to use so-and-so’s getIPData() function because it works perfectly, it’s cheap, and it uses very little memory.

In any device made in the last few years, from phones to cars to thermostats to televisions, there are dozens to hundreds of these modules in the processor, all made by different people at different companies at different times.

And there is the risk. You can identify one particular function that everybody is using, and insert your trojan horse there. “Hey, how can we take down that reactor in Iran? We don’t know what systems they have, what turbines they have, or what protocols are in place.” And a programmer on your side could say, “Well, no matter what they have, if they have a turbine at all, they will be using OzKomSoft’s initOverheat() module. Everybody does. And they probaly are using RusPak’s SysOne module for temperature monitoring.”

So they tailor the code. If we are in or around Iran based on the IP addresses, and we are using initOverheat(), and SysOne protocols are on the network, we can bet we are in an Iranian nuclear facility. So override the initOverheat() module that causes the turbine to spin itself apart.

The problem is that other companies around the world are using the same modules for a variety of unrelated systems. If your company is in France and manufacturing heavy generators for export to Kurdistan, you could be running both modules on your control systems as well as have IP addresses from Iran passing through your network. And pow—you see some resulting weirdness.

So despite the seemingly incredible nature of such a trojan horse, needing to hide among literally hundreds of thousands of device protocols, it is possible to streamline this with three or four logical considerations. And while this concept is making news now, the underlying concepts have been known and feared for years.

The real question, which the Volgi asks, is whether or not such an event actually happened.

Updated: more information is being revealed, that begins to reveal how StuxNet gets around (through a Windows print spooler function) and that it lives as a module within a Siemens SCADA system. And yeah: looks like it might be intended to go after something related to Iranian nuclear work.

The Czar of Muscovy

Божію Поспѣшествующею Милостію Мы, Дима Грозный Императоръ и Самодержецъ Всероссiйскiй, цѣсарь Московскiй. The Czar was born in the steppes of Russia in 1267, and was cheated out of total control of all Russia upon the death of Boris Mikhailovich, who replaced Alexander Yaroslav Nevsky in 1263. However, in 1283, our Czar was passed over due to a clerical error and the rule of all Russia went to his second cousin Daniil (Даниил Александрович), whom Czar still resents. As a half-hearted apology, the Czar was awarded control over Muscovy, inconveniently located 5,000 miles away just outside Chicago. He now spends his time seething about this and writing about other stuff that bothers him.