According to the report, parts of Duqu are nearly identical to Stuxnet, but with a completely different purpose as analyzed by the lab and confirmed by Symantec. Some of the similarities include the use of a driver in one of the variants that used a valid digital certificate that expires August 2, 2012 from a company headquarted in Taipei, Taiwan (same as the Realtek and JMicron certs used with the original Stuxnet). This cert was revoked on October 14, 2011.
The following figure (published by Symantec) provides some good comparisons between Stuxnet and Duqu:
 |
| Courtesy Symantec |
The malware is designed as a remote access Trojan (RAT) used to gather data intelligence from various entities including ICS manufacturers. The code appears to be looking for information such as design documents that could be used to launch a future attack against a facility under the control of an ICS - including electric generation, water/wasterwater treatment, oil and gas production/distribution/refining, chemical/petrochemical processing, transportation systems, and building automation systems (just about any major building in the world!). Interesting ... all along I have postulated that the easiest way to attack a manufacturing site is to compromise the site of their ICS vendor! My theory has been confirmed!
Duqu uses HTTP and HTTPS to communicate with a command-and-control (C&C) server, that if you have seen my newest demonstration, is very easy through any enterprise gateway that does not utilize a proxy server. Duqu uses a custom C&C protocol which should be relatively easy to identify via an IDS/IPS once signatures are released. Interesting enough ... it is set to expire after just 36 days and remove itself from the system - another very powerful feature of the original Stuxnet code. This means that if you happened to be attacked in the early phases of this malware (estimated at December 2010), then the information has been collected and you did not detect the breach!
As you may recall, Anonymous reverse engineered and published a large quantity of the Stuxnet code after breaching the networks of security consultant HB Gary. For this reason, I wonder if the statement in the report that "the threat was written by the same authors ... and appears to have been created since the last Stuxnet file was discovered". With easy access to the source code, the actual author of the varients could be very hard to trace!
The code does not appear to be self-replicated at this point. However, people should be aware that it appears that other variants of the code exist and could be targeting other sites. This is also an interesting point, since the code that I was able to obtain from Anonymous lacked some of the code necessary for the initial infection and some propagation methods. I wonder if the authors intentionally omitted the self-replication code, or that they were unaware that some of these settings were deactivated via a setting in one of the configuration files.
If you recall, the original Stuxnet code contained a data file which kept track of each infection point, effectively producing a network "map" of how to penetrate and propagate within a multi-tier, segmented network architecture. This is why I was most alarmed when I found out that even though 40% of the critical infrastructure providers discovered Stuxnet in their environments, only 57% launched special security audits or other measures in response to the breach. These companies must have had some bad advice, because they should have known that a data file was created and communicated with other nodes that provided a roadmap of sorts on how each host was compromised.
This is obviously going to generate a lot of renewed interested in ICS security ... but I have to say that I am glad it has happened. In the months following the discovery of Stuxnet, many so-called security experts went on record saying that this could never be re-used or re-engineered. Since I focus entirely on ICS/SCADA security, and also having done a great deal of research into Stuxnet, I knew all along that it would be rather easy to modify the code to target just about any control system of your choosing.
I will try to keep up to date on these activities, and am now very excited about what DHS and ICS-CERT has to say about this next week at the Fall ICSJWG conference. Obviously, in their ICS-ALERT posted yesterday, their mitigations appear weak and ineffective. They need to read the paper I co-authored on "How Stuxnet Spreads" to see that none of these three mitigation strategies would work against Stuxnet in a typical ICS environment, which leads me to my next blog which I hope to publish later this week.
References:
- Symantec Blog: W32.Duqu: The Precursor to the Next Stuxnet
- Symantec Report: W32.Duqu: The Precursor to the Next Stuxnet
- ICS-ALERT-11-291-01A - W32.Duqu Malware Targeting ICS Manufacturers
- Homeland Security News Wire: A Precursor to the Next Stuxnet Discovered
- White Paper: "How Stuxnet Spreads: A Study of Infection Paths in Best Practice Systems"
- SCADAhacker Stuxnet Reference Material
Joel, both Mikko Hyponnen and Ralph Langner have said that the Stuxnet source code has never been released into the wild. Therefore, regardless of the reverse engineering of Stuxnet by Anonymous, the authors of DuQu apparently didn't use that , which gives credence to the suspicion that they are the same people who created Stuxnet. Any thoughts about that?
ReplyDeletehi jeol, this is a very scary post, i must know how things turned out. thanks for posting!
ReplyDeleteClever, too clever for script kiddies. Wonder what kind of creepy crawlies they inject into the financial systems to glean data and rig trades. This site helps me to my thesis writing on this theme. This is likely only the tip of the iceberg, what lurks below?
ReplyDelete