By Kim Zetter
January 17, 2011 | 10:13 pm
Courtesy Of "Wired's Danger Room"
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.
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. And after Langner blogged about it in December, Siemens removed it 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. 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 A26 enriching cascades had dropped to six, with 12 cascades under vacuum, according to the International Atomic Energy Agency, 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.
Nonetheless, the rate of low enriched uranium (LEU) production 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.
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.
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
Hasan Sarbakhshian/AP
See Also:
- Report Strengthens Suspicions That Stuxnet Sabotaged Iran’s Nuclear Plant
- Iran: Computer Malware Sabotaged Uranium Centrifuges
- New Clues Point to Israel as Author of Blockbuster Worm, Or Not
- Clues Suggest Stuxnet Virus Was Built for Subtle Nuclear Sabotage
- Blockbuster Worm Aimed for Infrastructure, But No Proof Iran Nukes Were Target
- SCADA System’s Hard-Coded Password Circulated Online for Years
- Simulated Cyberattack Shows Hackers Blasting Away at the Power Grid
-----------------------------------------
Below, Is An Additional Article:
Stuxnet Authors Made Several Basic Errors
By Dennis Fisher
January 18, 2011, 1:53PM
Courtesy Of "The Threat Post"
ARLINGTON, VA--There is a growing sentiment among security researchers that the programmers behind the Stuxnet attack may not have been the super-elite cadre of developers that they've been mythologized to be in the media. In fact, some experts say that Stuxnet could well have been far more effective and difficult to detect had the attackers not made a few elementary mistakes.
In a talk at the Black Hat DC conference here Tuesday, Tom Parker, a security consultant, presented a compelling case that Stuxnet may be the product of a collaboration between two disparate groups, perhaps a talented group of programmers that produced most of the code and exploits and a less sophisticated group that may have adapted the tool for its eventual use. Parker analyzed the code in Stuxnet and looked at both the quality of the code itself as well as how well it did what it was designed to do, and found several indications that the code itself is not very well done, but was still highly effective on some levels.
Parker wrote a tool that analyzed similarities between the Stuxnet code and the code of some other well-known worms and applications and found that the code was fairly low quality. However, he also said that there was very little chance that one person could have put the entire attack together alone.
Recommended Reads
"There are a lot of skills needed to write Stuxnet," he said. "Whoever did this needed to know WinCC programming, Step 7, they needed platform process knowledge, the ability to reverse engineer a number of file formats, kernel rootkit development and exploit development. That's a broad set of skills. Does anyone here think they could do all of that?"
That broad spectrum of abilities is what has led many analysts to conclude that Stuxnet could only be the work of a well-funded, highly skilled group such as an intelligence agency or other government group. However, Parker pointed out that there were a number of mistakes in the attack that one wouldn't expect to find if it was launched by such an elite group. For example, the command-and-control mechanism is poorly done and sends its traffic in the clear and the worm ended up propagating on the Internet, which was likely not the intent.
"This was probably not a western state. There were too many mistakes made. There's a lot that went wrong," he said. 'There's too much technical inconsistency. But, the bugs were unlikely to fail. They were all logic flaws with high reliability."
Parker said that Stuxnet may have been developed originally on contract and then once it was handed off to the end user, that group adapted it by adding the C&C infrastructure and perhaps one of the exploits, as well.
The mistakes weren't limited to the operational aspects of Stuxnet, either. Nate Lawson, a cryptographer and expert on the security of embedded systems, said in a blog post Monday that the Stuxnet authors were very naive in the methods they used to cloak the payload and target of the malware. Lawson said that the Stuxnet authors ignored a number of well-known techniques that could have been much more effective at hiding the worm's intentions.
"Rather than being proud of its stealth and targeting, the authors should be embarrassed at their amateur approach to hiding the payload. I really hope it wasn’t written by the USA because I’d like to think our elite cyberweapon developers at least know what Bulgarian teenagers did back in the early 90′s," Lawson said. "First, there appears to be no special obfuscation. Sure, there are your standard routines for hiding from AV tools, XOR masking, and installing a rootkit. But Stuxnet does no better at this than any other malware discovered last year. It does not use virtual machine-based obfuscation, novel techniques for anti-debugging, or anything else to make it different from the hundreds of malware samples found every day."
Lawson concludes that whoever wrote Stuxnet likely was constrained by time and didn't think there was enough of a return to justify the investment of more time in advanced cloaking techniques.
No comments:
Post a Comment