La semana pasada tuvo lugar en Estocolmo, la 4ª conferencia europea sobre investigación en seguridad, Security Research Conference (SRC’09).

El nivel de participación fue francamente alto, más de 500 inscripciones, lo que pone de manifiesto el interés generalizado que despiertan todos los temas relativos a la seguridad dentro y fuera de nuestras fronteras. La delegación española estaba compuesta por 49 personas de empresas, universidades y organismos públicos.
Aunque como es habitual en estos eventos el nivel de profundidad alcanzado en las exposiciones de los ponentes no puede ser mucho, sí nos permite hacernos una idea de los campos en los que se está investigando y desarrollando iniciativas a nivel europeo poniendo de manifiesto las áreas de interés de los distintos actores o stakeholders (ciudadanos, administración, empresas, etc…)

Siguiendo las recomendaciones que en su día realizó la ESRAB, “European Security Research Advisory Board“ en su informe “Meeting the Challenge: The European Security Research Agenda”, en esta cuarta edición de la conferencia tuvimos la oportunidad de asistir a la presentación de proyectos enmarcados en el ámbito de las cuatro principales áreas de trabajo o misiones que identificó el informe que les indicaba, y que son la base de la Call 3 de Seguridad del 7º Programa Marco:

• Seguridad de los ciudadanos
• Seguridad de las infraestructuras críticas y “utilities”
• Seguridad de las fronteras y vigilancia inteligente
• Gestión de crisis

Todos los avances presentados, como consecuencia de los proyectos de investigación y desarrollo apoyados por la Comisión, contribuyen, en definitiva, a mejorar y desarrollar capacidades que salvaguardan la seguridad a través del desarrollo de tecnologías y conocimiento en estas áreas.

Tuvimos también la oportunidad de conocer, de primera mano, las conclusiones del informe que va a publicar en las próximas semanas la entidad que recogió el testigo de ESRAB hace un par de años: la ESRIF, “European Security Research & Innovation Forum“, de las que ya existe un resumen ejecutivo y que podrán consultarse en su sitio web en breve. Asistimos además al anuncio de la creación de la ESRIA, “European Security Research and Innovation Agenda”, organizada en torno a cinco grandes clusters que abarcan desde el ciclo clásico de la seguridad (prevención, protección, detección, respuesta y recuperación) hasta la securización de identidades, accesos y movimientos de personas y mercancías, pasando por la seguridad de los activos críticos o la identificación de diferentes medios de ataque.

A las puertas del cierre de la Call 3 relativa a Seguridad del 7º Programa Marco, las conferencias fueron también punto de encuentro para el desarrollo de las propuestas. En definitiva, mucha información concentrada en poco tiempo, pero que nos permite analizar el pulso del mercado de la seguridad global en Europa, y conocer las líneas estratégicas hacia las que se van a dirigir los proyectos en los próximos años.

Vaya por delante que cualquier parecido de lo que les voy a contar con la realidad es pura coincidencia. Vamos, que se trata de una situación hipotética, que no se trata de un caso “tengo un amigo que”. Vamos con ello.

Imagine que usted descubre un día, por casualidad o mientras investigaba, un gran problema de seguridad en el software o hardware de uno de los grandes. Cuando digo grande, me refiero grande en ambos sentidos; uno de esos que hacen desplomarse las cotizaciones en bolsa del afectado: Microsoft, Sony, Dell, Google, Hewlett Packard, Oracle, Intel, etc. Vamos, un problema de los gordos para una compañía de las gordas.

Podemos asumir que el primer paso que muchos darían, excepto aquellos interesados por aprovechar el problema de seguridad in the wild —a los que vamos a dejar de lado en este hilo de suposiciones— sería ponerse en contacto con la compañía para comunicarle el hallazgo. Sin embargo, aunque es razonable esperar una respuesta positiva por parte de ésta, no podemos descartar que descubrir algo que puede suponerle una terrible migraña al fabricante ponga en acción a su equipo de abogados, y éste te llame a ti, amenazándote con una demanda y una posible indemnización millonaria por daños y perjuicios a la marca si el tema se hace público. Que tengan o no razón nos da lo mismo; meterse en algo así es un problema ganes o pierdas.

Así que, previniendo eso, la comunicación con el proveedor se hace de manera segura, y tomando todas las precauciones razonables para que éste no pueda averiguar la procedencia del mensaje, le hacemos llegar a la empresa en cuestión el problema. Pasan los días, pero nada pasa. No hay anuncios oficiales, no hay ningún tipo de parche de seguridad; como si nada hubiese pasado, un mes, dos meses, tres meses, y nada, absolutamente nada. Vacío.

Llegado este punto, usted ha hecho todo lo que es razonable, y dado que está totalmente en contra de que la seguridad pueda alcanzarse a través de la oscuridad (Security thru obscurity), se plantea hacer público su hallazgo. No hay nada peor que un problema de seguridad que el fabricante no ve la necesidad de parchear, porque no es público. Al final siempre habrá gente que lo conozca, dispuesta a aprovecharlo. Siempre.

Claro que aquí volvemos al problema del inicio: exponerse a una demanda millonaria, aparte de vayaustedasaber qué técnicas de desprestigio personal que pueden afectar seriamente a su vida profesional (entre otras cosas). La primera opción sería recurrir al anonimato; colgar la vulnerabilidad en cualquier foro, dando los detalles de la vulnerabilidad y la respuesta de la empresa, y poner todas las medidas posibles para ser virtualmente ilocalizable. Claro que eso tiene dos pegas: la primera, que renuncia usted a cualquier tipo de prestigio o reconocimiento por el descubrimiento, y la segunda, que siempre quedan huellas y por tanto la posibilidad de que den con usted.

Es obvio que se trata de una hipótesis, y que la empresa no tiene porqué comportarse de esa manera, pero eso es algo a lo que no vale la pena arriesgarse. A la vista de todo lo anterior, ¿renunciaría usted a la publicación de la vulnerabilidad, dejando que unas semanas, meses o años más tarde fuese otro quien se llevase los laureles… y los problemas? ¿Dejaría un problema de esta magnitud tapado?

¿Qué haría usted?

(La fotografía es del mayor agujero del mundo, una mina de diamantes en Mirna, en Siberia [Google maps])

—

(Hemos visto que la práctica totalidad de las cuentas de Hotmail suscritas al blog por e-mail no han sido verificadas. Si es su caso, por favor revise la carpeta de correo basura y verifique la suscripción. Pasen un buen fin de semana.)

Hace un tiempo solicitamos a nuestros lectores que respondieran a una cuestión aparentemente sencilla:

[Read more…]

En nuestro trabajo habitual, a menudo nos hemos encontrado con información muy útil sobre aplicaciones de backups, tales como problemas solucionados, scripts de uso, consejos de optimización, trucos, etc.

Para poder compartirla, nos gustaría saber cuales son los sistemas de backups más usados por nuestros lectores. Hemos incluido en la encuesta los más usados en entornos empresariales, aunque también nos pueden decir cual es el que usan ustedes. Si usan el xcopy de windows, o incluso no hacen copia….. ¡¡mejor pasen por aquí mas a menudo!!

(Mañana comentaremos el resultado de la anterior encuesta —la que tienen a la derecha— y pasaremos esta al lateral…)

No sé cómo se habrán sentido ustedes tras observar la polémica suscitada por la publicación de la famosa fotografía de las hijas del presidente del gobierno en el Metropolitan de Nueva York, y observar —cada vez me sorprende más lo desocupados y aburridos que pueden llegar a estar mis congéneres— esa especie de “variaciones sobre el mismo tema” en que se ha convertido la generación de fotografías de las menores cambiando el escenario, los rostros y los aderezos de los retratados.

No voy a entrar en la disquisición de dónde termina el círculo privado y empieza el ámbito público, tema más propio de uno de estos “programas” de “prensa” rosa/morbosa. Con independencia de lo que se piense (¿era o no era un viaje privado? ¿Un presidente de gobierno y su familia son o no son personajes públicos?), personalmente me parece preocupante la falta de respeto general observada al tratar el tema después de leer/oír los comentarios vertidos en los medios de comunicación, partiendo de la base de que se trata de menores de edad.

Sólo me remitiré a lo dicho por el artículo 4.3. de la Ley 1/1996 de Protección Jurídica del Menor:

Pero con independencia de esta ley, ¿demonizar a unas niñas en función de su manera de vestir? Pensaba que vivíamos en un país más avanzado, que no juzga la educación o la calidad humana de una persona por su manera de vestir, pero en fin, veo que sigo equivocado… En cualquier caso, aunque es un tema interesante no es esto de lo que quería hablarles.

Al hilo de un post de Javier Cao en su blog sobre la aparición de esta fotografía en Internet, quería proponerles el siguiente aspecto que, como no podía ser de otra manera, entronca con la gestión de la seguridad de la información.

Vayamos al origen de la situación. Al parecer —y corríjanme si estoy equivocado, porque no lo sé a ciencia cierta— la famosa foto fue publicada en la página web de la Casa Blanca y/o en la galería que el Departamento de Estado norteamericano tiene en flickr. Me da igual. En cualquiera de los dos casos, si vamos tirando del hilo, llegaremos al culpable de la publicación de la famosa foto, al responsable de todo esto… ¡Ya lo tenemos! ¡Que detengan al webmaster de la Casa Blanca! ¡O al “currito” que gestiona la galería de fotos del Departamento de Estado!… ¿O no?

Porque ¿quién decide si un usuario de una organización tiene o no tiene acceso a un determinado recurso? O yendo más lejos, ¿quién determina si una información es pública, restringida, confidencial, secreta? ¿El técnico que va a asignar los privilegios de acceso al directorio?

Porque un técnico no determina por su cuenta y riesgo si el documento de seguridad de una organización se publica en la zona pública de un servidor de ficheros o no, o a qué grupos de usuarios se les da permisos de acceso al directorio “Gerencia”… Lo lógico sería abordar un estudio de clasificación de la información, atendiendo a criterios organizativos y de negocio, ¿no? Evidentemente esta clasificación de la información provocará la creación de procedimientos que regulen su tratamiento, definiendo, entre otros aspectos, los permisos de acceso que los técnicos de sistemas tendrán que asignar a los recursos. Pero evidentemente éstos no serán los responsables de la asignación formal, de la definición de los permisos de acceso, serán responsables “solamente” de la asignación técnica. “Alguien” habrá definido previamente los mismos.

El caso concreto de la publicación de la famosa fotografía, además de poner encima de la mesa la necesidad de establecer normas o leyes supranacionales que protejan determinados derechos básicos de las personas, con independencia del país en el que nos encontremos (por ejemplo la protección de los datos personales en USA brilla por su ausencia…), en mi modesta opinión subraya el papel fundamental que deben jugar en la gestión de la seguridad de la información los responsables funcionales, responsables organizativos, encargados de definir el protocolo a seguir y de determinar/supervisar/otorgar las autorizaciones necesarias, ya sea para asignar los permisos de acceso a un estudiante en prácticas, para autorizar la restauración de la copia de seguridad de una determinada información, …. o para publicar una fotografía en Internet.

Tal como vimos en la entrada anterior, estamos intentando contrastar la información respecto a un fallo de seguridad en el FTP del IIS. Nos hemos dado cuenta de que tras ejecutar el exploit en todas sus versiones, no ha funcionado pese a ejecutarse sin fallos.

Revisando los logs del ftp, comprobando el tráfico con el tcpdump, y revisando el código del exploit seguíamos sin saber el motivo por el cual éste no funcionaba. La última opción que nos faltaba era usar el ollydbg con el inetinfo.exe, así como todo aquel programa que tenga relación con el FTP e intentar averiguar por qué el exploit fallaba. Pero lógicamente esto requería de un tiempo del que no disponíamos.

Analizando los motivos por el cual era posible que el exploit no funcionara decidimos realizar una maqueta lo más real posible. Instalamos un windows sobre una máquina física y conectamos a ésta otra máquina física que sería la máquina atacante. Pero el resultado fue el mismo: el exploit no funcionaba.

Analizando de nuevo el código, nos dimos cuenta que había direcciones estáticas, en concreto esta:

$retaddr = "\x9B\xB1\xF4\x77";

Esto nos hizo pensar que posiblemente esa dirección funcionara únicamente para la versión de Windows que tuviese el creador del exploit, la que resultó ser ni más ni menos que un windows 2000 pero en INGLÉS. Efectivamente, instalamos una versión en ingles sobre una máquina virtual para intentarlo de nuevo, y esta vez sí, el exploit funcionó concediendo una shell en el sistema atacado con permisos de usuario SYSTEM:

Esto confirmaba nuestras sospechas: el motivo del fallo en la ejecución del exploit era a causa de que éste toma las direcciones estáticas pensadas para funcionar sobre un windows en ingles. Lógicamente, si pensamos apilar la palabra “hello“, ésta requiere de 5 bytes mientras que la palabra “hola” requiere de 4 bytes, por lo que es muy posible que la dirección no fuera la misma en la versión en castellano.

Para terminar de confirmarlo pensamos en qué usuarios que no fueran de habla inglesa habrían buscado cual era la dirección correcta para ejecutar el exploit en sus sistemas. Me vinieron rápidamente a la cabeza los alemanes, así que me decidí a realizar búsquedas en foros alemanes que trataran el tema y por fin lo localice. Un usuario había publicado una variante del exploit para aquellas versiones de Windows en alemán, y tal como pensábamos, únicamente había que modificar la dirección del “retaddr”.

Por tanto, la vulnerabilidad existe, es un zero-day —ya que el creador del exploit no notificó al fabricante—, no hay todavía parche que la solucione y lo más importante, los sistemas en castellano si son vulnerables; lo único que el atacante debe hacer es modificar el retaddr del exploit por el que toca para entornos en castellano.

Entonces, ¿es una alerta grave? Si se cumplen los requisitos es gravísima, pero seamos sinceros, ¿qué administrador de sistemas concede permisos de escritura a usuarios anónimos o otros usuarios genéricos que no tengan contraseña? (alguno dirá que muchos, pero yo no llamaría a esos “administrador de sistemas”).

Donde reside realmente el problema de esta vulnerabilidad es en aquellos usuarios, que aunque protegidos con contraseñas, tengan permisos de escritura en el ftp. Si el atacante mediante diversos medios consigue obtener la contraseña del ftp del usuario podrá obtener una shell en el servidor. Teniendo en cuenta que las contraseñas del ftp se transmiten en texto plano, y que los usuarios por naturaleza no suelen tener excesivo cuidado en cuanto a la seguridad de sus máquinas personales, esta vulnerabilidad se convierte en un fallo de seguridad importante.

¿Solución? Pues hasta que salga el parche correspondiente para esta vulnerabilidad, la solución no es otra que revocar permisos de escritura a todos los usuarios, y emplear otros medios para subir los datos al ftp. De esta forma, todas las aplicaciones que dependan de la lectura de datos del ftp seguirán funcionando. Es algo “estricta”, pero si alguno de ustedes tiene una idea mejor, por favor que la indique en los comentarios.

Les voy a contar mi pequeña experiencia con un incidente ocurrido hace unas semanas atrás relacionado con una vulnerabilidad en el FTP del IIS. Ésta afecta tanto a la versión 5.0, 5.1, 6.0 y 7.0, provocando una denegación de servicios [Véase boletín de seguridad de Microsoft], pero es en la versión 5.0 donde la vulnerabilidad es más grave, debido a que hay suficiente espacio como para introducir código. Esto ha dado lugar a dos versiones adicionales del exploit: una permite crear usuarios en el sistemas y la otra la ejecución de una shell remota.

Era finales de agosto cuando comenzaron a llegar noticias de un zero-day en el ftp del IIS. Como todo lo que ocurre con vulnerabilidades de entornos Microsoft, siempre es difícil medir cuánto de toda la información que te llega es verdad. Lo primero es comprobar que realmente no es un bulo y efectivamente, no lo era; demasiadas fuentes apuntaban a este fallo de seguridad grave.

Nos pusimos manos a la obra, y obtuvimos los exploits, los nse del nmap para comprobar la vulnerabilidad, y preparamos una maqueta virtual de un entorno de pruebas que cumpliera todos los requisitos: un servidor FTP del IIS con un usuario con permisos de escritura. Pese a que algunas informaciones apuntaban a que no se requería permisos de escritura, todas las pruebas realizadas apuntan a que se requieren permisos de escritura en el FTP para poder ejecutar dicha vulnerabilidad.

Una vez preparada la maqueta, un Windows 2000 SP4 con el FTP IIS 5.0 habilitado con el usuario anónimo con permisos de escritura, ejecutamos el nse del nmap para comprobar si el sistema lo detectaba como vulnerable y de esta forma poder saber que máquinas eran vulnerables.

Al ejecutarlo nos llevamos el primer chasco: el nse que se ofrecía en las webs de seguridad nos decía que el servidor no era vulnerable. Mirando el código vimos que el nse comprobaba si las respuestas del servidor se correspondían con la firma típica del FTP IIS. Si esto era cierto, se intentaba conectar con usuario anónimo y escribir un directorio en el FTP, tras cuya escritura (y por tanto vulnerable el FTP) eliminaba el directorio creado y notificaba que el servidor es vulnerable. No obstante, en nuestro caso nos indicaba que no lo era:

# nmap -p 21 -sV 192.168.244.129 --script=IIS-FTP --script-trace

Starting Nmap 5.00 ( http://nmap.org ) at 2009-09-01 22:12 CEST
NSOCK (0.3340s) nsock_loop() started (timeout=50ms). 0 events pending
...
NSOCK (5.3400s) nsock_loop() started (timeout=50ms). 0 events pending
NSE: TCP 192.168.244.1:54540 > 192.168.244.129:21 | CLOSE
Interesting ports on 192.168.244.129:
PORT STATE SERVICE VERSION
21/tcp open ftp Microsoft ftpd 5.0

Mirando y analizando detenidamente paso por paso el código del nse, vemos que la negociación entre el nmap y el servidor FTP no coincide con los mensajes que está devolviendo el servidor FTP al iniciar la conexión. Esta es la razón de que indicase que no era vulnerable cuando realmente cumplía todos los requisitos. Además, hay que tener en cuenta que un servidor que respondiese con una firma modificada por el administrador no cumpliría con los requisitos del script y nos diría que no era vulnerable (de ahí la importancia de modificar la “imagen pública” de un servidor web). Por último, el script estaba preparado para entrar con cuenta anónima con permisos de escritura, pero lógicamente podría tratarse de un FTP con cuentas con permisos de escritura, pero que tuviera la cuenta anónima deshabilitada. Por todo ello el nse ofrecido no era una solución adecuada.

Analizando alternativas, llegamos a la conclusión de que con un simple bucle que usaras las marcas de la firma (-sV) cuya firma fuera “Microsoft ftpd” sería un servidor vulnerable a este fallo de seguridad. Un vez ejecutado y obtenido que servidores eran vulnerables podríamos notificar a los administradores que máquinas tenían el fallo de seguridad y estos comprobaran que usuarios tenían permisos de escritura para revocarlos temporalmente. El script empleado fue el siguiente:

#!/bin/sh 
[ $# -eq 1 ] || { echo "USAGE: $0 RED" && exit 1; } 
for i in `seq 1 254`; 
do 
        RES=`nmap -p 21 -sV $1.$i | grep -i 'Microsoft ftpd' 2> /dev/null` 
        [ "$RES" = "" ] || { echo "$1.$i" >> "vulnerable_FTP.txt"; } 
done

Su ejecución sobre la red virtual de pruebas fue la siguiente:

$ ./miscript.sh 192.168.244
$ cat vulnerable_FTP.txt
192.168.244.129

Una vez tenemos un mecanismo que nos permite detectar los servidores vulnerables, nos dedicamos a analizar cual era el funcionamiento del exploit. Tal como pensábamos, son necesarios permisos de escritura para ir sobrescribiendo la pila hasta tenerla justo donde el atacante quiere, y modificar entonces la dirección de vuelta. Como se ha comentado al principio del artículo existen tres versiones del exploit para el FTP IIS 5.0: una deniega el servicio, otra crea un usuario y la última obtiene una shell.

Así que nos ponemos manos a la obra y cogemos el exploit que permite crear una shell remota. Ejecutamos el exploit sobre nuestra máquina virtual, y en este caso parece que funciona ya que se ejecuta correctamente… pero no. Llega la segunda sorpresa del día: el exploit tampoco en este caso funciona, ni tampoco las otras versiones del exploit. Ni usuario, ni shell ni denegación de servicios… el exploit sencillamente no funciona. ¿Por qué?

Lo veremos mañana, en la siguiente entrada. Permanezcan atentos.

Para acabar con esta serie de entradas sobre los ataques de buffer overflow, y una vez explicadas las bases, vamos a ejecutar el programa que vimos en la entrada anterior varias veces, para ver cual es la posición del EPI (dirección de la siguiente línea a ejecutar):

user1@base:~/Desktop> for i in `seq 1 5`; do ./prueba | grep Premio; done
Premio: Valor: 0x29 PosMem: 0xBFFFF04C
Premio: Valor: 0x29 PosMem: 0xBFFFF04C
Premio: Valor: 0x29 PosMem: 0xBFFFF04C
Premio: Valor: 0x29 PosMem: 0xBFFFF04C
Premio: Valor: 0x29 PosMem: 0xBFFFF04C

[Read more…]

Tras el pequeño rollo teórico que vimos ayer, hoy toca entrar de lleno en las cuestiones prácticas, que espero que aclaren todas las dudas que ayer pudieran surgir. Veamos el siguiente trozo de código en C de 4 líneas. La primera instrucción asigna el valor 9 a la variable X, la segunda llama a una función, la tercera le asigna a X el valor 1 y la siguiente línea mostrará el valor de X:

La función lo que va a hacer es obtener la dirección donde se guarda el EIP (dirección de la siguiente
línea a ejecutar), de tal forma que modificaremos su contenido para que en vez de saltar a la
siguiente línea que sería “x = 1″, salte al “printf” mostrando que x es igual a 9, y no 1 que sería lo esperado.

Antes de mostrar el código completo recordar un par de cosas:

• En relación con los punteros, recordar que si yo declaro un puntero “int *p;”, para modificar la dirección donde apunta debo hacer “p = dirección;”, y a su vez, para modificar el valor (el contenido) del dato donde apunta el puntero se realiza “*p = dato;”.
• La segunda es que la memoria se numera por bytes (8 bits) y está agrupada por palabras, siendo una palabra 32 bits es decir, 4 bytes. Por tanto, un registro que guarde una dirección de memoria ocupa una palabra, es decir 4 bytes (32 bits). Por último, recordar que un char ocupa 1 byte, y en una palabra caben 4 chars.

Con esto, pasemos al código:

#include <stdio.h>
void funct(int a, int b, int c){
     int i, j;
     char buffer[4];
     char *ret;
     buffer[0] = 'A';
     buffer[1] = 'B';
     buffer[2] = 'C';
     buffer[3] = 'D';
     for(i = 0; i < (9*4); i += 4){
          ret = buffer + i;
          if( i == 0){
               printf("Vector:\n");
               for( j=0; j < 4; j++){
                    printf("Valor: 0x%X PosMem: 0x%X\n", *ret, ret);
                    ret += 1;
               }
               printf("-----------\n");
          }
          else{
               printf("Valor: 0x%X PosMem: 0x%X\n", *ret, ret);
          }
     }
     // Aquí es donde esta la fiesta
     // Retrocedemos hasta donde esta el EIP

     ret -= 12;

     // Modificamos la dirección de vuelta y le sumamos 7 
     // que es la siguiente instrucción

     *ret += 7;
     printf("Premio: Valor: 0x%X PosMem: 0x%X\n", *ret, ret);
}

int main(void){
     int x;
     x = 9;
     funct(4,5,6);
     x = 1;
     printf("El valor de X es: %d\n", x);
     return 0;
}

Recapitulemos. Como vemos, asignamos 9 a la variable X. La siguiente instrucción llama a la función pasándole los números 4, 5 y 6 como parámetros. Por tanto, apilará el valor 6, 5 y 4. A continuación apila el valor del EIP que es el valor de la siguiente instrucción a ejecutar, que en nuestro caso es la instrucción “x = 1″. Encima del EIP apilara el valor del EBP de la pila actual, y sobre éste las variables locales de la función.

Dentro de la función apilamos variables locales para los bucles así como un vector de 4 caracteres “ABCD” o lo que es lo mismo en hexadecimal “0x41 0x42 0x43 0x44″, el cual ocupa una palabra (4 x char (1 byte) = 4 bytes = 32 bits).

Una vez realizadas estas operaciones, se muestra el contenido de la pila de la función seguido de la posición de memoria donde se guardan el dato, que corresponde con lo explicado en teoría. Ya por último se mueve el puntero “ret” a la posición donde se guarda el EIP (próxima linea a ejecutar) y se modifica con un valor de tal forma que cambia la posición de la siguiente instrucción a ejecutar, que seria “x = 1”, por la instrucción “printf”. Compilamos y ejecutamos el programa:

user1@base:~/Desktop> gcc -ggdb --no-stack-protector prueba.c -o prueba
user1@base:~/Desktop> ./prueba
Vector:
Valor: 0x41 PosMem: 0xBF869098
Valor: 0x42 PosMem: 0xBF869099
Valor: 0x43 PosMem: 0xBF86909A
Valor: 0x44 PosMem: 0xBF86909B
--------
Valor: 0x4 PosMem: 0xBF86909C
Valor: 0x4 PosMem: 0xBF8690A0
Valor: 0xFFFFFFA4 - PosMem: 0xBF8690A4
Valor: 0xFFFFFFD8 - PosMem: 0xBF8690A8
Valor: 0x22 - PosMem: 0xBF8690AC
Valor: 0x4 PosMem: 0xBF8690B0
Valor: 0x5 PosMem: 0xBF8690B4
Valor: 0x6 PosMem: 0xBF8690B8
Premio: Valor: 0x29 PosMem: 0xBF8690AC
El valor de X es: 9

Analicemos el resultado de la ejecución. Comienza mostrando la cima de la pila que es el vector de caracteres (char) de nombre “buffer”, donde podemos ver que las posiciones son consecutivas (claro, un char ocupa un byte). Posteriormente muestra los datos de 4 en 4 bytes (una palabra), puesto que lo que nos interesa son los registros que guardan direcciones de memoria que ocupan 32 bits (4 bytes, una palabra). Se muestra un
registro sin importancia (0xBF8690A4) que se emplea en la ejecución de los bucles de la función, y luego hay dos registros en la posición 0xBF8690A8 y 0xBF8690AC (nos interesa el último). A continuación vienen 3 registros que son el valor 4, 5 y 6 que son los valores que hemos pasado a la función en su llamada.

Como podemos imaginar, el dato que hay en la posición de memoria 0xBF8690AC cuyo valor es 0x22 corresponde con el EIP (dirección de la siguiente instrucción a ejecutar una vez termine la función). Por tanto lo que hacemos es ir a dicha posición de memoria, y modificarla incrementando su valor en 7 para que salte a la posición de memoria donde nosotros queremos: la instrucción “printf”. ¿Pero, cómo sabía que tenia que sumarle 7? Veamos:

user1@base:~/Desktop> gdb -q prueba
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) disassemble main
0x080484ee <main+0>: lea 0x4(%esp),%ecx
...
0x080484ff <main+17>: movl $0x9,0x8(%ebp)
...
0x0804851d <main+47>: call 0x8048404 <funct>
0x08048522 <main+52>: movl $0x1,-0x8(%ebp)
0x08048529 <main+59>: mov -0x8(%ebp),%eax
...

¡No salgais corriendo! Fijaos bien… hay una llamada (main+17) que mueve al registro el valor 9 ($0x9), posteriormente llama a la función (main+47) y la siguiente línea de código es la misma que la de (main+17), pero esta vez le asigna el valor 1 ($0x1). Por tanto, claramente (main+17) es x = 9 y (main+52) es x = 1.

Por lo que si la instrucción “x = 1” se encuentra en la posición de memoria 0x08048522, la siguiente línea de ejecución 0x08048529 será el printf. Si restamos las posiciones de memoria obtenemos el 7 empleado en el programa. Pero es más, fijaros bien, ¿en qué terminan las posiciones de memoria de estas dos líneas de código? En 22 y en 29 ¿Os suenan? Fijaos lo que mostraba el programa en su ejecución:

...
Valor: 0x22 PosMem: 0xBF8690AC
...
Premio: Valor: 0x29 PosMem: 0xBF8690AC

En la próxima entrada, una vez vistos los detalles técnicos y teóricos de los buffer overflow, pasaremos a comentar brevemente una de las principales protecciones del kernel de Linux frente a este tipo de ataques. Hasta entonces, buen fin de semana a todos.