Creating the Son of Stuxnet
by Pam O’Neal
Stuxnet. Old news, right? After all, it’s been six months since this particularly nasty breed of malware made headlines. But in the security realm, six months is a lifetime during which newer, even nastier variants of Stuxnet malware ("son of stuxnet" anyone?) could be formulated to attack enterprise, military, and other national infrastructure targets. That’s the prediction according to researchers at Websense:
“Stuxnet targeted critical industrial infrastructure, but it was only a preview. Based on how long it takes to develop complicated attacks like Stuxnet, we predict similar exploits will be carried out once or twice in 2011. These state-sponsored offenses will test national infrastructure systems to determine what is effective for future attacks.”
What makes the Stuxnet malware so interesting — and frightening to cyber security experts — is the complexity and targeted nature of the code, which spread from Windows PCs to infect Siemens Supervisory Control And Data Acquisition (SCADA) systems. According to a recent New York Times article, the Stuxnet worm also included code for a man-in-the-middle attack that fakes industrial process control sensor signals so an infected system does not shut down due to abnormal behavior. This made the attack difficult to detect until it was too late to prevent damage.
With this in mind, how can you be certain your security defenses will protect you next time from “Bride of Stuxnet — The Mother of All Malware”? The answer: unleash Stuxnet, and variations on its theme, against your own network defenses to harden their resiliency. It’s the only way to know with certainty that defenses will detect and block the attacks to prevent outages and costly cleanup.
The following step-by-step demonstration and screencast demonstrate a quick way to simulate Stuxnet and even greater mayhem by morphing the attack using the BreakingPoint Storm CTM. As the only product that includes live Stuxnet malware in a growing library of 4,500 attacks, 150 applications, and 100 evasions, the BreakingPoint Storm CTM can simulate Stuxnet and all variations of the attack in a matter of minutes.
We realize that the actual Stuxnet worm propagated via USB devices. But “Bride of Stuxnet” could spread by any number of vectors. The variant we simulate here will take just one of these alternate routes.
Recreating Stuxnet — A Very Real Simulation
Using the Network Neighborhood feature of the BreakingPoint Storm CTM, my partner in (simulated) cyber crime, Mike Hamilton, and I configured the conditions required to simulate the propagation of the infection throughout the world. We used five ports on the product to simulate domains representing each of five geographic locations connected to Stuxnet — in Israel, the United States, the United Kingdom, Indonesia, and Iran. Below is a map showing where each of our network subnets are located physically. Each of these locations was selected based on the Symantec Stuxnet Dossier (Version 1.3, dated November 2010), which indicated that they were the most targeted locales.
The idea behind this simulation — and really any simulation created using BreakingPoint products — was to make it as real as possible. Thus the Israeli IP block comes from a service provider for mobile and wireline networks. The U.S. IP block comes from Halliburton, the huge oil services company. The Indian and Indonesian IP blocks are generic hosts, because we couldn’t get the names of the owners of those blocks. Then, of course, the Iranian IP block is for the Iranian National Oil Company, which could conceivably be the end target of a “Bride of Stuxnet” attack.
The screenshot below shows step 1 of the process, setting up the Network Neighborhood. Each geographical segment is represented by a different interface. This particular screenshot shows the configuration of the Israeli mobile network block; the other geographical regions all looked very similar to this.
Once Network Neighborhoods were defined, we needed to actually simulate the various application and network traffic patterns between all the various nodes, or geographic regions. We used the BreakingPoint Test Editor for this.
Our next step was to emulate the application traffic that would be originating from the network of B Communications, the Israeli telecom carrier network, which would likely look like a mobile network with both smart phones and laptops connected. For this emulation, we used an Application Simulator component and named it “Benign Background Traffic–Israel” so that the reporting would be very clear.
In order to create the most realistic simulation possible, we turned to one of BreakingPoint’s default Application Profiles, ”European Wireless Carrier Daytime with iPhone.” This profile is so accurate because we receive actual traffic profiles from the world’s largest carriers, and our profiles are built using real applications from among our library of 150+. Real applications, user load, and behavior are critical aspects of doing this sort of simulation, and BreakingPoint products are the only systems that deliver this functionality and the ability to simulate millions of users out of the box. Choosing the Application Profile is shown in the next screenshot.
Once we set up our very specific mobile traffic originating from Israel and destined for each of our other geographical locations, we needed to simulate the traffic that would originate from each of the other geographical regions. These would most likely be all landline network connections, using desktops and laptops with standard Wide Area Network (WAN) traffic. Thus, we created an Application Simulator component with a blend of HTTP, DNS, peer-to-peer, voice over IP, and other protocols that would likely traverse the network. This component, shown in the screenshot below, represents traffic originating from all of the landline connections and is considered to be benign.
After establishing our baseline background traffic, we began to simulate the propagation of the “Bride of Stuxnet” malware by creating a Strike List that uses BreakingPoint’s live malware version of Stuxnet.
With this Strike List, we began to develop the propagation vector. We added four security components to the simulation, as shown in the screenshot below. You’ll notice that the start times are all staggered. The first security component simulated the propagation of Stuxnet through SMTP from Israel to the United States, targeting a prominent oil services company. Some period of time later, we simulated the propagation of Stuxnet from the US to India via a IMAPv4 download. Once our Stuxnet simulation infected India, it further propagated via HTTP download to Indonesia, another one of the hardest-hit Stuxnet locales. Finally, the last stage in the propagation was the final POP3 download into the targeted location. This is shown with the 4th security component in the screenshot below.
Once we configured the simulation in this straightforward way, we ran it to see what would happen to the network devices in our lab, given this type of attack vector.
The Next Chapter in the Stuxnet Saga
While we cannot divulge the effects on the brand-name devices we infected, and we didn’t pop any baloons like the Symantec researchers, we can tell you that you really should be conducting this type of simulation in your own lab. No one knows exactly when or how the next attack will happen, but it is possible to determine exactly how it will affect you.
By the way, anyone can set up this simulation in a few minutes using the BreakingPoint Storm CTM. That’s why we built it, and no one else can do it. For more information, take a look at the resources and methodologies on our website.