VIRUS INFORMÁTICOS: Y así empezó todo...
Autor: Juan-Mariano de Goyeneche.
Publicado en el Número 6 de Programación Actual.
Virus. Todo el mundo ha oído hablar de
ellos y muchos los han sufrido, pero su forma de infectar, reproducirse
o atacar sigue siendo un gran misterio para la mayoría.
Una antigua máxima reza: "Si quieres vencer a tu enemigo,
conócelo primero". Eso es lo que se intentará
en esta entrega: si se ejecutan en un ordenador, es que son programas.
Y si son programas, se pueden comprender. Es cierto que no contamos
con el código fuente, pero ¿acaso es imprescindible?
¿Es que no tenemos el código objeto...?
Desde que en 1987 se diera el primer caso documentado
de ataque de un virus informático en la Universidad de
Delaware, mucho se ha dicho y escrito sobre el tema dentro de
los foros más insospechados. A pesar de ello los virus
siguen siendo grandes desconocidos para la gran mayoría,
razón que sin duda contribuye no poco a que cada vez sea
mayor el número de ellos en expansión. Conocer y
entender la forma en que actúan, se reproducen y se comportan
es la mejor forma de estar prevenido y saber cómo reaccionar;
la solución de formatear el disco duro nada más
enterarse de que dentro hay un virus es bastante extrema y, por
lo demás, suele eliminar toda la información del
disco duro... a excepción del propio virus.
Por otra parte, ya no en el caso de un particular,
sino en el de las empresas, es muy posible que no puedan permitirse
esperar a que se saque la siguiente versión de un antivirus
que elimine el que les afecta, y necesiten que alguien realice
un estudio inmediato de su virus, identifique su forma
de actuar, sus efectos, y se pueda poner a corregirlos cuanto
antes.
Esta serie de artículos tratará de
dar cumplida visión del funcionamiento y técnicas
de estos programas, pensando que el conocimiento y el entendimiento
son dos armas básicas en la lucha contra cualquier amenaza.
Hay quien opina que este tipo de información
no debe hacerse pública para evitar que más gente
se dedique a fabricar virus. Pero, ya que según los estudiosos
la media de aparición de virus nuevos viene a ser de unos
5 o 6 cada día -por no contar las modificaciones y mutaciones
sobre otros ya existentes-, es fácil llegar a la conclusión
de que "los malos" ya tienen toda la información
que necesitan. Normalmente las políticas de ocultación
de información de este tipo con ánimo de evitar
que se utilice con "malos fines" fracasan estrepitosamente
al acabar siempre desinformados los que sufren los ataques y nunca
quienes los perpetran, cosa que ayuda a que los ataques sean mucho
más efectivos.
Por eso aquí se tratará con virus reales,
estudiando su comportamiento a través de su propio código.
La naturaleza de estos programas obliga, eso sí, a suponer
en el lector conocimientos mínimos de lenguaje ensamblador.
Se explicarán construcciones crípticas u operaciones
poco evidentes por estar fuertemente ligadas a la arquitectura
de la máquina, pero no el repertorio de instrucciones o
los modos de direccionamiento. Para información sobre estos
aspectos, referirse a la bibliografía.
La paternidad de la idea de un programa capaz de
reproducirse se le atribuye a John von Neumann por su artículo
"Theory and Organization of Complicated Automata" del
año 1949. Von Neumann estaba interesado en la creación
de vidas artificiales electrónicamente, a las que
daba el nombre de autómatas que, según él,
podían reproducirse sin excesiva dificultad.
También por aquel entonces, cuando empezaban
a desarrollarse los primeros ordenadores, se vio la necesidad
de llevar a la computadora a un estado inicial conocido, eliminando
rastros de otros programas previamente cargados. Una solución
muy ingeniosa consistía en implementar una instrucción
que simplemente se copiaba a la siguiente posición de memoria
y saltaba a ella para seguir ejecutándose. De esta forma
todo el mapa de memoria se llenaba con un único valor conocido:
el código correspondiente a la instrucción. Este
fue otro ejemplo claro de código capaz de reproducirse.
Seguramente basado en él, más adelante, en los años
60, cobró gran popularidad el juego "Core Wars",
diseñado en los laboratorios Bell de AT&T: dos jugadores
lanzaban simultáneamente sus programas que se reproducían
en memoria hasta que ésta se agotaba. Ganaba aquel que
fuera capaz de "conquistar" más memoria, para
lo cual era perfectamente legal "matar" a las copias
del adversario y "robarle" esa memoria.
Aparte del méramente lúdico, también
se trató de darle un uso algo más práctico
a este tipo de programas, y así, a finales de los años
70, dos investigadores del Centro de Investigación Xerox
de Palo Alto, California, idearon un programa que debía
encargarse de las labores de mantenimiento y administración
del complejo, al que dieron el nombre de "gusano". El
programa "dormía" por el día y por la
noche se propagaba por todos los ordenadores del Centro haciendo
copias de seguridad y otras tareas de gestión. Todo esto
en la teoría, porque en la práctica el gusano escapó
de los ordenadores de prueba del laboratorio, se extendió
por toda la red y paralizó todas las máquinas. Al
intentar eliminarlo, seguía reapareciendo, así que
no hubo más remedio que crear otro programa vermicida que
fuera por todas las máquinas matando copias del gusano.
La palabra virus no se empezó a usar
hasta que Fred Cohen, un estudiante graduado de la Universidad
del Sur de California, lo utilizó en 1984 para su tesis
sobre programas autoduplicadores. En ella daba la primera definición
formal del término y hacía un estudio matemático
de la expansión de este tipo de engendros, mediante el
cual demostró que crear un programa detector de virus perfecto
era lógicamente imposible (ver recuadro).
Como se dijo antes, en 1987, el 22 de octubre, se
da el primer ataque de virus del que se tiene noticia. En realidad
era inofensivo y contenía la dirección y teléfono
de los autores: dos hermanos de Pakistán, estudiantes de
la Universidad de Lahore, aunque, al parecer, hubo un estudiante
que perdió su tesis debido a efectos secundarios del virus.
También ese año se produce la primera infección
masiva sobre ordenadores Macintosh: un consultor de Aldus Corporation
se infectó con un disco de juegos y al realizar luego pruebas
al programa Aldus Freehand contaminó el disco que luego
distribuyó su empresa. El virus se limitaba a presentar
en pantalla un "mensaje universal de paz" a todos los
usuarios del Mac, firmado por Richard Brandow, editor de la revista
MacMag, al llegar al 2 de Marzo de 1988 (fecha del aniversario
de la aparicíon del Macintosh II) y se autodestruía
inmediatamente.
Pero los buenos deseos de paz pronto se transformaron
en sentimientos menos encomiables. Así, tiempo después,
un banco de la isla de Malta se vio afectado por un virus que
sacaba el siguiente mensaje por pantalla:
"DISK DESTROYER - A SOUVENIR OF MALTA / I have
just DESTROYED the FAT on your Disk!! / However, I have kept a
copy in RAM, / and I'm giving you / a last chance to restore your
precious data./ WARNING: IF YOU RESET NOW ALL YOUR / DATA / WILL
BE LOST FOREVER!! / Your data depends on a game of JACKPOT / CASINO
DE MALTE JACKPOT/ +L+ +?+ +C+ / CREDITS: 5 / <<ANY KEY TO
PLAY>>"
El virus borraba la FAT, una estructura básica
de cualquier disco DOS que permite encontrar los datos, pero guardaba
una copia en memoria. Después invitaba a jugar a las tragaperras:
si salían tres "L", restauraba la FAT y no se
perdían datos, pero si salían tres "?"
o tres "C", destruía también la copia
de RAM y se perdían todos los datos. Como era de esperar,
el banco perdió la información en dos terceras partes
de sus máquinas.
LOS COMIENZOS
LOS AÑOS 80
|
|
|
En su tesis doctoral para la Universidad de California, Los Angeles, Fred Cohen demostraba, en 1983, que no hay ningún algoritmo general que pueda concluir con total fiabilidad -100%- si un programa es o no un virus. Para ello se valía de la siguiente demostración por reducción al absurdo: Supóngase que existe un algoritmo general A que, analizando cualquier programa P, devuelve "true" si y sólo si P es un virus. Entonces sería posible crear un programa, P, que hiciera lo siguiente:
if ( A(P) = false ) then infecta el sistema if ( A(P) = true ) then no infectes nada Es decir: P es un virus si A dice que no lo es, y no lo es si A dice que lo es. Por contradicción, ese algoritmo general A no existe. |
HISTORIA LIGADA AL DOS
Aunque también se han dado casos de virus en otros sistemas operativos, la inmensa mayoría son propios del D.O.S. Esto no es difícil de entender si se tienen en cuenta los nulos mecanismos de protección de este entorno en comparación, por ejemplo, con UNIX en donde existen dueños y permisos de ficheros, o el sistema operativo limita el acceso a partes críticas del hardware y del propio sistema operativo. La creación de virus en estos sistemas que ofrecen ciertas protecciones no es, a pesar de todo, imposible, y desde febrero de este año han aparecido nuevas versiones de un virus para Linux, el Bliss, con características francamente interesantes : guarda su número de versión en las infecciones, y actualiza éstas si él mismo es una versión más moderna, o se auto-actualiza si se encuentra con un fichero infectado con una versión más reciente de sí mismo ; modifica las fuentes del kernel para poder hacerse root mediante llamadas poco convencionales a la función umask ; como a todo buen programa UNIX, se le puede llamar especificando opciones en la línea de comandos, alguna tan singular como "-disinfect_files_please" que, efectivamente, desinfecta el fichero que se le diga ; guarda logs de todas las infecciones en el /tmp, etc. Es un virus experimental, aunque, ciertamente, promete.
TIPOS DE VIRUS
Pese a que desde aquel no tan lejano 1987 el número de virus existente ha crecido ampliamente por encima del millar, todos ellos pueden ser englobados en tres categorías: virus de arranque, virus de ejecutables y, recientemente, virus de macros, interpretados por otras aplicaciones.
Los virus de arranque toman el control antes de que se cargue el sistema operativo, y son por tanto independientes de él; se localizan en los sectores de arranque de los disquetes y en la Master Boot Record (Tabla de Particiones) de los discos duros. Serán el objeto de estudio del próximo artículo.
Los virus de ejecutables modifican los ficheros .EXE o .COM para alojarse en ellos añadiéndose a su código a modo de mochila para ejecutarse cuando se llama al programa anfitrión. A diferencia de los de arranque, que siempre son residentes en memoria, estos pueden optar entre serlo o no, lo que influirá tanto en su velocidad de difusión como en la facilidad y forma de ser detectados.
Por último, los virus de macros son consecuencia de la inclusión por parte de Microsoft de un lenguaje de programación, WordBasic, para crear macros que se interpretan en los documentos de Word versíon 6.x y superiores, así como en hojas de cálculo Excel. Han sido revolucionarios al ser los primeros virus que no infectan código, sino datos, y además independientemente de la plataforma en la que se encuentren. Todos los demás virus, al estar escritos en última instancia en código máquina de un procesador determinado, sólo funcionan en este tipo de máquinas. Estos en cambio funcionan lo mismo en un Word ejecutándose sobre plataformas Intel, Motorola o PowerPC.
UN POCO DE VOCABULARIO
Hasta ahora hemos hablado de virus sin dar una definición más o menos formal, confiando en esa idea más o menos intuitiva que tiene todo el mundo de lo que son. En realidad la definición no dista mucho de la dada inicialmente por Cohen, aunque hay que modificarla ligeramente para dar cabida en ella a los virus de macros. Un virus de ordenador es un programa (en general, aunque no necesariamente, compilado) capaz de reproducirse infectando otros programas, a los que añade o sobrescribe su código -posiblemente encriptado o modificado- de modo que ese código sea, a su vez, capaz de reproducirse de nuevo infectando otros programas. La infección puede hacerse de forma indirecta: no es imprescindible modificar el código del programa que se va a infectar. Algunos virus, como el "Dir-II", alteran las entradas de directorio para que al ejecutar un fichero, primero se les llame a ellos. De esta forma el programa original no se toca, pero la entrada en el directorio sí. Al hablar de "programa" no debe pensarse sólo en ficheros ejecutables. En un sector de arranque también hay un programa; una macro contiene una serie de acciones que se ejecutan secuencialmente, y como tal, también es un programa.
El mero hecho de reproducirse no implica que el programa sea un virus. Concretamente, este tipo de software que crea y expande copias de sí mismo pero sin unirse a otros programas ni modificarlos suele denominarse gusano. El caso más conocido de gusanos es, sin duda, el gusano de Internet, que Robert Morris Jr. soltó en la red ARPANET en la tarde del miércoles 2 de Noviembre de 1988. En poco más de 3 horas saturó ARPANET, entró en MILNET (la red del Departamento de Defensa americano) y se extendió por Internet, liberando copias de sí mismo de un extremo a otro del continente. Pasada la medianoche las universidades de California en Berkeley, San Diego, Stanford, Maryland, Pardue, el MIT, el Ames Laboratory de la NASA, Aerospace y el Laboratorio de Investigación Balística del ejército en Maryland estaban ya completamente colapsados con copias del gusano. Muchos centros se desconectaron de la red como única forma de evitar que sus ordenadores se paralizaran.
El gusano no modificaba ni destruía nada de los ordenadores en que se colaba. Simplemente aprovechaba un agujero de seguridad en el sendmail -programa que envía y recibe el correo electrónico- que permitía ejecutar comandos como root desde ordenadores remotos, y otro en el finger, que tenía problemas de "buffer overrun", para transmitirse de un ordenador a otro. Era autónomo, y por tanto no era un virus.
Tampoco el hecho de tener comportamientos no esperados ni deseados por parte del que ejecuta un programa es suficiente para catalogarlo como virus. Si no se reproduce se trata, más bien, de un "caballo de Troya", es decir, un programa que aparenta un comportamiento (normalmente atractivo para instar a los usuarios a que lo ejecuten) pero que después lleva a cabo otro tipo de tareas no deseadas o documentadas.
Pero, dentro de los propios virus, hay un extenso vocabulario -normalmente sin traducción, por lo menos generalmente aceptada, al español- que permite catalogarlos y diferenciar distintos comportamientos. Se dice que un virus es polimórfico cuando es capaz de modificar las copias que hace de sí mismo con el objeto de hacer más difícil su identificación por parte de programas antivirus. Esto se consigue, por ejemplo, encriptando con semillas aleatorias dichas copias, usando técnicas distintas de encriptación en cada infección, insertando instrucciones que no tienen efecto sobre el propósito del fragmento de código modificado, o reemplazando instrucciones por otras con el mismo resultado, pero distinto código máquina (para poner el registro AX a cero son equivalentes: "mov ax,0", "sub ax,ax", "xor ax,ax" o "mov ax,FFFF; inc ax".
Un virus se dice que utiliza técnicas stealth cuando incorpora rutinas para tratar de ocultar o disimular sus "huellas". Muchos virus de arranque redirigen las llamadas a la interrupción 13h de la BIOS (encargada del control de discos duros y disqueteras) para que si algún programa de diagnóstico trata de inspeccionar el sector de arranque el virus lo detecte y,en lugar de mostrárselo, redirija la llamada para enseñarle otro sector en el que guarda una copia del sector de arranque original no infectado. De esta forma y mientras el virus esté activo en memoria, la ilusión será que el sector de arranque se encuentra intacto. Para los virus que infectan ejecutables hay técnicas parecidas: normalmente se puede detectar la infección mirando si el programa ha "crecido". Pero si el virus es lo suficientemente inteligente puede interceptar las llamadas al sistema y devolver el tamaño original del fichero y así, al hacer un "dir", parecerá que su tamaño se mantiene como siempre. Todas estas técnicas exigen que el programa se encuentre continuamente residente en memoria; no basta con que se active cada vez que ejecutamos un programa infectado.
Un armoured virus intenta hacer lo más difícil posible el desensamblado y estudio del virus. Utiliza las mismas técnicas que otros programas comerciales que funcionan bien en condiciones normales, pero al intentar inspeccionar su código se "cuelgan".
Un companion virus no modifica los ejecutables. En su lugar crea otro programa que se ejecuta antes que el original, y a continuación llama al que quería el usuario. En PCs ejecutándose bajo DOS esto suele conseguirse creando un fichero con el mismo nombre que el que se quiere suplantar, pero con extensión COM en vez de EXE. De esta forma, si el usuario quiere que se ejecute PROGRAMA.EXE y lo llama escribiendo simplemente "PROGRAMA", pero el virus ha creado ya un "PROGRAMA.COM" será éste el que se ejecute y no el .EXE.
Un cavity virus no añade su código al programa que infecta, sino que lo sobrescribe. Para que el programa infectado siga funcionando es preciso que el virus conozca previamente su estructura interna para que tras la sobrescritura el programa siga funcionando. Evidentemente esto restringe la infección a ficheros muy concretos, especialmente el COMMAND.COM. Uno de los primeros virus, el Lehigh, usaba esta técnica.
Por último, un tunnelling virus es uno particularmente ingenioso y complicado: examina las rutinas de interrupción de la BIOS y el DOS, y va "subiendo" hasta encontrar las rutinas originales. De esta forma, si se ha instalado un antivirus que "espíe" las llamadas a estos servicios, no detectará las acciones de estos virus pues llaman directamente a las rutinas originales sin pasar por las interpuestas por el antivirus.
TUTORIAL DEBUG
A la hora de analizar y eliminar virus será necesario valerse de algunas herramientas tales como desensambladores o editores hexadecimales.
Para la casi totalidad de los casos bastará con un pequeño programa que acompaña al DOS y que, no obstante su utilidad, es un gran desconocido para la mayoría de los usuarios: el DEBUG.
Se trata de una utilidad bastante poco amigable, cierto, sin menús y -sólo en versiones recientes- con ayuda mínima, pero una vez aprendidos unos cuantos comandos es extremadamente potente. Hay quien lo considera como el mejor programa que ha hecho Microsoft.
Debug, invocado sin parámetros, se carga y pasa a mostrar un lacónico guión, a la espera de órdenes del usuario. Todas -a excepción de las relativas a operaciones con memoria expandida, que no se verán aquí- constan de una única letra seguida o no de parámetros. Si se va a desensamblar un programa, se le puede indicar a debug que lo cargue también tras cargarse él escribiendo:
debug nombre-del-programa argumentos-del-programa
El programa no se ejecuta; simplemente se carga en
memoria. Al igual que de la manera anterior, aparece un guión
esperando alguna de las órdenes siguientes:
A: ASSEMBLE
Sin parámetros ensambla las instrucciones que se introduzcan, guardándolas en la dirección siguiente a la que se llegó en el último "a".
También se le puede decir qué zona
se desea ver con a <direccion> pudiendo ser la dirección
absoluta (a segmento:desplazamiento) o relativa al segmento
de código actual (a desplazamiento).
D: DUMP
Muestra el contenido de una zona de memoria en hexadecimal
y en ASCII. Sin parámetros muestra los primeros 128 bytes
a partir de la posición a la que se llegó en el
último "d". Si se le da un rango, mostrará ese rango.
E DIRECCION: EDIT
Permite editar, byte por byte, una zona de memoria. Muestra -en hexadecimal- el byte de esa posición y permite escribir otro valor para cambiarlo. Pulsando espacio pasa al byte siguiente, dejando como estaba el anterior si no se ha cambiado, o guardando los cambios si sí se ha hecho. Para terminar la edición se pulsa Enter.
F: FILL
Llena una zona de memoria con un valor determinado. Como al terminar un programa la zona de memoria en que se residía no se borra (poniéndola a cero, por ejemplo), a menudo es útil para distinguir entre lo que son datos del programa actual y lo que es basura del anterior.
Ej: -f 100 ffff 0
Llena de ceros lo que hay desde la posición 100 (hexadecimal) hasta el final del segmento.
G: GO
Sin parámetros, empieza a ejecutar desde la posición cs:ip hasta que se acabe el programa. Si la orden es "g <direccion>", la ejecución empieza en cs:ip y termina (debug pone un break point) justo antes de ejecutar la instrucción que se encuentra en <direccion>.
H NUM1 NUM2: HEX
Muestra por pantalla el resultado (en hexadecimal)
de las operaciones num1+num2 y num1-num2.
L: LOAD
La sintaxis completa es l
[direccion] [unidad] [sector] [nsectores].
Si se le dan todos los parámetros lee de la unidad dada,
empezando en el sector indicado, tantos sectores como determine
"nsectores" y los guarda en la posición de memoria
especificada por "direccion". Poniendo sólo l
direccion intenta cargar el fichero definido con la orden
n (ver abajo) en esa posición.
M RANGO DIRECCION: MOVE
Mueve la zona de memoria delimitada por "rango" a la dirección "direccion".
N NOMBRE: NAME
Da un nombre de fichero sobre el que actúan l y w.
P: STEP
Trace puede ser incómodo si no se quiere depurar el código de las rutinas de interrupción (cosa en general poco útil, ... salvo que estemos tratando con virus) o si ya se sabe el código que hay en las subrutinas y tan sólo interesa seguir avanzando sin entrar en ellas. En estos casos se usa p.
Q: QUIT
Salir de debug y volver al DOS.
R: REGISTERS
Sin parámetros, muestra el contenido de los registros de la CPU, así como la próxima instrucción a ejecutar.
r registro muestra el contenido del registro especificado y cambia el prompt de "-" a ":" invitando a que se cambie su valor. Pulsando Enter sin más lo deja como estaba.
S: SEARCH
Busca una secuencia de bytes o una cadena en el rango especificado, mostrando la dirección en que aparece en pantalla. s 100 500 cd 13 Busca todas las llamadas a la interrupción 13h (código máquina cdh 13h). s 100:0 ffff "virus" muestra las zonas de memoria del segmento 100h en que aparece la palabra "virus".
T: TRACE
Ejecuta la instrucción apuntada por cs:ip y vuelve a debug. Permite ejecutar paso a paso un programa -o un virus- y observar en cada instrucción el efecto producido. Si haciendo "trace" se llega a una subrutina (CALL) o a una interrupción (INT) la siguiente instrucción que se ejecutará será la primera de la subrutina o la primera de la rutina de atención de la interrupción correspondiente.
U : UNASSEMBLE
Desensambla una zona de memoria. Si no se le dan parámetros empieza a hacerlo en la dirección apuntada por cs:ip. También se le puede decir qué zona se quiere ver con u <dirección> pudiendo ser la dirección absoluta (u segmento:desplazamiento) o relativa al segmento de código actual (u desplazamiento).
Si se da un rango de direcciones desensamblará esa zona: u 1000 2000 desensambla el código que haya desde cs:1000 a cs:2000. Todos los números son tratados como hexadecimales, así que u 1000 empieza a desensamblar desde la posición 4096 (decimal) del segmento de código.
W: WRITE
La sintaxis completa es w [direccion] [unidad] [sector] [nsectores] Con todos los parámetros escribe en la unidad y sectores dados el contenido de la dirección de memoria.
Pasándole sólo la dirección escribe en el fichero definido con n (ver arriba) tantos bytes como determinen el par de registros BX:CX a partir de la posición de memoria dada.
?: AYUDA?
En versiones recientes de MS-DOS (por lo menos a partir de la 5) muestra una mini-ayuda.
Existen algunas órdenes más para tratar con memoria expandida y
otras operaciones que no serán de especial relevancia para el tema que
nos ocupa.
Para asentar ideas y de paso aprender algunos pasos
útiles a los que se hará referencia varias veces
a lo largo de esta entrega se verán, para acabar, unos
ejemplos.
Guardar una copia del sector de arranque del disco duro en el fichero a:sector.arr
C:\> debug
-l 100 2 0 1
-na:sector.arr
-w100
-q
Guardar una copia de la tabla de particiones del
primer disco duro. Esto requiere llamar a rutinas de la BIOS puesto
que ese sector está fuera de la partición lógica
DOS (esto se explicará con detalle en la próxima
entrega):
C:\> debug
-a
XXXX:100 mov ax,0201
XXXX:103 mov bx,7c00
XXXX:106 mov cx,1
XXXX:109 mov dx,80
XXXX:10C int 13
XXXX:10E int 20
XXXX:110
-g
El programa ha terminado de forma normal
-r cx
CX XXXX
:200
-n a:partic.tbl
-w 7c00
Escribiendo 00200 bytes
-q
Como ejercicio, se puede echar un vistazo a la tabla
de particiones (usando "d"), que tras ejecutar el mini-programa
anterior queda en ES:7c00, y luego desensamblarla ("u")
para ver lo que hace. Servirá de preparación para
el mes que viene, en que se estudiará en detalle.
|