Adobe releases third security update this month for Flash Player

Adobe has released an emergency security update for its widely used Flash media player to patch a vulnerability being actively exploited on the Internet. The company is advising Windows and Mac users to install it in the next 72 hours.

An advisory the software company issued on Tuesday said only that affected Flash flaws "are being exploited in the wild in targeted attacks designed to trick the user into clicking a link which directs to a website serving malicious Flash (SWF) content." It identified the bugs as CVE-2013-0643 and CVE-2013-0648 as indexed in the common vulnerabilities and exposures database. The advisory added the exploits targeted the Firefox browser. A spokeswoman said no other attack details are available.

Adobe's advisory assigns a priority rating of 1 to Flash versions that run on Microsoft Windows or Mac OS X computers. The rating is reserved for "vulnerabilities being targeted, or which have a higher risk of being targeted, by exploit(s) in the wild." The priority for Linux users carries a rating of 3, which is used to designate "vulnerabilities in a product that has historically not been a target for attackers."

Read 2 remaining paragraphs | Comments

Revealed: Stuxnet “beta’s” devious alternate attack on Iran nuke program

Researchers have uncovered a never-before-seen version of Stuxnet. The discovery sheds new light on the evolution of the powerful cyberweapon that made history when it successfully sabotaged an Iranian uranium-enrichment facility in 2009.

Stuxnet 0.5 is the oldest known version of the computer worm and was in development no later than November of 2005, almost two years earlier than previously known, according to researchers from security firm Symantec. The earlier iteration, which was in the wild no later than November 2007, wielded an alternate attack strategy that disrupted Iran's nuclear program by surreptitiously closing valves in that country's Natanz uranium enrichment facility. Later versions scrapped that attack in favor of one that caused centrifuges to spin erratically. The timing and additional attack method are a testament to the technical sophistication and dedication of its developers, who reportedly developed Stuxnet under a covert operation sponsored by the US and Israeli governments. It was reportedly personally authorized by Presidents Bush and Obama.

Also significant, version 0.5 shows that its creators were some of the same developers who built Flame, the highly advanced espionage malware also known as Flamer that targeted sensitive Iranian computers. Although researchers from competing antivirus provider Kaspersky Lab previously discovered a small chunk of the Flame code in a later version of Stuxnet, the release unearthed by Symantec shows that the code sharing was once so broad that the two covert projects were inextricably linked.

Read 24 remaining paragraphs | Comments

Stuxnet 0.5: Command-and-Control Capabilities

Similar to Stuxnet 1.x versions, Stuxnet 0.5 has limited command-and-control (C&C) ability. In particular, Stuxnet 0.5 does not provide fine-grained control to its authors. Instead, Stuxnet 0.5 can only download new code and update itself. Stuxnet needs to spread on isolated networks and therefore has been designed to be autonomous, reducing the need to have robust and fine-grained C&C ability. Stuxnet 0.5 also uses a secondary peer-to-peer mechanism in order to propagate code updates to peers on networks inaccessible to the broader Internet.

Stuxnet 0.5 has four C&C servers, all of which are now either unavailable or have since been registered by an unrelated party.

Interestingly, Stuxnet 0.5 is programmed to stop contacting the C&C server after January 11, 2009, even though the threat is programmed to stop spreading several months later after July 4, 2009.

The C&C server domains were created in 2005 and all displayed the same front page purporting to be an Internet advertising agency named Media Suffix with the tag line “Believe What the Mind Can Dream.”
 

Figure 1. Stuxnet C&C server front page
 

The servers were hosted on commercial hosting providers in the United States, Canada, France, and Thailand.

The final target network for Stuxnet 0.5 was, in all likelihood, isolated from the Internet. To allow updates to reach these computers, Stuxnet 0.5 used a peer-to-peer mechanism. If one updated version of the threat was introduced into a network, on a USB key for example, all other compromised computers on the network could receive updates or new code modules.

Stuxnet 0.5 uses Windows mailslots for peer-to-peer communication. Mailslots allow a process to pass a message to another process on a remote computer. The threat enumerates all computers on the network and attempts to connect to a mailslot with the following name:

\\\mailslot\svchost

The threat then provides the following callback mailslot name:

\\\mailslot\imnotify

Stuxnet 0.5 uses these mailslots to provide peer-to-peer communication and distribute updates to other versions of the threat. In addition, Stuxnet 0.5 may configure the system to allow anonymous logins and open four file shares (temp$, msagent$, SYSADMIN$, and WebFiles$), sharing a set of files for retrieval by peer infections.

Stuxnet 1.x versions also included a peer-to-peer updating mechanism, but implemented in a different manner using a remote procedure call.

Additional details of the various components of Stuxnet 0.5 can be found in the following blogs, video, and technical whitepaper:

For further details on Stuxnet 0.5 you can download a copy of our whitepaper.
 

Stuxnet 0.5: Disrupting Uranium Processing at Natanz

When Symantec first disclosed details about how Stuxnet affected the programmable logic controllers (PLCs) used for uranium enrichment in Natanz, Iran, we documented two attack strategies. We also noted that the one targeting 417 PLC devices was disabled. We have now obtained an earlier version of Stuxnet that contains the fully operational 417 PLC device attack code.

After painstaking analysis, we can now confirm that the 417 PLC device attack code modifies the state of the valves used to feed UF6 (uranium hexafluoride gas) into the uranium enrichment centrifuges. The attack essentially closes the valves causing disruption to the flow and possibly destruction of the centrifuges and related systems. In addition, the code will take snapshots of the normal running state of the system, and then replay normal operating values during an attack so that the operators are unaware that the system is not operating normally. It will also prevent modification to the valve states in case the operator tries to change any settings during the course of an attack cycle.
 

Figure 1. Summary of the Stuxnet 0.5 attack strategy
 

Given Stuxnet 0.5 is an earlier version of Stuxnet, the 417 attack strategy was the original strategy, and likely abandoned in favor of modifying the centrifuge speeds instead—a technique used in Stuxnet 1.x versions.

Stuxnet 1.x contained missing pieces of code, which are present in Stuxnet 0.5. These pieces of code perform the necessary fingerprinting of the target system before deploying the 417 attack strategy and build a critical PLC data block (DB8061). Therefore, we can now fully describe the intended 417 attack strategy.
 

Fingerprinting target system configuration

This version of Stuxnet extensively fingerprints the target system to determine whether it is in the right location before it will activate the payload. To make this determination, Stuxnet checks if the infected system is running Step 7 software and parses the symbol table of the target system. The symbol table holds identification labels for each physical device in the target system. For example, each valve, pump, and sensor will have a unique identifier. The symbol labels loosely follow the ANSI/ISA-5.1 Instrumentation Symbols and Identification standard, which is used in piping and instrumentation diagrams (P&ID).
 

Figure 2. An example of a P&ID diagram from a uranium enrichment facility in Iran (Source: PressTV)
 

The following table summarizes what devices and labels Stuxnet looks for within the symbol table.
 

Table 1. Device types and labels targeted by Stuxnet
 

The labels for each of these devices follow the following specific format:

For example, for a valve in module A21, in cascade eight, associated with centrifuge 160, the label would be PV-A21-8-160.

The logic used to parse these strings yields additional interesting clues. For example, the cascade module must be between A21 and A28; this matches the known configuration of cascade modules at Natanz, Iran. Stuxnet expects a maximum of 18 cascades per module, 164 centrifuges grouped into 15 stages per cascade, which again matches the published configuration at Natanz, Iran.

Furthermore, the number of centrifuges is expected to be distributed within stages, as shown in the following table.
 

Table 2. Configuration of process stages and centrifuges
 

Within each stage, centrifuges can be further grouped into sub-clusters of four.

During fingerprinting, Stuxnet keeps a counter for each device that matches the expected configuration. Once the counter surpasses a particular threshold, Stuxnet considers the system that is being fingerprinted to match the target system configuration and will inject the attack PLC code. Stuxnet also determines which six cascades out of the possible 18 are the highest value targets and saves this information along with device addresses and configuration information into data block DB8061.
 

Attack process

Similar to version 1.x of Stuxnet, the 417 PLC device attack code consists of a state machine with eight possible states. The states conduct an attack by closing valves within six of the possible 18 cascades.
 

Figure 3. 417 PLC device attack code state flow diagram
 

  • State 0 – Wait: Perform system identification and wait for the enrichment process to reach steady-state before attacking (approximately 30 days).
  • State 1 – Record: Take peripheral snapshots and build fake input blocks for replaying later.
  • State 2 – Attack centrifuge valves: Begin replaying fake input signals. Close valves on most centrifuges with the exception of the initial feed stage valves.
  • State 3 – Secondary pressure reading: Open valves in the final stage of a single cascade to obtain a low pressure reading.
  • State 4 – Wait for pressure change: Wait for desired pressure change or time limit. This can take up to two hours.
  • State 5 – Attack auxiliary valves: Open all auxiliary valves except valves believed to be near the first feed stage (stage 10). Waits for three minutes in this state.
  • State 6 – Wait for attack completion: Waits for six minutes whilst preventing any state changes.
  • State 7 – Finish: Reset and return to state zero.

By closing almost all valves except the initial feed stage valves, UF6 will continue to flow into the system. This act alone may cause damage to the centrifuges themselves. However, the attack expects the pressure to reach five times the normal operating pressure. At this pressure, significant damage to the uranium enrichment system could occur and the UF6 gas could even revert to a solid.

Whether the attack succeeded in this manner or not remains unclear. Even if the attack did succeed, the attackers decided to switch to a different strategy, of attacking the speed of the centrifuges themselves instead, in Stuxnet 1.x versions.

Symantec would like to thank the Institute for Science and International Security (ISIS) for their continued assistance in understanding centrifugal uranium enrichment systems.

More information on key aspects of Stuxnet 0.5 can be found in the following blogs, video, and technical white paper:

For further details on Stuxnet 0.5 you can download a copy of our white paper.