by Stephen Cobb ESET Security Evangelist
A week ago the big malware news was the code known as Flame, Flamer, or sKyWIper (detected by ESET as Win32/Flamer.A), then on June 1, this news broke: “A damaging cyberattack against Iran’s nuclear program was the work of U.S. and Israeli experts and proceeded under the secret orders of President Obama.” (Washington Post) Clearly, the antivirus community is going to have a lot to say about this news and there will probably be several posts on the topic from ESET researchers.
Just to give some background, the attack was Stuxnet, a piece of malware that was documented in detail in the ESET white paper Stuxnet Under the Microscope (an 85 page PDF document). The goal of Stuxnet was to attack and sabotage Iran’s nuclear program, and as the New York times put it: “the last of that series of attacks, a few weeks after Stuxnet was detected around the world, temporarily took out nearly 1,000 of the 5,000 centrifuges Iran had spinning at the time to purify uranium.”
Of course, like any malicious code that is deployed in anger, Stuxnet was destined to become public knowledge and public property, open to abuse by criminals, crazies, nation states and hacktivists. The same is true of other government Trojan code, as documented in March by ESET malware researchers Robert Lipovsky writing about German code, and Alexis Dorais-Joncas addressing potentially Chinese code.
All of which means that many antivirus researchers found the following statement in the New York Times quite laughable:
“an element of the program accidentally became public in the summer of 2010 because of a programming error that allowed it to escape Iran’s Natanz plant and sent it around the world on the Internet.”
Just to be clear, a programming error was not needed for Stuxnet to escape. Whenever the people running systems attacked by malicious code eventually find it, they have the option to tell the world about it, which is exactly what Iran’s Computer Emergency Response Team did with Flame on May 28 (triggering announcements from researchers who had been hoping to complete their analysis of the code before making it public). Furthermore, anyone who worked on making the code, or who found the code, could themselves copy it and spread it, or sell it, or modify it, or do any of a range of things you can so easily do with digital products, as opposed to physical artifacts.
Unfortunately, the New York Times quote perpetuates a crazy notion that was widely debunked by AV researchers decades ago, a misguided belief that can be summed up like this: “I believe that I can create a piece of infectious code which will be free of programming errors, remain under my control after it is deployed, and have no unexpected side effects.” People have tried to do that many times but none have succeeded, which is why we can confidently predict that infectious malware which is deployed is destined to be made public.
Anyone who works with malicious code knows just how hard it is to control if you place it outside the laboratory in which it is created. Frankly, controlling malware at any point after its creation is challenging, just ask the people who run antivirus labs. In fact, the world would have been saved a lot of trouble and expense if the people who made Stuxnet had listened to the people who have dedicated themselves to the fight against malicious code.
Instead, an arrogance of intellect prevailed and Stuxnet became a gift to criminals and nation states with malicious intent. Code from Stuxnet was bound to appear elsewhere (consider Win32/Duqu which was documented on the ESET Threat Blog last year). The same will be true of Flamer. What this means in practical terms is that every dollar a nation state spends to develop malicious code is a gift to criminals and other nation states. Think of it like this: You create a revolutionary new shoulder-fired, surface-to-air missile and issue it to your troops while simultaneously placing all of the manufacturing blueprints and operating instructions into the public domain and on your website for anyone to download, plus a toll-free number from which anyone can order the tools and materials to build their own missiles, with free shipping on all orders. Deploying malicious code for nation-state purposes is not that dumb, it is even dumber.
The only good news about Flamer, the latest piece of apparently state-sponsored digital terrorism to come to light, is that Flamer is probably not headed your way any time soon. It is unlikely that you are the target of Flamer unless you are an official in a Middle Eastern government or working on weapons research for such a government. Flamer is not “out there” on the Internet right now, spreading from country to country. You are not likely to find Flamer attached to an email in your Outlook Inbox (USB flash drives seem to be Flamer’s infection vector of choice). And if you are using a good antivirus product it is now protecting you from Flamer. The major AV products were quickly updated to detect Flamer and the better ones will now have generic detection of malware that has “Flamer-like” characteristics.
Perhaps more important, and this needs to be stressed, organizations that follow information security best practices, such as deploying endpoint security with device controls that prevent malware infection from USB flash drives, are well-defended against most of the malicious software attacks they are likely to encounter today. Despite some serious hand-wringing in the AV community about the time taken to “discover” the Flamer code, I am not aware of anyone claiming that it infected systems which were protected to currently accepted information security standards.
Consider this: one recent study found that over 90 percent of security breaches could have been prevented with simple, cheap, or intermediate measures. That’s good news for companies and consumers who might otherwise be spooked by media hype about sophisticated new malware attacks; do the work to properly protect your systems and you have a high probability of defeating those attacks.
David Harley Says:
My article at http://scmagazine.com/w32flamer-detection-failure-the-real-lesson/article/244107/ is kind of relevant to this one: in fact, I cited your final paragraph. 🙂 I was starting out, though, from the claims that Flamer signifies the end of signature detection (in the sense of exact or near-exact identification. In fact, the opposite is true: the problem is that those techniques don’t work till you have a sample from which to capture the range(s) of constant bytes. But that was just as much the case in the 1980s as it is now.