Go to sleep. It's past your bedtime grandpa.lkwalker wrote:what about an atom bomb? that's a little more kick than a gun.
Stuxnet Worm
Re: Stuxnet Worm
Re: Stuxnet Worm
No doubt. Listen, as I've said, I don't know a whole lot about programming at all. However, letting something like this loose.... seems to me that there's a possibility of mutation. The only thing that seems like a possible fail safe switch is the fact that the Iran nuclear facility is not online.lkwalker wrote:what about an atom bomb? that's a little more kick than a gun.
Re: Stuxnet Worm
So what are you gonna do? High tech comes packaged with the seeds of its own destruction built in. Break out the sack cloth and tug your forelocks if that provides some solace. Or just quit yer bitchin and enjoy the denouement of history. It's a good show.
"If you don't think to good, don't think too much." Yogi
Re: Stuxnet Worm
You're a funny fucker. You mention pandora's box and then tell me to quit my bitching when I do the same.lkwalker wrote:So what are you gonna do? High tech comes packaged with the seeds of its own destruction built in. Break out the sack cloth and tug your forelocks if that provides some solace. Or just quit yer bitchin and enjoy the denouement of history. It's a good show.
Honestly, BE, as the days go by, I care less and less. I have no children and have decided that's a good thing for me. All this bullshit is going to be other people's problems.
It's all good for a discussion, though. It's a good way to pass the time.
Re: Stuxnet Worm
Pandora's box? I'm not the one investing the furies with moralistic imperatives. To me they're just more actors in the drama.
"If you don't think to good, don't think too much." Yogi
Re: Stuxnet Worm
This is a good read if one would like to know more of the details discovered in the analysis of the software.
How digital detectives deciphered Stuxnet, the most menacing malware in history
How digital detectives deciphered Stuxnet, the most menacing malware in history
Re: Stuxnet Worm
The Stuxnet computer worm used to sabotage Iran's nuclear program was planted by a double agent working for Israel. The agent used a booby-trapped memory stick to infect machines deep inside the Natanz nuclear facility, according to a report published on Wednesday.
Once the memory stick was infected, Stuxnet was able to infiltrate the Natanz network when a user did nothing more than click on an icon in Windows, ISSSource reported. They cited former and serving US intelligence officials who requested anonymity because of their proximity to the investigations. Covert operators from Israel and the US wanted to use a saboteur on the ground to spread the infection to insure the worm burrowed into the most vulnerable machines in the system, reporter Richard Sale added.
The double agent was probably a member of an Iranian dissident group, possibly from the Mujahedeen-e-Khalq group. This group is believed to be behind the assassinations of key Iranian nuclear scientists. In October, a huge blast destroyed an underground site near the town of Khorramabad in western Iran that housed most of Iran's Shehab-3 medium-range missiles capable of reaching Israel and Iraq. Former and current US officials told ISSSource that the MEK was behind the attack, and one of the officials said "computer manipulations" caused the blast. "Given the seriousness of the impact on Iran's (nuclear) program, we believe it took a human agent to spread the virus," the source told the publication.
More
Once the memory stick was infected, Stuxnet was able to infiltrate the Natanz network when a user did nothing more than click on an icon in Windows, ISSSource reported. They cited former and serving US intelligence officials who requested anonymity because of their proximity to the investigations. Covert operators from Israel and the US wanted to use a saboteur on the ground to spread the infection to insure the worm burrowed into the most vulnerable machines in the system, reporter Richard Sale added.
The double agent was probably a member of an Iranian dissident group, possibly from the Mujahedeen-e-Khalq group. This group is believed to be behind the assassinations of key Iranian nuclear scientists. In October, a huge blast destroyed an underground site near the town of Khorramabad in western Iran that housed most of Iran's Shehab-3 medium-range missiles capable of reaching Israel and Iraq. Former and current US officials told ISSSource that the MEK was behind the attack, and one of the officials said "computer manipulations" caused the blast. "Given the seriousness of the impact on Iran's (nuclear) program, we believe it took a human agent to spread the virus," the source told the publication.
More
Re: Stuxnet Worm
In July 2010, Stuxnet, one of the most sophisticated pieces of malware ever written, was discovered in the wild. This complex malware took many months to analyze and the eventual payload significantly raised the bar in terms of cyber threat capability. Stuxnet proved that malicious programs executing in the cyber world could successfully impact critical national infrastructure. The earliest known variant of Stuxnet was version 1.001 created in 2009. That is, until now.
Symantec Security Response has recently analyzed a sample of Stuxnet that predates version 1.001. Analysis of this code reveals the latest discovery to be version 0.5 and that it was in operation between 2007 and 2009 with indications that it, or even earlier variants of it, were in operation as early as 2005.
Key discoveries found while analyzing Stuxnet 0.5:
Oldest variant of Stuxnet ever found
Built using the Flamer platform
Spreads by infecting Step 7 projects including on USB keys
Stops spreading on July 4, 2009
Does not contain any Microsoft exploits
Has a full working payload against Siemens 417 PLCs that was incomplete in Stuxnet 1.x versions
As with version 1.x, Stuxnet 0.5 is a complicated and sophisticated piece of malware requiring a similar level of skill and effort to produce.
Despite the age of the threat and kill date, Symantec sensors have still detected a small number of dormant infections (Stuxnet 0.5 files found within Step 7 project files) worldwide over the past year.
Link
Symantec Security Response has recently analyzed a sample of Stuxnet that predates version 1.001. Analysis of this code reveals the latest discovery to be version 0.5 and that it was in operation between 2007 and 2009 with indications that it, or even earlier variants of it, were in operation as early as 2005.
Key discoveries found while analyzing Stuxnet 0.5:
Oldest variant of Stuxnet ever found
Built using the Flamer platform
Spreads by infecting Step 7 projects including on USB keys
Stops spreading on July 4, 2009
Does not contain any Microsoft exploits
Has a full working payload against Siemens 417 PLCs that was incomplete in Stuxnet 1.x versions
As with version 1.x, Stuxnet 0.5 is a complicated and sophisticated piece of malware requiring a similar level of skill and effort to produce.
Despite the age of the threat and kill date, Symantec sensors have still detected a small number of dormant infections (Stuxnet 0.5 files found within Step 7 project files) worldwide over the past year.
Link
Step 7 software infection
According to researcher Ralph Langner, once installed on a Windows system Stuxnet infects project files belonging to Siemens' WinCC/PCS 7 SCADA control software (Step 7), and subverts a key communication library of WinCC called s7otbxdx.dll. Doing so intercepts communications between the WinCC software running under Windows and the target Siemens PLC devices that the software is able to configure and program when the two are connected via a data cable. In this way, the malware is able to install itself on PLC devices unnoticed, and subsequently to mask its presence from WinCC if the control software attempts to read an infected block of memory from the PLC system.
The malware furthermore used a zero-day exploit in the WinCC/SCADA database software in the form of a hard-coded database password.
PLC infection
The entirety of the Stuxnet code has not yet been disclosed, but its payload targets only those SCADA configurations that meet criteria that it is programmed to identify. Stuxnet requires specific slave variable-frequency drives (frequency converter drives) to be attached to the targeted Siemens S7-300 system and its associated modules. It only attacks those PLC systems with variable-frequency drives from two specific vendors: Vacon based in Finland and Fararo Paya based in Iran. Furthermore, it monitors the frequency of the attached motors, and only attacks systems that spin between 807 Hz and 1210 Hz. The industrial applications of motors with these parameters are diverse, and may include pumps or gas centrifuges.
Stuxnet installs malware into memory block DB890 of the PLC that monitors the Profibus messaging bus of the system. When certain criteria are met, it periodically modifies the frequency to 1410 Hz and then to 2 Hz and then to 1064 Hz, and thus affects the operation of the connected motors by changing their rotational speed. It also installs a rootkit – the first such documented case on this platform – that hides the malware on the system and masks the changes in rotational speed from monitoring systems.
Link
Re: Stuxnet Worm
Stuxnet 0.5: How It Evolved
Stuxnet stores a version number within its code. Analysis of this code reveals the latest discovery to be version 0.5. Based on website domain registration details, Stuxnet 0.5 may have been in operation as early as 2005. The exact date this version began circulating in the wild is unclear. What is known is that the date this early variant stopped compromising computers was July 4, 2009—just 12 days after version 1 was created.
Table 1. Known Stuxnet variants, based on main module PE timestamps
This blog focuses on the Stuxnet timeline, how Stuxnet 0.5 fits into the attack timeline, and its evolution to Stuxnet version 1.
Evolution
Stuxnet 0.5 is the oldest known Stuxnet variant analyzed to date. This variant stopped compromising computers on July 4, 2009 and stopped communicating with its command-and-control (C&C) servers on January 11 of the same year. The compile timestamps found within most of the code appear unreliable and generally are in the range of 2001.
The main differences between Stuxnet 0.5 and later versions are as follows:
Later versions significantly increased their spreading capability and use of vulnerabilities
Replacement of Flamer platform code with Tilded platform code
Later versions adopted an alternative attack strategy from uranium enrichment valve disruption to centrifuge speed modification
1. Significantly increased spreading capability and use of vulnerabilities
Stuxnet significantly increased its spreading capabilities and aggressiveness by introducing multiple vulnerabilities. The only method of replication identified in Stuxnet 0.5 was through the infection of Siemens Step 7 project files. Stuxnet 0.5 does not exploit any Microsoft vulnerabilities to move from one computer to the next unlike version 1.x.
Tables 2 and 3 show the differences in exploited vulnerabilities and spreading mechanisms.
Table 2. Evolution of the Stuxnet exploits
![Image](http://www.symantec.com/connect/imagebrowser/view/image/2718431/_original)
Table 3. Evolution of the Stuxnet replication mechanisms
2. Migration from Flamer toward Tilded
Until now Stuxnet was believed to be a project developed by people with access to Flamer components and not necessarily the whole Flamer platform source code. The discovery of Stuxnet 0.5 shows that Stuxnet’s developers had access to the complete Flamer platform source code.
Stuxnet 0.5 is partly based on the Flamer platform whereas 1.x versions were based primarily on the Tilded platform. Over time, the developers appear to have migrated more towards the Tilded platform. The developers actually re-implemented Flamer platform components using the Tilded platform in later versions.
Both the Flamer and Tilded platform code bases are different enough to suggest different developers were involved.
3. Adopting an alternative attack strategy
Stuxnet version 1 contained code that targeted Siemens 315 PLCs, which controlled the speed of spinning centrifuges, and also an incomplete code sequence that targeted Siemens 417 PLCs with unknown consequences at that time.
We have discovered a full working version of the attack on Siemens 417 PLCs in version 0.5, the purpose of which is to modify the valve operation during uranium enrichment.
Stuxnet 0.5 only contains the 417 attack code and does not contain the 315 attack code.
Detailed information on the 417 attack code can be found in the blog Stuxnet 0.5: Disrupting Uranium Processing at Natanz.
Summary
The discovery of Stuxnet 0.5 further clarifies the evolution of Stuxnet. To put this evolution in context, we have mapped key dates of Stuxnet development against low-enriched uranium (LEU) production levels at Natanz. Interesting events are dips in feed or production amounts and lower levels of production given the same or greater feed amounts (gaps between the two lines).
The existence of unrecovered versions of Stuxnet, both before version 0.5 and especially between versions 0.5 and 1.001, are likely. Partial components of Stuxnet discovered in 2010 still remain unmatched to known versions of Stuxnet.
![Image](http://www.symantec.com/connect/imagebrowser/view/image/2718461/_original)
Link
Stuxnet stores a version number within its code. Analysis of this code reveals the latest discovery to be version 0.5. Based on website domain registration details, Stuxnet 0.5 may have been in operation as early as 2005. The exact date this version began circulating in the wild is unclear. What is known is that the date this early variant stopped compromising computers was July 4, 2009—just 12 days after version 1 was created.
Table 1. Known Stuxnet variants, based on main module PE timestamps
This blog focuses on the Stuxnet timeline, how Stuxnet 0.5 fits into the attack timeline, and its evolution to Stuxnet version 1.
Evolution
Stuxnet 0.5 is the oldest known Stuxnet variant analyzed to date. This variant stopped compromising computers on July 4, 2009 and stopped communicating with its command-and-control (C&C) servers on January 11 of the same year. The compile timestamps found within most of the code appear unreliable and generally are in the range of 2001.
The main differences between Stuxnet 0.5 and later versions are as follows:
Later versions significantly increased their spreading capability and use of vulnerabilities
Replacement of Flamer platform code with Tilded platform code
Later versions adopted an alternative attack strategy from uranium enrichment valve disruption to centrifuge speed modification
1. Significantly increased spreading capability and use of vulnerabilities
Stuxnet significantly increased its spreading capabilities and aggressiveness by introducing multiple vulnerabilities. The only method of replication identified in Stuxnet 0.5 was through the infection of Siemens Step 7 project files. Stuxnet 0.5 does not exploit any Microsoft vulnerabilities to move from one computer to the next unlike version 1.x.
Tables 2 and 3 show the differences in exploited vulnerabilities and spreading mechanisms.
Table 2. Evolution of the Stuxnet exploits
Table 3. Evolution of the Stuxnet replication mechanisms
2. Migration from Flamer toward Tilded
Until now Stuxnet was believed to be a project developed by people with access to Flamer components and not necessarily the whole Flamer platform source code. The discovery of Stuxnet 0.5 shows that Stuxnet’s developers had access to the complete Flamer platform source code.
Stuxnet 0.5 is partly based on the Flamer platform whereas 1.x versions were based primarily on the Tilded platform. Over time, the developers appear to have migrated more towards the Tilded platform. The developers actually re-implemented Flamer platform components using the Tilded platform in later versions.
Both the Flamer and Tilded platform code bases are different enough to suggest different developers were involved.
3. Adopting an alternative attack strategy
Stuxnet version 1 contained code that targeted Siemens 315 PLCs, which controlled the speed of spinning centrifuges, and also an incomplete code sequence that targeted Siemens 417 PLCs with unknown consequences at that time.
We have discovered a full working version of the attack on Siemens 417 PLCs in version 0.5, the purpose of which is to modify the valve operation during uranium enrichment.
Stuxnet 0.5 only contains the 417 attack code and does not contain the 315 attack code.
Detailed information on the 417 attack code can be found in the blog Stuxnet 0.5: Disrupting Uranium Processing at Natanz.
Summary
The discovery of Stuxnet 0.5 further clarifies the evolution of Stuxnet. To put this evolution in context, we have mapped key dates of Stuxnet development against low-enriched uranium (LEU) production levels at Natanz. Interesting events are dips in feed or production amounts and lower levels of production given the same or greater feed amounts (gaps between the two lines).
The existence of unrecovered versions of Stuxnet, both before version 0.5 and especially between versions 0.5 and 1.001, are likely. Partial components of Stuxnet discovered in 2010 still remain unmatched to known versions of Stuxnet.
Link
Re: Stuxnet Worm
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.
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.