Via NYTimes -
From his first months in office, President Obama secretly ordered increasingly sophisticated attacks on the computer systems that run Iran’s main nuclear enrichment facilities, significantly expanding America’s first sustained use of cyberweapons, according to participants in the program.
Mr. Obama decided to accelerate the attacks — begun in the Bush administration and code-named Olympic Games — even after an element of the program accidentally became public in the summer of 2010 because of a programming error that allowed it to escape Iran’s Natanz plant and sent it around the world on the Internet. Computer security experts who began studying the worm, which had been developed by the United States and Israel, gave it a name: Stuxnet.
At a tense meeting in the White House Situation Room within days of the worm’s “escape,” Mr. Obama, Vice President Joseph R. Biden Jr. and the director of the Central Intelligence Agency at the time, Leon E. Panetta, considered whether America’s most ambitious attempt to slow the progress of Iran’s nuclear efforts had been fatally compromised.
“Should we shut this thing down?” Mr. Obama asked, according to members of the president’s national security team who were in the room.
Told it was unclear how much the Iranians knew about the code, and offered evidence that it was still causing havoc, Mr. Obama decided that the cyberattacks should proceed. In the following weeks, the Natanz plant was hit by a newer version of the computer worm, and then another after that. The last of that series of attacks, a few weeks after Stuxnet was detected around the world, temporarily took out nearly 1,000 of the 5,000 centrifuges Iran had spinning at the time to purify uranium.
This account of the American and Israeli effort to undermine the Iranian nuclear program is based on interviews over the past 18 months with current and former American, European and Israeli officials involved in the program, as well as a range of outside experts. None would allow their names to be used because the effort remains highly classified, and parts of it continue to this day.
These officials gave differing assessments of how successful the sabotage program was in slowing Iran’s progress toward developing the ability to build nuclear weapons. Internal Obama administration estimates say the effort was set back by 18 months to two years, but some experts inside and outside the government are more skeptical, noting that Iran’s enrichment levels have steadily recovered, giving the country enough fuel today for five or more weapons, with additional enrichment.
Whether Iran is still trying to design and build a weapon is in dispute. The most recent United States intelligence estimate concludes that Iran suspended major parts of its weaponization effort after 2003, though there is evidence that some remnants of it continue.
[...]
The impetus for Olympic Games dates from 2006, when President George W. Bush saw few good options in dealing with Iran. At the time, America’s European allies were divided about the cost that imposing sanctions on Iran would have on their own economies. Having falsely accused Saddam Hussein of reconstituting his nuclear program in Iraq, Mr. Bush had little credibility in publicly discussing another nation’s nuclear ambitions. The Iranians seemed to sense his vulnerability, and, frustrated by negotiations, they resumed enriching uranium at an underground site at Natanz, one whose existence had been exposed just three years before.
[...]
For years the C.I.A. had introduced faulty parts and designs into Iran’s systems — even tinkering with imported power supplies so that they would blow up — but the sabotage had had relatively little effect. General James E. Cartwright, who had established a small cyberoperation inside the United States Strategic Command, which is responsible for many of America’s nuclear forces, joined intelligence officials in presenting a radical new idea to Mr. Bush and his national security team. It involved a far more sophisticated cyberweapon than the United States had designed before.
--------------------------------------------------------------------
Those looking for a deeper look, can grab Flamer/Skywiper samples from Mila Parkour at the Contagio blog.
Showing posts with label Stuxnet. Show all posts
Showing posts with label Stuxnet. Show all posts
Friday, June 1, 2012
Sunday, February 5, 2012
Cone of Silence Surrounds U.S. Cyberwarfare
Via Stars and Stripes (Oct 18, 2011) -
The burial at sea was just a few hours old when sources around Washington began to spill the tactics and objectives of the May 1 mission that killed Osama bin Laden. Quickly, a substantial picture of shadowy mission in Pakistan emerged.
But nearly two years after another operation that in terms of ingenuity and audacity might be considered the cyberwar equivalent of the bin Laden mission — the Stuxnet attack that destroyed crucial equipment in Iran’s nuclear program — the silence remains unbroken. Military and civilian leaders have steadfastly refused to confirm or deny U.S. involvement.
Classified, it seems, is the enduring reality of computer warfare.
Even though the Pentagon this year formally declared cyber a new domain of warfare equal in importance to land, sea and air, a murky blanket of secrecy covers not only its operations but its policies and doctrines. It’s a level of obfuscation that far outstrips that which surrounds U.S. conventional and nuclear capabilities.
[...]
No one has yet proven who perpetrated the Stuxnet malware operation that in late 2009 or early 2010 began to cause computers in the Natanz nuclear facility in Iran to go haywire. The worm may have set work back by several years in a program that the United States says is aimed at one day producing nuclear weapons with which to threaten its neighbors.
Though Western researchers and Iranian investigators alike point a finger at the United States, frequently alleging a U.S.-Israeli collaboration, U.S. officials will not comment.
Months before the attack was disclosed, Bumgarner, a retired U.S. Army special operations veteran, former intelligence officer and cyberwarrior, penned an article in an information warfare journal that, clearly, no one in Iran’s nuclear program read or took seriously. The article, titled “Computers as Weapons of War,” suggested that centrifuges used to refine nuclear fuel could be made to destroy themselves with the right kind of offensive cyberweapon. Soon after, that’s what happened. (Among its other effects, Stuxnet is also thought to have put a Russian-built Iranian nuclear power plant at risk of meltdown.)
Bumgarner says he wrote about the centrifuge vulnerability simply to show what can be accomplished. Many other U.S. opponents have similarly vulnerable systems, as does the United States, he said.
The key from the standpoint of the attacker is not to tip one’s hand, Bumgarner said. Obscuring precise capabilities gives you an edge, while revealing too much information weakens you.
“When it comes to cyberweapons, some of the things that you develop need to be held close to the vest,” he said. “If information about a specific cyberweapon leaks out, the adversary can adjust their defenses and your offensive capability will be diminished.”
The key for U.S. officials, and the thing that perhaps keeps their lips sealed in public, is knowing the line between healthy public discussion and tipping off adversaries to their own weaknesses.
“A conventional weapon can be effective for years, perhaps even decades,” he said. “A cyberweapon’s effectiveness might be measured in minutes until someone applies a patch or a new security filter.”
The burial at sea was just a few hours old when sources around Washington began to spill the tactics and objectives of the May 1 mission that killed Osama bin Laden. Quickly, a substantial picture of shadowy mission in Pakistan emerged.
But nearly two years after another operation that in terms of ingenuity and audacity might be considered the cyberwar equivalent of the bin Laden mission — the Stuxnet attack that destroyed crucial equipment in Iran’s nuclear program — the silence remains unbroken. Military and civilian leaders have steadfastly refused to confirm or deny U.S. involvement.
Classified, it seems, is the enduring reality of computer warfare.
Even though the Pentagon this year formally declared cyber a new domain of warfare equal in importance to land, sea and air, a murky blanket of secrecy covers not only its operations but its policies and doctrines. It’s a level of obfuscation that far outstrips that which surrounds U.S. conventional and nuclear capabilities.
[...]
No one has yet proven who perpetrated the Stuxnet malware operation that in late 2009 or early 2010 began to cause computers in the Natanz nuclear facility in Iran to go haywire. The worm may have set work back by several years in a program that the United States says is aimed at one day producing nuclear weapons with which to threaten its neighbors.
Though Western researchers and Iranian investigators alike point a finger at the United States, frequently alleging a U.S.-Israeli collaboration, U.S. officials will not comment.
Months before the attack was disclosed, Bumgarner, a retired U.S. Army special operations veteran, former intelligence officer and cyberwarrior, penned an article in an information warfare journal that, clearly, no one in Iran’s nuclear program read or took seriously. The article, titled “Computers as Weapons of War,” suggested that centrifuges used to refine nuclear fuel could be made to destroy themselves with the right kind of offensive cyberweapon. Soon after, that’s what happened. (Among its other effects, Stuxnet is also thought to have put a Russian-built Iranian nuclear power plant at risk of meltdown.)
Bumgarner says he wrote about the centrifuge vulnerability simply to show what can be accomplished. Many other U.S. opponents have similarly vulnerable systems, as does the United States, he said.
The key from the standpoint of the attacker is not to tip one’s hand, Bumgarner said. Obscuring precise capabilities gives you an edge, while revealing too much information weakens you.
“When it comes to cyberweapons, some of the things that you develop need to be held close to the vest,” he said. “If information about a specific cyberweapon leaks out, the adversary can adjust their defenses and your offensive capability will be diminished.”
The key for U.S. officials, and the thing that perhaps keeps their lips sealed in public, is knowing the line between healthy public discussion and tipping off adversaries to their own weaknesses.
“A conventional weapon can be effective for years, perhaps even decades,” he said. “A cyberweapon’s effectiveness might be measured in minutes until someone applies a patch or a new security filter.”
Wednesday, December 28, 2011
Stuxnet/Duqu: The Evolution of Drivers
Via SecureList (Kaspersky Lab) -
We have been studying the Duqu Trojan for two months now, exploring how it emerged, where it was distributed and how it operates. Despite the large volume of data obtained (most of which has yet to be published), we still lack the answer to the fundamental question - who is behind Duqu?
In addition, there are other issues, mostly to do with the creation of the Trojan, or rather the platform used to implement Duqu as well as Stuxnet.
In terms of architecture, the platform used to create Duqu and Stuxnet is the same. This is a driver file which loads a main module designed as an encrypted library. At the same time, there is a separate configuration file for the whole malicious complex and an encrypted block in the system registry that defines the location of the module being loaded and name of the process for injection.
This platform can be conventionally named as ‘Tilded’ as its authors are, for some reason, inclined to use file names which start with "~d".
We believe Duqu and Stuxnet were simultaneous projects supported by the same team of developers.
Several other details have been uncovered which suggest there was possibly at least one further spyware module based on the same platform in 2007-2008, and several other programs whose functionality was unclear between 2008 and 2010.
These facts significantly challenge the existing "official" history of Stuxnet. We will try to cover them in this publication, but let us first recap the story so far.
[...]
Conclusion
From the data we have at our disposal, we can say with a fair degree of certainty that the “Tilded” platform was created around the end of 2007 or early 2008 before undergoing its most significant changes in summer/autumn 2010. Those changes were sparked by advances in code and the need to avoid detection by antivirus solutions. There were a number of projects involving programs based on the “Tilded” platform throughout the period 2007-2011. Stuxnet and Duqu are two of them – there could have been others, which for now remain unknown. The platform continues to develop, which can only mean one thing – we’re likely to see more modifications in the future.
We have been studying the Duqu Trojan for two months now, exploring how it emerged, where it was distributed and how it operates. Despite the large volume of data obtained (most of which has yet to be published), we still lack the answer to the fundamental question - who is behind Duqu?
In addition, there are other issues, mostly to do with the creation of the Trojan, or rather the platform used to implement Duqu as well as Stuxnet.
In terms of architecture, the platform used to create Duqu and Stuxnet is the same. This is a driver file which loads a main module designed as an encrypted library. At the same time, there is a separate configuration file for the whole malicious complex and an encrypted block in the system registry that defines the location of the module being loaded and name of the process for injection.
This platform can be conventionally named as ‘Tilded’ as its authors are, for some reason, inclined to use file names which start with "~d".
We believe Duqu and Stuxnet were simultaneous projects supported by the same team of developers.
Several other details have been uncovered which suggest there was possibly at least one further spyware module based on the same platform in 2007-2008, and several other programs whose functionality was unclear between 2008 and 2010.
These facts significantly challenge the existing "official" history of Stuxnet. We will try to cover them in this publication, but let us first recap the story so far.
[...]
Conclusion
From the data we have at our disposal, we can say with a fair degree of certainty that the “Tilded” platform was created around the end of 2007 or early 2008 before undergoing its most significant changes in summer/autumn 2010. Those changes were sparked by advances in code and the need to avoid detection by antivirus solutions. There were a number of projects involving programs based on the “Tilded” platform throughout the period 2007-2011. Stuxnet and Duqu are two of them – there could have been others, which for now remain unknown. The platform continues to develop, which can only mean one thing – we’re likely to see more modifications in the future.
Tuesday, November 15, 2011
STRATFOR Dispatch: Countering Iran in the Covert World
http://www.stratfor.com/analysis/20111114-dispatch-countering-iran-covert-world
Director of Analysis Reva Bhalla examines how a recent chain of Iran-related events sheds light on the geopolitical environment in which Iran’s adversaries are operating.
Read more: Dispatch: Countering Iran in the Covert World | STRATFOR
Director of Analysis Reva Bhalla examines how a recent chain of Iran-related events sheds light on the geopolitical environment in which Iran’s adversaries are operating.
Read more: Dispatch: Countering Iran in the Covert World | STRATFOR
Tuesday, October 18, 2011
Analysis: Duqu Targets Certificate Authorities
Via Threatpost.com -
With virus researchers scrambling to decode a new piece of malware that is based on the code of the Stuxnet worm, an analyst at McAfee is speculating that the new worm, Duqu, may have been created to target certificate authorities.
Writing on McAfee's research blog, Guilherme Venere and Peter Szor say that an analysis of the Duqu code by McAfee experts suggests that the worm was created "for espionage and targeted attacks against sites such as Certificate Authorities (CAs)." The McAfee analysis, if accurate, is the first to explicitly mention the type of organization that the Duqu worm targeted, and would suggest that those behind the worm intended to use it as a precursor to subsequent, targeted attacks.
Certificate authorities have been prominent targets of hackers in recent months.
[...]
McAfee said that the Duqu worm has been identified in "professional, targeted attacks" against CAs in parts of Europe, the Middle East, Asia and Africa. The researchers speculate that a digital certificate belonging to the firm C-Media, based in Taipei, was not stolen, but forged by a compromised CA.
The McAfee analysis fills in some details omitted from a longer analysis released by Symantec Corp on Tuesday. That research declined to name the kind of firm targeted by the worm, but provided a detailed analysis of the Duqu code, which bears a close resemblance to Stuxnet, with shared code used for the injection attack and several encryption keys and techniques that were used in Stuxnet.
Like Symantec's report, the analysis from McAfee says that it knows of only a few infections linked to Duqu, and says the worm doesn't appear to be designed to attack industrial control systems, as Stuxnet was.
With virus researchers scrambling to decode a new piece of malware that is based on the code of the Stuxnet worm, an analyst at McAfee is speculating that the new worm, Duqu, may have been created to target certificate authorities.
Writing on McAfee's research blog, Guilherme Venere and Peter Szor say that an analysis of the Duqu code by McAfee experts suggests that the worm was created "for espionage and targeted attacks against sites such as Certificate Authorities (CAs)." The McAfee analysis, if accurate, is the first to explicitly mention the type of organization that the Duqu worm targeted, and would suggest that those behind the worm intended to use it as a precursor to subsequent, targeted attacks.
Certificate authorities have been prominent targets of hackers in recent months.
[...]
McAfee said that the Duqu worm has been identified in "professional, targeted attacks" against CAs in parts of Europe, the Middle East, Asia and Africa. The researchers speculate that a digital certificate belonging to the firm C-Media, based in Taipei, was not stolen, but forged by a compromised CA.
The McAfee analysis fills in some details omitted from a longer analysis released by Symantec Corp on Tuesday. That research declined to name the kind of firm targeted by the worm, but provided a detailed analysis of the Duqu code, which bears a close resemblance to Stuxnet, with shared code used for the injection attack and several encryption keys and techniques that were used in Stuxnet.
Like Symantec's report, the analysis from McAfee says that it knows of only a few infections linked to Duqu, and says the worm doesn't appear to be designed to attack industrial control systems, as Stuxnet was.
W32.Duqu: The Precursor to the Next Stuxnet
Via Symantec Security Response Blog -
On October 14, 2011, a research lab with strong international connections alerted us to a sample that appeared to be very similar to Stuxnet. They named the threat "Duqu" [dyü-kyü] because it creates files with the file name prefix “~DQ”. The research lab provided us with samples recovered from computer systems located in Europe, as well as a detailed report with their initial findings, including analysis comparing the threat to Stuxnet, which we were able to confirm. Parts of Duqu are nearly identical to Stuxnet, but with a completely different purpose.
Duqu is essentially the precursor to a future Stuxnet-like attack. The threat was written by the same authors (or those that have access to the Stuxnet source code) and appears to have been created since the last Stuxnet file was recovered. Duqu's purpose is to gather intelligence data and assets from entities, such as industrial control system manufacturers, in order to more easily conduct a future attack against another third party. The attackers are looking for information such as design documents that could help them mount a future attack on an industrial control facility.
Duqu does not contain any code related to industrial control systems and is primarily a remote access Trojan (RAT). The threat does not self-replicate. Our telemetry shows the threat was highly targeted toward a limited number of organizations for their specific assets. However, it’s possible that other attacks are being conducted against other organizations in a similar manner with currently undetected variants.
The attackers used Duqu to install another infostealer that could record keystrokes and gain other system information. The attackers were searching for assets that could be used in a future attack. In one case, the attackers did not appear to successfully exfiltrate any sensitive data, but details are not available in all cases. Two variants were recovered, and in reviewing our archive of submissions, the first recording of one of the binaries was on September 1, 2011. However, based on file compile times, attacks using these variants may have been conducted as early as December 2010.
[...]
Duqu shares a great deal of code with Stuxnet; however, the payload is completely different. Instead of a payload designed to sabotage an industrial control system, the payload has been replaced with general remote access capabilities. The creators of Duqu had access to the source code of Stuxnet, not just the Stuxnet binaries. The attackers intend to use this capability to gather intelligence from a private entity to aid future attacks on a third party. While suspected, no similar precursor files have been recovered that predate the Stuxnet attacks.
You can find additional details in our paper here. The research lab that originally found the sample has allowed us to share their initial report as an appendix. We expect to make further updates over the coming days.
Key points:
-----------------------------------------------------------------------------
Whitepaper - W32.Duqu: The Precursor to the Next Stuxnet
http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/w32_duqu_the_precursor_to_the_next_stuxnet.pdf
W32.Duqu - Summary
http://www.symantec.com/business/security_response/writeup.jsp?docid=2011-101814-1119-99
On October 14, 2011, a research lab with strong international connections alerted us to a sample that appeared to be very similar to Stuxnet. They named the threat "Duqu" [dyü-kyü] because it creates files with the file name prefix “~DQ”. The research lab provided us with samples recovered from computer systems located in Europe, as well as a detailed report with their initial findings, including analysis comparing the threat to Stuxnet, which we were able to confirm. Parts of Duqu are nearly identical to Stuxnet, but with a completely different purpose.
Duqu is essentially the precursor to a future Stuxnet-like attack. The threat was written by the same authors (or those that have access to the Stuxnet source code) and appears to have been created since the last Stuxnet file was recovered. Duqu's purpose is to gather intelligence data and assets from entities, such as industrial control system manufacturers, in order to more easily conduct a future attack against another third party. The attackers are looking for information such as design documents that could help them mount a future attack on an industrial control facility.
Duqu does not contain any code related to industrial control systems and is primarily a remote access Trojan (RAT). The threat does not self-replicate. Our telemetry shows the threat was highly targeted toward a limited number of organizations for their specific assets. However, it’s possible that other attacks are being conducted against other organizations in a similar manner with currently undetected variants.
The attackers used Duqu to install another infostealer that could record keystrokes and gain other system information. The attackers were searching for assets that could be used in a future attack. In one case, the attackers did not appear to successfully exfiltrate any sensitive data, but details are not available in all cases. Two variants were recovered, and in reviewing our archive of submissions, the first recording of one of the binaries was on September 1, 2011. However, based on file compile times, attacks using these variants may have been conducted as early as December 2010.
[...]
Duqu shares a great deal of code with Stuxnet; however, the payload is completely different. Instead of a payload designed to sabotage an industrial control system, the payload has been replaced with general remote access capabilities. The creators of Duqu had access to the source code of Stuxnet, not just the Stuxnet binaries. The attackers intend to use this capability to gather intelligence from a private entity to aid future attacks on a third party. While suspected, no similar precursor files have been recovered that predate the Stuxnet attacks.
You can find additional details in our paper here. The research lab that originally found the sample has allowed us to share their initial report as an appendix. We expect to make further updates over the coming days.
Key points:
- Executables using the Stuxnet source code have been discovered. They appear to have been developed since the last Stuxnet file was recovered.
- The executables are designed to capture information such as keystrokes and system information.
- Current analysis shows no code related to industrial control systems, exploits, or self-replication.
- The executables have been found in a limited number of organizations, including those involved in the manufacturing of industrial control systems.
- The exfiltrated data may be used to enable a future Stuxnet-like attack.
-----------------------------------------------------------------------------
Whitepaper - W32.Duqu: The Precursor to the Next Stuxnet
http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/w32_duqu_the_precursor_to_the_next_stuxnet.pdf
W32.Duqu - Summary
http://www.symantec.com/business/security_response/writeup.jsp?docid=2011-101814-1119-99
Saturday, July 16, 2011
How Digital Detectives Deciphered Stuxnet, the Most Menacing Malware in History
Via Wired's Threat Level Blog (July 11, 2011) -
It was January 2010, and investigators with the International Atomic Energy Agency had just completed an inspection at the uranium enrichment plant outside Natanz in central Iran, when they realized that something was off within the cascade rooms where thousands of centrifuges were enriching uranium.
Natanz technicians in white lab coats, gloves and blue booties were scurrying in and out of the “clean” cascade rooms, hauling out unwieldy centrifuges one by one, each sheathed in shiny silver cylindrical casings.
Any time workers at the plant decommissioned damaged or otherwise unusable centrifuges, they were required to line them up for IAEA inspection to verify that no radioactive material was being smuggled out in the devices before they were removed. The technicians had been doing so now for more than a month.
Normally Iran replaced up to 10 percent of its centrifuges a year, due to material defects and other issues. With about 8,700 centrifuges installed at Natanz at the time, it would have been normal to decommission about 800 over the course of the year.
But when the IAEA later reviewed footage from surveillance cameras installed outside the cascade rooms to monitor Iran’s enrichment program, they were stunned as they counted the numbers. The workers had been replacing the units at an incredible rate — later estimates would indicate between 1,000 and 2,000 centrifuges were swapped out over a few months.
The question was, why?
Iran wasn’t required to disclose the reason for replacing the centrifuges and, officially, the inspectors had no right to ask. Their mandate was to monitor what happened to nuclear material at the plant, not keep track of equipment failures. But it was clear that something had damaged the centrifuges.
What the inspectors didn’t know was that the answer they were seeking was hidden all around them, buried in the disk space and memory of Natanz’s computers. Months earlier, in June 2009, someone had silently unleashed a sophisticated and destructive digital worm that had been slithering its way through computers in Iran with just one aim — to sabotage the country’s uranium enrichment program and prevent President Mahmoud Ahmadinejad from building a nuclear weapon.
But it would be nearly a year before the inspectors would learn of this. The answer would come only after dozens of computer security researchers around the world would spend months deconstructing what would come to be known as the most complex malware ever written — a piece of software that would ultimately make history as the world’s first real cyberweapon.
-----------------------------------------------------------------------------
Definitely the best write-up on Stuxnet thus far. It is hard to believe that it has just about a year since its public discovery.
A Malware Anniversary to Remember (by Liam O Murchu)
http://www.symantec.com/connect/blogs/malware-anniversary-remember
It was January 2010, and investigators with the International Atomic Energy Agency had just completed an inspection at the uranium enrichment plant outside Natanz in central Iran, when they realized that something was off within the cascade rooms where thousands of centrifuges were enriching uranium.
Natanz technicians in white lab coats, gloves and blue booties were scurrying in and out of the “clean” cascade rooms, hauling out unwieldy centrifuges one by one, each sheathed in shiny silver cylindrical casings.
Any time workers at the plant decommissioned damaged or otherwise unusable centrifuges, they were required to line them up for IAEA inspection to verify that no radioactive material was being smuggled out in the devices before they were removed. The technicians had been doing so now for more than a month.
Normally Iran replaced up to 10 percent of its centrifuges a year, due to material defects and other issues. With about 8,700 centrifuges installed at Natanz at the time, it would have been normal to decommission about 800 over the course of the year.
But when the IAEA later reviewed footage from surveillance cameras installed outside the cascade rooms to monitor Iran’s enrichment program, they were stunned as they counted the numbers. The workers had been replacing the units at an incredible rate — later estimates would indicate between 1,000 and 2,000 centrifuges were swapped out over a few months.
The question was, why?
Iran wasn’t required to disclose the reason for replacing the centrifuges and, officially, the inspectors had no right to ask. Their mandate was to monitor what happened to nuclear material at the plant, not keep track of equipment failures. But it was clear that something had damaged the centrifuges.
What the inspectors didn’t know was that the answer they were seeking was hidden all around them, buried in the disk space and memory of Natanz’s computers. Months earlier, in June 2009, someone had silently unleashed a sophisticated and destructive digital worm that had been slithering its way through computers in Iran with just one aim — to sabotage the country’s uranium enrichment program and prevent President Mahmoud Ahmadinejad from building a nuclear weapon.
But it would be nearly a year before the inspectors would learn of this. The answer would come only after dozens of computer security researchers around the world would spend months deconstructing what would come to be known as the most complex malware ever written — a piece of software that would ultimately make history as the world’s first real cyberweapon.
-----------------------------------------------------------------------------
Definitely the best write-up on Stuxnet thus far. It is hard to believe that it has just about a year since its public discovery.
A Malware Anniversary to Remember (by Liam O Murchu)
http://www.symantec.com/connect/blogs/malware-anniversary-remember
Tuesday, February 15, 2011
Israeli General Claims Stuxnet Attacks as One of his Successes
Via Net-Security.org -
The latest results of a Symnatec study concentrating on the Stuxnet worm revealed that its developers knew what they were doing - once finished, it took only 12 hours to infect the first target.
The study also concluded that the Stuxnet attacks can be dated back to June 2009 - more than a year prior to it being first discovered by security experts - and that its initial targets were five separate organizations that have a presence in Iran and most of which have been attacked at various points through 2009 and 2010.
Last month, The New York Times ran a story about Stuxnet having been developed by the Americans and the Israelis as a part of a joint project, but it was based on the claims by confidential sources and there was only circumstantial evidence that would corroborate them.
But, it now seems that the information from these sources was correct. The Haaretz - Israel's oldest daily newspaper - reports (via Google Translate) about the a surprising video that was played at a party organized for General Gabi Ashkenazi's last day on the job.
The video contained references to the successes he achieved during his stint as chief of staff, and enumerated among them was the Stuxnet worm attack on Iran's uranium enrichment facility at Natanz and and the nuclear reactor at Bushehr.
There is always the possibility that this was just a way of magnifying the General's achievements, but it is also possible it is true. As we all know, Israel has never commented on the speculations about its involvement in the attacks.
The latest results of a Symnatec study concentrating on the Stuxnet worm revealed that its developers knew what they were doing - once finished, it took only 12 hours to infect the first target.
The study also concluded that the Stuxnet attacks can be dated back to June 2009 - more than a year prior to it being first discovered by security experts - and that its initial targets were five separate organizations that have a presence in Iran and most of which have been attacked at various points through 2009 and 2010.
Last month, The New York Times ran a story about Stuxnet having been developed by the Americans and the Israelis as a part of a joint project, but it was based on the claims by confidential sources and there was only circumstantial evidence that would corroborate them.
But, it now seems that the information from these sources was correct. The Haaretz - Israel's oldest daily newspaper - reports (via Google Translate) about the a surprising video that was played at a party organized for General Gabi Ashkenazi's last day on the job.
The video contained references to the successes he achieved during his stint as chief of staff, and enumerated among them was the Stuxnet worm attack on Iran's uranium enrichment facility at Natanz and and the nuclear reactor at Bushehr.
There is always the possibility that this was just a way of magnifying the General's achievements, but it is also possible it is true. As we all know, Israel has never commented on the speculations about its involvement in the attacks.
Sunday, February 13, 2011
Updated W32.Stuxnet Dossier is Available
http://www.symantec.com/connect/blogs/updated-w32stuxnet-dossier-available
When we released our paper on Stuxnet by Nicolas Falliere, Liam O Murchu, and Eric Chien in September, we mentioned we’d likely continue to make revisions.
We have two major updates to the paper and some other minor changes throughout. A summary of these updates follows and more detailed information can be found in the paper. Please note that these new details are included in version 1.4 or higher.
-----------------------------------------------------------
According to the revision history....
Version 1.4 (February 11, 2011)
When we released our paper on Stuxnet by Nicolas Falliere, Liam O Murchu, and Eric Chien in September, we mentioned we’d likely continue to make revisions.
We have two major updates to the paper and some other minor changes throughout. A summary of these updates follows and more detailed information can be found in the paper. Please note that these new details are included in version 1.4 or higher.
-----------------------------------------------------------
According to the revision history....
Version 1.4 (February 11, 2011)
- New content added to the Infection Statistics, The monitor thread, Sequence C, and Variants sections.
- Minor edits and updates to Configuration Data Block, Behavior of a PLC infected by sequence A/B, and Other export hooks sections.
Tuesday, January 18, 2011
F-Secure Wrap-up on Case Stuxnet
Stuxnet means cyber sabotage is here. Mikko Hyppönen, Chief Research Officer at F-Secure, says Stuxnet is probably the most significant malware of the decade.
Monday, January 3, 2011
Report Strengthens Suspicions That Stuxnet Sabotaged Iran’s Nuclear Plant
Via Wired.com (Threat Level) -
A new report appears to add fuel to suspicions that the Stuxnet superworm was responsible for sabotaging centrifuges at a uranium-enrichment plant in Iran.
The report, released Thursday by the Institute for Science and International Security, or ISIS, indicates that commands in the Stuxnet code intended to increase the frequency of devices targeted by the malware exactly match several frequencies at which rotors in centrifuges at Iran’s Natanz enrichment plant are designed to operate optimally or are at risk of breaking down and flying apart.
The frequencies of the Natanz rotors were apparently not a secret and were disclosed to ISIS in mid-2008 — the earliest samples of Stuxnet code found so far date back to June 2009, a year after ISIS learned about the frequencies. They were disclosed to ISIS by "an official from a government that closely tracks Iran’s centrifuge program."
The unnamed government official told ISIS that the nominal frequency for the IR-1 centrifuges at Natanz was 1,064 Hz, but that Iran kept the actual frequency of the centrifuges lower to reduce breakage. According to another source, Iran often ran its centrifuges at 1,007 Hz.
The information would have been gold to someone looking to sabotage the centrifuges since, as ISIS notes, it provided both confirmation that Iran’s centrifuges were prone to an unusual amount of breakage and that they were subject to breakage at a specific frequency of rotation.
[...]
It’s known that Iran decommissioned and replaced about a thousand IR-1 centrifuges at its Natanz plant between November 2009 and February 2010. It’s not known if this was due to Stuxnet or due to a manufacturing defect or some other cause, but the ISIS report increases plausibility that Stuxnet could have played a role in their demise.
[...]
According to an examination of Stuxnet by security firm Symantec, once the code infects a system, it searches for the presence of two kinds of frequency converters made by the Iranian firm Fararo Paya and the Finnish company Vacon, making it clear that the code has a precise target in its sights. Once it finds itself on the targeted system, depending on how many frequency converters from each company are present on that system, Stuxnet undertakes two courses of action to alter the speed of rotors being controlled by the converters. In one of these courses of action, Stuxnet begins with a nominal frequency of 1,064 Hz — which matches the known nominal frequency at Natanz but is above the 1,007 Hz at which Natanz is said to operate — then reduces the frequency for a short while before returning it back to 1,064 Hz.
In another attack sequence, Stuxnet instructs the speed to increase to 1,410 Hz, which is "very close to the maximum speed the spinning aluminum IR-1 rotor can withstand mechanically," according to the ISIS report, which was written by ISIS president David Albright and colleagues.
"The rotor tube of the IR-1 centrifuge is made from high-strength aluminum and has a maximum tangential speed of about 440-450 meters per second, or 1,400-1,432 Hz, respectively," according to ISIS. "As a result, if the frequency of the rotor increased to 1,410 Hz, the rotor would likely fly apart when the tangential speed of the rotor reached that level."
[...]
ISIS notes that the Stuxnet commands don’t guarantee destruction of centrifuges. The length of the frequency changes may be designed simply to disrupt operations at the plant without breaking rotors outright, and the plant could conceivably have secondary control systems in place to protect centrifuges and that are not affected by Stuxnet’s malicious commands.
There are still a lot of unanswered questions about both Stuxnet and the Natanz facility.
[...]
If Stuxnet was indeed aimed at Natanz, and if its goal was to quickly destroy all of the centrifuges at Natanz, ISIS notes that it failed at this task.
"But if the goal was to destroy a more-limited number of centrifuges and set back Iran’s progress in operating the FEP, while making detection difficult, it may have succeeded, at least temporarily," according to the report.
The authors close their report with a warning to governments that using tools like Stuxnet "could open the door to future national security risks or adversely and unintentionally affect U.S. allies."
"Countries hostile to the United States may feel justified in launching their own attacks against U.S. facilities, perhaps even using a modified Stuxnet code,” they write. “Such an attack could shut down large portions of national power grids or other critical infrastructure using malware designed to target critical components inside a major system, causing a national emergency."
A new report appears to add fuel to suspicions that the Stuxnet superworm was responsible for sabotaging centrifuges at a uranium-enrichment plant in Iran.
The report, released Thursday by the Institute for Science and International Security, or ISIS, indicates that commands in the Stuxnet code intended to increase the frequency of devices targeted by the malware exactly match several frequencies at which rotors in centrifuges at Iran’s Natanz enrichment plant are designed to operate optimally or are at risk of breaking down and flying apart.
The frequencies of the Natanz rotors were apparently not a secret and were disclosed to ISIS in mid-2008 — the earliest samples of Stuxnet code found so far date back to June 2009, a year after ISIS learned about the frequencies. They were disclosed to ISIS by "an official from a government that closely tracks Iran’s centrifuge program."
The unnamed government official told ISIS that the nominal frequency for the IR-1 centrifuges at Natanz was 1,064 Hz, but that Iran kept the actual frequency of the centrifuges lower to reduce breakage. According to another source, Iran often ran its centrifuges at 1,007 Hz.
The information would have been gold to someone looking to sabotage the centrifuges since, as ISIS notes, it provided both confirmation that Iran’s centrifuges were prone to an unusual amount of breakage and that they were subject to breakage at a specific frequency of rotation.
[...]
It’s known that Iran decommissioned and replaced about a thousand IR-1 centrifuges at its Natanz plant between November 2009 and February 2010. It’s not known if this was due to Stuxnet or due to a manufacturing defect or some other cause, but the ISIS report increases plausibility that Stuxnet could have played a role in their demise.
[...]
According to an examination of Stuxnet by security firm Symantec, once the code infects a system, it searches for the presence of two kinds of frequency converters made by the Iranian firm Fararo Paya and the Finnish company Vacon, making it clear that the code has a precise target in its sights. Once it finds itself on the targeted system, depending on how many frequency converters from each company are present on that system, Stuxnet undertakes two courses of action to alter the speed of rotors being controlled by the converters. In one of these courses of action, Stuxnet begins with a nominal frequency of 1,064 Hz — which matches the known nominal frequency at Natanz but is above the 1,007 Hz at which Natanz is said to operate — then reduces the frequency for a short while before returning it back to 1,064 Hz.
In another attack sequence, Stuxnet instructs the speed to increase to 1,410 Hz, which is "very close to the maximum speed the spinning aluminum IR-1 rotor can withstand mechanically," according to the ISIS report, which was written by ISIS president David Albright and colleagues.
"The rotor tube of the IR-1 centrifuge is made from high-strength aluminum and has a maximum tangential speed of about 440-450 meters per second, or 1,400-1,432 Hz, respectively," according to ISIS. "As a result, if the frequency of the rotor increased to 1,410 Hz, the rotor would likely fly apart when the tangential speed of the rotor reached that level."
[...]
ISIS notes that the Stuxnet commands don’t guarantee destruction of centrifuges. The length of the frequency changes may be designed simply to disrupt operations at the plant without breaking rotors outright, and the plant could conceivably have secondary control systems in place to protect centrifuges and that are not affected by Stuxnet’s malicious commands.
There are still a lot of unanswered questions about both Stuxnet and the Natanz facility.
[...]
If Stuxnet was indeed aimed at Natanz, and if its goal was to quickly destroy all of the centrifuges at Natanz, ISIS notes that it failed at this task.
"But if the goal was to destroy a more-limited number of centrifuges and set back Iran’s progress in operating the FEP, while making detection difficult, it may have succeeded, at least temporarily," according to the report.
The authors close their report with a warning to governments that using tools like Stuxnet "could open the door to future national security risks or adversely and unintentionally affect U.S. allies."
"Countries hostile to the United States may feel justified in launching their own attacks against U.S. facilities, perhaps even using a modified Stuxnet code,” they write. “Such an attack could shut down large portions of national power grids or other critical infrastructure using malware designed to target critical components inside a major system, causing a national emergency."
Tuesday, November 23, 2010
Exploit Code For Stuxnet Windows Task Scheduler Bug Posted
Via Threatpost.com -
Exploit code is now publicly available for one of the four previously undisclosed Windows vulnerabilities that the Stuxnet worm exploits. The availability of exploit code for the Windows Task Scheduler bug used by Stuxnet makes the bug somewhat more dangerous, as there is currently no patch available for the flaw.
The Windows Task Scheduler exploit code was added to the Exploit Database over the weekend and is designed for use against systems running Windows Vista, Windows 7 or Windows Server 2008. The Task Scheduler bug is just one of several vulnerabilities that the Stuxnet worm uses in its attack routine. It's one of the less severe of that group of flaws, in that it's only used for privilege escalation once an attacker has already compromised a machine.
Microsoft has not released a patch for the Task Scheduler vulnerability as yet. The company has patched three other bugs used by Stuxnet, including the LNK flaw that was one of the things that originally brought the worm to researchers' attention earlier this year.
---------------------------------------------------------------------------------------------------------------------------
On Saturday, Nov 20th, the unpatched Task Scheduler exploit was also added to Metasploit.
https://www.metasploit.com/redmine/projects/framework/repository/revisions/11079/changes/scripts/meterpreter/schelevator.rb
Exploit code is now publicly available for one of the four previously undisclosed Windows vulnerabilities that the Stuxnet worm exploits. The availability of exploit code for the Windows Task Scheduler bug used by Stuxnet makes the bug somewhat more dangerous, as there is currently no patch available for the flaw.
The Windows Task Scheduler exploit code was added to the Exploit Database over the weekend and is designed for use against systems running Windows Vista, Windows 7 or Windows Server 2008. The Task Scheduler bug is just one of several vulnerabilities that the Stuxnet worm uses in its attack routine. It's one of the less severe of that group of flaws, in that it's only used for privilege escalation once an attacker has already compromised a machine.
Microsoft has not released a patch for the Task Scheduler vulnerability as yet. The company has patched three other bugs used by Stuxnet, including the LNK flaw that was one of the things that originally brought the worm to researchers' attention earlier this year.
---------------------------------------------------------------------------------------------------------------------------
On Saturday, Nov 20th, the unpatched Task Scheduler exploit was also added to Metasploit.
https://www.metasploit.com/redmine/projects/framework/repository/revisions/11079/changes/scripts/meterpreter/schelevator.rb
Sunday, November 14, 2010
Stuxnet Breakthrough: Frequency Converter Drives
http://www.symantec.com/connect/blogs/stuxnet-breakthrough
Thanks to some tips from a Dutch Profibus expert who responded to our call for help, we’ve connected a critical piece of the puzzle.
Since our discovery that Stuxnet actually modifies code on PLCs in a potential act of sabotage, we have been unable to determine what the exact purpose of Stuxnet is and what its target was.
However, we can now confirm that Stuxnet requires the industrial control system to have frequency converter drives from at least one of two specific vendors, one headquartered in Finland and the other in Tehran, Iran. This is in addition to the previous requirements we discussed of a S7-300 CPU and a CP-342-5 Profibus communications module.
A frequency converter drive is a power supply that can change the frequency of the output, which controls the speed of a motor. The higher the frequency, the higher the speed of the motor.
The new key findings are:
Once operation at those frequencies occurs for a period of time, Stuxnet then hijacks the PLC code and begins modifying the behavior of the frequency converter drives. In addition to other parameters, over a period of months, Stuxnet changes the output frequency for short periods of time to 1410Hz and then to 2Hz and then to 1064Hz. Modification of the output frequency essentially sabotages the automation system from operating properly. Other parameter changes may also cause unexpected effects.
With this discovery, we now understand the purpose of all of Stuxnet’s code. We’ve modified our paper, in particular multiple subsections of the Modifying PLCs section, to include the finer details. Since we are far from experts in industrial control systems, we appreciate any feedback or further tips or explanation of some of the data. You can click on my name at the top of the blog post to get in touch.
We’d like to sincerely thank the Dutch Profibus expert who got in touch, serving as the catalyst to this breakthrough in understanding the purpose and potential targets of Stuxnet.
Here is the link to the updated paper.
Thanks to some tips from a Dutch Profibus expert who responded to our call for help, we’ve connected a critical piece of the puzzle.
Since our discovery that Stuxnet actually modifies code on PLCs in a potential act of sabotage, we have been unable to determine what the exact purpose of Stuxnet is and what its target was.
However, we can now confirm that Stuxnet requires the industrial control system to have frequency converter drives from at least one of two specific vendors, one headquartered in Finland and the other in Tehran, Iran. This is in addition to the previous requirements we discussed of a S7-300 CPU and a CP-342-5 Profibus communications module.
A frequency converter drive is a power supply that can change the frequency of the output, which controls the speed of a motor. The higher the frequency, the higher the speed of the motor.
The new key findings are:
- We are now able to describe the purpose of all of Stuxnet’s code.
- Stuxnet requires particular frequency converter drives from specific vendors, some of which may not be procurable in certain countries.
- Stuxnet requires the frequency converter drives to be operating at very high speeds, between 807 Hz and 1210 Hz. While frequency converter drives are used in many industrial control applications, these speeds are used only in a limited number of applications.
- Stuxnet changes the output frequencies and thus the speed of the motors for short intervals over periods of months. Interfering with the speed of the motors sabotages the normal operation of the industrial control process.
- Stuxnet’s requirement for particular frequency converter drives and operating characteristics focuses the number of possible speculated targets to a limited set of possibilities.
Once operation at those frequencies occurs for a period of time, Stuxnet then hijacks the PLC code and begins modifying the behavior of the frequency converter drives. In addition to other parameters, over a period of months, Stuxnet changes the output frequency for short periods of time to 1410Hz and then to 2Hz and then to 1064Hz. Modification of the output frequency essentially sabotages the automation system from operating properly. Other parameter changes may also cause unexpected effects.
With this discovery, we now understand the purpose of all of Stuxnet’s code. We’ve modified our paper, in particular multiple subsections of the Modifying PLCs section, to include the finer details. Since we are far from experts in industrial control systems, we appreciate any feedback or further tips or explanation of some of the data. You can click on my name at the top of the blog post to get in touch.
We’d like to sincerely thank the Dutch Profibus expert who got in touch, serving as the catalyst to this breakthrough in understanding the purpose and potential targets of Stuxnet.
Here is the link to the updated paper.
Tuesday, November 2, 2010
Stuxnet Under the Microscope v1.2
http://www.eset.com/resources/white-papers/Stuxnet_Under_the_Microscope.pdf
Updated Stuxnet paper by ESET, with full description of unpatched Task Scheduler vulnerability.
See Page 39-41.
Updated Stuxnet paper by ESET, with full description of unpatched Task Scheduler vulnerability.
See Page 39-41.
Monday, October 25, 2010
Siemens Stuxnet Patch Does Not Provide Sufficient Protection
Va h-online.com -
The Siemens SIMATIC Security Update for protecting WinCC systems against Stuxnet infections doesn't close the actual hole in the SQL server configuration. It only prevents the known Stuxnet variants from working. As IT forensics expert Oliver Sucker demonstrates (German language link) in a video, only a few steps are required to bypass the protection and regain full remote access to a WinCC system.
The issue is based around the hard-coded access data for the WinCC system's Microsoft SQL database. The Stuxnet worm uses this data to log into further systems from another infected system. There, it uses the integrated xp_cmdshell command shell to access the underlying Windows operating system at system privilege level from the database.
The SIMATIC update prevents the database from executing commands via xp_cmdshell by switching the pertaining configuration option from 1 to 0. According to Sucker, however, the privileges of the hard-coded WinCCAdmin database user are so comprehensive that an attacker can use a few trivial SQL commands to switch the setting back from 0 to 1 after logging in. This will re-enable the execution of commands via the command shell. Sucker has so far not disclosed the exact SQL commands required.
When asked by The H's associates at heise Security, Siemens refused to comment on the issue. Siemens spokesman Gerhard Stauss said in an email, "Our (latest) official statement to the effect that we are investigating ways of tightening authentication procedures remains in place". Until Siemens decides to improve its authentication by allowing the definition of custom access credentials, users can only hope that there will be no further Stuxnet variants or hacker attacks.
---------------------------------------------------------------------------------------------------
SCADA Vendors Still Need Security Wake Up Call
http://threatpost.com/en_us/blogs/scada-vendors-still-need-security-wake-call-102410
The Siemens SIMATIC Security Update for protecting WinCC systems against Stuxnet infections doesn't close the actual hole in the SQL server configuration. It only prevents the known Stuxnet variants from working. As IT forensics expert Oliver Sucker demonstrates (German language link) in a video, only a few steps are required to bypass the protection and regain full remote access to a WinCC system.
The issue is based around the hard-coded access data for the WinCC system's Microsoft SQL database. The Stuxnet worm uses this data to log into further systems from another infected system. There, it uses the integrated xp_cmdshell command shell to access the underlying Windows operating system at system privilege level from the database.
The SIMATIC update prevents the database from executing commands via xp_cmdshell by switching the pertaining configuration option from 1 to 0. According to Sucker, however, the privileges of the hard-coded WinCCAdmin database user are so comprehensive that an attacker can use a few trivial SQL commands to switch the setting back from 0 to 1 after logging in. This will re-enable the execution of commands via the command shell. Sucker has so far not disclosed the exact SQL commands required.
When asked by The H's associates at heise Security, Siemens refused to comment on the issue. Siemens spokesman Gerhard Stauss said in an email, "Our (latest) official statement to the effect that we are investigating ways of tightening authentication procedures remains in place". Until Siemens decides to improve its authentication by allowing the definition of custom access credentials, users can only hope that there will be no further Stuxnet variants or hacker attacks.
---------------------------------------------------------------------------------------------------
SCADA Vendors Still Need Security Wake Up Call
http://threatpost.com/en_us/blogs/scada-vendors-still-need-security-wake-call-102410
Speaking at the ToorCon Security Conference in San Diego, Jeremy Brown, a vulnerability researcher at security firm Tenable said that many SCADA software vendors lag far behind other IT firms in vulnerability research and lack even a basic awareness of modern security principles. Despite the recent, high profile Stuxnet worm, which made headlines around the world by targeting Siemens industrial control system (ICS) software used in power plants and other critical infrastructure, SCADA vendors are not receptive to vulnerability reports from security researchers and often lack the internal processes to properly handle and address vulnerabilities discovered by outside researchers, Brown said.
Monday, October 18, 2010
Technical Analysis of the Windows Win32K.sys Keyboard Layout Stuxnet Exploit
http://www.vupen.com/blog/20101018.Stuxnet_Win32k_Windows_Kernel_0Day_Exploit_CVE-2010-2743.php
This time we will share very interesting technical details on how Stuxnet authors have achieved reliable code execution while exploiting one of the two Windows privilege escalation 0-Day vulnerabilities. This one was patched last week with the MS10-073 update, and a remaining Task Scheduler vulnerability is still unpatched.
While we deeply analyzed Stuxnet and its behaviors, we will not explain its architecture or features as two detailed documents have already been published by our friends from Symantec and ESET.
We will focus here on the Windows Win32K.sys keyboard layout vulnerability (CVE-2010-2743) and how it was exploited by Stuxnet using custom Portable Executable (PE) parsing tricks to achieve a reliable code execution.
----------------------------------------------------------------------------------------------------------------
The Stuxnet developers did a fair amount of work to ensure the exploit worked on all service pack versions of Windows 2000 and Windows XP
ESET has updated their "Stuxnet under the Microscope” whitepaper to include information about the recently-patched win32k.sys vulnerability (MS10-073, or CVE-2010-2743), and just a little about the Task Scheduler issue that hasn't been patched yet.
Dave Aitel, CTO of Immunity, wrote and informed me the still unpatched Task Scheduler 0day was released in the last version of CANVAS, along with improved version of the Win32K.sys keyboard exploit. He stated the "ESET paper does not really go into the details of making it reliable on cross-language versions, which STUXNET did do."
This time we will share very interesting technical details on how Stuxnet authors have achieved reliable code execution while exploiting one of the two Windows privilege escalation 0-Day vulnerabilities. This one was patched last week with the MS10-073 update, and a remaining Task Scheduler vulnerability is still unpatched.
While we deeply analyzed Stuxnet and its behaviors, we will not explain its architecture or features as two detailed documents have already been published by our friends from Symantec and ESET.
We will focus here on the Windows Win32K.sys keyboard layout vulnerability (CVE-2010-2743) and how it was exploited by Stuxnet using custom Portable Executable (PE) parsing tricks to achieve a reliable code execution.
----------------------------------------------------------------------------------------------------------------
The Stuxnet developers did a fair amount of work to ensure the exploit worked on all service pack versions of Windows 2000 and Windows XP
ESET has updated their "Stuxnet under the Microscope” whitepaper to include information about the recently-patched win32k.sys vulnerability (MS10-073, or CVE-2010-2743), and just a little about the Task Scheduler issue that hasn't been patched yet.
Dave Aitel, CTO of Immunity, wrote and informed me the still unpatched Task Scheduler 0day was released in the last version of CANVAS, along with improved version of the Win32K.sys keyboard exploit. He stated the "ESET paper does not really go into the details of making it reliable on cross-language versions, which STUXNET did do."
Friday, October 15, 2010
Win32k.sys: A Patched Stuxnet Exploit
Via ESET Threat Blog -
While the LNK vulnerability patched by MS10-046 dominated the headlines when the Stuxnet carnival started rolling back in early summer 2010, one of the surprises of further analysis of the Stuxnet binaries/components is that it exploited no less than three other vulnerabilities that were generally unknown at the time. The print spooler attack (MS10-61) is, like the LNK vulnerability, described in our lengthy analysis “Stuxnet under the Microscope”.
However, we also indicated in that paper that there are two Elevation of Privilege (EoP) vulnerabilities that we chose not to describe while patches were pending. One of these has now been patched (MS10-073, re CVE-2010-2743) , so we’re now able to publish some of the information we have on it. (When the other vulnerability has been patched, we plan to update the Stuxnet paper with information on both issues.)
When the Win32/Stuxnet worm doesn't have enough privileges to install itself in the system it exploits a recently patched 0-day vulnerability in the win32k.sys system module to escalate privilege level up to SYSTEM, which enables it to perform any tasks it likes on the local machine. The vulnerable systems are:
To perform this trick, it loads a specially crafted keyboard layout file, making it possible to execute arbitrary code with SYSTEM privileges.
-----------------------------------------------------------------------------------------------------
So what is the other, still unpatched, privilege escalate bug?
Symantec's Stuxnet Dossier hinted at both EOP bugs in Page 10 (Installation)....
When the process does not have Adminstrator rights on the system it will try to attain these privileges by using one of two zero-day escalation of privilege attacks. The attack vector used is based on the operating system of the compromised computer. If the operating system is Windows Vista, Windows 7, or Windows Server 2008 R2 the currently undisclosed Task Scheduler Escalation of Privilege vulnerability is exploited. If the operating sys tem is Windows XP the currently undisclosed win32k.sys escalation of privilege vulnerability is exploited.
While the LNK vulnerability patched by MS10-046 dominated the headlines when the Stuxnet carnival started rolling back in early summer 2010, one of the surprises of further analysis of the Stuxnet binaries/components is that it exploited no less than three other vulnerabilities that were generally unknown at the time. The print spooler attack (MS10-61) is, like the LNK vulnerability, described in our lengthy analysis “Stuxnet under the Microscope”.
However, we also indicated in that paper that there are two Elevation of Privilege (EoP) vulnerabilities that we chose not to describe while patches were pending. One of these has now been patched (MS10-073, re CVE-2010-2743) , so we’re now able to publish some of the information we have on it. (When the other vulnerability has been patched, we plan to update the Stuxnet paper with information on both issues.)
When the Win32/Stuxnet worm doesn't have enough privileges to install itself in the system it exploits a recently patched 0-day vulnerability in the win32k.sys system module to escalate privilege level up to SYSTEM, which enables it to perform any tasks it likes on the local machine. The vulnerable systems are:
- Microsoft Windows 2000
- Windows XP – all service packs
To perform this trick, it loads a specially crafted keyboard layout file, making it possible to execute arbitrary code with SYSTEM privileges.
-----------------------------------------------------------------------------------------------------
So what is the other, still unpatched, privilege escalate bug?
Symantec's Stuxnet Dossier hinted at both EOP bugs in Page 10 (Installation)....
When the process does not have Adminstrator rights on the system it will try to attain these privileges by using one of two zero-day escalation of privilege attacks. The attack vector used is based on the operating system of the compromised computer. If the operating system is Windows Vista, Windows 7, or Windows Server 2008 R2 the currently undisclosed Task Scheduler Escalation of Privilege vulnerability is exploited. If the operating sys tem is Windows XP the currently undisclosed win32k.sys escalation of privilege vulnerability is exploited.
Friday, October 1, 2010
Stuxnet Update: Dossier & FAQ
http://www.symantec.com/connect/de/blogs/w32stuxnet-dossier
We’re pleased to announce we’ve compiled the results of many weeks of fast-paced analysis of Stuxnet into a white paper entitled the W32.Stuxnet Dossier. On top of finding elements we described in the ongoing Stuxnet summer blog series, you will find all technical details about the threat’s components and data structures, as well as high level information, including:
-------------------------------------------------------------------------------------------------
Stuxnet Questions and Answers
http://www.f-secure.com/weblog/archives/00002040.html
Q: Is it true that there's are biblical references inside Stuxnet?
A: There is a reference to Myrtus (myrtle plant). However, this is not "hidden" in the code. It's an artifact left inside the program when it was compiled. Basically this tells us where the author stored the source code in his system. The specific path in Stuxnet is: \myrtus\src\objfre_w2k_x86\i386\guava.pdb. The authors probably did not want us to know they called their project "Myrtus", but thanks to this artifact we do. We have seen such artifacts in other malware as well. The Operation Aurora attack against Google was named Aurora after this path was found inside one of the binaries: \Aurora_Src\AuroraVNC\Avc\Release\AVC.pdb.
-----------------------------------------------------------------------------------------------
Myrtus (myrtle) is a genus of one or two species of flowering plants in the family Myrtaceae (or Myrtle family), native to southern Europe and north Africa. Guavas are plants in the myrtle family (Myrtaceae) genus Psidium, which contains about 100 species of tropical shrubs and small trees.
------------------------------------------------------------------------------------------------
Stuxnet Used in Blackhat SEO Campaign
http://blog.trendmicro.com/stuxnet-used-in-blackhat-seo-campaign/
As expected, criminals are now taking advantage of the notoriety of Stuxnet as a mechanism to deploy malicious code. Senior Threats Researcher Ivan Macalintal found poisoned search results that leveraged on this notorious malware threat. Some of the search strings used in this blackhat SEO campaign include “stuxnet SCADA,” “stuxnet removal tool,” “stuxnet cleanup,” “stuxnet siemens,” and “stuxnet worm” among others. Some of these poisoned search words/phrases appeared on top results.
We’re pleased to announce we’ve compiled the results of many weeks of fast-paced analysis of Stuxnet into a white paper entitled the W32.Stuxnet Dossier. On top of finding elements we described in the ongoing Stuxnet summer blog series, you will find all technical details about the threat’s components and data structures, as well as high level information, including:
- Attack scenario and timeline
- Infection statistics
- Malware architecture
- Description of all the exported routines
- Injection techniques and anti-AV
- The RPC component
- Propagation methods
- Command and control feature
- The PLC infector
-------------------------------------------------------------------------------------------------
Stuxnet Questions and Answers
http://www.f-secure.com/weblog/archives/00002040.html
Q: Is it true that there's are biblical references inside Stuxnet?
A: There is a reference to Myrtus (myrtle plant). However, this is not "hidden" in the code. It's an artifact left inside the program when it was compiled. Basically this tells us where the author stored the source code in his system. The specific path in Stuxnet is: \myrtus\src\objfre_w2k_x86\i386\guava.pdb. The authors probably did not want us to know they called their project "Myrtus", but thanks to this artifact we do. We have seen such artifacts in other malware as well. The Operation Aurora attack against Google was named Aurora after this path was found inside one of the binaries: \Aurora_Src\AuroraVNC\Avc\Release\AVC.pdb.
-----------------------------------------------------------------------------------------------
Myrtus (myrtle) is a genus of one or two species of flowering plants in the family Myrtaceae (or Myrtle family), native to southern Europe and north Africa. Guavas are plants in the myrtle family (Myrtaceae) genus Psidium, which contains about 100 species of tropical shrubs and small trees.
------------------------------------------------------------------------------------------------
Stuxnet Used in Blackhat SEO Campaign
http://blog.trendmicro.com/stuxnet-used-in-blackhat-seo-campaign/
As expected, criminals are now taking advantage of the notoriety of Stuxnet as a mechanism to deploy malicious code. Senior Threats Researcher Ivan Macalintal found poisoned search results that leveraged on this notorious malware threat. Some of the search strings used in this blackhat SEO campaign include “stuxnet SCADA,” “stuxnet removal tool,” “stuxnet cleanup,” “stuxnet siemens,” and “stuxnet worm” among others. Some of these poisoned search words/phrases appeared on top results.
Wednesday, September 29, 2010
Reality Check: Is Stuxnet’s Iran Connection The New Iraqi WMD?
Via Forbes' Firewall Blog (by Jeffrey Carr)-
The Stuxnet worm isn’t just infecting thousands of industrial control systems–its hype is also spreading unchecked throughout the news outlets of the Western world. The latest take on the media’s new favorite piece of malicious software: this article in the New York Times wherein John Markoff makes a series of bad assumptions when he writes “As in real warfare, even the most carefully aimed weapon in computer warfare leaves collateral damage. The Stuxnet worm was no different.”
Markoff’s conclusion is presumably based upon the work of German researcher Ralph Langner of Langner Communications who has said of his own theory that it’s completely speculative. In fact he closes by passing this “non-technical stuff” over to others more qualified than he to do the analysis, which was a good thing because the three paragraphs under his heading “Ralph’s Theory – Completely Speculative From Here” are nothing more than sheer guesswork without any attempt by Langner to apply an analytic method to his guesstimate.
Unfortunately, as the media frenzy heated up and Langner was fast becoming the star attraction, he left the world of scientific objectivity far behind when he reportedly told the Christian Science Monitor that “Stuxnet is essentially a precision, military-grade cyber missile deployed early last year to seek out and destroy one real-world target of high importance – a target still unknown.” Unknown is correct, but that didn’t stop Langner from making a guess – Iran’s Bushehr nuclear reactor.
So if Langner’s speculation is correct, the same minds behind the most sophisticated piece of malware that anyone has ever seen couldn’t figure out a way to deliver it without involving a dozen countries and contaminating thousands of hosts? Even worse, that of all the possible targets to pick from, they chose an IAEA-supervised civilian power facility that has zero military value and isn’t even operational yet?
The lynchpins that support his argument are almost as flimsy and can be applied to numerous facilities around the world. It’s an astoundingly weak case based on more flaws than I have the time to document here. The worst, though, is today’s post on Langner’s web page wherein he claims to have been proven right by Iran’s announcement that they were dealing with thousands of Stuxnet- infected hosts across their nation including ones on the commercial side of the Bushehr reactor.
Really, Ralph? That’s what proved you right? We already knew that Iran, Indonesia and India had thousands of infected computers. What you apparently didn’t know, Ralph, was that Iran wasn’t the most heavily hit country in the first five days of the attack. According to Kaspersky Labs data, India was first with 8565 infections, followed by Indonesia (5148), and Iran came in third with 3062. More importantly, these numbers don’t tell the whole story because they’re derived solely by the reporting of protected hosts back to the AV vendor (i.e., Kaspersky, Microsoft, ESET, F-Secure, etc.). In other words, no one really knows how widespread the Stuxnet infection rate is.
The worst part about this entire mess is that we’ve apparently learned nothing from the intelligence failure of Iraqi WMDs. Bad analysis combined with a political agenda supported by a non-critical media propelled us into a war that never should have happened. This past week we could be seeing history repeat itself. The Iranian government is not the most rational of regimes, and their politicians are not technically literate. If Iran attacks Israel because of unfounded conclusions drawn by ambitious researchers and a media that is far more competitive than critical, then you only have yourselves to blame for the consequences.
------------------------------------------------------------------
Some people have suggested that Stuxnet was designed to attack Iran's Bushehr nuclear power station, while others have speculated that it was designed to attack Natanz, but most of the theories (while sounding solid) lack any real solid evidence. However, the points outlined by Frank Rieger tell a very good story and I would personally pick Natanz over Bushehr (if it was a coin toss).
Then again, perhaps there wasn't any specific target behind Stuxnet. Maybe the people behind it just wanted the ability to break the high-speed process of their choosing at a time of their choosing, based on changing conditions on the ground. A sort of, sabotage network in the waiting.
Who knows.
But in hope of stimulating "alternative analysis", Carr has just posted another entry - Did The Stuxnet Worm Kill India’s INSAT-4B Satellite?
The Stuxnet worm isn’t just infecting thousands of industrial control systems–its hype is also spreading unchecked throughout the news outlets of the Western world. The latest take on the media’s new favorite piece of malicious software: this article in the New York Times wherein John Markoff makes a series of bad assumptions when he writes “As in real warfare, even the most carefully aimed weapon in computer warfare leaves collateral damage. The Stuxnet worm was no different.”
Markoff’s conclusion is presumably based upon the work of German researcher Ralph Langner of Langner Communications who has said of his own theory that it’s completely speculative. In fact he closes by passing this “non-technical stuff” over to others more qualified than he to do the analysis, which was a good thing because the three paragraphs under his heading “Ralph’s Theory – Completely Speculative From Here” are nothing more than sheer guesswork without any attempt by Langner to apply an analytic method to his guesstimate.
Unfortunately, as the media frenzy heated up and Langner was fast becoming the star attraction, he left the world of scientific objectivity far behind when he reportedly told the Christian Science Monitor that “Stuxnet is essentially a precision, military-grade cyber missile deployed early last year to seek out and destroy one real-world target of high importance – a target still unknown.” Unknown is correct, but that didn’t stop Langner from making a guess – Iran’s Bushehr nuclear reactor.
So if Langner’s speculation is correct, the same minds behind the most sophisticated piece of malware that anyone has ever seen couldn’t figure out a way to deliver it without involving a dozen countries and contaminating thousands of hosts? Even worse, that of all the possible targets to pick from, they chose an IAEA-supervised civilian power facility that has zero military value and isn’t even operational yet?
The lynchpins that support his argument are almost as flimsy and can be applied to numerous facilities around the world. It’s an astoundingly weak case based on more flaws than I have the time to document here. The worst, though, is today’s post on Langner’s web page wherein he claims to have been proven right by Iran’s announcement that they were dealing with thousands of Stuxnet- infected hosts across their nation including ones on the commercial side of the Bushehr reactor.
Really, Ralph? That’s what proved you right? We already knew that Iran, Indonesia and India had thousands of infected computers. What you apparently didn’t know, Ralph, was that Iran wasn’t the most heavily hit country in the first five days of the attack. According to Kaspersky Labs data, India was first with 8565 infections, followed by Indonesia (5148), and Iran came in third with 3062. More importantly, these numbers don’t tell the whole story because they’re derived solely by the reporting of protected hosts back to the AV vendor (i.e., Kaspersky, Microsoft, ESET, F-Secure, etc.). In other words, no one really knows how widespread the Stuxnet infection rate is.
The worst part about this entire mess is that we’ve apparently learned nothing from the intelligence failure of Iraqi WMDs. Bad analysis combined with a political agenda supported by a non-critical media propelled us into a war that never should have happened. This past week we could be seeing history repeat itself. The Iranian government is not the most rational of regimes, and their politicians are not technically literate. If Iran attacks Israel because of unfounded conclusions drawn by ambitious researchers and a media that is far more competitive than critical, then you only have yourselves to blame for the consequences.
------------------------------------------------------------------
Some people have suggested that Stuxnet was designed to attack Iran's Bushehr nuclear power station, while others have speculated that it was designed to attack Natanz, but most of the theories (while sounding solid) lack any real solid evidence. However, the points outlined by Frank Rieger tell a very good story and I would personally pick Natanz over Bushehr (if it was a coin toss).
Then again, perhaps there wasn't any specific target behind Stuxnet. Maybe the people behind it just wanted the ability to break the high-speed process of their choosing at a time of their choosing, based on changing conditions on the ground. A sort of, sabotage network in the waiting.
Who knows.
But in hope of stimulating "alternative analysis", Carr has just posted another entry - Did The Stuxnet Worm Kill India’s INSAT-4B Satellite?
Monday, September 27, 2010
Stuxnet Update: Iran Confirms Infections
Via H-Online.com -
The head of the Bushehr nuclear plant has confirmed that Stuxnet did infect the plant in Southern Iran, but that staff personal computers were primarily affected. An IT security team is reported to be in place checking computers and removing the malware. Mahmoud Jafari told the Iranian IRNA news agency, "We have not had any problems with the computer system which have affected work in the plant itself."
A day earlier, an IT expert at the Ministry for Industries and Mines had stated that thousands of computers in industrial facilities in Iran were infected by the malware. According to experts at the Iranian Mehr agency, a total of 30,000 computers are affected. Many of the control systems used in Iranian industrial plant are manufactured by German company Siemens.
[...]
In recent days, there have been repeated reports that the Stuxnet malware is specifically targeted at the Iranian nuclear programme, although this remains unconfirmed. The Tehran based ISNA agency has reported that the Iranian nuclear authorities are looking for ways to remove the trojan. Other Iranian media sources report that a number of ministries have formed a joint working group to fight the virus.
----------------------------------------------------------------------------------------------
Stuxnet Infection of Step 7 Projects
http://www.symantec.com/connect/blogs/stuxnet-infection-step-7-projects
Our research has also uncovered another method of propagation that impacts Step7 project folders, causing one to unknowingly become infected when opening an infected project folder that may have originated from a third party.
[...]
Stuxnet monitors Step7 projects (.S7P files) being worked on by hooking CreateFile-like APIs of specific DLLs within the s7tgtopx.exe process (the Simatic manager). Any project encountered by the threat in this way may be infected. Analysis additionally shows that projects inside Zip archives may also be infected through the same method.
-----------------------------------------------------------------------------------------------
NYTimes - A Silent Attack, But Not a Subtle One
http://www.nytimes.com/2010/09/27/technology/27virus.html
One big question is why its creators let the software spread widely, giving up many of its secrets in the process.
One possibility is that they simply did not care. Their government may have been so eager to stop the Iranian nuclear program that the urgency of the attack trumped the tradecraft techniques that traditionally do not leave fingerprints, digital or otherwise.
While much has been made in the news media of the sophistication of Stuxnet, it is likely that there have been many other attacks of similar or even greater sophistication by intelligence agencies from many countries in the past. What sets this one apart is that it became highly visible.
Security specialists contrast Stuxnet with an intrusion discovered in the Greek cellphone network in March 2005. It also displayed a level of skill that only the intelligence agency of some foreign power would have.
The head of the Bushehr nuclear plant has confirmed that Stuxnet did infect the plant in Southern Iran, but that staff personal computers were primarily affected. An IT security team is reported to be in place checking computers and removing the malware. Mahmoud Jafari told the Iranian IRNA news agency, "We have not had any problems with the computer system which have affected work in the plant itself."
A day earlier, an IT expert at the Ministry for Industries and Mines had stated that thousands of computers in industrial facilities in Iran were infected by the malware. According to experts at the Iranian Mehr agency, a total of 30,000 computers are affected. Many of the control systems used in Iranian industrial plant are manufactured by German company Siemens.
[...]
In recent days, there have been repeated reports that the Stuxnet malware is specifically targeted at the Iranian nuclear programme, although this remains unconfirmed. The Tehran based ISNA agency has reported that the Iranian nuclear authorities are looking for ways to remove the trojan. Other Iranian media sources report that a number of ministries have formed a joint working group to fight the virus.
----------------------------------------------------------------------------------------------
Stuxnet Infection of Step 7 Projects
http://www.symantec.com/connect/blogs/stuxnet-infection-step-7-projects
Our research has also uncovered another method of propagation that impacts Step7 project folders, causing one to unknowingly become infected when opening an infected project folder that may have originated from a third party.
[...]
Stuxnet monitors Step7 projects (.S7P files) being worked on by hooking CreateFile-like APIs of specific DLLs within the s7tgtopx.exe process (the Simatic manager). Any project encountered by the threat in this way may be infected. Analysis additionally shows that projects inside Zip archives may also be infected through the same method.
-----------------------------------------------------------------------------------------------
NYTimes - A Silent Attack, But Not a Subtle One
http://www.nytimes.com/2010/09/27/technology/27virus.html
One big question is why its creators let the software spread widely, giving up many of its secrets in the process.
One possibility is that they simply did not care. Their government may have been so eager to stop the Iranian nuclear program that the urgency of the attack trumped the tradecraft techniques that traditionally do not leave fingerprints, digital or otherwise.
While much has been made in the news media of the sophistication of Stuxnet, it is likely that there have been many other attacks of similar or even greater sophistication by intelligence agencies from many countries in the past. What sets this one apart is that it became highly visible.
Security specialists contrast Stuxnet with an intrusion discovered in the Greek cellphone network in March 2005. It also displayed a level of skill that only the intelligence agency of some foreign power would have.
Subscribe to:
Posts (Atom)