Flame: replicación mediante el servidor proxy MITM Windows Update

El malware Flame utiliza varios métodos para replicarse. El más interesante es el que utiliza el servicio Microsoft Windows Update. Este método se implementa en los módulos “SNACK”, “MUNCH” y “GADGET”. Como son parte de Flame, es fácil reconfigurar estos módulos. El registro global de Flame, la base de datos que contiene miles de opciones de configuración, controla el comportamiento de estos módulos.

SNACK: falsificación de NBNS

El módulo SNACK crea un socket de red RAW puro para todas las interfaces de red predeterminadas y comienza a recibir todos los paquetes de redes. Después explora los paquetes NBNS de otros ordenadores buscando los nombres de las redes locales. Cuando recibe uno de estos paquetes, lo escribe en un archivo de registro codificado y lo deja pasar para que se lo siga procesando.

Cuando un nombre en una solicitud NBNS coincide con la expresión “wpad*” o “MSHOME-F3BE293C”, responde con su propia dirección IP. Si la variable “SNACK.USE_ATTACK_LIST” está puesta en “True”, también revisa si los paquetes se originan desde direcciones IP especificadas en su lista “SNACK.ATTACK_LIST” y responde a los equipos con estas direcciones.

“Wpad” es un nombre que se utiliza para detectar proxies de forma automática. Al responder a las solicitudes llamadas “wpad” con su propia dirección IP, el módulo SNACK presenta al ordenador infectado como un servidor proxy para su propia red local.

SNACK y MUNCH también se comunican con la unidad GADGET que facilita la administración de diferentes eventos de otros módulos. El registro de Flame contiene módulos LUA para procesar eventos como “MUNCH_ATTACKED”, “SNACK_ENTITY.ATTACK_NOW”.

MUNCH: falsificación de detecciones de proxy y solicitudes de Windows Update

El módulo de servidor HTTP en Flame se llama “MUNCH” y se inicia sólo si la variable “MUNCH.SHOULD_RUN” está puesta en “True” y si no se están ejecutando programas que puedan alertar a la víctima. Estos programas (antivirus, cortafuegos, rastreadores de red, etc.) se especifican en una lista llamada “SECURITY.BAD_PROGRAMS” dentro del registro de Flame.
Cuando MUNCH se ejecuta, lee un búfer de la variable “MUNCH.WPAD_DATA”, reemplaza el patrón “%%DEFAULT%%” con la dirección IP de su interfaz de redes más apropiada y espera que lleguen las solicitudes HTTP.

Contenidos de la variable “MUNCH.WPAD_DATA”
El búfer “MUNCH.WPAD_DATA” es en realidad un archivo WPAD que los clientes de redes solicitan para implementar la detección automática de servidores proxy. El código en el archivo WPAD busca el hash MD5 del “hostname” con el que el cliente se está conectando en su lista y, si lo encuentra, se ofrece a sí mismo como un proxy HTTP. Hemos identificado algunos de los hashes:
download.windowsupdate.com
download.microsoft.com
update.microsoft.com
www.update.microsoft.com
v5.windowsupdate.microsoft.com
windowsupdate.microsoft.com
www.download.windowsupdate.com
v5stats.windowsupdate.microsoft.com

Así que, cuando un ordenador configurado con detección proxy automática trata de acceder a uno de los anfitriones de Windows Update, SNACK le envía la dirección IP del equipo infectado y MUNCH le manda la dirección IP del mismo ordenador como servidor proxy desde “wpad.dat”. De ahí en adelante, las solicitudes al servicio Windows Update pasan a través del servidor MUNCH.

Cuando un cliente de red se conecta al servidor MUNCH y solicita una URI que no sea “/wpad.dat” y “/ view.php”, el servidor:

1) Ejecuta “MUNCH.SHOULD_ATTACK_SCRIPT” – Script LUA que comprueba si el encabezado User-Agent coincide con al menos uno de los patrones especificados en el script “MUNCH.USER_AGENTS.CAB_PATTERN_*”. Los archivos de registro de Flame que tenemos contienen los siguientes patrones:
MUNCH.USER_AGENTS.CAB_PATTERN_4 : WinHttp%-Autoproxy%-Service.*
MUNCH.USER_AGENTS.CAB_PATTERN_3 : Windows%-Update%-Agent.*
MUNCH.USER_AGENTS.CAB_PATTERN_2 : Industry Update.*
MUNCH.USER_AGENTS.CAB_PATTERN_1 : Microsoft SUS.*

2) Revisa si el URI solicitado coincide con cualquier patrón que se encuentre en la lista de cadenas de caracteres “MUNCH.GENERIC_BUFFERS.*.data.PATTERN”. Si una de las expresiones coincide, la especifica en el valor “MUNCH.GENERIC_BUFFERS.*.data.FILE_DATA”, lee el valor de la funcionalidad maliciosa llamada “MUNCH.GENERIC_BUFFERS_CONTENT.value_of_FILE_DATA” y lo envía al cliente.
Todas las funcionalidades están listadas en el registro de Flame con nombres que comienzan con “MUNCH.GENERIC_BUFFERS_CONTENT.payload_name” y están codificados con una llave 104-byte RC4 fija.
Patrón URI Nombre de la funcionalidad
*v9/windowsupdate/redir/muv4wuredir.cab*
*v8/windowsupdate/redir/muv3wuredir.cab*
*v7/windowsupdate/redir/wuredir.cab*
*v6/windowsupdate/redir/wuredir.cab*
*ws03sp1/windowsupdate/redir/wuredir.cab* WUREDIR
*/v9/windowsupdate/?/?elf?pdate/WSUS3/x86/Other/wsus3setup.cab*
*/v9/windowsupdate/?/SelfUpdate/AU/x86/NetServer/*/wusetup.cab*
*/v9/windowsupdate/?/SelfUpdate/AU/x86/XP/*/wusetup.cab*
*/v9/windowsupdate/?/SelfUpdate/AU/x86/W2K/*/wusetup.cab*
*/v9/windowsupdate/?/SelfUpdate/AU/x86/W2KSP2/*/wusetup.cab* WUSETUP
*update.microsoft.com/v6/windowsupdate/selfupdate/wuident.cab* XP_WUIDENT
*v5/redir/wuredir.cab* XP_WUREDIR
*download.windowsupdate.com/v6/windowsupdate/?/SelfUpdate/
AU/x86/XP/en/wusetup.cab* XP_WUSETUP
*muauth.cab* MUAUTH
*muredir.cab* MUREDIR
*muident.cab* MUIDENT
*/version_s.xml VISTA_7_VERSION_S
*/version.xml VISTA_7_VERSION
*v9/windowsupdate/redir/muv4wuredir.cab*
*v8/windowsupdate/redir/muv3wuredir.cab*
*v7/windowsupdate/redir/wuredir.cab*
*v6/windowsupdate/redir/wuredir.cab*
*ws03sp1/windowsupdate/redir/wuredir.cab* VISTA_7_WUREDIR
*/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

La mayoría de las funcionalidades maliciosas son archivos comprimidos CAB. Los archivos comprimidos que contienen códigos maliciosos tienen firmas de “MS” que datan de diciembre de 2010 y noviembre de 2011, mientras que al parecer los otros archivos comprimidos se originan en el servicio Windows Update genuino y están firmados por “Microsoft Corporation”.

Nombres de la funcionalidad Contenidos Fecha de la firma
WUREDIR VISTA_7_WUREDIR wuredir.xml Microsoft Corporation July 01, 2009
WUSETUP Default/wuapplet2.ocx
Default/wuaucom.dat
Default/wuauinfo.ocx
Default/wuconf.ini
Default/wusetup.ocx
wsus3setup.cat
wsus3setup.inf
wuapplet2.ocx
wuaucom.dat
wuauinfo.ocx
wuconf.ini
wups2.cab
wups2.cat
wusetup.cat
wusetup.inf
wusetup.ocx MS
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
Default/wuaucom.dat
Default/wuauinfo.ocx
wups2.cab
wusetup.cat
wusetup.inf
wusetup.ocx MS
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
VISTA_7_WUSETUPHANDLER WuSetupV.exe MS
December 28, 2010
VISTA_7_WUCLIENT update.cat
update.mum MS
December 28, 2010
VISTA_7_WSUS3SETUP WUClient-SelfUpdate-
ActiveX~31bf3856ad364e35~x86~
~7.0.6000.381.mum
WuPackages.xml MS
December 28, 2010
VISTA_7_WUIDENT wuident.txt MS
December 28, 2010

Como los archivos CAB tienen firmas válidas (que Microsoft ya ha revocado), el servicio Windows Update las recibe y procesa como actualizaciones válidas. Las descarga e instala para ejecutar la funcionalidad maliciosa.

El módulo principal de la funcionalidad dentro de estos archivos CAB es un componente descargador llamado “Wusetup.ocx” o “WuSetupV.exe”. Recolecta datos generales sobre el ordenador, incluyendo información sobre su zona horaria, e intenta descargar “http://MSHOME-F3BE293C/view.php” con información del anfitrión adjunta a la URI solicitada. Como el módulo SNACK gestiona el nombre “MSHOME-F3BE293C”, la URL dirige al servidor MUNCH que se está ejecutando que entrega el módulo principal de Flame “mssecmgr.ocx” en esta URI.
WuSetupV descarga el archivo, lo guarda en “%windir%Temp~ZFF042.tmp” en el ordenador atacado, lo carga como DLL e invoca la exportación “DDEnumCallback”, que es la rutina de instalación de Flame. Así es como se infecta el nuevo ordenador.

Mejor que una vulnerabilidad del “día cero”

Cuando descubrimos Flame, comenzamos a buscar en su código algún exploit que utilice una vulnerabilidad del día cero para propagarlo e infectar a otros ordenadores dentro de la red. Era la explicación más razonable, tomando en cuenta su alto nivel de sofisticación y el hecho de que infectaba equipos con Windows 7 que estaban al día con sus parches de seguridad. Lo que hemos descubierto ahora es mucho mejor que cualquier exploit del día cero. Es más, parece un código de trampa de “modo dios” – un código válido firmado por un llavero de Microsoft. Microsoft descubrió y eliminó la firma digital de inmediato, y no tardó en publicar una recomendación de seguridad con la actualización KB2718704.