Flame’s Replication via Windows Update MITM proxy server

Posted: June 8, 2012 in Analysis, Vulnerabilities

The Flame malware uses several methods to replicate itself. The most interesting one is the use of the Microsoft Windows Update service. This is implemented in Flame’s “SNACK”, “MUNCH” and “GADGET” modules. Being parts of Flame, these modules are easily reconfigurable. The behavior of these modules is controlled by Flame’s global registry, the database that contains thousands of configuration options.

SNACK: NBNS spoofing

The SNACK module creates a RAW network socket for either all or pre-set network interfaces and begins receiving all network packets. It looks for NBNS packets of other machines looking for local network names. When such a packet is received, it is written to an encrypted log file (“%windir%\temp\~DEB93D.tmp”) and passed on for further processing.

When a name in the NBNS request matches the expression “wpad*” or “MSHOME-F3BE293C”, it responds with its own IP address. If “SNACK.USE_ATTACK_LIST” variable is set to “True”, it also checks whether packets originate from IP addresses specified in its “SNACK.ATTACK_LIST” and responds to machines with these addresses.

“Wpad” is a name used for automatic proxy detection. By responding to “wpad” name requests with its own IP address, the SNACK module announces the infected machine as a proxy server for its local network.

SNACK and MUNCH also communicate with the GADGET unit that provides facilities for handling different events that come from other modules. The Flame’s registry contains LUA modules for processing events like “MUNCH_ATTACKED”, “SNACK_ENTITY.ATTACK_NOW”.

MUNCH: Spoofing proxy detection and Windows Update request

“MUNCH” is the name of the HTTP server module in Flame. It is started only if “MUNCH.SHOULD_RUN” variable is set to “True” and there are no running programs that can alert the victim. These programs (anti-virus, firewalls, network sniffers etc.) are defined in the Flame’s registry in a list called “SECURITY.BAD_PROGRAMS”

When MUNCH is started, it reads a buffer from the “MUNCH.WPAD_DATA” variable, replaces the pattern “%%DEFAULT%%” with the IP address of its best suitable network interface and waits for HTTP requests.

Contents of the “MUNCH.WPAD_DATA” variable

The “MUNCH.WPAD_DATA” buffer is actually a WPAD file that is requested by network clients that implement automatic proxy server detection. The code in the WPAD file matches the MD5 hash of the hostname that the client is connecting to against its own list, and if found, offers itself as a HTTP proxy. We were able to identify some of the hashes:


So, when a machine configured with automatic proxy detection tries to access one of the Windows Update hosts, it receives an IP address of the infected machine from SNACK, and then receives the IP address of the same machine as a proxy server from “wpad.dat” provided by MUNCH. From then, requests to the Windows Update service are passed through the MUNCH server.

When a network client connects to the MUNCH server and requests an URI other than “/wpad.dat” and “/ view.php”, the server :

1) Runs “MUNCH.SHOULD_ATTACK_SCRIPT” – Lua script that checks if the User-Agent header matches at least one of the patterns specified in “MUNCH.USER_AGENTS.CAB_PATTERN_*”. The Flame registry files that we have contained the following patterns:

MUNCH.USER_AGENTS.CAB_PATTERN_4 : WinHttp%-Autoproxy%-Service.*
MUNCH.USER_AGENTS.CAB_PATTERN_3 : Windows%-Update%-Agent.*

2) Checks if the requested URI matches any pattern specified in the list of strings called “MUNCH.GENERIC_BUFFERS.*.data.PATTERN”. If one of the expressions match, it then gets the buffer specified in the corresponding “MUNCH.GENERIC_BUFFERS.*.data.FILE_DATA” value, reads the payload value called “MUNCH.GENERIC_BUFFERS_CONTENT.value_of_FILE_DATA” and sends it to the client.

All the payloads are listed in the Flame’s registry with names starting with “MUNCH.GENERIC_BUFFERS_CONTENT.payload_name”, and are encoded with a fixed 104-byte RC4 key.

URI pattern Payload name
*update.microsoft.com/v6/windowsupdate/selfupdate/wuident.cab* XP_WUIDENT
*v5/redir/wuredir.cab* XP_WUREDIR
*muauth.cab* MUAUTH
*muredir.cab* MUREDIR
*muident.cab* MUIDENT
*/version_s.xml VISTA_7_VERSION_S
*/version.xml VISTA_7_VERSION
*/windowsupdate/?/?elf?pdate/WSUS3/x86/Vista/WuSetupHandler.cab* VISTA_7_WUSETUPHANDLER
*/windowsupdate/?/?elf?pdate/WSUS3/x86/Vista/WUClient-SelfUpdate-ActiveX~31bf3856ad364e35~x86~~7.0.6000.381.cab* VISTA_7_WUCLIENT
*/windowsupdate/?/?elf?pdate/WSUS3/x86/Vista/wsus3setup.cab* VISTA_7_WSUS3SETUP
*v9/windowsupdate/selfupdate/wuident.cab* VISTA_7_WUIDENT

Most of the payloads are signed CAB archives. The archives that contain malicious code are signed by “MS” in Dec 2010 and Nov 2011 while other archives seem to originate from the genuine Windows Update service and are signed by “Microsoft Corporation”.

Payload names Contents Signed
WUREDIR VISTA_7_WUREDIR wuredir.xml Microsoft Corporation July 01, 2009
WUSETUP Default/wuapplet2.ocx
November 10, 2011
XP_WUIDENT wuident.txt Microsoft Corporation
May 25, 2005
XP_WUREDIR wuredir.xml Microsoft Corporation
June 16, 2005
XP_WUSETUP Default/ wuapplet2.ocx
December 28, 2010
MUAUTH authorization.xml Microsoft Corporation
June 05, 2008
MUREDIR wuredir.xml “Microsoft Corporation
July 01, 2009
MUIDENT muident.txt MS
December 28, 2010
VISTA_7_VERSION_S empty no signature
VISTA_7_VERSION 92 bytes, not a CAB file no signature
December 28, 2010
VISTA_7_WUCLIENT update.cat
December 28, 2010
VISTA_7_WSUS3SETUP WUClient-SelfUpdate-
December 28, 2010
VISTA_7_WUIDENT wuident.txt MS
December 28, 2010

Since the CAB files have valid signatures (revoked by Microsoft at the moment), the Windows Update service receives and processes them as valid updates. They are downloaded and installed, effectively executing the malicious payload.

The main payload module within these CAB files is a downloader component called “Wusetup.ocx” or “WuSetupV.exe”. It collects general information about the computer, including time zone information, and tries to download “http://MSHOME-F3BE293C/view.php”, with host information appended to the request URI. Since the name “MSHOME-F3BE293C” is handled by the SNACK module, the URL points to the running MUNCH server that serves the main Flame module “mssecmgr.ocx” on this URI.

WuSetupV downloads the file, saves it to “%windir%\Temp\~ZFF042.tmp” on the target machine, loads it as a DLL and invokes its export “DDEnumCallback”, which is Flame’s installation routine. The new machine then becomes infected.

Better than zero-day

When we first discovered Flame, we started looking in its code for at least one exploit that used a zero-day vulnerability to spread Flame and infect other machines inside the network. Given its sophistication and the fact that it infected fully patched Windows 7 machines, there should have been one. What we’ve found now is better than any zero-day exploit. It actually looks more like a “god mode” cheat code – valid code signed by a keychain originating from Microsoft. The signature was discovered and immediately revoked by Microsoft, and a security advisory with update KB2718704 was promptly published.

source: http://www.securelist.com


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s