MS08-067: Server Service y Conficker (2008)
Análisis técnico de CVE-2008-4250, el stack buffer overflow en la canonicalización de rutas de NetAPI32.dll que obligó a Microsoft a publicar un parche fuera de ciclo. Conficker explotó esta vulnerabilidad para infectar entre 9 y 15 millones de máquinas, combinando RPC exploit, DGA con 50.000 dominios diarios, P2P cifrado con RSA-4096 y firmas digitales.
El parche que no podía esperar
El 23 de octubre de 2008, Microsoft hizo algo que rara vez hacía: publicar un parche de seguridad fuera de su ciclo mensual de Patch Tuesday. El boletín MS08-067, calificado como "Crítico", corregía un stack buffer overflow en la función de canonicalización de rutas del servicio Windows Server (implementada en NetAPI32.dll). La vulnerabilidad, CVE-2008-4250, permitía ejecución remota de código sin autenticación a través de una solicitud RPC especialmente construida.
Microsoft tomó esta decisión excepcional porque ya había detectado ataques dirigidos limitados explotando la vulnerabilidad. Sabían que era cuestión de tiempo que apareciera un exploit automatizado. Tenían razón: tres semanas después del parche, el 21 de noviembre de 2008, apareció Conficker.
Lo que nadie anticipó fue la escala. Conficker infectó entre 9 y 15 millones de máquinas en pocos meses, convirtiéndose en la mayor infección de un gusano de red desde SQL Slammer en 2003. Más importante aún, Conficker no era un gusano simple como Blaster o Sasser. Era una pieza de ingeniería sofisticada con algoritmos de generación de dominios, comunicación peer-to-peer, y firmas criptográficas RSA-4096 para verificar las actualizaciones.
La vulnerabilidad: CVE-2008-4250
El servicio Windows Server y NetAPI32.dll
El servicio Windows Server (también conocido como LanmanServer o srv.sys) gestiona los recursos compartidos de red en Windows: carpetas compartidas, impresoras, named pipes. Cuando un cliente remoto accede a un recurso compartido a través de SMB (Server Message Block), el servicio Server procesa las solicitudes.
La biblioteca NetAPI32.dll contiene las funciones de la API de red de Windows, incluyendo funciones para gestionar recursos compartidos, usuarios, grupos y sesiones de red. Una de estas funciones maneja la canonicalización de rutas: el proceso de convertir una ruta de red en su forma canónica, resolviendo componentes relativos como .. y ..
El bug de canonicalización de rutas
La vulnerabilidad estaba en la función que canonicalizaba rutas de red recibidas a través de solicitudes RPC al servicio Server. La función procesaba rutas del tipo:
\\servidor\recurso\..\..\ruta\destino
El algoritmo de canonicalización debía resolver los componentes .. (directorio padre) para producir la ruta canónica final. El problema era un error en el manejo de ciertos patrones de ruta que provocaba un stack buffer overflow.
El flujo vulnerable:
- Recepción: el servicio recibía una solicitud RPC con una ruta que contenía una combinación específica de caracteres Unicode y componentes
.. - Canonicalización: la función copiaba la ruta a un búfer en la pila mientras procesaba los componentes relativos
- Overflow: ciertas secuencias de componentes de ruta causaban que la función escribiera más allá del final del búfer de la pila, sobrescribiendo la dirección de retorno
El exploit específico enviaba una solicitud RPC NetPathCanonicalize con una ruta cuidadosamente construida. La ruta incluía caracteres Unicode de doble byte que el algoritmo de canonicalización procesaba de forma incorrecta, calculando mal la longitud de la ruta resultante y permitiendo el desbordamiento.
// Pseudocódigo simplificado del bug
DWORD NetpwPathCanonicalize(
LPWSTR PathName, // ruta de entrada (controlada por atacante)
LPWSTR Outbuf, // búfer de salida en la pila
DWORD OutbufLen, // tamaño del búfer
LPWSTR Prefix, // prefijo de la ruta
LPDWORD PathType, // tipo de ruta
DWORD Flags
) {
WCHAR canonBuf[MAX_PATH]; // búfer temporal en la pila
// El procesamiento de '..' con ciertos patrones Unicode
// calcula mal la longitud resultante, causando que
// la copia desborde canonBuf
while (*src) {
if (IsDotDot(src)) {
// Retrocede en el búfer destino
// BUG: no verifica que no retroceda más allá del inicio
// ni que la ruta resultante no exceda el búfer
dst = BacktrackOneLevel(dst, canonBuf);
}
*dst++ = *src++; // Copia sin verificar límites
}
}
La llamada RPC que disparaba el bug
El exploit invocaba la función NetPathCanonicalize a través de una solicitud RPC al named pipe \pipe\browser del servicio Server. Esta solicitud se podía enviar a través del puerto TCP 445 (SMB directo) o del puerto TCP 139 (NetBIOS sobre TCP).
El aspecto crítico era que la solicitud no requería autenticación en Windows XP y Windows 2000 con la configuración por defecto. En Windows Server 2003, se requería una sesión SMB nula (null session), que también estaba permitida por defecto.
La combinación de accesibilidad sin autenticación + bug de corrupción de pila + ejecución con privilegios SYSTEM hacía que la vulnerabilidad fuera "perfecta" para un gusano de red.
Por qué era wormable
No toda vulnerabilidad de ejecución remota de código produce un gusano. Para que una vulnerabilidad sea "wormable" (explotable de forma automatizada para propagación masiva), necesita cumplir varios criterios:
- Accesible sin autenticación: el atacante no necesita credenciales
- Sin interacción del usuario: no requiere que alguien haga clic en algo
- Amplia superficie de ataque: el servicio vulnerable está presente y activo en muchas máquinas
- Explotación fiable: el exploit funciona de forma consistente en diferentes configuraciones
- Privilegios suficientes: el código ejecutado tiene permisos para propagarse
CVE-2008-4250 cumplía los cinco criterios. El servicio Server estaba activo en toda máquina Windows con red, el puerto 445 estaba accesible en redes internas (y en muchas máquinas directamente en Internet), y la explotación producía ejecución con privilegios SYSTEM.
Conficker: anatomía del último gran gusano
Variantes y evolución
Conficker (también conocido como Downup, Downadup o Kido) evolucionó a través de varias variantes, cada una más sofisticada que la anterior:
| Variante | Fecha | Propagación | DGA | Características clave |
|---|---|---|---|---|
| Conficker.A | Nov 2008 | MS08-067 | 250 dom/día, 5 TLDs | Exploit básico, autoactualización |
| Conficker.B | Dic 2008 | MS08-067 + USB + shares | 250 dom/día, 8 TLDs | Anti-debug, bloquea antivirus |
| Conficker.C | Feb 2009 | Autoactualización P2P | 50.000 dom/día, 116 TLDs | P2P, RSA-4096 |
| Conficker.D | Mar 2009 | Solo actualización | 50.000 dom/día | Refuerza P2P, elimina MS08-067 |
| Conficker.E | Abr 2009 | P2P actualización | 50.000 dom/día | Instala SpamBot, Waledac |
Propagación: tres vectores
Vector 1: exploit MS08-067 (variantes A y B)
El vector principal era la explotación de CVE-2008-4250. El gusano escaneaba direcciones IP buscando el puerto TCP 445 abierto y enviaba el exploit RPC. El shellcode resultante descargaba y ejecutaba el binario del gusano desde un servidor HTTP que la máquina atacante había levantado en un puerto aleatorio.
A partir de la variante B, el gusano parcheaba NetAPI32.dll en memoria para cerrar la vulnerabilidad MS08-067 en la máquina infectada. Esta medida impedía que otras instancias de Conficker (u otros exploits) comprometieran la misma máquina. El gusano protegía su "territorio".
Vector 2: recursos compartidos de red (variante B)
Conficker.B añadió la capacidad de propagarse a través de carpetas compartidas de red. El gusano utilizaba un diccionario de contraseñas comunes para intentar autenticarse en recursos compartidos administrativos (ADMIN$, C$) de otras máquinas en la red local. Si conseguía acceso, copiaba su binario y creaba una tarea programada para ejecutarlo.
Vector 3: dispositivos USB (variante B)
El gusano se copiaba a cualquier unidad extraíble (USB, disco externo) conectada al sistema infectado. Creaba un archivo autorun.inf que ejecutaba el gusano automáticamente cuando el dispositivo se conectaba a otra máquina con la función de AutoRun habilitada.
El DGA: de 250 a 50.000 dominios por día
El Domain Generation Algorithm (DGA) de Conficker fue una de sus innovaciones más significativas. El DGA generaba nombres de dominio pseudoaleatorios que el gusano consultaba periódicamente para buscar actualizaciones de sus operadores.
Variantes A y B: generaban 250 dominios por día usando la fecha actual (obtenida de servidores de tiempo públicos) como semilla del generador pseudoaleatorio. Los dominios se distribuían entre 5 TLDs (.com, .net, .org, .info, .biz). Los operadores solo necesitaban registrar uno de esos 250 dominios para poder enviar comandos o actualizaciones al botnet.
# Pseudocódigo simplificado del DGA de Conficker.A
def generate_domains(date):
seed = date.year * 10000 + date.month * 100 + date.day
domains = []
for i in range(250):
domain_len = random_range(seed, 8, 12)
domain = ""
for j in range(domain_len):
domain += chr(random_range(seed, ord('a'), ord('z')))
tld = TLDS_5[random_range(seed, 0, 4)]
domains.append(f"{domain}.{tld}")
return domains
Variante C: escaló a 50.000 dominios por día distribuidos entre 116 TLDs, incluyendo country-code TLDs como .cn, .ru, .ar, .br. De esos 50.000, el gusano solo intentaba contactar 500 por día (seleccionados aleatoriamente). Esta escalada hizo que la estrategia de registro preventivo de dominios fuera económicamente inviable.
P2P y criptografía: la evolución de la resiliencia
A partir de la variante C, Conficker implementó un protocolo de comunicación peer-to-peer (P2P) que operaba en paralelo al DGA:
Descubrimiento de pares: las máquinas infectadas escaneaban rangos de IP buscando otros nodos Conficker. El protocolo utilizaba puertos UDP y TCP derivados de la IP de la máquina.
Intercambio de actualizaciones: los nodos podían compartir actualizaciones entre sí sin depender de un servidor central. Si un nodo obtenía una actualización (a través del DGA o de otro par), la redistribuía a los nodos que contactaba.
Verificación con RSA-4096: toda actualización distribuida a través del P2P o del DGA debía estar firmada digitalmente con una clave privada RSA de 4096 bits. Solo los operadores originales de Conficker poseían la clave privada. Esto impedía que los investigadores o los defensores inyectaran actualizaciones falsas para neutralizar el botnet, a diferencia de gusanos anteriores donde se podía explotar el mecanismo de actualización.
La combinación de DGA + P2P + firmas RSA-4096 creaba una infraestructura de comando y control extremadamente resiliente: si el DGA se bloqueaba, quedaba el P2P; si se infiltraba la red P2P, las actualizaciones no autorizadas serían rechazadas por la verificación criptográfica.
Técnicas anti-análisis
Conficker implementaba numerosas técnicas para dificultar su análisis y eliminación:
Deshabilitación de servicios de seguridad: el gusano terminaba y deshabilitaba Windows Defender, Windows Update, Windows Security Center, y varios servicios de antivirus.
Bloqueo de dominios de seguridad: modificaba la resolución DNS para bloquear el acceso a sitios web de compañías antivirus (Symantec, McAfee, Kaspersky, etc.) y a Windows Update.
Anti-debug: detectaba la presencia de depuradores y herramientas de análisis, y modificaba su comportamiento o terminaba su ejecución.
Cifrado del payload: el binario del gusano estaba cifrado con un esquema personalizado que dificultaba el análisis estático.
La respuesta: Conficker Working Group
La escala y sofisticación de Conficker provocó la formación de una coalición sin precedentes en la industria de seguridad: el Conficker Working Group (CWG).
Miembros y estrategia
El CWG incluía a Microsoft, ICANN, VeriSign, Afilias, CNNIC, NeuStar, Symantec, F-Secure, Kaspersky, Georgia Institute of Technology, SRI International, y decenas de otras organizaciones. Su estrategia principal era el "sinkholing" de dominios: registrar preventivamente los dominios que el DGA generaría antes de que los operadores de Conficker pudieran hacerlo.
Con la variante A (250 dominios/día, 5 TLDs), la tarea era manejable. El CWG coordinaba con los registradores de los 5 TLDs para bloquear o registrar los dominios predichos.
Con la variante C (50.000 dominios/día, 116 TLDs incluyendo ccTLDs), la tarea se volvió monumental. Requirió la cooperación de registradores de dominios de más de 100 países, muchos de los cuales no tenían experiencia previa con operaciones de seguridad informática y operaban bajo marcos legales diferentes.
La recompensa de Microsoft
En febrero de 2009, Microsoft anunció una recompensa de 250.000 dólares por información que llevara a la identificación y arresto de los creadores de Conficker. A pesar de esta recompensa y de los recursos dedicados por el CWG, los autores nunca fueron identificados.
El 1 de abril de 2009
La variante C de Conficker estaba programada para activar su DGA expandido (50.000 dominios/día) el 1 de abril de 2009. Los medios de comunicación generaron un pánico considerable con titulares sobre un "ciberapocalipsis" inminente. En la práctica, el 1 de abril pasó sin incidentes visibles: el DGA ya estaba en operación, pero los operadores de Conficker no enviaron ningún comando destructivo ese día.
El 8 de abril de 2009, la variante E de Conficker finalmente descargó su payload: instalaba el spambot Waledac y el scareware SpyProtect 2009 en las máquinas infectadas. Después de meses de sofisticación técnica, el payload final era monetización simple a través de spam y software falso de seguridad. Este anticlímax sugirió que los operadores de Conficker eran criminales motivados por beneficio económico, no un actor estatal.
Impacto y números
Escala de la infección
Las estimaciones de infección variaron significativamente según la fuente:
- Pico de infecciones activas: entre 9 y 15 millones de máquinas únicas
- IPs únicas observadas: más de 10 millones en el punto máximo
- Países afectados: más de 190
- Redes corporativas: afectó a organizaciones militares, hospitalarias, gubernamentales y financieras
- Detecciones activas en 2018: según Trend Micro, Conficker seguía siendo detectado en redes corporativas una década después, especialmente en dispositivos IoT y sistemas legacy
La Armada francesa
Uno de los incidentes más notables fue la infección de la red interna de la Marina francesa (Marine nationale) en enero de 2009. Conficker se propagó a través de medios USB y la red interna, afectando los sistemas de comunicación de aviones Rafale. La Marina tuvo que desconectar temporalmente parte de su red.
Análisis técnico del exploit
El exploit en detalle
El exploit de MS08-067 enviaba una solicitud RPC al servicio Server a través de SMB:
- Conexión SMB: establecer sesión con el puerto 445
- Tree connect: conectarse al recurso compartido IPC$ (inter-process communication)
- Named pipe: abrir el named pipe
\pipe\browser - RPC bind: solicitar acceso a la interfaz
srvsvc(Server Service) - NetPathCanonicalize: invocar la función vulnerable con una ruta malformada
El shellcode inyectado a través del overflow:
- Localizaba las funciones de API necesarias (LoadLibrary, GetProcAddress)
- Descargaba el binario del gusano desde un servidor HTTP
- Lo ejecutaba con CreateProcess
- Parcheaba NetAPI32.dll en memoria para cerrar la vulnerabilidad
Fiabilidad del exploit
A diferencia de exploits anteriores (como el de Blaster), el exploit de MS08-067 era notablemente fiable. Los investigadores de seguridad desarrollaron exploits funcionales para múltiples versiones de Windows (XP SP2, SP3; 2000 SP4; Server 2003 SP1, SP2) con tasas de éxito superiores al 90%.
La razón de esta fiabilidad era que el bug producía un stack overflow controlable: el atacante tenía control preciso sobre qué datos se escribían en la pila y dónde se sobrescribía la dirección de retorno. Las mitigaciones como ASLR (presente en Vista pero no en XP) habrían dificultado significativamente la explotación, pero la mayoría de máquinas infectadas ejecutaban XP sin ASLR.
Análisis MITRE ATT&CK
| Fase del ataque | Técnica ATT&CK | Descripción |
|---|---|---|
| Acceso inicial | T1190 (Exploit Public-Facing Application) | Stack overflow en NetAPI32 (puerto 445) |
| Propagación | T1210 (Exploitation of Remote Services) | Escaneo y explotación automática |
| Propagación | T1091 (Replication Through Removable Media) | USB + autorun.inf |
| Acceso a credenciales | T1110.001 (Password Guessing) | Diccionario contra shares administrativos |
| Persistencia | T1543.003 (Windows Service) | Instalación como servicio de Windows |
| Evasión | T1562.001 (Disable Security Tools) | Deshabilitación de AV y Windows Update |
| C2 | T1568.002 (Domain Generation Algorithms) | DGA de 250 a 50.000 dominios/día |
| C2 | T1573.002 (Asymmetric Cryptography) | RSA-4096 para firmar actualizaciones |
| C2 | T1090 (Proxy / P2P) | Red P2P para distribución de actualizaciones |
El final de una era
MS08-067 y Conficker marcaron el final de la era de los gusanos de red masivos que explotaban servicios de Windows. Los factores que cerraron esta época:
Firewalls por defecto: desde XP SP2 (2004), el firewall de Windows bloqueaba los puertos internos. Las máquinas que Conficker infectó eran en su mayoría XP sin SP2, máquinas en redes internas donde los puertos SMB estaban abiertos, o máquinas infectadas por USB.
ASLR y DEP: Windows Vista (2007) introdujo ASLR y DEP mejorado, que hacían la explotación de stack overflows significativamente más difícil. Windows 7 (2009) reforzó ambas mitigaciones.
Actualizaciones automáticas: la cultura de parcheado automático se normalizó. Las máquinas que quedaban sin parchear eran excepciones (sistemas legacy, entornos industriales, máquinas aisladas), no la norma.
Segmentación de red: las redes corporativas implementaron segmentación más estricta, limitando la propagación lateral incluso cuando una máquina se comprometía.
Conficker fue el canto del cisne de una clase de amenaza que dominó la primera década del siglo XXI. Los gusanos de red no desaparecieron (WannaCry en 2017 y NotPetya en 2017 demostraron que seguían siendo posibles), pero las condiciones para una propagación de la escala de Conficker se han vuelto mucho más difíciles de reproducir.
Preguntas frecuentes
Artículos relacionados
Este contenido tiene fines exclusivamente educativos y de investigación en ciberseguridad defensiva. No se proporcionan binarios maliciosos ni payloads ejecutables. El uso indebido de esta información es responsabilidad exclusiva del usuario. Leer disclaimer completo.