Ralph Langner’s article on the Stuxnet worm discusses the hardware, distribution and targets of the attack. He also goes into detail regarding the outlook of future attacks and what we can do to prevent them.
The Stuxnet attack was not executed to steal or erase information. It was carried out to physically destroy a military target; Iran’s Natanz nuclear facility. The attack was aimed at industrial SCADA controllers and was a stand-alone attack. It was not an attack that required access to the Internet. The attackers relied on local networks and USB drives to carry out the attack. It targeted Siemens controllers and underwent a complex process to make sure that it found the correct target. Once the target was found, malicious code was entered into the controller, which caused their centrifuges to become over-pressurised and break more easily. The attack was also meant to be limited to Natanz, but it eventually spread to approximately 100,000 other controllers and systems worldwide. Langner proposed that the best solution to prevent future physical attacks is to monitor controllers for changes by using independent drivers.
The early version of Stuxnet either had to be installed on a computer or installed via a USB drive that contained infected configuration files for Siemens controllers. When the file was opened by engineering software, the computer was infected (Langner, 2013). However, if there was no engineering software to open the infected file, nothing would happen. Thus, a new version was created. The second version contained self-replication code that allowed it to spread on networks and via USB drives until it got to the computers running the engineering software. Since this version of Stuxnet was self-replicating, it made it possible to infiltrate and identify nuclear sites that the attackers were not aware of (Langner, 2013). At some point, Stuxnet came to be equipped with Windows exploits and stolen digital certificates. This allowed the worm to be recognized as a device driver and to not be rejected by the Windows operating system.
The early version of the worm functioned as a man-in-the-middle attack. It sat between the engineering software and the Siemens controllers for the input and output valves feeding into each centrifuge. The worm would accept commands from the engineering software and give false responses to indicate that these commands were being processed by the controllers. In reality, the worm was regularly allowing the centrifuges to be over-pressurized, which had the effect of causing the centrifuges to wear out and break more quickly. The later version of the software was much more crude. It would take over the centrifuges and refuse to acknowledge signals from the engineering software while an attack was active.
The attack operated about once a month and worked by slowing down the centrifuges and then spinning them back up to past their normal full speed. This would cause damage as the centrifuges passed through what was known as a resonance speed, which would destabilize the rotor. Stuxnet managed to increase the rotor speeds at Iran’s Natanz nuclear facility from a normal speed of 63,000 rpm to 84,600 rpm. The worms were carefully designed so that it would not be obvious to someone in the facility that their mechanical systems were being sabotaged. For example, the worm would randomly affect different centrifuges at different times or otherwise attempt to mask what it was doing (Langner, 2013).
The latter version of Stuxnet took advantage of the “Microsoft Windows Shortcut ‘LNK’ Automatic File Execution Vulnerability” (Murchu, 2010). This vulnerability would automatically launch when Windows Explorer was used to access a thumb drive, causing .dll files to be loaded and executed on the host machine. It would patch the Windows kernel to mask its operation. Once the kernel was patched, the main payload of the worm would install, including the logic for infecting any new, non-infected media that was attached to the computer, as well as logic that would allow it to propagate to the trusted local network. The payload also contained the logic for interacting with the Siemens control system, as well as communicating with command and control servers. This later version of the worm would also collect information regarding the systems that it infected, and was updatable as new exploits were discovered or created by the authors of the worm. Personal Reflection
Case re: Defensive/Offensive Cyberware Strategy
Stuxnet and other attacks have caused significant damage over the years. While it is important to be aware of past and current attacks, it is also imperative to implement strategies and policies in order to prevent future attacks. In cases like Stuxnet, prevention can be very tricky. It is not as easy as using passwords and access control, because computers with proper credentials were attacked and infected with Stuxnet. Once infected, the account was able to access the controller, so strong passwords and access control would not have stopped it (Ghosh, 2010).
Additionally, there is no anti-virus software that can catch Stuxnet once it has infected your computer or network. According to Baldonado (2014), the best thing to do would be to avoid it by setting up a layered defense that addresses security throughout the entire network. This would include security policy, training, and enforced methods and procedures. There should also be physical and logical segregation between different network types. Baldonaldo also recommends that software needs to be written to detect actions that are non-conforming with other programs on a network. User privileges should also be strict and use strong passwords and multi-factor authentication, to possibly include biometrics.