Stuxnet's Earliest Known Version Discovered and Analyzed 77
An anonymous reader writes "Symantec researchers have discovered an older version of the infamous Stuxnet worm that caused the disruption at Iran's nuclear facility in Natanz: Stuxnet 0.5. According to a whitepaper released by the researchers at RSA Conference 2013, Stuxnet 0.5 has first been detected in the wild in 2007 when someone submitted it to the VirusTotal malware scanning service, but has been in development as early as November 2005. Unlike Stuxnet versions 1.x that disrupted the functioning of the uranium enrichment plant by making centrifuges spin too fast or too slow, this one was meant to do so by closing valves."
Re:State sponsored (Score:0, Informative)
Who has the knowledge (or will) to write a program to disrupt centrifuges.
Anyone willing to search the Internet for the info? Are you really so naive to think that only governments or their agents have this info?
Re:State sponsored (Score:2, Informative)
I... am not 'wholly certain' that your assessment is accurate -- although I concur it appears to be the most probable.
While the equipment to refine Uranium is pretty ... restricted, and I've never programmed a centrifuge -- I have programmed SCADA.
As one of the relatively few actual programmers to do so -- there's still a pretty decent community.
It's relatively uncommon, but not impossible to find or recruit such skill. Frankly, exploiting pretty much any SCADA system is... absolutely trivial if you actually understand software and what they do -- instead of being just a glorified "configuration programmer" (and even some of those guys stumble onto things by mistake)
Like hacking webservers circa 1998 trivial, when early vhost compromises infected hundreds of pages at a time and attrition just... gave up on page mirroring.
The hard "part" is basically two things:
- Only a person working on a specific system knows how to reliably exploit (although not crash quite often) it and related ones (e.g. a specific valve controller, model)
- Alternately, people researching some system may discover a class of exploit specific a vendor and go looking for those.
- And lots of these are on what amounts to a NAT'd off internet.
Given a known system as a target -- the hard part as an outsider is gaining access to the configuration, manuals, instructions -- the vendors don't like to just ship you "Here's the manual for controller 3805b, revision 1.34b" (and when you can get the manual, they are /often/ that good, with signing history, versions annotated, tables indicating what changed in what revision). They don't even like to ship to people that are legitimate most of the time. If you're a contractor of a customer they'll often outright refuse unless there was a prior agreement. If you're a customer, they'll try to use it to upsell consulting. But you can eventually get one with the right pens on the right letterhead. The SCADA vendors do absolutely horribly weird, bizarre things with their protocols, register layouts, and data -- but they do seem to track it well.
That stated -- with purchase of a piece of hardware (may cost $2,000 to hundreds of thousands or millions), or careful google searching -- you can often find... enough to talk to the device. To query some basic settings, or switch between classes of operation. Sort of like a printer, you know how to hit the button to change the paper trays, but you don't know how to reprogram the size in tray #4 and only let "bob" use it without a pin #.
Knowing the probable configuration is something any sort of decent process engineer could guess at with high accuracy. Obtaining the relevant manuals is something a relatively small (but still large within its community) is fairly likely to have.
I'd say you can very confidently conclude it was a long term (nevermind the observed duration) effort with a minimal team of at least three individuals, or one "forty years of experience" software-and-domain-specific expert that frankly has better things to do.
Nobody but a psychopath or a government has the incentive to do such a thing, but completely ruling an individual or group of individuals out is not reasonably guaranteed correct.
Most of the items you indicate need to be known up front are issues of configuration that could be authored in advance.