Virus en Linux (y II)

Por Pablo Garaizar Sagarminaga

[Primera parte: Introducción a los virus]

En Linux no hay virus... ¡Falso!

Objetivos y técnicas

Scripts: sh, Perl

Los lenguajes interpretados han sido una constante en todo sistema UNIX. Actualmente los más utilizados son los scripts de shell y Perl. Programar un virus en estos lenguajes es un juego de niños. Aquí tenemos un ejemplo de un virus de shell sencillo:

#!/bin/sh
for FICHERO in *
do
  tail -4 $0 >> $FICHERO
done

¿Qué hace? Va copiando sus cuatro últimas líneas (tail -4 $0) al final de cada fichero en este directorio (">>" es append, o añadir al final). Como podemos ver, es un virus bastante tonto, infecta tanto ejecutables como ficheros de datos, y puede dejarlos inutilizados, pero con unas pocas decenas de líneas más podría hacerse algo más presentable...

La sencillez de estos virus es su ventaja para sus programadores, pero también su debilidad: son tremendamente fáciles de detectar a simple vista, engordan el tamaño del fichero infectado considerablemente y realentizan su ejecución más allá de lo que podría resultar imperceptible por un usuario normal.

Binarios

a.out

Es un formato realmente simple, casi tanto como los COM de DOS. Actualmente este tipo de ejecutables está en desuso, pero todavía quedan sistemas con a.out's (a pesar de que el compilador genere un fichero llamado "a.out", eso no implica que tenga este formato, casi con seguridad se tratará de un ELF).

Formato de un a.out:

Infeccion de ejecutables a.out

Se puede optar por aumentar el tamaño de la sección de código (.text) y desplazar el resto del archivo, o por tratar de encontrar una cavidad (cavity) para instalar el virus allí. El virus, además, deberá modificar la cabecera para reflejar los cambios (diferente tamaño de secciones, diferente entry point...).

ELF

El formato ELF es el más utilizado hoy en día en los ejecutables para UNIX. Es un formato muy flexible y bastante bien diseñado.

Formato de un ELF:

Un ELF frente a un a.out:

Infeccion de ejecutables ELF

Las investigaciones más serias en este campo vienen de la mano de Silvio Cesare. Ha publicado ya numerosos artículos acerca de este tema, y todos sus virus han sido programados en C, para poder ser compilados en cualquier sistema UNIX. El método que utiliza es el siguiente:

• Incrementar un campo en la cabecera del ELF (p_shoff) que indica el desplazamiento u offset donde se encuentra la tabla de cabecera de secciones (Section header table).
• Hallar la cabecera de programa del segmento de código y:
• Incrementar la variable que indica el tamaño que ocupa el código físicamente (p_filesz).
• Incrementar la variable que indica el tamaño que ocupa el código cuando se carga en memoria (p_memsz).
• Para cada cabecera de programa cuyo segmento está después del de código (que es donde hemos introducido el virus):
  • Incrementar el offset del segmento en el fichero (p_offset).
• Para cada cabecera de sección cuya sección esté después de nuestra inserción:
  • Incrementar sh_offset, para tener en cuenta el nuevo código.
• Insertar el virus en sí en el fichero

Esto puede parecer un lío para más de uno, pero en pocas palabras lo que se trata es de hacer el tamaño del segmento de código más grande, para hacer espacio para el virus. Luego hay que actualizar todos los valore,s para que el código nuevo se cargue, y cambiar el entry point para que apunte al virus.

Infección de un ELF por el método de Silvio Cesare:

Este método de infección funciona perfectamente, pero no es el único. Wintermute presentó en el hackmeeting de 2000 un nuevo virus para Linux, el Lotek, que realizaba una infección aprovechando una cavidad (cavity) en la sección ".note".

Recientemente el ex-VXer Bumblebee ha publicado un virus para Linux con residencia per-process en RING-3 y unas cuantas técnicas aprendidas en entornos win32. Muchas de las estructuras de win32 tienen su paralelismo en Linux, por lo que gran cantidad de técnicas pueden portarse fácilmente a los virus de Linux.

Ficheros de fuentes

Hay algunos intentos de infectar ficheros fuente en lugar de binarios. Se puede realizar un enfoque desde el punto de vista de ensamblador "inline" o embebido dentro del código, o bien un ejecutable que genere fuente como salida.

Packages: .deb, .rpm, .mdk

Un punto todavía poco explotado es el de los paquetes de software de las diferentes distribuciones de Linux. Mucha gente utiliza paquetes para instalar programas de manera sencilla y ordenada, y en ocasiones esos paquetes son descargados por un usuario sin privilegios desde un navegador, para ser instalados posteriormente por "root". En ese intervalo de tiempo en el que permanecen en el directorio del usuario sin privilegios, podrían ser infectados y luego, al ser instalados por "root", acceder a todo el sistema.

Un paquete generalmente tiene comprobaciones mediante MD5, pero pueden recalcularse, por lo que éste puede ser un punto flaco importante en nuestras distribuciones Linux.

Infección de un paquete .deb tras ser descargado por un usuario desde su navegador:

Ya, pero Linux es seguro, ¿no?

Linux es seguro

Sí, Linux es bastante seguro. De hecho un virus deberá utilizar algun despiste de configuración en el sistema para poder colarse hasta tener acceso a todas sus partes.

Está claro que actualmente usar Linux es el mejor antivirus que existe. No he visto a nadie que haya sufrido un virus en Linux y eso que conozco a mucha gente que usa Linux masivamente. Es posible que con el tiempo esta situación vaya cambiando y Linux sea otro escenario donde se libren las batallas entre programadores de virus y de antivirus. Por el momento, salvo experimentos de laboratorio, estamos a salvo.

¿Cómo podemos hacer una escalada de privilegios?

Exploits

Un exploit es un programa que aprovecha un fallo en el sistema para conseguir algo no permitido de él. Si un virus incluye ese código dentro del suyo, podría conseguir acceder a zonas no permitidas y hacerse con el control del sistema.

Este enfoque ha sido utilizado en varios virus para Linux, como el staog por Quantum/VLAD, pero implica la extinción del virus en cuanto el fallo que explota el exploit sea subsanado. Algunos virus intentan aprovecharse del exploit, y si no tiene éxito, eliminan el código del exploit del resto de infecciones.

Este enfoque es más propio de entornos menos dinámicos en cuanto a correcciones de fallos en programas, como Windows (poca gente actualiza periódicamente su navegador o su editor de textos). En entornos de desarrollo open source los fallos suelen ser detectados y subsanados más dinámicamente.

LKMs (Loadable Kernel Modules)

Hemos dicho en la introducción que el núcleo de Linux es monolítico, pero tiene un sistema de carga y descarga de módulos que permite un uso más eficiente de los controladores de dispositivos (drivers).

Un módulo del kernel (o LKM) se ejecuta en RING-0, dentro del espacio reservado para el kernel, es decir, tiene un poder total sobre la máquina. Es posible programar LKMs que tengan más poder o que engañen a "root", por lo que si un virus lograse cargar un módulo dentro del módulo, podría ser una pesadilla para el administrador de la máquina, y el único límite de acción serían las limitaciones físicas de los dispositivos.

Con un LKM se puede hacer de todo: ocultar procesos, modificar tamaños de archivos, etc. por lo que puede que los futuros virus de Linux incluyan LKMs para sus propósitos.

Windows/Linux

Muchos de los ordenadores personales que utilizan los usuarios de Linux, aunque a veces cueste reconocerlo, tienen una partición con Windows. Existen varias herramientas para acceder a particiones Linux desde Windows, de las que explore2fs quizá sea la más conocida.

Si un virus atacase un sistema Windows, consiguiese los privilegios suficientes como para acceder al disco duro y buscar un fichero clave dentro de la partición Linux -como pueda ser "init" (el proceso inicial del que se crean todos los demás proceos) o la shell que use "root"- todas las protecciones de Linux como tal habrían sido inútiles. Aunque suene un poco fuerte: la inseguridad inherente de Windows actuaría como "Caballo de Troya" contra el sistema Linux.

Existe otra herramienta bastante utilizada, VMWare, que permite tener varias máquinas virtuales corriendo Sistemas Operativos diferentes. Es también muy común tener Windows y Linux funcionando al mismo tiempo con VMWare. En lugar de tener que esperar a que el sistema rearranque con Linux como en el caso anterior, la infección podría hacerse directamente, ya que VMWare es fácilmente detectable (utiliza un RING que no es ni 0 ni 3).

fork() y crack

Un virus desde una cuenta de usuario podría armarse de paciencia y crear un proceso con muy baja prioridad (para no interferir en el rendimiento normal del sistema) que intentase crackear las contraseñas por fuerza bruta.

Imaginemos un sistema automatizado, en el que el administrador entra sólo cada semana a retocar 4 cosas, pero no hay una supervisión real. Un virus podría colarse desde una cuenta sin privilegios, y estar un par de semanas intentando crackear las contraseñas. Una vez conseguido esto, sólo queda dar el salto a "root" y de ahí a donde quiera (kernel, otros ordenadores...).

Entonces... ¿por qué no hay (casi) virus para Linux?

Perfil del usuario medio

Actualmente el usuario medio de Linux tiene poco que ver con el usuario medio de Windows o Macintosh. Quizá mucha gente cayó con lo de "Enanito sí, pero que pedazo de coj...", pero esto tendría poco éxito en un entorno de usuarios de Linux.

La gente acostumbra a conocer el origen de sus programas, y examina su código fuente. No quiero decir que todos los usuarios de Linux lo hagan, pero sí hay un grupo importante de gente que lo hace y lo comenta al resto.

Las llamadas "técnicas de ingeniería social" (es decir, hacer uso de la candidez del usuario que recibe un virus o gusano) tienen muchas más dificultades con usuarios de Linux.

Filosofía del software

Como acabo de comentar, que Linux sea de código abierto y haya una mentalidad clara en cuanto a ese tema, dificulta ocultar código en los programas.

Ken Thompson dijo que ningún software creado por otro podía ser confiable, especialmente si había sido creado por él. Tal y como explicó en una conferencia en mitad de la década de los 80, Thompson había introducido un sistema de autorreplicación y "troyanización" en todo compilador C para UNIX que le permitió hasta entonces poder entrar como "root" en todo sistema hasta la fecha. Si alguien quiere saber cómo se las ingenió el bueno de Thompson, lo explicaré por email gustosamente, o bien esperáis al turno de preguntas O:-)

Pocos VXers linuxeros

Todavía hay pocos escritores de virus que usan Linux habitualmente. Algunos han instalado Linux en una partición para hacer sus pruebas y conocen bastantes cosas de él, pero no tienen en absoluto la soltura que han conseguido durante años de uso de DOS y Windows.

Supongo que esto cambiará con el tiempo, y pronto los VXers usarán Linux a diario. Cuando esto ocurra, yo creo que habrá una nueva hornada de virus para Linux programados desde la experiencia, no como un experimento de laboratorio.

¿Y qué puede pasar en el futuro?

• Más usuarios novatos
• Más empresas usan Linux -> Menos Open Source
• Más configuraciones "click&play" -> Menos robustez del sistema
• Más VXers linuxeros

Conclusión

Solución: una buena "salud" informática

Es decir:

• Actualizar las versiones de nuestros programas para evitar bugs.
• Conseguir los programas de fuentes fidedignas.
• Utilizar siempre que sea posible la versión en código fuente de los programas.
• No ejecutar todo lo que nos llegue por Internet
• ...

Todo ese tipo de cosas que, como espero haya quedado claro ;-), utilizan los virus para colarse en nuestros sistemas.

Para saber más...

• http://vx.netlux.org/29a: Página de 29a, el grupo de virus de más nivel de la viruscene actual.
• http://pagina.de/wintermute: Página de wintermute, gran VXer y amigo ;-)
• http://linuxassembly.org: Página de ensamblador en Linux