Plant Breakdown

Over the last few days I have been piecing together a number of reports on the Iranian nuclear efforts. The reports lead me to some interesting conclusions/speculations. More on the conclusions/speculations later. First let me start with the breakdown of Iran's enrichment centrifuges from July of this year.

Iran has suffered a series of technical setbacks to its nuclear programme in the past 12 months, triggering suggestions that western intelligence agencies are sabotaging its likely ambition to build an atomic weapon.

As Iran continues to defy international sanctions, western security analysts say the country is making progress towards the ability to test a nuclear bomb in the next few years.

But a series of recent reverses, notably affecting Iran’s ability to enrich uranium, is prompting debate over whether the programme is being undermined by sabotage, sanctions, or the incompetence of the regime’s scientists.

In the past year, a dramatic reduction has taken place in the number of centrifuges enriching uranium at the regime’s nuclear plant in Natanz.

In May 2009, the International Atomic Energy Agency said there were 4,920 operational centrifuges. Twelve months later the IAEA stated that Iran was running only 3,936, a reduction of 20 per cent.

Iran also appears to be having difficulties on other fronts. Ivan Oelrich, of the Federation of American Scientists, said the centrifuges were only working at 20 per cent efficiency. The latest IAEA report says that 4,592 centrifuges are installed at Natanz – but are sitting idle and doing nothing at all.

Well isn't that interesting?

And that is not the only interesting thing. We have some recent reports about the Stuxnet computer virus. More accurately described as a worm. But virus will do for generic discussions.

Iran's nuclear agency is trying to combat a complex computer worm that has affected industrial sites throughout the country and is capable of taking over power plants, Iranian media reports said.

Experts from the Atomic Energy Organization of Iran met this week to discuss how to remove the malicious computer code, or worm, the semi-official ISNA news agency reported Friday.

The computer worm, dubbed Stuxnet, can take over systems that control the inner workings of industrial plants. Experts in Germany discovered the worm in July, and it has since shown up in a number of attacks — primarily in Iran, Indonesia, India and the U.S.

The ISNA report said the malware had spread throughout Iran, but did not name specific sites affected. Foreign media reports have speculated the worm was aimed at disrupting Iran's first nuclear power plant, which is to go online in October in the southern port city of Bushehr.

Iranian newspapers have reported on the computer worm hitting industries around the country in recent weeks, without giving details.

Some folks think it was targeted at Iran's nuclear power plant which is due to come on line in the next few months.

By August, researchers had found something more disturbing: Stuxnet appeared to be able to take control of the automated factory control systems it had infected – and do whatever it was programmed to do with them. That was mischievous and dangerous.

But it gets worse. Since reverse engineering chunks of Stuxnet's massive code, senior US cyber security experts confirm what Mr. Langner, the German researcher, told the Monitor: Stuxnet is essentially a precision, military-grade cyber missile deployed early last year to seek out and destroy one real-world target of high importance – a target still unknown.

Note the bolded text. I'm going to develop that theme further.


But first some old news (July 2009) from Israel.

In the late 1990s, a computer specialist from Israel's Shin Bet internal security service hacked into the mainframe of the Pi Glilot fuel depot north of Tel Aviv.

It was meant to be a routine test of safeguards at the strategic site. But it also tipped off the Israelis to the potential such hi-tech infiltrations offered for real sabotage.

"Once inside the Pi Glilot system, we suddenly realized that, aside from accessing secret data, we could also set off deliberate explosions, just by programming a re-route of the pipelines," said a veteran of the Shin Bet drill.

So began a cyberwarfare project which, a decade on, is seen by independent experts as the likely new vanguard of Israel's efforts to foil the nuclear ambitions of its arch-foe Iran.

And there are more clues.

German IACS security researcher Ralph Langner has successfully analyzed the Stuxnet malware that appeared to be a miracle. Stuxnet is a directed attack against a specific control system installation. Langner will disclose details, including forensic evidence, next week at Joe Weiss' conference in Rockville.


Stuxnet logbook, Sep 16 2010, 1200 hours MESZ

With the forensics we now have it is evident and provable that Stuxnet is a directed sabotage attack involving heavy insider knowledge. Here is what everybody needs to know right now.

Fact: As we have published earlier, Stuxnet is fingerprinting its target by checking data block 890. This occurs periodically every five seconds out of the WinCC environment. Based on the conditional check in code that you can see above, information in DB 890 is manipulated by Stuxnet.

Interpretation: We assume that DB 890 is part of the original attacked application. We assume that the second DWORD of 890 points to a process variable. We assume that this process variable belongs to a slow running process because it is checked by Stuxnet only every five seconds.

Fact: Another fingerprint is DB 8062. Check for the presence of DB 8062 in your project.

Fact: Stuxnet intercepts code from Simatic Manager that is loaded to the PLC. Based on a conditional check, original code for OB 35 is manipulated during the transmission. If the condition matches, Stuxnet injects Step7 code into OB 35 that is executed on the PLC every time that OB 35 is called. OB 35 is the 100 ms timer in the S7 operating environment. The Step7 code that Stuxnet injects calls FC 1874. Depending on the return code of FC 1874, original code is either called or skipped. The return code for this condition is DEADF007 (see code snipplet).

Well that is clear as mud to anyone but a code geek (me, me, me). So how about a layman's explanation?

Interpretation: Stuxnet manipulates a fast running process. Based on process conditions, the original code that controls this fast running process will no longer be executed. (Some people will now want to have their process engineers explain what the DEADF could mean.) After the original code is no longer executed, we can expect that something will blow up soon. Something big.

Now that everybody is getting the picture let's try to make sense out of the findings. What do they tell us about the attack, the attackers, and the target?

1. This is sabotage. What we see is the manipulation of one specific process. The manipulations are hidden from the operators and maintenance engineers (we have the intercepts identified).

2. The attack involves heavy insider knowledge.

3. The attack combines an awful lot of skills -- just think about the multiple 0day vulnerabilities, the stolen certificates etc. This was assembled by a highly qualified team of experts, involving some with specific control system expertise. This is not some hacker sitting in the basement of his parents house. To me, it seems that the resources needed to stage this attack point to a nation state.

4. The target must be of extremely high value to the attacker.

5. The forensics that we are getting will ultimately point clearly to the attacked process -- and to the attackers. The attackers must know this. My conclusion is, they don't care. They don't fear going to jail.

6. Getting the forensics done is only a matter of time. Stuxnet is going to be the best studied piece of malware in history. We will even be able to do process forensics in the lab. Again, the attacker must know this. Therefore, the whole attack only makes sense within a very limited timeframe. After Stuxnet is analzyed, the attack won't work any more. It's a one-shot weapon. So we can conclude that the planned time of attack isn't somewhen next year. I must assume that the attack did already take place. I am also assuming that it was successful. So let's check where something blew up recently.

But what if it is not something big breaking down? Suppose it is a lot of not so big somethings? Like centrifuges. And suppose the code was designed to misregulate the speed of centrifuges so that they break down from overspeed. You want your code to only go into operation only when the centrifuges were at operational speed. It is not very destructive if the code starts working when the centrifuges were at a relatively slow speed. You can hit the master power switch manually if erratic operation is observed at slow speed.

One thing this points to is that who ever designed the virus/worm had to know exactly what parts of the control computer were used to control a vulnerable processes. The kinds of controllers used to control machinery have lots of options in terms of how their internal computers are configured to control a given device. Is it Timer 1 or Timer 6? Port 0 or Port 7? And other such details. So inside information is definitely required. Speculation is that the Russians designed the control system. So did the Russians design the virus? Or did they hand off the details of the design to some one else to design the virus?

Which reminds me of something that happened during the 2007 Israeli attack on a purported Syrian nuclear installation where a defense system provided by Russia didn't work as advertised. Curious. Perhaps the Israelis had inside information on the vulnerabilities of the Russian defense system. Or the Russians told the Israelis of a backdoor that they could access in real time by sending the right sequence of pulses (say via a radar jamming device) to the Russian system.

Now for the speculation I promised at the beginning. Such a software attack depends on a few things. First off Iran had to do research and development to design the uranium enrichment equipment. This takes time. Once such a system is developed and the hardware and software are working the production of the systems had to be ramped up. Any attack on the systems before a significant number are deployed would blunt the attack. Such an attack could only have maximum effectiveness when the systems were in production and significant quantities were deployed. Any attack would have to be timed with some precision. Too soon and the attack is ineffective. Too late and well... it would be too late. So there is a window of opportunity maybe a few months. A year at most. So who ever did the attack had to have inside information, not only about the equipment used but also the deployment rate. That kind of attack is best done when as much system integration as possible was completed in order to maximize the damage.

So where do the Iranians go from here? Basically they have to start from scratch because they do not know if there are any unknown vulnerabilities still hiding in their systems. Which means they may still have a good design for centrifuges but all the supporting control equipment must be redesigned from the ground up. This could take several more years (or more) depending on the level of testing being done. And the testing will be much more severe than it was the first time around to prevent (as much as possible) a repeat. In this case the advantage lies with the offense. This is because they must fill all the security holes while the attackers only need to find one or a very few vulnerabilities.

The question for the regime in Iran is: can they keep a lid on their population until they are successful? Only time will tell.

So what would I do? Accelerate the collapse of the Chinese real estate bubble so that petroleum demand falls below a price level that can sustain Iran. Bleed them economically.

I covered the economic war against Iran at:

Iran to Enter Cash Flow Jihad Zone

and Iran's economic vulnerability (actually written by A. Jacksonian) at:

Oil Outlook

A lot of food for thought.

Cross Posted at Classical Values