Video Screencast Help
Security Response

W32.Flamer: Microsoft Windows Update Man-in-the-Middle

Created: 04 Jun 2012 18:16:23 GMT • Updated: 23 Jan 2014 18:14:57 GMT • Translations available: 日本語
Symantec Security Response's picture
+2 2 Votes
Login to vote

Flamer has a variety of ways of spreading on the local network. One of the methods is to hijack clients performing Windows Update. Three Flamer apps are involved in delivering the rogue update: SNACK, MUNCH, and GADGET.

When Internet Explorer starts, by default it will automatically search for proxy configuration settings. This happens through the Web Proxy Auto-Discovery Protocol (WPAD). Internet Explorer will attempt to retrieve proxy settings (wpad.dat) based on the computer's domain name. For example, if the computer is computerA.group.company.com, Internet Explorer will request wpad.dat from:

  • wpad.group.company.com
  • wpad.company.com

Typically, resolution of these domain names will go to the DNS server. However, if the DNS server does not have records registered, Internet Explorer will also use WINS or NetBIOS for name resolution.

NetBIOS name resolution allows computers to find each other on a local network in a peer-to-peer fashion without a central server. Each computer simply broadcasts its own name to identify itself. Obviously, this is not secure and this is how computers can spoof each other.

SNACK performs a variety of functions, including sniffing NetBIOS requests on the local network. When clients attempt to resolve a computer name on the network, and in particular make WPAD requests, Flamer will claim it is the WPAD server and provide a rogue WPAD configuration file (wpad.dat). NetBIOS WPAD hijacking is a well-known technique and many publicly available hack tools have implemented the technique.

Once a computer that has not yet been compromised receives the rogue wpad.dat file, it will set its proxy server to the Flamer-compromised computer. All its web traffic will now be redirected to the Flamer compromised computer first.

MUNCH is a Web server within Flamer and receives the redirected traffic. MUNCH checks for a variety of queries, including matching URLs for Windows Update.

Hijacking Windows Update is not trivial because updates must be signed by Microsoft. However, Flamer bypasses this restriction by using a certificate that chains to the Microsoft Root Authority and improperly allows code signing. So when a Windows Update request is received, the GADGET module through MUNCH provides a binary signed by a certificate that appears to belong to Microsoft.

The binary is downloaded by the uninfected computer as if it is a legitimate Windows Update file and is executed. The binary is not Flamer itself, but a loader for Flamer. One sample of this binary refers to itself as TumblerEXE.exe.

Tumbler first performs some checks on the network interfaces and system information, including installed security products.

Next, Tumbler contacts the Flamer-compromised computer through HTTP with a URL in this form:

[http://]MSHOME-<STRING>/view.php?mp=1&jz=<STRING>&fd=<STRING>&am=<STRING>&ef=<STRING>&pr=<STRING>&ec=<STRING>&ov=<STRING>&dd=<STRING>

The MUNCH app of a Flamer-compromised computer then replies with itself (mssecmgr.ocx) and Tumbler saves this as %Windir%\temp\~ZFF042.tmp and executes it. This filename may be different in different samples.

Once executed, the computer becomes compromised with Flamer.
 

  1. Clients make WPAD requests through NetBIOS
  2. Flamer spoofs a WPAD configuration file response setting the proxy on the requesting computer
  3. Clients make Windows Update requests that are redirected to Flamer
  4. Flamer responds with a signed binary, Tumbler
  5. Tumbler downloads and installs Flamer