Whenever a new example of malware is discovered and becomes the hot topic of the security world, it's always perceived...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
to be unique and more advanced compared to other malware, even when reality differs from the perception.
Enterprises, understandably, find it difficult to wade through the hype surrounding new malware to determine if it poses any real threat. With its similarities to the infamous Stuxnet malware toolkit, the recent discovery of the Flame malware toolkit has invoked plenty of discussion regarding the unique methods it employs. While it has proven to be a significant threat, the truth is much of Flame's functionality has been used before in other malware.
In this tip, we'll provide an analysis of the Flame malware in order to understand if it really is as unique as some experts have claimed. We'll also discuss how enterprises can ensure they have the appropriate protections in place to guard against the attack methods used by Flame, including fraudulent certificates.
In-depth Flame malware analysis has been conducted by the Laboratory of Cryptography and System Security (CrySyS Lab) at the Budapest University of Technology and Economics and by vendor Kaspersky Lab, among others. Most of the techniques used by Flame are not new, but some of the functionally used indicated its authors had significant expertise that is rarely found in general malware. With a reported size of around 20 MB, Flame is larger than most malware samples, but this is most likely a result of the shared libraries it uses. The use of shared libraries could be a sign that professional software development practices were used for Flame's development; software developers typically reuse code to reduce the effort to develop new malware.
Though Microsoft has since fixed the vulnerabilities that Flame exploited, this development brings the security of all Windows updates and Microsoft software into question.
Flame infiltrated systems via USB drives and used some of the same exploits as Stuxnet and Duqu. These exploits could have been bought on the black market from a black hat vulnerability or exploit researcher or developed by the organization responsible for the malware. Flame was used for targeted attacks, so it is also possible that it infected systems through physical break-ins.
The most unique and concerning component is its ability to hijack Windows Update. Though Microsoft has since fixed the vulnerabilities that Flame exploited, this development brings the security of all Windows updates and Microsoft software into question. Flame used a fraudulent certificate that it generated through an MD5 collision with an insecure Microsoft Terminal Services certificate. That, in turn, allowed a fraudulent CA to be created that closely resembled a Microsoft CA. It didn't spoof other CAs. This is concerning because enterprises have taken a long time to trust Microsoft updates and depend on the Microsoft update ecosystem being secure. It isn't overly important that the data for updates is encrypted, but a trusted CA must sign it to ensure the system's integrity. Ultimately, it remains to be seen whether Microsoft can successfully defend against this tactic should it be employed by future malware.
Though it has been in use for several years, Flame is reported to have infected few machines in comparison to most malware and only targets specific individuals and organizations in the Middle East, particularly Iran and Northern Africa. This means Flame poses little risk to most enterprises, but because it uses known attack methods, enterprises must still be prepared for future attacks that use elements of Flame.
Preparing for Flame-style attacks
Most enterprises will never need protection from Flame because it is a highly targeted piece of malware. This does not mean that the lessons of Flame can be ignored completely. Enterprises need to be prepared for future targeted malware campaigns that incorporate similar functionality. Several safeguards that enterprises can deploy would protect against the various Flame attack methods.
From the editors: More on cyberweapons
Prepare for Stuxnet malware-style attacks and collateral damage as a result of cyberwar
Learn to defend against the Duqu Trojan
To protect against the use of fraudulent certificates, enterprises can use whitelisting or only use specified CAs and trusted patches. For example, if an enterprise were to push all patches through a centralized infrastructure using software signed by the enterprise, and if the clients were configured to only trust the internally signed software, it would be protected against Flame. Disabling the print spooler service and functionality would have stopped Flame's print spooler exploit.
Businesses can also monitor their systems closely and configure alerts to trigger whenever new files are found or executed on a system or when suspicious network traffic is identified. Suspicious network traffic includes any outgoing connections to new external IPs or DNS lookups for new domain names. Such analysis can be time consuming but could potentially be automated.
Listen to this tip
as an MP3!
Listen to Flame malware analysis: How to defend against fraudulent certificates as an MP3.
Average malware authors may not be able to include an attack technique as complex as the fraudulent certificates, but as they become more professional, malware authors will adopt the techniques used for professional software development to give their attacks a decidedly more sophisticated element. They may even use malware toolkits that automate the process and incorporate advanced techniques.
Possible professional features that could be brought include making software modular with automatic updates and using encrypted connections and a distributed architecture. The MD5 collision required advanced methods to generate the fraudulent certificate because of the timing of the attack. By using the Hashclash tool, the authors could reuse some of Flame's code as described in the MD5 collision presentation.
Despite a lot of unnecessary hype surrounding newly discovered malware, enterprises shouldn't ignore malware research findings. Malware that uses a new class of vulnerabilities and attacks many systems might require an immediate response, though admittedly malware that recycles old attack methods might require little or no response to current security procedures.
Flame brought together many different exploit techniques to target specific organizations and individuals. As details about Flame's methods have become public, some of the techniques might be reused by malware authors, but most were already publically known and have been used in other toolkits. Though most enterprises will never be targeted by Flame, using the details from Flame in a CSIRT tabletop exercise would be useful for many enterprises.
About the author:
Nick Lewis (CISSP) is an information security architect at Saint Louis University. Nick received his Master of Science in Information Assurance from Norwich University in 2005 and Telecommunications from Michigan State University in 2002. Prior to joining Saint Louis University in 2011, Nick worked at the University of Michigan and previously at Children's Hospital Boston, the primary pediatric teaching hospital of Harvard Medical School, as well as for Internet2 and Michigan State University.