Security Art Work

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.

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 :)