Security Art Work

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.

Esta es mi primera (que no última) aportación al blog, y aunque es de un cierto nivel técnico, espero no aburriros. El artículo que presento a continuación trata de los ataques de desbordamientos de memoria (buffer overflow), y de una protección del núcleo Linux 2.6 contra éstos llamada “Virtual Address Space Randomization”, también llamado ASLR. Este último año la funcionalidad de esta protección se ha visto comprometida, como veremos en detalle mañana en la segunda parte de esta entrada.

En esta primera parte, creo necesario para comprender el funcionamiento de esta protección explicar las bases de los desbordamientos de memoria, que a partir de ahora llamaremos Buffer Overflow. De manera muy resumida, los ataques de buffer overflow aprovechan código donde no se comprueba correctamente la longitud de las cadenas de entrada, de manera que es posible introducir un dato de longitud mayor que el espacio reservado para ese dato. Es decir, si reservo un espacio de 10 bytes para la variable de la función, ésta recibe un dato de 25 bytes, y no compruebo correctamente el tamaño del dato recibido, escribiré en memoria los 10 bytes reservados más 15 bytes no legítimos. ¿Y esto para que sirve? Pues para entenderlo vamos a explicar el funcionamiento a nivel de memoria de un proceso.

Cuando un proceso se ejecuta, el espacio de memoria reservado para el proceso se divide en tres partes: la primera es el texto que no es más que el código a ejecutar, la segunda son los datos (como puedan ser variables inicializadas o no, y constantes), y por último la pila (stack). En nuestro caso, nos vamos a centrar en la pila o stack. Ésta se emplea para las llamadas a funciones, ya que permite guardar (apilar, que por eso es una pila) los valores que se requieran para la ejecución de la función, y al mismo tiempo restaurar el estado de los registros una vez termina la ejecución de la función. Es importante recordar que la pila va de la parte alta de la memoria a la parte baja.

Cuando una función se ejecuta, lo primero que hace es apilar los valores que la función recibe como argumentos. Lo segundo que se guarda es el estado actual de los registros para poderlos restaurar una vez finalice la ejecución de la función: EIP y EBP. El primero de ellos, EIP, indica la siguiente línea de código que el procesador debe ejecutar, y el segundo, EBP, indica la dirección del final de la pila actual. Dicho de otra forma, nos estamos asegurando de que al final de la ejecución de la función sabremos dónde hemos de volver. Una vez guardados los registros EIP y EBP de la pila actual, se modifica el registro EBP asignándole el valor del registro ESP (registro donde se guarda la dirección de la cima de la pila). ¿A que no hemos entendido nada? No os preocupéis, con el dibujo se ve (un poco) más claro:

Ahora viene lo interesante. Cuando la función termina, ésta llama a la instrucción Ret, que se encarga de desapilar absolutamente todo hasta llegar al EBP de la pila. Una vez llegue al EBP de la pila quedan dos registros por desapilar: el primero contiene la dirección del EBP antiguo de la pila que había antes de la ejecución de la función, por lo que el registro EBP tomará dicho valor restaurando el estado anterior. Por último, y presten atención porque esto es lo importante, leerá el valor del EIP —que contiene la dirección de la siguiente linea de código a ejecutar—, que es justamente lo que un ataque de buffer overflow intentará falsificar, modificando la dirección de retorno de la siguiente línea a ejecutar por la dirección donde se encuentre el código del atacante que desea ejecutar. Como nota adicional, ya que seguramente nadie ha caído, en caso de que la función devuelva un valor, éste se guarda en el registro EAX. No obstante, voy a dejarles un tiempo para meditar todo esto, y mañana volvemos. No se preocupen si no han entendido mucho, seguro que mañana todo les resultará más sencillo.

Interesante, ¿no les parece?

Seguiendo con la serie de Seguridad Sectorial, que iniciamos en junio con el post sobre seguridad bancaria, me gustaría hablar hoy de las particularidades de seguridad en los puertos -en las instalaciones portuarias en general-. Los puertos son uno de los principales puntos de entrada y salida del territorio nacional, lo que de entrada ya implica dos cosas: son objetivos prioritarios para el terrorismo, y son un elemento clave para el tráfico ilícito, en especial de mercancías. Por ello, en el sector portuario es crítico garantizar la seguridad a todos los niveles (seguridad de la información, seguridad de las personas, seguridad de la cadena de suministro…).

El departamento de seguridad de cualquier instalación portuaria de magnitud (como los puertos de todas nuestras ciudades) se enfrenta a una serie de amenazas entre las que se encuentran el terrorismo, las amenazas industriales -vertidos tóxicos, fugas…- el tráfico ilícito de personas y mercancías, los disturbios o el robo, por citar sólo unos ejemplos. Y todo esto, por supuesto, sin menoscabo de amenazas comunes a todos los sectores, que por supuesto también pueden materializarse en un puerto: robos de información, desastres naturales -agravados en ocasiones por la ubicación natural de los puertos-… Aunque viendo algunas de estas amenazas puede parecer que el componente tecnológico de la seguridad portuaria es bajo, realmente no es así: desde los controles de acceso físico a recintos, hasta el cierre electrónico de contenedores mediante RFID, la seguridad “tecnológica” es, como siempre en estos tiempos, tan importante como la seguridad “clásica”.

De un tiempo a esta parte, es especialmente relevante la seguridad que se está aplicando a la cadena de suministro, con normas como ISO 28000; la idea es sencilla: interesa mantener la seguridad de, por ejemplo, un contenedor, garantizando que si salió de su origen con N toneladas de un producto, llegue a su destino con el mismo contenido, ni más ni menos. Que desde que se cerró el contenedor hasta que se vuelve a abrir nadie haya eliminado nada de su interior, ni por supuesto que nadie haya introducido mercancía nueva, como explosivos o drogas.

Para combatir estas amenazas -y algunas otras-, en los puertos encontramos lo que quizás representa uno de los mayores entornos de convivencia de medios humanos; y es que en las instalaciones portuarias conviven seguridad privada y pública, y dentro de esta última podemos encontrar Capitanía Marítima, Policía Portuaria, Policía Local, Policía Nacional, Guardia Civil… Cada uno de estos cuerpos tiene unas competencias (extranjería, fiscal, tráfico, seguridad ciudadana…) que en algunos casos pueden -o al menos parecen- solaparse, aunque por lo general el ambiente suele ser de convivencia y cooperación (o al menos eso dicen). También es necesario destacar el trabajo del personal adscrito a los Centros de Control de Emergencias, dependientes de las Autoridades Portuarias correspondientes (por ejemplo, la de Valencia, y que actúan como coordinadores de seguridad de las operaciones e instalaciones portuarias.

En lo que respecta a medios técnicos, obviamente en las instalaciones portuarias juega un papel fundamental la tecnología; y ya no solo en su vertiente más física, tal y como adelantábamos antes -control de acceso, contenedores, videovigilancia…-, sino desde el punto de vista de seguridad de la información pura y dura. Aunque no sea propiamente un puerto, si hablamos de astilleros un barco de pasaje puede costar más de 130 millones de euros, mientras que uno de carga puede costar más de 18 millones de euros; el precio del diseño (ingeniería naval + ingeniería de detalle) de estos barcos ronda el 10% y representa entre un millón y medio y dos millones de horas de trabajo, con lo que si alguien roba los planos de un astillero se está ahorrando entre 1,8 y 13 millones de euros. Tentador, ¿verdad? Y eso por no hablar de listas de pasajeros de cruceros de lujo, ensayos de nuevos materiales, relaciones de barcos y mercancías que llegan o salen del puerto… Toda esta información vale su peso en oro, y obviamente es necesario protegerla de forma adecuada.

NOTA: Quiero agradecer a Pepe Rosell la información sobre precios orientativos de barcos que me ha facilitado para la realización de este post :)

En mis primeros días de Erasmus en Londres, un profesor de una asignatura sobre sistemas distribuidos y seguridad nos dio a leer un curioso texto llamada “Worse is better” (Peor es mejor) donde se explicaba, a través de una curiosa discusión sobre sistemas operativos entre una persona del MIT y otra de la universidad de Berkeley, dos escuelas totalmente diferentes a la hora de llevar a termino un proyecto.

Mientras la escuela nacida del MIT defendía hacer las cosas “correctamente”, tomara el tiempo y el esfuerzo que tomara, y siguiendo los principios básicos de simplicidad, corrección, consistencia y completitud, la postura de la gente de Berkeley era más pragmática y hacia más hincapié en obtener un producto “suficientemente bueno” en un tiempo razonable, de forma que pudiera ser usado lo más pronto posible y a partir de ahí ir corrigiendo los fallos que pudieran quedar.

Estas dos filosofías se pueden aplicar a prácticamente cualquier ámbito de la informática, incluyendo, por supuesto, la seguridad. Ante el lanzamiento de un producto o servicio totalmente nuevo para la compañía, se puede optar por hacer análisis exhaustivos, empaparse de toda la documentación disponible perfilando al milímetro cada aspecto del proyecto y realizando complejas pruebas para asegurar que no existe ningún fallo de seguridad —llegando incluso a descartar el proyecto por no poder conseguir un producto realmente seguro tomando el tiempo que ello requiera— o por el contrario se puede hacer un análisis más ligero, ajustar los aspectos críticos e imprescindibles que realmente puedan poner en verdadero peligro al proyecto, y lanzar una versión suficientemente buena como para que los usuarios la adopten en un plazo aceptable, mientras sobre la marcha se van puliendo todos los aspectos que se quedaron en el tintero.

[Read more…]

Me despertaba esta mañana con la noticia de que el Partido Popular ha propuesto en el Congreso de los Diputados que a) los menores de 18 años necesiten consentimiento (actualización: al parecer, ahora ya sólo piden conocimiento) para acceder a las redes sociales, y b) los menores de 14 años no puedan siquiera acceder a éstas ([elmundo.es][ElPais.com]). Francamente, la primera de ellas me parece una barbaridad en toda regla, y aunque la segunda es más lógica por aquello de la edad, les diría que también estoy en desacuerdo. Veamos.

Lo primero que se me ocurre es que, en un país en el que existe actualmente, y a la vista de los últimos delitos, un debate sobre reducir o no la edad penal de los menores de la actual 14 a 12 años, parece una contradicción que una persona de menos de 18 años, que a partir de 16 puede conducir una motocicleta, tenga que solicitar autorización paterna para acceder a las redes sociales. Entonces, ¿debemos o no considerar a una persona madura a los 16 años? ¿Sí o no? ¿Sí para entrar en la cárcel, pero no para entrar en las redes sociales? Si asumimos que una persona de 15 años debe ser responsable penalmente de sus actos… bueno, pues ya saben cómo sigue el argumento.

Ya lo sé. La finalidad de rebajar la edad penal y la de incrementar la edad “tecnológica” (porque esa es al fin y al cabo la idea) es diferente. En este caso, se trata de proteger al menor de todo el abanico de “sujetos” e indeseables que pululan por las redes sociales. El problema es que pensar que Internet está limitado a las grandes redes sociales Tuenti, Facebook y MySpace es por completo ingenuo y una muestra más del desconocimiento de Internet del estamento político (en esto es fácil generalizar). Por suerte para aquellos que no somos especialmente aficionados a las redes sociales, Internet es mucho más que las tres Marías de arriba o todo lo que les he enumerado: hay infinidad de chats, pequeñas redes sociales, foros de aficiones (algo a lo que, vaya por Dios, los menores suelen ser muy propensos), blogs, sistemas de mensajería instantánea como MSN, ICQ, o Gtalk, y eso para empezar. Entonces, ¿es factible que los menores de 18 años necesiten consentimiento para acceder a Internet? Estaremos de acuerdo en que es una barbaridad, ¿cierto? En su lugar, ¿no sería mucho más lógico enseñar a los menores, independientemente de su edad, a aplicar las medidas de protección que aplican en su vida diaria? Ya saben, no fiarse del primero que pasa, no dar datos personales, no aceptar “caramelos”, no exponer tu vida íntima, etc.

Claro que en Internet hay contenido pornografico, violento, racista y totalmente perjudicial para los menores, todo ello accesible sin ningún tipo de restricción; sólo hay que buscarlo un poco, y cuesta poco nada encontrarlo. Sin duda, está llena de indeseables; real como la vida misma. ¿Vamos a prohibirle a un menor de 18 años que vaya al cine, salga de fiesta o simplemente quede con los amigos en una plaza cualquiera (por la que muy probablemente de vez en cuando pasa algún camello, algún delincuente, algún skinhead, o algún sujeto de pocos escrúpulos)? Creo que no, ¿verdad? (Si intentan prohibir ese tipo de cosas, suerte con sus hijos y las autoridades judiciales). Educación.

Verán, durante toda mi vida he ido de vacaciones a un pequeño pueblo de la provincia de Valencia, llamado Cortes de Pallás [Google maps]. Durante los últimos años, un extraño fenómeno ha sucedido: cuando llega la hora de la siesta, un puñado de menores se reunen en las escaleras de la vieja escuela, con el portátil en las rodillas, y allí se pasan sus buenas dos horas hasta que (imagino) la batería del portátil no da más de sí. ¿La razón? Es el único lugar del pueblo que dispone de conexión a Internet vía Wifi, es decir: Tuenti, Facebook, MSN, etc. No entraré a valorar la idiotez de esta costumbre, propia de la adolescencia y la pubertad, teniendo una fenomenal piscina que a las cuatro de la tarde es todo un lujo, pero si quiero comentar sobre la prolongación de la vida social en que se ha convertido Internet para los menores; les permite estar en contacto con sus amigos casi de manera permanente, compartir fotos, experiencias, comentarios, y cotilleos, y eso es algo que, aunque uno haya tenido una adolescencia moderadamente autista, a esa edad es imprescindible. Es más, voy a llevar ese argumento un poco más lejos: quizá no hoy, pero dentro de unos años no estar presente en Internet de manera activa puede llegar a ser una carencia social importante.

Con lo que vamos al siguiente punto. Hemos hablado de la necesidad de educar, no prohibir, y de lo vital que es Internet para las relaciones sociales (de todo tipo). Pero lo cierto es que las redes sociales son el punto de entrada de muchos menores a Internet, la excusa si quieren, a partir del cual desarrollar toda una identidad digital, y familiarizarse con la tecnología. Si no tener Internet en casa te pone en desventaja con otras personas (hoy quizá no, mañana sin duda), limitar mediante prohibición el primer contacto de los menores con Internet sólo conseguirá ponerlos en desventaja con los menores de otras partes del mundo, e incrementar la edad de la primera toma de contacto con Internet y los ordenadores. Es decir, con el futuro.

Aunque hay sin duda innumerables argumentos en contra de la propuesta, acabo con el más típico. No cabe duda de que el Estado debe estar ahí para velar por la seguridad de sus ciudadanos, independientemente de su edad, pero no nos pasemos. En primera instancia, quien debe velar por la seguridad de un niño son sus progenitores; quizá sería mejor dotarles también de una necesaria formación, y animarles a estar en contacto con sus hijos en las mismas redes sociales. Decisiones como dar a un menor un portátil, o poner un PC en su habitación deben ser previamente reflexionadas y no tomadas alegremente, con su necesaria dosis de diálogo y conversación. Una cosa es prohibir a un chaval de 16 años salir de casa a cualquier hora y a cualquier sitio, y otra muy diferente verlo salir el viernes y no preocuparse por él hasta el lunes. Sí, ya sé que es lo de siempre, pero es lo que hay.

Acabo. Dicen que tememos aquello que desconocemos, y no me cabe duda de que esa es la raíz de la prohibición propuesta. Por suerte, les guste o no, Internet ha venido a quedarse, y sus ventajas y oportunidades superan con mucho sus problemas.