Аll formatting is mine.All quotes are taken from the single Symantec document, reference to which
http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/w32_stuxnet_dossier.pdf was published in my blog in
some previous post Note: (c) p.2 - means, that all text above is quote from the page 2 of this pdf document.
If you are not interested in the the technical details (started from "Export 16..." (c) p.13-14) you can skip all the text till the "Summary" (c) 45.
Attack Scenario
The following is a possible attack scenario...
There is more below.
Ниже есть продолжение.
...It is only speculation driven by the technical features of Stuxnet.
Industrial control systems (ICS) are operated by a specialized assembly like code on programmable logic controllers
(PLCs). The PLCs are often programmed from Windows computers not connected to the Internet or even the internal network. In addition, the industrial control systems themselves are also unlikely to be connected to the Internet.
First, the attackers needed to conduct reconnaissance. As each PLC is configured in a unique manner, the attackers
would first need the ICS’s schematics. These design documents may have been stolen by an insider or even retrieved by an early version of Stuxnet or other malicious binary. Once attackers had the design documents and potential knowledge of the computing environment in the facility, they would develop the latest version of Stuxnet.
Each feature of Stuxnet was implemented for a specific reason and for the final goal of potentially sabotaging
the ICS.
Attackers would need to setup a mirrored environment that would include the necessary ICS hardware, such as PLCs, modules, and peripherals in order to test their code. The full cycle may have taken six months and five to ten core developers not counting numerous other individuals, such as quality assurance and management.
In addition their malicious binaries contained driver files that needed to be digitally signed to avoid suspicion. The attackers compromised two digital certificates to achieve this task. The attackers would have needed to obtain the digital certificates from someone who may have physically entered the premises of the two companies and stole them, as the two companies are in close physical proximity.
To infect their target, Stuxnet would need to be introduced into the target environment. This may have occurred by infecting a willing or unknowing third party, such as a contractor who perhaps had access to the facility, or an insider. The original infection may have been introduced by removable drive.
Once Stuxnet had infected a computer within the organization it began to spread in search of Field PGs, which are typical Windows computers but used to program PLCs. Since most of these computers are non-networked, Stuxnet would first try to spread to other computers on the LAN through a zero-day vulnerability, a two year old vulnerability, infecting Step 7 projects, and through removable drives. Propagation through a LAN likely served as the first step and propagation through removable drives as a means to cover the last and final hop to a Field PG that is never connected to an untrusted network.
While attackers could control Stuxnet with a command and control server, as mentioned previously the key computer
was unlikely to have outbound Internet access. Thus, all the functionality required to sabotage a system was embedded directly in the Stuxnet executable. Updates to this executable would be propagated throughout the facility through a peer-to-peer method established by Stuxnet.
When Stuxnet finally found a suitable computer, one that ran Step 7, it would then modify the code on the PLC. These modifications likely sabotaged the system, which was likely considered a high value target due to the large resources invested in the creation of Stuxnet.
Victims attempting to verify the issue would not see any rogue PLC code as Stuxnet hides its modifications.
While their choice of using self-replication methods may have been necessary to ensure they’d find a suitable Field PG, they also caused noticeable collateral damage by infecting machines outside the target organization. The attackers may have considered the collateral damage a necessity in order to effectively reach the intended target. Also, the attackers likely completed their initial attack by the time they were discovered.
(c) p.3
Timeline
November 20, 2008
Trojan.Zlob variant found to be using the LNK vulnerability only later identified in Stuxnet.
April, 2009
Security magazine Hakin9 releases details of a remote code execution vulnerability in the Printer Spooler service. Later identified as MS10-061.
June, 2009
Earliest Stuxnet sample seen. Does not exploit MS10-046. Does not have signed driver files.
January 25, 2010
Stuxnet driver signed with a valid certificate belonging to Realtek Semiconductor Corps.
March, 2010
First Stuxnet variant to exploit MS10-046 [LNK vulnerability].
June 17, 2010
Virusblokada reports W32.Stuxnet (named RootkitTmphider). Reports that it’s using a vulnerability in the processing of shortcuts/.lnk files in order to propagate (later identified as MS10-046).
July 13, 2010
Symantec adds detection as W32.Temphid (previously detected as Trojan Horse).
July 16, 2010
Microsoft issues Security Advisory for “Vulnerability in Windows Shell Could Allow Remote Code Execution (2286198)” that covers the vulnerability in processing shortcuts/.lnk files.
Verisign revokes Realtek Semiconductor Corps certificate.
July 17, 2010
Eset identifies a new Stuxnet driver, this time signed with a certificate from JMicron Technology Corp.
July 19, 2010
Siemens report that they are investigating reports of malware infecting Siemens WinCC SCADA systems.
Symantec renames detection to W32.Stuxnet.
July 20, 2010
Symantec monitors the Stuxnet Command and Control traffic.
July 22, 2010
Verisign revokes the JMicron Technology Corps certificate.
August 2, 2010
Microsoft issues MS10-046, which patches the Windows Shell shortcut vulnerability.
August 6, 2010
Symantec reports how Stuxnet can inject and hide code on a PLC affecting industrial control systems.
September 14, 2010
Microsoft releases MS10-061 to patch the Printer Spooler Vulnerability identified by Symantec in August.
Microsoft report two other privilege escalation vulnerabilities identified by Symantec in August.
September 30, 2010
Symantec presents at Virus Bulletin and releases comprehensive analysis of Stuxnet.
(c) p.4
Geographic Distribution of Infections
Iran - 58,31%, Indonesia - 17.83%, India - 9.96%, Azerbaijan - 3.40%, Pakistan - 1.40%, Malaysia - 1.16%, USA - 0.89%, Russia - 0.61%, Great Britain - 0.57%, others - 5.15%.
Percentage of Stuxnet infected Hosts with Siemens Software installed
Iran - 67.60%, South Korea - 8.10%, USA - 4.98%, UK - 2.18%, Indonesia - 2.18%, Taiwan - 1.56%, India - 1.25%, others - 12.15%.
(c) p.6
Export 16 [the main installer for Stuxnet] first checks that the configuration data is valid, after that it checks the value “NTVDM TRACE” in the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\MS-DOS Emulation
If this value is equal to 19790509 the threat will exit. This is thought to be an infection marker or a “do not infect”
marker. If this is set correctly infection will not occur. The value appears to be a date of May 9, 1979. While on May 9, 1979 a variety of historical events occured, according to Wikipedia “Habib Elghanian was executed by a firing squad in Tehran sending shock waves through the closely knit Iranian Jewish community. He was the first Jew and one of the first civilians to be executed by the new Islamic government. This prompted the mass exodus of the once 100,000 member strong Jewish community of Iran which continues to this day.” Symantec cautions readers on drawing any attribution conclusions. Attackers would have the natural desire to implicate another party.
Next, Stuxnet reads a date from the configuration data (offset 0x8c in the configuration data). If the current date is later than the date in the configuration file then infection will also not occur and the threat will exit. The date found in the current configuration file is June 24, 2012.
(c) p.13-14
Explorer.exe is injected with oem7m.pnf, an unknown file, which does not appear to be dropped by Stuxnet.
(c) p.16
In the driver file, the project path b:\myrtus\src\objfre_w2k_x86\i386 \guava.pdb was not removed.
Guavas are plants in the myrtle (myrtus) family genus. In addition, according to Wikipedia, “Esther was originally named Hadassah. Hadassah means ‘myrtle’ in Hebrew.” Esther learned of a plot to assassinate the king and “told the king of Haman’s plan to massacre all Jews in the Persian Empire...The Jews went on to kill only their would-be executioners.” Symantec cautions readers on drawing any attribution conclusions. Attackers would have the natural desire to implicate another party.
(c) p.20
Because the peer-to-peer mechanism occurs through RPC, it is unlikely as an alternative method of command and control as RPC generally is only effective within a local area network (LAN). The purpose of the peer-to-peer mechanism is likely to allow the attackers to reach computers that do not have outbound access to the general Internet, but can communicate with other computers on the LAN that have been infected and are able to contact the command and control servers.
(c) p.22
MS08-067 Windows Server Service vulnerability
In addition, Stuxnet also exploits MS08-067, which is the same vulnerability utilized by W32.Downadup. MS08-067 can be exploited by connecting over SMB and sending a malformed path string that allows arbitrary execution.
Stuxnet uses this vulnerability to copy itself to unpatched remote computers.
Stuxnet will verify the following conditions before exploiting MS08-67:
• The current date must be before January 1, 2030
• Antivirus definitions for a variety of antivirus products dated before January 1, 2009
• Kernel32.dll and Netapi32.dll timestamps after October 12, 2008 (before patch day)
(c) p.24
...Different circumstances will cause Stuxnet to remove the files from an infected removable drive. For example, once the removable drive has infected three computers, the files on the removable drive will be deleted...Before infecting the drive, the current time must be before June 24, 2012....
(c) p.25
Previous versions of Stuxnet did not use the LNK 0-day exploit, but instead spread via an autorun.inf file. Resource
207 is a 500kb file that was only present in the older version of Stuxnet, and was removed in the new version.
(c) p.27
While we are able to describe everything the injected PLC code does, what address are set, what values are checked without design documents of the intended target, the information is essentially useless. For example, if a particular output is set to 100, we can not determine if that output is connected to a pump, a centrifuge, or a turbine. Without that context, we are unable to understand the real-world impact of the PLC code.
However, there are some additional interesting clues. For example, code added to OB35 uses a magic marker value of 0xDEADF007 (possibly to mean Dead Fool or Dead Foot—a term used when an airplane engine fails) to specify when the routine has reached its final state.
(c) p.38
From the samples we have reviewed (which are only a subset of the total samples to date) we observed four distinct
file sizes for the installer component as shown below...There are four different types of installers, the first three types are actually the same but with added junk or nulls. However, the fourth type is significantly different from the other 3 types.
...
|
Date |
# of Resources |
File Size |
|---|
Type 1 |
March 2010 |
14 |
498,117 |
Type 4 |
June 2009 |
11 |
596,481 |
(c) p.42
Both types of samples operate in mostly the same way except that the newer samples have additional resources added to enable propagation through the .lnk vulnerability. In fact the samples using the .lnk vulnerability were the first samples to be named W32.Stuxnet so although the Type 4 samples predate the name W32.Stuxnet Symantec identifies both types of samples as W32.Stuxnet. The name W32.Stuxnet!lnk is used by Symantec to identify malicious .lnk files used by the threat.
Analyzing the different types of samples Symantec has observed to date has shed some light on how long this threat has been under development and/or in use. The development of the threat dates back to at least June of 2009. The threat has been under continued development as the authors added additional components, encryption,
and exploits. The amount of components and code used is very large. In addition to this the authors ability to adapt the threat to use an unpatched vulnerability to spread through removable drives shows that the creators
of this threat have huge resources available to them and have the time needed to spend on such a big task; this is not a teenage hacker coding in his bedroom type operation.
(c) p.44
Summary
Stuxnet represents the first of many milestones in malicious code history – it is the first to exploit four 0-day vulnerabilities, compromise two digital certificates, and inject code into industrial control systems and hide the code from the operator. Whether Stuxnet will usher in a new generation of malicious code attacks towards real-world infrastructure—overshadowing the vast majority of current attacks affecting more virtual or individual assets—or if it is a once- in-a-decade occurrence remains to be seen.
Stuxnet is of such great complexity—requiring significant resources to develop—that few attackers will be capable of producing a similar threat, to such an extent that we would not expect masses of threats of similar in sophistication to suddenly appear. However, Stuxnet has highlighted direct-attack attempts on critical infrastructure
are possible and not just theory or movie plotlines.
The real-world implications of Stuxnet are beyond any threat we have seen in the past. Despite the exciting challenge in reverse engineering Stuxnet and understanding its purpose, Stuxnet is the type of threat we hope to never see again.
(c) 45
http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/w32_stuxnet_dossier.pdf
См. также
Иран подвергся атаке нового вируса
Вирус Stuxnet отбросил ядерную программу Ирана на два года назад
Эксперт: Промышленный вирус Stuxnet попал на черный рынок
Израиль остановил ядерную программу Ирана
Эксперты: Stuxnet мог уничтожить иранские центрифуги
Stuxnet - highlights of the Symantec document (English)
Stuxnet - версия "Коммерсанта" (Russian)
Stuxnet - more technical details (English)
Stuxnet podcast (Russian)
Stuxnet - Israelis eye cyberwar on Iran on July 2009? (English)
Stuxnet - technical details (English)
Stuxnet - технические детали (Russian)
Иран подтверждает: он был атакован сложнейшим компьютерным вирусом
