Blockbuster Worm Aimed for Infrastructure, But No Proof Iran Nukes Were Target | Threat Level | Wired.com
Blockbuster Worm Aimed for Infrastructure, But No Proof Iran Nukes Were Target
- By Kim Zetter
- September 23, 2010 |
- 3:57 pm |
- Categories: Breaches, Cybersecurity, Hacks and Cracks, Threats
An exceptionally sophisticated piece of malware designed to attack programs used in critical infrastructure and other facilities garnered extensive attention among computer security experts this week as new details about its design and capabilities emerge, along with speculation it was aimed at disrupting Iran’s nuclear program.“It’s the most complex piece of malware we’ve seen in the last five years or more,” says Nicolas Falliere, a code analyst at security firm Symantec. “It’s the first known time that malware is not targeting credit card [data], is not trying to steal personal user data, but is attacking real-world processing systems. That’s why it’s unique and is not over-hyped.”
The Stuxnet worm, which was discovered in June and has infected more than 100,000 computer systems worldwide, is designed to attack the Siemens Simatic WinCC SCADA system. SCADA systems, short for “supervisory control and data acquisition,” are programs installed in pipelines, nuclear plants, utility companies and manufacturing facilities to manage operations.
But even more intriguingly, researchers say the worm is designed to attack a very particular configuration of the Simatic SCADA software, indicating the malware writers had a specific facility or facilities in mind for their attack and had extensive knowledge of the system they were targeting. Although it’s not known what system was targeted, once on the targeted system, the worm was designed to install additional malware, possibly with the purpose of destroying the system and creating real-world explosions in the facility where it ran.
The worm was publicly exposed after VirusBlokAda, an obscure Belarusian security company, found it on computers belonging to a customer in Iran — the country where the majority of the infections occurred. Initial analysis suggested the worm was designed only to steal intellectual property — perhaps by competitors wishing to copy manufacturing operations or products.
But researchers who have spent the last three months reverse-engineering the code and running it in simulated environments now say that it’s designed for sabotage, and that its level of sophistication suggests that a well-resourced nation-state is behind the attack. A few researchers have speculated that Iran’s nascent nuclear program was a possible target for the worm’s destructive payload, though that’s based on circumstantial evidence.
Sophisticated Code
Ralph Langner, a computer security researcher in Germany, published an extensive look at the malware last week. He determined that once on a computer the malware looks for a specific configuration of a Siemens component called the Programmable Logic Controller, or PLC. If the malware determines it’s on the correct system, it begins to intercept communications from the system’s Simatic Manager to the PLC and interjects numerous commands to reprogram the PLC to do what it wants.
Symantec provided an even more detailed description of the malware on Wednesday and plans to release a paper about Stuxnet at a conference Sept. 29. Symantec’s Falliere, reached in France, said two models of Siemens PLCs are targeted by the worm — the S7-300 series and the S7-400 series — which are used in many facilities.
The malware is huge — about half a megabyte of code — and has a number of sophisticated and previously unseen characteristics:
- It uses four zero-day vulnerabilities (vulnerabilities that haven’t yet been patched by a software vendor and are generally undetected by antivirus programs). One zero-day is used to spread the worm to a machine by a USB stick. A Windows printer-spooler vulnerability is used to propagate the malware from one infected machine to others on a network. The last two help the malware gain administrative privileges on infected machines to feed the system commands.
- The malware is digitally signed with legitimate certificates stolen from two certificate authorities.
- The attacker uses a command-and-control server to update the code on infected machines but also uses, in case the command server is taken down, peer-to-peer networking to propagate updates to infected machines.
The malware would have required a team or teams of people with different skills — some with extensive knowledge of the targeted PLC, and others who specialize in vulnerability research to find the zero-day holes, analysts say. The malware would have required extensive testing to ensure it could commandeer a PLC without crashing the system or setting off other alerts of its presence.
Eric Byres, chief technology officer for Byres Security, says the malware isn’t content to just inject a few commands into the PLC but does “massive reworking” of it.
“They’re massively trying to do something different than the processor was designed to do,” says Byres, who has extensive experience maintaining and troubleshooting Siemens control systems. “Every function block takes a fair amount of work to write, and they’re trying to do something quite radically different. And they’re not doing it in a light way. Whoever wrote this was really trying to mess with that PLC. We’re talking man-months, if not years, of coding to make it work the way it did.”
Although it’s unclear what specific processes the malware attacked, Langner, who couldn’t be reached, wrote on his blog that “we can expect that something will blow up” as a result of the malware.
Byres agrees and says this is because the malware interjects what’s known as Organizational Block 35 data blocks. OB35 data blocks are used for critical processes that are either moving very fast or are in high-pressure situations. These data blocks take priority over everything else in the processor and run every 100 milliseconds to monitor critical situations that can change quickly and wreak havoc.
“You use this priority for things that are absolutely mission-critical on the machine — things that really are threatening to the life of the people around it or the life of the machine,” Byres says, “like a turbine or a robot or a cyclone — something that’s going very, very fast and will tear itself apart if you don’t respond quickly. Big compressor stations on pipelines, for example, where the compressors are moving at very high RPMs would use OB35.”
The malware also affects the Windows programming station that communicates with the PLC and monitors it. The hack ensures that anyone examining the logic in the PLC for problems would see only the logic that was in the system before the malware struck — the equivalent of inserting a video clip into a surveillance camera feed so that someone watching a security monitor would see a looped image of a static picture rather than a live feed of the camera’s environment.
Beyond this, the malware injects dozens of other data blocks into the PLC for unknown reasons. Byres believes these disable safety systems and cancel alarms to “make absolutely certain that there’s nothing in [the attackers'] way” preventing them from releasing their destructive payload.
Langner calls the malware “a one-shot weapon,” and assumes the attack already occurred and was successful at what it intended to do, though he acknowledges this is just speculation.
Iran Connection
Langner believes the Bushehr nuclear power plant in Iran was the Stuxnet target, but offers little evidence to support this theory. He points to a computer screenshot published by United Press International which purports to have been taken at Bushehr in February 2009 showing a schematic of the plant’s operations and a pop-up box indicating the system was using Siemens’ control software.
But Frank Rieger, chief technology officer at Berlin security firm GSMK, thinks it more likely the target in Iran was a nuclear facility in Natanz. The Bushehr reactor is designed to develop non–weapons-grade atomic energy, while the Natanz facility, a centrifuge plant, is designed to enrich uranium and presents a greater risk for producing nuclear weapons. Rieger backs this claim with a number of seeming coincidences.
The Stuxnet malware appears to have begun infecting systems in January 2009. In July of that year, the secret-spilling site WikiLeaks posted an announcement saying that an anonymous source had disclosed that a “serious” nuclear incident had recently occurred at Natanz.
WikiLeaks broke protocol to publish the information — the site generally only publishes documents, not tips — and indicated that the source could not be reached for further information. The site decided to publish the tip after news agencies began reporting that the head of Iran’s atomic energy organization had abruptly resigned for unknown reasons after 12 years on the job.
There’s speculation his resignation may have been due to the controversial 2009 presidential elections in Iran that sparked public protests — the head of the atomic agency had also once been deputy to the losing presidential candidate. But information published by the Federation of American Scientists in the United States indicates that something may indeed have occurred to Iran’s nuclear program. Statistics from 2009 show that the number of enriched centrifuges operational in Iran mysteriously declined from about 4,700 to about 3,900 beginning around the time the nuclear incident WikiLeaks mentioned would have occurred.
If Iran was the target, however, it raises questions about the scattershot method of infection — the malware spread by worm among thousands of computers in multiple countries. Targeted attacks usually start by tricking an employee at the target facility to install malware through a phishing attack or other common means. Langner suggests the scattershot approach may be the result of the infection spreading through a Russian company known to be working on the Bashehr plant and which has contracts in other countries infected by the worm.
The Russian contractor, AtomStroyExport, had security problems with its web site, leading Langner to believe it had general lax security practices that could have been exploited by attackers to get the malware into Iran. Then the malware may have simply spread to machines in other countries where AtomStroyExport worked.
If Iran was the target, the United States or Israel are suspected as the likely perpetrators — both have the skill and resources to produce complicated malware such as Stuxnet. In 1981, Israel bombed Iraq’s Osiraq nuclear reactor. Israel is also believed to be behind the bombing of a mysterious compound in Syria in 2007 that was believed to be an illicit nuclear facility.
Last year, an article published by Ynetnews.com, a web site connected to the Israeli newspaper Yediot Ahronot, quoted a former Israeli cabinet member saying the Israeli government determined long ago that a cyber attack involving the insertion of targeted computer malware was the only viable way to halt Iran’s nuclear program.
Photo: mugley/flickr
See also
Comments
Post a Comment