[cabfpub] Flame attack used new variant of MD5 chosen-prefix collision

Benjamin T. Wilson ben at digicert.com
Thu Jun 7 19:43:41 UTC 2012

Another account-

Bride of Stuxnet

Webcraft as spycraft.

Jun 11, 2012, Vol. 17, No. 37	 • By JONATHAN V. LAST

Last April, the Iranian Oil Ministry and the National Iranian Oil Company noticed a problem with some of their computers: A small number of machines were spontaneously erasing themselves. Spooked by the recent Stuxnet attack, which had wrecked centrifuges in their nuclear labs, the Iranians suspected a piece of computer malware was to blame. They went to the United Nations’ International Telecommunications Union and asked for help. After an initial investigation, it was determined that the Iranians had been hit with a new piece of malicious software; it was temporarily labeled Wiper. Or Viper. After translating the moniker into different languages, no one is quite sure what the original nickname was.


The experts from Turtle Bay quickly realized they were out of their depth with Wiper/Viper and contracted a Russian computer security firm, Kaspersky Lab, to help. As the techs at Kaspersky investigated, they began to find bits and pieces of a much bigger program. What they eventually uncovered forced them to put aside Wiper/Viper and send out an all-hands call to the tech community: a cyber-weapon that made Stuxnet look primitive. They called it Flame.

Stuxnet was like a guided missile with a targeted payload. It was created to spread rapidly, but always to be seeking a particular set of computers​—​machines made by Siemens and used to control centrifuge operations at a uranium enrichment plant. Once Stuxnet reached its destination, it had very precise instructions: It altered the speed of the centrifuges in such a manner as to slowly degrade the equipment and destroy the uranium they contained​—​all while sending false readings back to the operating console so that neither the computer nor the human supervisors would notice the damage being done.

If Stuxnet was like a missile, then Flame is more like a surveillance satellite.

Once a computer is infected by Flame, the program begins a process of taking over the entire machine. Flame records every keystroke by the user, creating a perfect log of all activity. It takes pictures of the screen every 60 seconds​—​and every 15 seconds when instant message or email programs are in use. It records all administrative action on the computer​—​taking note of network passwords, for instance. And it rummages through the computer’s hard drive copying documents and files.

But that’s not all. Flame also takes control of the machine’s Bluetooth capability and turns it into a hub for a small wireless network, bonding with other Bluetooth-enabled devices in the vicinity, such as cell phones. It then uses the Bluetooth connection to case whatever information is on the remote device​—​say, an address book, calendar, or email list. Most spectacularly, Flame is able to turn on the computer’s built-in microphone and record the user, or anyone else who happens to be chatting in the vicinity.

Flame then compiles all of this information​—​the passwords, the documents, the keystroke logs, the screenshots, and the audio recordings​—​encrypts it, and secretly uploads it to a command-and-control server (C&C), where someone is waiting to analyze it.

The first thing the white hats noticed about Flame was its size. Most malware is designed to be tiny​—​the smaller the package of code, the harder it is for your computer’s constantly updating security protocols to intercept it. It took half a megabyte of code to build Stuxnet, which was a remarkably large footprint by the standards of malware. When completely deployed, Flame takes up 20 megabytes. Which is positively gargantuan.

But Flame is deployed in stages. When it works its way onto a new machine, Flame comes in an initial package of six megabytes. After the worm takes control of the box, it inventories the machine and the surrounding networks, and then begins communicating with a remote C&C  server. On the other end of the line, a team takes in the data being sent by Flame, makes a determination of the new host’s value, and then returns instructions to the waiting worm. Depending on what the C&C team see, they might instruct Flame to install any of 14 additional modules​—​mini add-on programs which, for instance, would give Flame the ability to take over the computer’s microphone, or Bluetooth functionality. One module, named “browse32,” is a kill module.  When activated by the C&C, browse32 systematically moves through the computer, deleting every trace of Flame’s existence. Its wipe is so thorough that once it’s been triggered, no one​—​not even computer security techs​—​can tell if Flame was ever there in the first place.

No one is sure how long Flame has been operational. There is evidence of its existence in the wild dating to March 2010, but Flame may be older than that. (Stuxnet was discovered in June 2010 and is believed to have been released 12 months before then.) It’s difficult to date Flame because its makers went to some trouble to disguise its age. Computer code typically has meta-data describing its “compilation date”​—​that is, the time and date it was assembled in final form. Flame’s 20 modules all have compilation dates set in 1994 and 1995. Which is impossible, because they’re written in a language that was released just a few years  ago.

Neither are analysts certain exactly how Flame spreads. It has the ability to move from one computer to another by piggybacking onto a USB flash drive (just like Stuxnet). Alternately, it can migrate across a local network by exploiting a shared printer (again, like Stuxnet). But Flame is also able to spread across a network without a printer if it finds itself on a computer that has administrative privileges. When that happens, the worm is smart enough to create backdoor accounts for all the other computers on the network and copy itself into those machines.

As for the question of security​—​how does Flame talk its way past the computer’s antivirus protections? No one knows. The techs at Kaspersky Lab watched Flame attack a PC running the fully updated Windows 7 security suite. The worm took over the computer effortlessly. This suggests that the worm’s designers have access to one or more vulnerabilities in the operating system that even the people who designed the OS don’t know about. (Stuxnet utilized four of these so-called zero-day exploits.)

Engineers are only two weeks into the teardown, but they already believe that Flame and Stuxnet were created by different development teams. The code and workings are dissimilar. And besides, the timelines on the two projects are too close. It is estimated that coding Stuxnet required 10,000 man-hours. For a team of 30 to 50 programmers, that’s a year or two of work. The same squad simply would not have had the time to build both Stuxnet and the much larger Flame.

That said, Kaspersky Lab notes that the worms do share two interesting similarities: They use the same rootkit-based exploit to hijack USB drives and the same print-spooler vulnerability to spread over a network’s shared printer. There are three possible explanations for this: (1) The teams that developed Flame and Stuxnet discovered these identical mechanisms independently; (2) the team which developed  Flame learned about them from analyzing an early version of Stuxnet; (3) the teams that developed the two worms were working in parallel, for the same organization(s), and thus were able to share information about these mechanisms.

Yet the most interesting aspect of Flame is the strategic ways it differs from Stuxnet. As a weapon, Stuxnet was a tool conceived in urgency. Every piece of malware has to balance virulence with stealth. The more aggressively a worm propagates, the more likely it is to be caught. Stuxnet was designed to spread at a fairly robust rate. Its  creators wanted it to get on lots of different computers and they were willing to risk quicker discovery on the chance that the worm would find its way to the very specific system it was meant for and deliver its payload. In the end, Stuxnet’s engineers made a good trade. Because it eventually spread to 100,000 computers, Stuxnet was caught reasonably quickly. Yet this aggressive approach got it to its target​—​Iran’s Natanz refinery​—​where it wrecked at least a year’s worth of work.

Flame, on the other hand, is a study in stealth and patience. Unlike Stuxnet, with its single-minded search for a specific computer system, Flame seems to have wandered in many directions: onto computers used by governments, universities, and private companies. It moved slowly, and the overall number of infected systems seems to be quite low. Current estimates put it at 1,000 computers, nearly all of them located in Iran,  the Palestinian territories, Sudan, Syria, and Lebanon. Flame kept the number of infections low because it never moved from one computer to another without explicit instructions from its C&C. According to Kaspersky Lab, the method went something like this:

[T]hey infect several dozen [machines], then conduct analysis of the data of the victim, [and] uninstall Flame from the systems that aren’t interesting, leaving the most important ones in place. After which they start a new series of infections.

It was a detailed, deliberate process of identifying and exploiting targets that must have required significant manpower and intelligence capability on the C&C side. In other words, the design and deployment of Flame was only half of the job. Another team, with a different skill set, was needed to run the operation once it was in the field.

But once Flame was running, it was like something out of science fiction. Flame could watch a target even when he was completely alone. It could listen to every word he said on the telephone, or through Skype, or to a colleague walking past his desk. It could rifle through his computer files and find any document. Or peek into a cell phone sitting in someone’s pocket in the next room. It never had to worry about getting caught in the act. And on a moment’s notice, it could erase any sign that it was ever there. It kept up constant communication with its handlers, even when they were thousands of miles away, and it always followed orders.

Whoever engineered Flame didn’t just build the most spectacular computer worm ever made. They created the perfect spy.

Jonathan V. Last is a senior writer at The Weekly Standard.

Sent from my iPhone

On Jun 7, 2012, at 11:24 AM, "Hill, Brad" <bhill at paypal-inc.com> wrote:

> http://www.cwi.nl/news/2012/cwi-cryptanalist-discovers-new-cryptographic-attack-variant-in-flame-spy-malware
> I believe this would be a good place to follow public cryptanalytic research on the Flame MD5 collision attack and whether it has implications for pre-image resistance.   I would be surprised if there is much additional news before Gjovik, given the pace at which such research typically progresses. 
> Brad Hill
> Internet Standards and Governance
> PayPal Information Risk Management
> cell: 206.245.7844 / skype: hillbrad
> email: bhill at paypal-inc.com
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> http://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20120607/e6295b23/attachment-0004.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5275 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20120607/e6295b23/attachment-0002.p7s>

More information about the Public mailing list