Stuxnet Cyber Warfare: Technical Analysis and Defense Strategy

Introduction

Today, computer systems are increasingly being used to cause widespread damage, with nation-states or individuals sponsored by nation-states deploying malicious code to compromise enemy information systems. In essence, cyber warfare involves attacks on the information networks, computers, or infrastructure of another entity by an international organization or nation-state. In the context of this discussion, cyber war is taken as the utilization of "coordinated attacks to specific critical sectors of a country" (Edwards, 2014, p. 67). The key aim of such attacks is usually sabotage or espionage.

This paper concerns itself with cyber warfare. In doing so, it analyzes a journal article titled Stuxnet: Dissecting a Cyberwarfare Weapon by Ralph Langner. More specifically, the paper conducts a technical analysis of that article, discusses both offensive and defensive cyberware strategy, and makes recommendations on how to prevent or avert future cyberware attacks. The relevance of this discussion cannot be overstated, particularly given the high likelihood of more sophisticated variants of Stuxnet emerging in the future.

Background: The Stuxnet Malware

Discovered sometime in mid-2010, Stuxnet — a sophisticated form of malicious software — was "the first demonstration, in the real world, of the capability of software to have a malicious physical effect" (Rosenzweig, 2013, p. 2). Before the discovery of this potent cyber weapon, the mantra of most people in the cyber and computer security realm, as Rosenzweig (2013, p. 2) points out, was that "cyber war only kills a bunch of little baby electrons." The discovery of Stuxnet therefore came as a real surprise, with many coming to the realization that cyber weapons of this kind posed a real threat to physical infrastructure and, perhaps, human life as well — what Rosenzweig refers to as "real babies."

Stuxnet was responsible for the destruction of numerous centrifuges being used for the enrichment of uranium (classified as weapons-grade) at Iran's Natanz nuclear facility. It accomplished this by, among other things, triggering the acceleration of electric motors to dangerously high speeds — effectively setting back the country's nuclear program by approximately two years. In short, this malicious software infected a physical manufacturing plant and caused it to malfunction by triggering the breakdown of machines (Rosenzweig, 2013). This nature of attack was unlike anything experienced before. Although the damage caused by Stuxnet was not catastrophic in terms of loss of life, it was, "figuratively, the first explosion of a cyber atomic bomb" (Rosenzweig, 2013).

In 2013, the Stuxnet cyberattack was, according to the Global Research Center for Research and Globalization (2013), termed an "act of force" by NATO. It is important to note that, as the Tallinn Manual on the International Law Applicable to Cyber Warfare observes, "acts that kill or injure persons or destroy or damage objects are unambiguously uses of force" (Global Research, 2013).

From the outset, Ralph Langner, the author of the article under consideration, points out that "not only was Stuxnet much more complex than any piece of malware seen before, it also followed a completely new approach." This new form of malware took everyone entirely by surprise. The approach taken by Stuxnet, as Langner further explains, did not align with the "conventional confidentiality, integrity, and availability thinking" of the time. Contrary to what most people believed, Stuxnet did not concern itself with the manipulation of data or espionage, nor did it erase any information. Instead, as Langner notes, this particular malware sought to "physically destroy a military target — not just metaphorically, but literally." In his article, Langner delves deeper and demonstrates just how Stuxnet managed to cause such damage.

Technical Analysis of Langner's Article

Langner begins by debunking two popular myths about Stuxnet. First, he points out that the assertion that SCADA systems were the specific targets of Stuxnet is largely untrue. The role SCADA systems played was simply that of distribution. The actual attack was "aimed at industrial controllers that might or might not be attached to a SCADA system" (Langner, 2011). Second, the claim that the attack was remotely controlled is also untrue. It has been established that this specific attack was entirely stand-alone and required no internet access. As noted above, the real targets were industrial controllers, and the physical damage described earlier can be attributed to the resulting controller manipulation.

When it came to distribution, the authors of Stuxnet chose a different route from that of previous malicious programs. The attackers sought to limit the spread of the malware by relying on less common, unconventional distribution methods — specifically, local networks and USB sticks. As Langner points out, Stuxnet was also highly selective when it came to choosing which controllers to infect. Although it infected any Windows computer it encountered, it only targeted controllers manufactured by Siemens, after which "it went through a complex process of fingerprinting to make sure it was on target" (Langner, 2011). Upon identifying the appropriate target, the malware dropped onto the controller what Langner refers to as a "loaded rogue code."

There have been media claims that Stuxnet was specifically designed for Iran's Natanz nuclear facility, with blame directed at the U.S. and Israel. These, however, remain allegations, with neither country acknowledging its involvement. What does appear to be the case is that the Natanz facility was the sole intended target. Although the malware's dropper spread hundreds of thousands of infections around the world, controller infections were limited exclusively to the Natanz facility. Langner attributes this to the fact that the rogue code was only loaded onto a controller once an exact fingerprint match was identified.

In all, there were three controller code sets contained in the rogue driver DLL (Langner, 2011). While two of these were intended for a Siemens S7-315 controller, the third targeted a S7-417 controller. One of these three code sets was loaded onto a controller once a matching target was identified. It was these code injections that, in Langner's words, "got Stuxnet in business — it could then do its thing and prevent legitimate code, which continued to be executed."

It is important to note that, as alarming as it may sound, threat mitigation efforts against sophisticated variants of Stuxnet might not work at all. With regard to Stuxnet specifically, some felt that the problem had been resolved with the release of a security patch by Microsoft. As Langner explains, however, the patches only addressed the dropper component of Stuxnet. This means the digital warheads remained fully operational. The complexity involved in fixing the vulnerabilities exploited by those digital warheads stems from the fact that they rely on "legitimate product features," as opposed to mere firmware or software bugs (Langner, 2011). In the final analysis, most of these vulnerabilities are here to stay.

As Langner observes, eliminating a specific vulnerability would require the release of an entirely new product generation, and asset owners would need to retire existing infrastructure before its scheduled end-of-life date. This is a real-world scenario applicable to many other systems vulnerable to attack — including power grids, traffic systems, missile defense systems, and other nuclear processing facilities. According to Shakarian, Shakarian, and Ruef (2013), cyberwar poses a serious threat to any nation's national security. The questions that naturally follow are: what constitutes an ideal defensive and offensive cyberware strategy, and what can be done to prevent future attacks like Stuxnet?

In response to scenarios such as the one described in Langner's article, he recommends the adoption of a different kind of controller — one that allows for digital code signing. This would help verify the origin of any code loaded onto the controller. The controllers currently in place do not permit digital code signing; instead, they treat any code as legitimate, regardless of its origin, as long as it is syntactically correct (Langner, 2011). Controllers could also be monitored for any suspicious changes in behavior.

Although an offensive strategy is founded on the assumption that we have advance knowledge of an attack, defensive strategies are designed with the understanding that not every attack can be anticipated (Ventre, 2013). This is particularly relevant given that attacks can be highly discrete. An offensive strategy would involve the creation of an "internet weapon" ready to be launched on short notice. This would require the establishment of a Cyber Command tasked with the active surveillance and potential infiltration of overseas target computer networks, with the aim of leaving behind programs that detect suspicious activity — particularly activity that could be detrimental to the safety of citizens or national security.

Conclusion

Ventre, D. (Ed.). (2013). Cyber Conflict: Competing National Perspectives. Hoboken, NJ: John Wiley & Sons.