To recap the current state of things for those who might still be getting up to speed -- During the last week of May, 2012, in two separate investigations, F-Secure and the Iranian CERTCC discovered a new, highly sophisticated worm, which we now know colloquially as Flame. What Flame does it and generally how it does it is an entirely different discussion, and we'll not dig into that here, except to discuss one particular issue which was discovered and reported by F-Secure on Monday, June 4, and analyze the lessons to be learned that we all can apply to our own security mechanisms. (A detailed explanation of Flame is available from a number of sources, including Securelist and TWIT's Security Now May 30th podcast.

 

In short, Flame exploits a defect in the Microsoft Terminal Server Licensing Services application that generates licensing certificates for Terminal Services clients.  The certificate template, it appears, was configured to allow a code-signing certificate to be created. These certificates all derive from the Microsoft Root Authority. And, as F-Secure correctly points out, a code-signing certificate from a Microsoft CA is the keys to the kingdom to being able to compromise the Windows Update Agent.

 

The replication of the worm then leverages this defect along with a couple of other weaknesses in Windows components. First, a man-in-the-middle attack using a spoofed Web Proxy Auto-Discovery (WPAD) Protocol service to intercept client requests to the Windows Update service was used to insert a downloader file onto an unsuspecting client system, and second, insufficient verification of the authenticity of the downloaded file on the part of the Windows Update Agent, thus allowing it to be infected. In this manner a single infected Flame system can replicate throughout an entire organization in about 22 hours (since every online Windows system will queries Windows Update at least once every 22 hours).

 

Now, to date, the industry has published information on how the replication occurs, but one key question still remains unanswered -- How does the original client get infected in an organization. There must be other non-WU oriented replication mechanisms, so we'll be looking for more information on what else this malware exploits as the investigations proceed. Passing by that missing information for the moment, let's look at a number of mitigation steps an organization can take, in general, but also with respect to this specific threat.

 

First, a couple of lessons we learn from Microsoft:

  • Make sure your certificates are only created for exactly the purpose they are intended to serve. For example, a licensing certificate should not ever have had code-signing capabilities! Truly the root cause of much of this fiasco is the improperly configured certificate template in Microsoft's Terminal Services Licensing Server. (It should also be noted that this flaw has been repaired.)
  • Second, isolate your certificate chains of authority so they do not have cross-over privileges between different security domains. There are two flaws in this issue that contributed. First, Microsoft did not isolate the certificate chain between those which must be created by a trusted Microsoft entity (i.e. a Microsoft employee), and those which can be created by an end-user (i.e. a user of Terminal Services who needs to license a TS client). The other is that the Windows Update Agent was configured to trust ALL Microsoft certificates. This is also being remediated, with a forthcoming  update to the Windows Update Agent that will trust only a certificate chain expressly created for only the Windows Update infrastructure.

 

Another contributing factor here is that WPAD is enabled, by default, on Windows systems. Use Group Policy to explicitly configure your organization's proxy configuration (if you require a proxy server for Internet access), or DISABLE this functionality completely if a proxy server is not required. Grant Bugher, CISSP, CSSLP, wrote a great blog post over four years ago about locking down WPAD -- specifically calling out this very type of man-in-the-middle attack as a risk where WPAD was improperly enabled.

 

Finally, using Windows Update as an organizational patching mechanism is a contributing factor. If clients were using a corporate managed patching infrastructure, such as WSUS, the clients would not be looking to go through a proxy server to get updates, they would be connecting locally to a WSUS server. Since the Flame malware expressly traps connection requests going to Windows Update, I believe this risk would be completely mitigated -- although I have not personally inspected the code.

 

So, to summarize:

     1. Use and configure certificates only for the specific purpose for which they are needed.

     2. Maintain separate certificate authority chains within separate security domains.

     3. Disable automatic configuration services -- particularly those that configure functionality you're not using.

     4. Implement a centralized patch management system -- and use it to immediately apply KB2718704 which revokes the compromised Microsoft certificate chain.