From a Time When The World has hardly known Cybersecurity

Stuxnet is a malicious computer worm that first came into the limelight in 2010 and was believed to have been in development since 2005. Stuxnet targets explicitly Supervisory Control and Data Acquisition (SCADA) and Programmable Logic Controllers (PLC)systems and is responsible for causing tremendous damage to Iran's nuclear program. However, it is believed that the malware was created jointly by the United States and Israel in a collaborative effort known as Operation Olympic Games.

Stuxnet targets Programmable Logic Controllers (PLCs) specifically, which allow the automation of electromechanical processes in plants, factories, or industrial infrastructures such as those used to control machinery and industrial methods in nuclear power plants-- gas centrifuges for separating nuclear material. Stuxnet exploited four zero-day flaws. Stuxnet functions by targeting machines that use the Microsoft Windows OS and then looking out for Siemens Step7 software. It was reported that the worm was able to compromise PLCs present in the Iranian nuclear plants by collecting information on industrial systems and causing the fast spinning of the centrifuges, which resulted in them tearing themselves apart. Stuxnet reportedly ruined almost 20% of Iran's nuclear centrifuges. The worm reportedly infected over 200,000 computers and caused hundreds of machines to degrade physically.

Timeline of the Stuxnet Attack

• November 20, 2008: It was found that Trojan - Zlob’s variant was using the LNK vulnerability, which was also later identified in Stuxnet.
• April 2009: The renowned security magazine “Hackin9” released details of a Remote Code Execution (RCE) vulnerability in the Printer Spooler service, later identified as MS10-061.
• June 2009: Evidence for the earliest Stuxnet sample found. It does not exploit MS10-046 nor has signed driver files.
• January 25, 2010: Stuxnet driver files are obtained with a valid certificate signed by Realtek Semiconductor Corporations.
• March 2010: MS10-046 is exploited by a Stuxnet variant.
• June 17, 2010: Virus-blokada, a European security software company, reports W32.Stuxnet uses a vulnerability in the processing of shortcuts/.lnk files to propagate. This was later identified as MS10-046.
• July 13, 2010: Symantec, an American software company, adds detection as W32.Temphid, which was previously detected as Trojan Horse.
• July 16, 2010: Microsoft released the Security Advisory for “Vulnerability in Windows Shell.” Verisign revokes the certificate--Realtek Semiconductor Corps.
• July 17, 2010: New Stuxnet driver is identified signed with a certificate from JMicron Technology Corporation rather than Realtek Semiconductor Corporation.
• July 19, 2010: Investigation on malware infecting Siemens WinCC SCADA systems was initiated by Siemens.
• July 20, 2010: Symantec monitors the Stuxnet Command and Control(C2) traffic.
• July 22, 2010: Verisign, an American network infrastructure company, revokes the JMicron Technology Corps certificate.
• August 2, 2010: Microsoft releases MS10-046, which patches the Windows Shell shortcut vulnerability.
• August 6, 2010: Symantec releases reports stating how Stuxnet can inject and hide code on a PLC affecting ICS.
• September 14, 2010: Microsoft released the MS10-061 patch for the Printer Spooler Vulnerability. Microsoft reported two other privilege escalation vulnerabilities. Both of which were identified by Symantec in August.
• September 30, 2010: Symantec releases comprehensive analysis of Stuxnet
• October 11, 2010: Open letter to Symantec addressing their weakly informed assessment of the threat posed by Stuxnet-inspired malware. The letter pointed out some significant shortcomings -- why Stuxnet can be copied easily and re-used by follow-up attackers without insider knowledge.
• November 14, 2010: Published intelligence on attacker profiling, pointing out that a coalition of nation-states appears behind Stuxnet, Suspecting --Israel, USA, Germany, Russia.
• December 6, 2010: The Langner Controller Integrity Checker mitigation tool for Stuxnet-inspired malware announced.

The How of “Stuxnet Attack”

The attackers developed the Stuxnet worm to exploit four Microsoft Windows OS zero-day vulnerabilities known to the intelligence agencies but not publicly disclosed to the world.

The four exploited vulnerabilities for the attacks were:

• The .lnk file extension for creating shortcuts
• A shared print-spooler vulnerability
• Two vulnerabilities related to privilege escalation

The LNK file extension was explicitly used to enable the worm to spread in the system using USB sticks. The shared print spooler vulnerability was used to extend the worm through the network using shared printing facilities used in the 2000s. Finally, the privilege escalation exploits enabled the worm to execute its code and damage the centrifuges secretly.

Firstly, the worm targeted the computers used to manage the SCADA and PLC devices that controlled the centrifuges present in the nuclear plant. The atomic facilities network was not connected to the broader Internet, thus creating an air gap. Therefore, physical means such as USB sticks were used to infiltrate the worm into the network. This was achieved by the intelligence agencies entering five nuclear facilities suppliers and secretly adding the Stuxnet code to their systems. As a result, the engineers at the supplier companies were cleared to work on the SCADA and PLC. However, the anti-virus systems implemented could not detect the malicious code. Once the USB sticks were plugged into the nuclear facilities' computers running on Microsoft Windows OS, the Stuxnet worm entered the system. It replicated itself to all other available Microsoft Windows-based computers on the nuclear facilities networks, thus resulting in a full-fledged spread over the Iranian nuclear network.

Once the worm had infiltrated and spread across the network, the code identified the specific Siemens's Step 7 Software running on the facilities’ computers with Microsoft Windows OS. Siemens's Step 7 application controlled SCADA and PLC, used to control the centrifuges. The code then executed the payload, which resulted in the manipulation of the controls that managed the speed and duration of the centrifuges; the high speed caused the centrifuges to burn themselves out. On the other hand, the low rate caused inefficient processing of nuclear material -uranium, thereby wasting resources and slowing the production. In addition, when the Stuxnet worm of the centrifuges was manipulating the speed, false data was being sent to the SCADA and PLC, which is monitored by the Siemens Step 7 application, giving the false impression that the instrument mechanics were working fine at the facility.

Later, a variant of Stuxnet was manipulating the valves to increase the pressure inside centrifuges, damaging both the valve and the centrifuge, thus slowing down the uranium enrichment process.

The Attack Vector

1. Stuxnet malware enters the system or network via a USB stick and infects all Microsoft Windows OS machines. By showcasing a digital certificate that seems to show that it comes from a reliable company, the worm can evade automated- detection systems.
2. Stuxnet malware then checks whether a given machine is part of Siemens's targeted Industrial Control System (ICS). Such systems are deployed in the Iranian nuclear plants to run high-speed centrifuges that help to enrich nuclear fuel.
3. If the system isn’t a target, Stuxnet does nothing; if it is, the worm attempts to access the internet and download a more recent version of itself.
4. The worm then compromises the target system’s logic controllers, exploiting zero-day vulnerabilities.
5. Stuxnet spies on the operations of the targeted system. Then it uses the information gathered to control the gas centrifuges, making them spin, resulting in complete failure.
6. Meanwhile, it provides false feedback to the outside that they won’t know what’s going wrong until it’s too late to do anything about it.

Effects of Stuxnet

Mainly to destroy centrifuges. Stuxnet speeds up the rotational speed of centrifuges from ordinary to 1,410 Hz for 15 minutes; then, 27 days later, it slows them down for 50 minutes, during which the rotational speed of centrifuges is reduced to 200 Hz. Almost every 27 days, the sequence repeats. The high speed causes the centrifuges to rupture, and the low rate would result in inefficient processing of nuclear material -uranium, thereby wasting resources and slowing the production.

To discover the Iranians- Stuxnet’s creators hoped to slow Iran’s nuclear program by creating doubt and confusion. Resulting in the Iranians halting uranium processing on several centrifuges. The creators of Stuxnet probably thought the worm wouldn’t be discovered as quickly as it was. If it hadn’t been discovered as early, the damage it would have caused could have been more significant. Waiting 27 days between attacks was done possibly to be stealthier.

Stuxnet worm also caused some unintended effects. It infected 100,000 computers around the world. Stuxnet didn’t do any severe damage outside Iran’s nuclear program, as it was highly targeted to destroy the efforts of Iran to become a nuclear power. However, others may use Stuxnet’s code as a base to attack SCADA or other systems in other countries.

Preventive countermeasures that can be taken to avoid such attacks in the first place:

• Effective implementation of security policies and procedures is the first step to securing control systems. These need to be reviewed and updated on a timely basis as part of a continuous improvement program.
• We are implementing a Security Awareness Program to make the employee aware of these attacks.
• Disabling of USB devices within the organization. These can be implemented with exceptions.
• Implementation of Software Restriction Policies (SRP) that prevent the execution of code present on a remote or removable media.
• Confirmation on the removal or modification of any default username/passwords.
• Confirmation on removing any unnecessary services is no longer required for any process.
• Use active vulnerability scanners on these systems to evaluate and document the configuration against known vulnerabilities and predetermine compliance guidelines.
• Implementing an effective Patch Management Program that regularly updates operating systems and installed applications. In addition, systems should be audited timely to ensure that updates are installed regularly.
• Implementation of non-repudiation methods for accountable logging.
• Logging of events should not be performed on the same device which generates the logs but should be done on a separate device for pre-and post-event analysis. This also helps minimize the possibility of an attacker altering system logs and hiding their tracks.
• Allowed security applications should be considered over Blacklisted solutions whenever possible to increase the likelihood that zero-days will be detected.
• The firewall rule “deny by default” should be implemented to all outbound traffic from the control system networks and zones; exceptions can be.

Once these attacks are detected inside the organization – system or networks, we can only react to the attack and minimize the potential risk the attack possesses.

• Security Information and Event Management (SIEM) systems should be installed to automatically analyze and correlate the data generated and stored in system logs throughout the control system network.
• Implementation of intrusion monitoring systems should be integrated with SIEM within control systems networks. These systems will analyze data traffic patterns between system components.
• Implementing Extrusion Detection Systems, appropriately integrated, will generate alerts or notifications for potential client-side attacks.
• Implementation of SCADA honeypot or identical system on the same network can be used as a dummy system for periodic scan and testing.
• When an attack is identified, staff should use the knowledge of the attack to possibly isolate affected hosts or networks until they can be trusted and placed back into service.
• Firewalls, switches, routers, and the hosts themselves can be used to isolate an attack in progress.
• Once the attack has been detected or confirmed, all non-essential communication should be filtered and carefully monitored to prevent the attack while negatively impacting plant operation.
• Reactive plans should be in place, tested regularly, and updated with the changing times to be effective in the event of an attack.
• Incident Response and Business Continuity procedures should be in place and initiated to maintain essential operations while recovering from an attack.
• As a last resort, it may be necessary to initiate a total shutdown of the process to minimize the potential for environmental or loss of life resulting from a potential control system failure. Disaster Recovery Systems can be used as a standby machine in active mode during a possible shutdown.

Bottom-Line: “This Could Have Been Very-Well; Avoided.”