Saturday, February 19, 2011

Did a U.S. Government Lab Help Israel Develop Stuxnet? | Threat Level | Wired.com

Did a U.S. Government Lab Help Israel Develop Stuxnet?

Questions are being raised about the involvement of U.S. government researchers in the creation of a digital weapon that experts believe may have sabotaged centrifuges at a uranium-enrichment plant in Iran.

Researchers at the Idaho National Laboratory, which is overseen by the U.S. Department of Energy, may have passed critical information to Israel about vulnerabilities in a system that controls Iran’s enrichment plant at Natanz. That information was then used to create and test the so-called Stuxnet worm that was unleashed in a joint cyberattack on Natanz, according to The New York Times.

The report, based on anonymous sources, is sparse on detail but asserts that in 2008, INL worked with the German firm Siemens to uncover vulnerabilities in its industrial-control system. Stuxnet was then created to exploit those vulnerabilities and was lab-tested at Israel’s nuclear facility in Dimona. The Dimona facility, according to the Times, has been involved in a joint U.S.-Israel operation for the last two years to thwart Iran’s production of enriched uranium and forestall its development of a nuclear weapon.

Researchers at Dimona set up a test bed composed of the Siemens system and the same IR-1 nuclear centrifuges (also known as P-1 centrifuges) used at Natanz to gauge Stuxnet’s effect on them. The malware was discovered in the wild last June infecting systems in Iran and elsewhere, and last November, Iran acknowledged that malicious software had sabotaged centrifuges at Natanz.

Threat Level has already reported extensively on how Stuxnet worked and on clues that were previously uncovered that suggested Israel was behind the attack. Although it’s long been suspected that the United States played a key role, if not the lead role, in creating the malware, there’s been no definitive evidence.

The Times story falls short of delivering that evidence, but Threat Level has been tracking the same story for months, and it’s worth fleshing out the report with additional details.

To back claims that the Idaho National Laboratory likely played a role in Stuxnet, the Times reports that in early 2008, Siemens worked with INL to identify vulnerabilities in the specific control system that Stuxnet targeted – Siemens’ PCS 7, or Process Control System 7. The project was initiated by the Department of Homeland Security.

Siemens told the Times that the research was part of a routine program to identify vulnerabilities in various critical infrastructure systems and find ways to secure them. The INL also said the research was part of a larger project and would not comment on whether information it learned about the Siemens system during these tests was passed to intelligence services.

But let’s look at the time frame and context of these tests.

The INL began setting up a test lab to research industrial-control systems in 2002 after U.S. officials became concerned that al-Qaida might be investigating methods to conduct cyberattacks against critical infrastructure systems in the United States.

In 2001, following the 9/11 terrorism attacks, a local police detective in California began investigating what appeared to be a series of cyber-reconnaissance operations against utility companies and government offices in the San Francisco Bay Area. The surveillance appeared to come from computers in the Middle East and South Asia.

The FBI and Lawrence Livermore National Laboratory got involved and discovered a nationwide pattern of digital surveillance being conducted at nuclear power plants, gas and electric facilities, as well as water plants. The intruders were particularly focused on examining industrial-control devices that allowed for remote access to systems operating critical infrastructures.

In January and March 2002, U.S. forces in Afghanistan and Pakistan conducting raids on al-Qaida offices and compounds seized computers that provided further evidence that al-Qaida was investigating means to conduct cyberattacks against dams and other critical infrastructures.

Three months later, INL contacted Joe Weiss, a control-systems expert who worked at the time for KEMA, an energy consulting firm, to come to Idaho to discuss creating an industry test bed to uncover vulnerabilities in SCADA systems, also known as Supervisory Control and Data Acquisition systems. As a result of these discussions, Weiss began helping INL work with SCADA vendors to provide INL with equipment and knowledge for research and testing.

The research paid off. In 2004, INL presented the first demonstration of a remote SCADA hack at the KEMA Control Systems Cyber Security Conference in Idaho Falls. The purpose of the demonstration was to show that recently identified vulnerabilities in Apache software could be used to compromise a control system remotely. The attack was conducted from Sandia National Laboratory against a system at INL in Idaho Falls.

The attack was designed to show how firewalls and other traditional security systems would fail to guard against a remote intrusion. But it also demonstrated a man-in-the-middle maneuver that would hide the attacker’s malicious activity from employees monitoring display screens at the targeted facility — something that Stuxnet later accomplished remarkably well.

A second remote SCADA hack was demonstrated at the KEMA Control System Cyber Security Conference in 2006 in Portland, Oregon. This one was conducted by a different DoE lab, the Pacific Northwest National Laboratory. The attack involved compromising a secure VPN to change voltages on a simulated Olympic Peninsula electric system while, again, altering operator displays to conceal the attack.

Then in February 2007, DHS got word of a potential vulnerability in industrial-control systems. If the vulnerability — dubbed “Aurora” — were exploited, DHS learned, it could result in physical damage to equipment. It was something that Weiss and a handful of other security experts had long worried about, but no one had ever actually seen it done.

A month later, INL conducted a private test, called the Aurora Generator Test, that successfully demonstrated the vulnerability. The test involved a remote attack using dial-up modem on an industrial-control-system generator, which left the generator a spinning mess of metal and smoke. The proof-of-concept demonstration showed that a remote digital attack could result in physical destruction of a system or components.

The vulnerability, and measures to mitigate it, were discussed in closed sessions with the NERC Critical Infrastructure Protection Committee. Word about the test leaked out and in September that year, the Associated Press published a video of the demonstration showing a generator emitting smoke after being hacked.

All of these demonstrations served to establish that a remote stealth attack on an industrial-control system was entirely feasible.

The timing is important, because by early 2008, Iran was busy installing centrifuge cascades in module A26 at the Natanz enrichment plant — the module that experts believe was later targeted by Stuxnet.

At the same time, in early 2008, President George Bush authorized a covert program that was reportedly designed to subtly sabotage Iran’s nuclear weapons program. Details of the program were never disclosed, but the Times later reported that it was, in part, aimed at undermining the electrical and computer systems at Natanz.

Enter the Idaho National Laboratory.

In March 2008, Siemens and INL researchers met to map out a vulnerability-test plan for the Siemens PCS7 system, the system that was targeted by Stuxnet. INL had tested Siemens SCADA systems previously but, according to Weiss, this is believed to be the first time INL was examining the Siemens PLC.

In May, Siemens shipped a test system from Germany to the Idaho Falls lab.

That same month, the DHS became aware of a vulnerability in the firmware upgrade process used in industrial-control systems. Firmware is the resident software, such as an operating system, that comes installed on a piece of hardware. In order to ease maintenance and troubleshooting of systems, vendors like to install patches or upgrades to software remotely, but this can expose the system to attack if the upgrade process has a vulnerability. A vulnerability was found, which DHS dubbed “Boreas.”

DHS issued a private alert – which was later inadvertently made public — saying that the vulnerability, if exploited, “could cause components within the control system to malfunction or shut down, potentially damaging the equipment and/or process.”

Stuxnet, it turns out, involved a type of remote firmware upgrade to the Siemens PLC, since it involved injecting malicious code into the ladder logic of a PLC. Boreas in retrospect, says Weiss, who is currently an independent consultant with Applied Control Systems and the author of Protecting Industrial Control Systems, showed that the concept of injecting code into the ladder logic was feasible.

“The Boreas alert never specifically discussed ladder logic or PLCs,” says Weiss. “But it showed that if you can remotely change firmware, you can cause real problems.”

Two months later, Siemens and INL began conducting research and tests on the Siemens PCS7 system to uncover and attack vulnerabilities in it. By November, the researchers had completed their work and delivered their final report to Siemens in Germany. They also created a PowerPoint presentation (.pdf) to deliver at a conference, which the Times mentions.

What the Times doesn’t say is that German researcher Ralph Langner, who has done some of the best research on Stuxnet and was the first to suggest that Iran’s nuclear program was Stuxnet’s target, discovered the PowerPoint presentation on Siemens’ website last year. After Langner blogged about it in December suggesting the tests might have been connected to Stuxnet, Siemens removed the presentation from the web, but not before Langner downloaded it.

In June 2009, seven months after INL and Siemens completed their report, the first sample of Stuxnet was found in the wild. The code was found by the Russian computer-security firm Kaspersky, although no one at Kaspersky knew at the time what they possessed.

That sample, now known as “Stuxnet Version A,” was less sophisticated than Version B of Stuxnet, which was later discovered in June 2010 and made headlines. Version A was picked up through Kaspersky’s global filtering system and sat in obscurity in the company’s malware archive until Version B made headlines and Kaspersky decided to sift through its archive to see if any samples of Stuxnet had been vacuumed up earlier than 2010.

Kaspersky researcher Roel Schouwenberg told Threat Level the company was never able to pinpoint geographically where the 2009 sample originated.

At the time Version A was discovered in June 2009, there were 12 centrifuge cascades in module A26 at Natanz that were enriching uranium. Six others were under vacuum but not enriching. By August, the number of A26 cascades that were being fed uranium had dropped to 10, and eight were now under vacuum but not enriching.

Was this the first indication that Stuxnet had reached its target and was beginning to sabotage centrifuges? No one knows for certain, but in July of that year, the BBC reported that Gholam Reza Aghazadeh, the long-time head of Iran’s Atomic Energy Organization, had resigned after 12 years on the job.

The reason for his resignation was unknown. But around the same time that he resigned, the secret-spilling site WikiLeaks received an anonymous tip that a “serious” nuclear incident had recently occurred at Natanz.

Over the next months, while the world was still ignorant of Stuxnet’s existence, the number of enriched centrifuges operational in Iran mysteriously declined from about 4,700 to about 3,900. The decline began around the time Version A of Stuxnet was captured by Kaspersky’s filter.

By November 2009, the number of enriching cascades in module A26 specifically had dropped to six, with 12 cascades under vacuum, according to the International Atomic Energy Agency (IAEA), which issues quarterly reports on Iran’s nuclear programs.

Between November 2009 and January 2010, module A26 suffered a major problem, with at least 11 cascades directly affected. During this period, Iran decommissioned or replaced 1,000 IR-1 centrifuges of the total 8,692 it had installed. Iranian officials have never explained to the IAEA what problem occurred with these 1,000 centrifuges.

Despite this apparent mishap, the rate of low enriched uranium (LEU) production in Iran increased significantly during this same period, and remained high for months afterward, though the rate was still far below what the IR-1 centrifuges are designed to produce, according to the Institute for Science and International Security (ISIS).

In June 2010, an obscure security firm in Belarus discovered Stuxnet Version B on a system belonging to an unnamed client in Iran. Within a couple of months, Stuxnet had spread to more than 100,000 computers, most of them in Iran.

It took weeks of research for experts to reverse-engineer the code and determine that it was targeting a very specific facility and that its primary aim was to subtly sabotage that facility by altering the frequency of something at the facility. The malware was designed to alter these frequencies over an extended period of time, suggesting the goal was to damage something but not completely destroy it in an obvious way that would draw attention.

Last month, ISIS revealed that the frequencies programmed into Stuxnet’s code were the precise frequencies that would have been needed to sabotage the IR-1 centrifuges at Natanz.

Photo: A security man stands next to an anti-aircraft gun as he scans Iran’s nuclear enrichment facility in Natanz, 300 kilometers (186 miles) south of Tehran, Iran, in April 2007.
Hasan Sarbakhshian/AP

See also:

via wired.com

Posted via email from Whistleblower

Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)