New Clues Point to Israel as Author of Blockbuster Worm, Or Not

Share

New Clues Point to Israel as Author of Blockbuster Worm, Or Not

New clues released this week show a possible link between Israel and sophisticated malware targeting industrial control systems in critical infrastructure systems, such as nuclear plants and oil pipelines.

Or, they could simply be red herrings planted in the code by programmers to point suspicion at Israel and away from other possible suspects.

The malware, called Stuxnet, appears to be the first to effectively attack critical infrastructure and in a manner that produces physical results, although there's no proof yet any real-world damage has been done by it. The malware's sophistication and infection of thousands of machines in Iran has led some to speculate that the U.S. or Israeli government built the code to take out Iran's nuclear program.

Symantec's paper adds to that speculation. It also provides intriguing data about an update the authors made to it in March of this year that ultimately led to it being discovered. The update suggests the authors, despite launching their malware as early as June 2009, may not have reached their target by March 2010.

The code has so far infected about 100,000 machines in 155 countries, apparently beginning in Iran and recently hitting computers in China. Researchers still have no idea if the malware reached the targeted system it was designed to sabotage.

Liam O Murchu, researcher at Symantec Security Response, said in a press call Friday that even though the malware's command-and-control server has been disabled, the attackers can still communicate with infected machines via peer-to-peer networking. Symantec hopes that experts in industrial control systems who read their paper may help identify the specific environment Stuxnet was targeting.

"We hope someone will look at the values and say this is a configuration you'd only find in an oil refinery or power plant," said O Murchu. "It's very important to find out what the target was. You can't tell what [Stuxnet] does unless you know what it was connected to. "

The code targets industrial control software made by Siemens called WinCC/Step 7, but is designed to deliver its malicious payload to only a particular configuration of that system. About 68 percent of infected systems in Iran have the Siemens software installed, but researchers don't know if any have the targeted configuration. By contrast, only 8 percent of infected hosts in South Korea are running Step 7 software, and only about 5 percent of infected hosts in the U.S. do. An apparent "kill" date in the code indicates that Stuxnet is designed to stop working June 24, 2012.

The first clue that may point to Israel's involvement in the malware involves two file directory names - myrtus and guava - that appear in the code. When a programmer creates code, the file directory where his work-in-progress is stored on his computer can find its way into the finished program, sometimes offering clues to the programmer's personality or interests.

In this case, Symantec suggests the name myrtus could refer to the biblical Jewish Queen Esther, also known as Hadassah, who saved Persian Jews from destruction after telling King Ahasuerus of a plot to massacre them. Hadassah means myrtle in Hebrew, and guavas are in the myrtle, or myrtus family of fruit.

A clue to Stuxnet's possible target lies in a "do not infect" marker in the malware. Stuxnet conducts a number of checks on infected systems to determine if it's reached its target. If it finds the correct configuration, it executes its payload; if not, it halts the infection. According to Symantec, one marker Stuxnet uses to determine if it should halt has the value 19790509. Researchers suggests this refers to a date – May 9, 1979 – that marks the day Habib Elghanian, a Persian Jew, was executed in Tehran and prompted a mass exodus of Jews from that Islamic country.

O Murchu said the authors, who were highly skilled and well-funded, were meticulous about not leaving traces in the code that would track back to them. The existence of apparent clues, then, would belie this precision.

One mystery still surrounding the malware is its wide propagation, suggesting something went wrong and it spread farther than intended. Stuxnet, when installed on any machine via a USB drive, is supposed to spread to only three additional computers, and to do so within 21 days.

"It looks like the attacker really did not want Stuxnet to spread very far and arrive at a specific location and spread just to computers closest to the original infection," O Murchu said.

But Stuxnet is also designed to spread via other methods, not just via USB drive. It uses a zero-day vulnerability to spread to other machines on a network. It can also be spread through a database infected via a hardcoded Siemens password it uses to get into the database, expanding its reach.

Symantec estimates it took between 5 and 10 developers with different areas of expertise to produce the code, plus a quality assurance team to test it over many months to make certain it would go undetected and not destroy a target system before the attackers intended to do so.

The WinCC/Step 7 software that Stuxnet targets connects to a Programmable Logic Controller, which controls turbines, pressure valves and other industrial equipment. The Step 7 software allows administrators to monitor the controller and program it to control these functions.

When Stuxnet finds a Step7 computer with the configuration it seeks, it intercepts the communication between the Step 7 software and the controller and injects malicious code to presumably sabotage the system. Researchers don't know exactly what Stuxnet does to the targeted system, but the code they examined provides a clue.

One value found in Stuxnet - 0xDEADF007 - is used by the code to specify when a process has reached its final state. Symantec suggests it may mean Dead Fool or Dead Foot, a term referring to an airplane engine failure. This suggests failure of the targeted system is a possible aim, though whether Stuxnet aims to simply halt the system or blow it up remains unknown.

Two versions of Stuxnet have been found. The earliest points back to June 2009, and analysis shows it was under continued development as the attackers swapped out modules to replace ones no longer needed with new ones and add encryption and new exploits, apparently adapting to conditions they found on the way to their target. For example, digital certificates the attackers stole to sign their driver files appeared only in Stuxnet in March 2010.

One recent addition to the code is particularly interesting and raises questions about its sudden appearance.

A Microsoft .lnk vulnerability that Stuxnet used to propagate via USB drives appeared only in the code in March this year. It was the .lnk vulnerability that ultimately led researchers in Belarus to discover Stuxnet on systems in Iran in June.

O Murchu said it's possible the .lnk vulnerability was added late because the attackers hadn't discovered it until then. Or it could be they had it in reserve, but refrained from using it until absolutely necessary. The .lnk vulnerability was a zero-day vulnerability – one unknown and unpatched by a vendor that takes a lot of skill and resources for attackers to find.

Stuxnet's sophistication means that few attackers will be able to reproduce the threat, though Symantec says many will try now that Stuxnet has taken the possibility for spectacular attacks on critical infrastructures out of Hollywood movies and placed them in the real world.

"The real-world implications of Stuxnet are beyond any threat we have seen in the past," Symantec writes in its report. "Despite the exciting challenge in reverse engineering Stuxnet and understanding its purpose, Stuxnet is the type of threat we hope to never see again."