El sábado 25 de enero fue, sin exagerar, el día que internet decidió echar el cierre. Cajeros caídos en medio mundo, la flamante conexión ADSL yendo a velocidades de un módem de 56k de los años 90 (o peor, ni conectaba).

El culpable de todo este desastre no ha sido un ataque sofisticadísimo sacado de la película Hackers, sino una chapuza de seguridad que ha sido explotada por un trocito de código ridículamente pequeño. Hoy quiero que destripemos un poco lo que ha pasado con el gusano Slammer (o Sapphire, como le llaman algunos analistas) para intentar entender cómo algo tan diminuto ha puesto al mundo tecnológico patas arriba.

Un paquete UDP de 376 bytes

La belleza técnica (si se le puede llamar así desde la perspectiva de un informático) y el terror de Slammer radican en su tamaño: ocupa exactamente 376 bytes. Todo el gusano entra sin problemas en un único paquete de red. Y aquí reside la genialidad maligna y el motivo de su increíble velocidad de propagación.

Al contrario que otras pesadillas recientes con las que nos hemos pegado, como Code Red o Nimda, que usaban el protocolo TCP y tenían que perder un tiempo valiosísimo en el three-way handshake (el famoso saludo de SYN, SYN-ACK, ACK para establecer la conexión), Slammer usa UDP.

Este protocolo funciona disparando a ciegas. El gusano genera direcciones IP aleatorias usando una rutina de código que él mismo lleva en sus tripas, y escupe copias de sí mismo sin importarle si llegan a su destino o no. Como la carga útil ocupa tan poco, un servidor infectado con una conexión decente a internet puede lanzar cientos o miles de estos paquetes por segundo. El resultado es la saturación total del ancho de banda y de la tabla de enrutamiento de los routers de las operadoras. Por eso colapsó la red mundial. No porque borrara discos duros o robara contraseñas, sino por puro ruido de tráfico basura.

El agujero: Desbordamiento de búfer en SQL Server

Pero, ¿cómo demonios entra al sistema? El gusano ataca el puerto 1434 (UDP). Este puerto lo usa el servicio de resolución de Microsoft SQL Server 2000 (y, ojo, también el MSDE 2000 que a veces te lo instalan a escondidas otros programas "de terceros" sin que te enteres) para informar a los clientes de qué instancias de la base de datos están corriendo en la máquina.

El funcionamiento del buffer overflow es de libro de texto. Si le envías a ese puerto 1434 un paquete cuidadosamente manipulado que empiece por el byte 0x04, seguido de una cadena de texto mucho más larga de lo que el programador de Microsoft reservó en la memoria, el búfer simplemente revienta. Ese exceso de datos sobrescribe la pila (stack) de ejecución del programa, alterando el puntero de instrucción del procesador. De esta forma, la CPU, en lugar de continuar con la ejecución normal del servicio de SQL, pega un salto y ejecuta el código malicioso que viene escondido justo detrás en ese mismo paquete.

A nivel muy conceptual, la anatomía del ataque en la memoria es algo así:

[Cabecera UDP destino 1434] + [0x04] + [A + A + A... (Desborda el búfer)] + [Código ensamblador del gusano]

Una vez que el gusano se ejecuta, se queda residente en la memoria de tu servidor (una gran ventaja para él: no escribe ni un solo byte en el disco duro, con lo cual los antivirus de escritorio que solemos usar no se enteran) y empieza a bombardear internet en un bucle infinito. La parte buena es que, con reiniciar el ordenador o matar el proceso, el gusano desaparece. La parte mala es que, si no parcheas el sistema o cortas el cable de red, te vuelves a infectar en cuestión de milisegundos porque internet sigue estando plagada de paquetes perdidos buscando víctimas.

Para cacharrear un poco y asegurarte de que tu máquina de desarrollo no está exponiendo el puerto maldito sin que lo sepas, abre el MS-DOS y tira un comando rápido:

netstat -an | find "1434"

Si aparece escuchando en tu IP pública... apaga y vámonos. Y si eres de los míos, de los que confía más en un buen Linux antiguo haciendo de firewall para la red perimetral, más vale que este fin de semana hayas metido una regla de este estilo para cortar la sangría:

iptables -A FORWARD -p udp --dport 1434 -j DROP

La reflexión que nos deja

Lo que me genera más impotencia de toda esta historia es que la vulnerabilidad técnica que explota Slammer no tiene absolutamente nada de nueva. Microsoft sacó el parche oficial, el famoso MS02-039, en ¡julio del año pasado! Llevaba seis meses cogiendo polvo en la web de descargas. ¿Por qué cayeron entonces tantos miles de servidores corporativos? Sencillamente porque en nuestro mundillo, actualizar sistemas en producción sigue dando pánico. Nadie quiere tocar un servidor de base de datos que está funcionando y dando servicio 24/7 por si se rompe algo o el software de contabilidad deja de funcionar, pero luego pasa lo que pasa.

Creo que nos estamos malacostumbrando a conectar todo a internet "por si acaso" o por pura comodidad de los administradores para trabajar desde casa. Trastear en local con los cacharros está bien, pero tener un SQL Server 2000 expuesto directamente a la internet pública y sin un firewall restrictivo por delante, en pleno 2003, es directamente un suicidio profesional.

Nos toca aprender la lección por las malas. Toca empezar a tomarse en serio la política de aplicar los parches en cuanto salen, y sobre todo, adoptar una filosofía de cerrar todo aquello que no sea estrictamente necesario.