Flame Malware Code Traced To Stuxnet

Did the U.S. government commission the recently discovered Flame malware? According to new research, the developers of the Stuxnet and Flame malware families crossed paths--swapping source code at least once--which suggests that the U.S. government didn't just commission Stuxnet, but Flame as well.

"In 2009, part of the code from the Flame platform was used in Stuxnet," said Alex Gostev, the chief malware researcher at Kaspersky Lab, Monday in a blog post. "We believe that source code was used, rather than complete binary modules," he said, which suggests some degree of collaboration or crossover.

But based on Kaspersky's ongoing teardowns of the Flame malware discovered in late May, he believes that "since 2010, the platforms have been developing independently from each other, although there has been interaction at least at the level of exploiting the same vulnerabilities."

According to published news reports, senior White House officials have said that the the United States led Stuxnet development, working with Israel. Hence if Stuxnet and Flame are related, it suggests that the United States is also behind the complex Flame malware.

[ Learn more about the links; read Flame Malware's Ties To Stuxnet, Duqu: Details Emerge. ]

That Stuxnet credit-taking--read by some as election-year boasting and by others as a direct warning to Iran--has led to charges that government officials mishandled classified information, although many security experts said all signs clearly pointed to the two governments having been behind Stuxnet and the related malware Duqu. Now add Flame to that equation.

But Gostev said there appear to have been different development groups behind the two malware families--each working independently since 2007 or 2008--which he refers to as "Team F" (for Flame) and "Team T" (for Tilded, which is the platform on which Stuxnet and Duqu were built).

"Flame and Tilded are completely different projects based on different architectures and each with their own distinct characteristics," he said. "For instance, Flame never uses system drivers, while Stuxnet and Duqu's main method of loading modules for execution is via a kernel driver."

According to Kaspersky Lab, Stuxnet appears to have been created in the first half of 2009, while Flame had been created by the summer of 2008. "The Stuxnet code of 2009 used a module built on the Flame platform, probably created specifically to operate as part of Stuxnet," said Gostev. That module, which he suspects exploited a then-unknown--a.k.a. zero-day--Windows kernel vulnerability later patched by Microsoft, was apparently removed in 2010. Its removal was likely prompted by Stuxnet's developers having created a new way to allow their malware to propagate, by exploiting a then-unknown Windows shell vulnerability, later patched by Microsoft.

While the two groups of malware developers appear to have shared code, "after 2009, the evolution of the Flame platform continued independently from Stuxnet," said Gostev.

Flame includes numerous attack capabilities, including the ability to spread via Windows Update by using a spoofed digital certificate. As a result, the malware can automatically install itself on targeted computers, providing another computer on the same network had first been compromised.

But Microsoft has been working quickly to patch the certificate bug exploited by Flame. Notably, Microsoft released an update Friday for Windows Server Update Services (WSUS) 3.0 Service Pack 2 (SP2), which according to the release notes "strengthens the WSUS communication channels ... [by] trusting only files that are issued by the Microsoft Update certification authority."

Microsoft is also set to issue an update Tuesday--as part of its monthly Patch Tuesday--that will further update all supported versions of Windows to block Flame. Security experts are recommending that all users install the update as soon as possible, since attackers will likely attempt to use the certificate vulnerability before it becomes widely patched. "Apply the certificate patch released a week ago today if you haven't done so already," said SANS Institute chief research officer Johannes B. Ullrich in a blog post. "This way, no patch signed by the bad certificate should be accepted tomorrow. Patch Tuesday is one of the best dates to launch such an attack, as you do expect patches anyway."

When installing the update, however, do so preferably only if using a trusted environment. "Avoid patches while 'on the road.' Apply them in your home [or] work network whenever possible," said Ullrich. "This doesn't eliminate the chance of a 'man in the middle' (MitM) attack, but it reduces the likelihood."

For users who must update while on the road, perhaps because they travel frequently, always use a VPN connection back to the corporate network, said Ullrich, since hotel networks can be malware and attack hotbeds. "Hotel networks and public hotspots frequently use badly configured HTTP proxies that can be compromised and many users expect bad SSL certificates--because of ongoing MitM attacks," he said.

Employees and their browsers might be the weak link in your security plan. The new, all-digital Endpoint Insecurity Dark Reading supplement shows how to strengthen them. (Free registration required.)