¡VIRUS!

Era un viernes. Todo el mundo estaba esperando el fin de semana. Nuestra red de 3.500 estaciones de trabajo mantenía su ritmo de actividad acostumbrado. Fue entonces cuando comenzó todo. Una estación de trabajo que comienza a funcionar de forma extraña. Un fichero de programas mayor de lo normal. Antes de darnos cuenta, lo impensable había sucedido. Un virus estaba infectando nuestro sistemas de información corporativos.

Habíamos invertidos miles de años/hombre y mucho dinero en investigaciones, pruebas e instalación de nuestro software, gateways, y red de comunicaciones. Como resultado, podemos intercambiar información con las instalaciones de proceso más remotas del mundo tan fácilmente como con el edificio de al lado. En el sótano de nuestro edificio, una multitud de servidores de mensajes y de ficheros están funcionando las 24 horas del día ofreciendo soporte a miles de usuarios; a pesar de esta estructura complicada, la red nunca ha experimentado una parada no prevista de más de cinco minutos.

Este funcionamiento eficiente y a alta velocidad se debe totalmente a una buena planificación y a un complicado conjunto de redundancias. Ningún fallo puede hacer que queden inactivos más de unos pocos usuarios en un momento dado. Sin embargo, durante aquel viernes del otoño pasado, nos vimos obligados a parar enteramente nuestra red.

VIERNES 9:30 A.M.

Todo comenzó con una llamada telefónica de un técnico. Un ordenador que estaba poniendo a punto para un viaje no estaba funcionando correctamente; después de instalar un paquete de software en su disco duro, el ordenador se negó a realizar el rebooting. No pudimos detectar ficheros entrelazados, y no había otros problemas con la Tabla de Asignación de Ficheros del disco duro del ordenador, por lo que realizamos una exploración en busca de virus en los ficheros del disco duro para ver si alguno había resultado infectado.

La ejecución de esta operación de scanning hizo que el ordenador se detuviera, por lo que realizamos un reboot utilizando un disco DOS nuevo en lugar de la unidad de disco duro, y lo intentamos de nuevo. Esta vez pudimos completar un scanning en busca de virus en el disco duro, y no encontramos ninguno. Sin embargo, una cosa resultaba extraña. El tamaño de fichero del programa COMMAND.COM era mayor de lo normal: 49.586 bytes en lugar de 48.113. Copié el fichero a un diskette y lo llevé a mi ordenador para analizarlo.

10:00 A.M.

Ejecuté un programa de debugging que había escrito y que permite desensamblar programas sobre la marcha y muestra la versión de la codificación en lenguaje Assembler. Al comienzo del fichero de programa, observé algo muy sospechoso. En lugar de comandos de programa normales ejecutados en orden secuencial, había una instrucción JMP que señalaba a una codificación situada al final del fichero. Esta codificación contenía secuencias que esperaban en memoria a programas ejecutables -generalmente programas .COM, .EXE y .OVR- y se conectaba al final de todos los ficheros que estaba ejecutando el ordenador. Se trataba claramente de un código de un virus.

Al desensamblar aún más la codificación observé que era un programa sencillo residente en memoria cuyo único fin era difundirse a sí mismo. Así, infectaría ficheros de programa y ficheros overlay mientras evitaba el sector de booting de disco. Sin embargo, en lugar de infectar sólo programas ejecutados en una forma DOS normal, el virus atacaría a cualquier fichero que fuera copiado o difundido utilizando una secuencia BIOS especial. Por lo tanto, no iba dirigido únicamente a ficheros .EXE y .COM, sino a cualquier cosa que pareciera ser ejecutada, incluyendo tipos de letra Windows de Microsoft o ficheros video.

La infección se manifestó en forma de pantallas corrompidas y texto irregular en Windows. Si no hubiera sabido que teníamos un virus entre manos, podríamos haber pensado que el problema procedía de fallos o bugs del programa.

10:45 A.M.

Unos minutos después de realizar este análisis, recibí noticias de que dos máquinas de usuarios situadas en diferentes partes del edificio estaban teniendo los mismos problemas que el ordenador infectado. Asumiendo lo peor, realicé una comprobación mental de lo que sabía:

- Un virus había infectado un pequeño número de estaciones de trabajo en diferentes partes de la empresa.

- El virus no podía ser detectado utilizando nuestro programa de scanning de virus normal, y hacía que nuestro software anti-virus parara los ordenadores.

- El virus infectaba ficheros de programa de forma indiscriminada.

Otra llamada confirmó otra nueva infección, así que añadí lo siguiente a mi lista:

- El virus se estaba difundiendo rápidamente.

11:45 A.M.

Consultamos el Bulletin Board System del vendedor de nuestro software anti-virus y vimos que acababa de presentar una nueva versión de su software. La utilizamos para realizar un scanning de la primera estación de trabajo infectada y comprobamos que existía un nombre para nuestro virus: Athens. Sin embargo, el nuevo software también dejo de funcionar cuando se trataba de una estación de trabajo infectada. Decidimos llevar a cabo una reunión de emergencia a la una y media de la tarde para discutir lo que se había detectado hasta el momento y planificar un ataque.

1:00 P.M.

Justo antes de la reunión, me dirigí a comprobar una de las estaciones de trabajo recién infectadas. Aparentemente, había conseguido infectar un programa ejecutable residente en uno de nuestros servidores NetWare 3.11 de Novell. Esta infección tuvo lugar a pesar de que el usuario de la estación de trabajo sólo tenía derechos de Lectura y Scanning de Ficheros para el directorio del fichero, y que el fichero estaba marcado como Compartido y Sólo Lectura. Además, aunque estábamos utilizando un paquete anti-virus basado en red para impedir todas las operaciones de escritura al servidor de ficheros, no pudo impedir la infección. Por otra parte, el fichero de programas residente en el servidor tenía una longitud 1.473 bytes mayor en tamaño de la que debería tener. Un rápido examen mediante mi herramienta de debugging confirmó nuestras sospechas: estaba infectado definitivamente. Mi lista de problemas estaba aumentando.

El virus estaba en la red y rehusaba obedecer a una ley que considerábamos tan buena como la ley de la gravedad: no se puede cambiar un fichero en un servidor NetWare para el que no se tengan los derechos adecuados. Por lo visto, el virus podía volar.

1:30 P.M.

En la reunión estratégica sobre el virus pensé en cómo funcionan los servidores de ficheros hasta llegar al mecanismo del disco duro, y me concentré en un pool de memoria conocido como cache sucio.

Cuando se ejecuta un programa en un servidor NetWare, el sistema debe cargarlo primero en un cache sucio; de lo contrario, procesar los cientos de peticiones de transacción realizadas por el servidor de ficheros duraría una eternidad. Los ficheros permanecen allí durante 3,3 segundos, después de lo cual se limpia el cache, a menos que se realicen más llamadas a los mismos ficheros. Si se hacen más llamadas, el fichero es movido al cache normal.

En los tests, comprobamos que un fichero podía permanecer en el cache sucio hasta 30 minutos, antes de limpiar el cache. Así, cualquier estación de trabajo que llamase a una misma codificación ejecutable procesaría un programa infectado residente en el cache del servidor, y se infectaría a sí misma. De esta forma, el virus podría moverse como una pelota de ping pong desde la estación de trabajo al servidor de ficheros y de nuevo a la estación de trabajo, hasta infectar a todas las estaciones de trabajo. Como este área cache no estaba protegida por nuestro programa anti-virus basado en servidor, el virus se iba a difundir con segu