Cómo proteger los servicios en Linux con Latch y NFQUEUE

martes, 30 de septiembre de 2014

Uno de los escenarios más habituales de Latch es el de proteger el login en una aplicación web, aunque también podamos usarlo para proteger el acceso por login a nuestro Windows, Linux, Mac o cualquier otro servicio que utilice PAM. Gracias a Latch, vamos a poder proteger nuestra identidad en el caso de que alguien pueda robar nuestro usuario y contraseña. Pero también podemos aplicar el mismo escenario no sólo a proteger nuestra cuenta en un determinado servicio, sino que además, podemos proteger ese servicio de ser accedido por cualquier persona; de esta manera, podríamos activar ese servicio cuando se necesitara y ya sólo no nos protegeríamos de robos de identidad, sino que también nos podríamos proteger de cualquier vulnerabilidad que le pudiera afectar (como ShellShock, gotofail, fallos en la implementación de criptografía, etc.).

Estos servicios que queremos proteger, generalmente suelen ser los servicios que se utilizan de forma privada, como la administración de un servidor usando OpenSSH, un servidor FTP, OpenVPN, etc. es decir, servicios que utilizamos esporádicamente pero no de forma habitual. De esta manera, tendríamos una doble protección con Latch, puesto que con Latch se podría activar ese servicio cuando se deseara, y también posteriormente activar el acceso con una cuenta de usuario concreta.

Algunas de las prácticas utilizadas para proteger estos servicios son bastante tediosas, como por ejemplo, filtrar el acceso por dirección IP (que limita el uso) o el uso de portknocking (que añade complejidad), entre otros. Esta solución propuesta puede sustituir al portknocking con menor complejidad.

NFQUEUE

En sistemas operativos Linux, existe una forma muy sencilla de realizarlo, mediante el uso de NFQUEUE.

NFQUEUE es una acción de "iptables" que permite delegar la decisión sobre qué hacer con un paquete de red a un programa que se ejecute en el espacio de usuario. Si bien, típicamente las acciones habituales son ACCEPT, DROP o REJECT, en este caso al hacer NFQUEUE, lo que estamos haciendo es enviar el paquete a una cola implementada como una lista enlazada de paquetes y sus metadatos, indexados por un entero. Posteriormente, desde el espacio de usuario, podemos acceder al contenido de esta cola de paquetes, y después de tratarlos, emitir un veredicto de qué queremos hacer con ellos (por ejemplo ACCEPT, DROP o REJECT).

La única desventaja de este método es que cuando la cola se llena, cualquier otro paquete que estaba dirigido a esa cola se descarta, con lo que hay que tener cuidado con que el tratamiento de los paquetes sea lo suficientemente rápido para y jugar con el tamaño máximo de esa cola.

El protocolo de comunicación entre el kernel y el espacio de usuario es nfnetlink. Los mensajes no utilizan ningún tipo de memoria compartida, sino que el funcionamiento está basado en un socket para enviar el paquete y sus metadatos.

Para poder utilizarlo, la configuración es muy sencilla:

  • Primero tenemos que establecer una regla en "iptables" para enviar ciertos paquetes a NFQUEUE (podemos incluso tener varias colas)
  • Posteriormente, tenemos que tener nuestro programa en espacio de usuario que lea las colas que hemos definido, trate los paquetes, y por último emita su veredicto.

El primer paso es muy sencillo, puesto que tan sólo tenemos que utilizar el comando "iptables"; por ejemplo, si quiero proteger el acceso a mi servidor de OpenSSH, utilizaría el siguiente comando:

iptables -A INPUT -p tcp --dport 22 -j NFQUEUE --queue-num 0

Con esta regla de "iptables" podemos tratar cualquier paquete cuyo puerto destino sea el 22 (generalmente el de OpenSSH), pero trataríamos todos los paquetes incluyendo el uso normal de OpenSSH. Como nuestra intención es poder controlar el inicio de la conexión solamente (y para así evitar sobrecargar la comprobación con Latch), podemos añadir esta otra regla "iptables" para que en el caso de que la conexión esté establecida, se dejen pasar los paquetes sin tratarlos, y tan sólo tratemos los inicios de conexión:

iptables -I INPUT -m state -p tcp --dport 22 --state ESTABLISHED -j ACCEPT

Existen además otros argumentos interesantes cuando estamos utilizando NFQUEUE:

  • --queue-balance: nos permite balancear los paquetes entre varias colas
  • --queue-bypass: nos permite aceptar el paquete si no hay ningún programa en espacio de usuario escuchando
  • --fail-open: en vez de descartar todos los paquetes cuando la cola está llena, los acepta.
  • --batching-verdict: permite emitir un veredicto a un grupo de paquetes

A continuación, es necesario tener ejecutándose el programa de espacio de usuario encargado de poder tratar los intentos de conexión, y para ello podemos usar la librería libnetfilter_queue en C, o cualquiera de sus bindings en Perl y Python.

Por ejemplo, en Python es tan sencillo como:




O en C, basándonos en el ejemplo que incluye libnetfilter_queue (no lo incluimos en el post por su extensión, pero se puede ver aquí).

Estas pruebas de concepto pueden ser claramente mejorables, sobre todo añadiendo operaciones asíncronas o hilos de ejecución para que sea más eficientes, así como filtros más concretos.

De esta manera podemos controlar en todo momento cuándo deseamos tener un cierto servicio accesible para su uso, o sea, una capa adicional de seguridad para evitar futuros incidentes de seguridad.


David Barroso
david.barroso@11paths.com

Shellshock, cómo se podría explotar en remoto

jueves, 25 de septiembre de 2014

Han pasado solo unas horas desde que se ha hecho público el fallo, y aunque ya ha dado tiempo a implementarlo en Faast como plugin, empieza a ser tarde para intentar aportar algo nuevo de Shellshock (CVE-2014-6271). Centrémonos en explicar cómo puede ser explotado el fallo en remoto, a través de un CGI, estudiando paso a paso qué ocurre.

Shellshock

Como toda gran vulnerabilidad desde HeartBleed, esta necesita un nombre. Parece que Shellshock es el consenso. Fundamentalmente el fallo es que Bash sigue ejecutando el código que se añade después de definir una función en una variable de entorno. Básicamente, en Bash podemos definir, por un lado, una función "anónima":

’(){ echo "hola"; };’

O incluso una función vacía y además anónima.

’(){ :; };’

Por otro, podemos definir variables de entorno en Bash, con env o cualquier otro método. E incluso, variables de entorno que son funciones. Por ejemplo.

env VARDENTORNO=’(){ :; };’

El fallo es que bash, al interpretar esto, no se detiene en el último punto y coma, sino que sigue. Por ejemplo:

env VARDENTORNO=’(){ :; }; echo "Se ha ejecutado el echo... y lo que queramos"’

lo ejecutaría cuando sea exportado o definida la función. Ya tenemos lo básico. En esta captura se resume el funcionamiento.

Jugando un poco con las variables de entorno, las exportaciones y la vulnerabilidad

¿En remoto?

Imaginemos un CGI en Bash colgado en una página. Si se le envía al script una cabecera con una función definida y un comando a continuación... ejecutará ese comando a continuación. Este ejercicio está inspirado en esta prueba de concepto. Para empezar, definimos un script cualquiera que haga de CGI.

Sencillo CGI

Ahora veamos paso a paso. Queremos pasarle una función cualquiera a una variable de entorno y a continuación un comando. Para eso, podemos aprovechar que Apache toma las cabeceras como (o las transforma en) variables de entorno. Por ejemplo, el User-Agent se introducirá como valor de la variable de entorno HTTP_USER_AGENT de Apache. Si se le envía una función definida y cuando termine un comando... interpretará el comando y ya tenemos la ejecución de código.

¿Cómo cambiar el User Agent? Muchas formas. ¿Qué comandos usarán si quieren hacer daño? Lo más sencillo (y de lo que habrá gusanos en cuestión de horas) sería descargar una shell php. Veamos cómo, por ejemplo con Curl.

Curl definiendo un user agent y atacando al servidor en 192.168.57.137

Con el comando -H se le define la cabecera User-Agent (o cualquier otra). Se usa una función vacía (es irrelevante su contenido para este fin) y luego el comando interesante (wget). En este caso, se baja una shell pública en c99txt.net y se almacena en /var/www/upload/d.php en el servidor. Estos son los logs de Apache una vez lanzado....

Logs de Apache durante el ataque

Devuelve un 500 porque la función no termina limpiamente, pero el comando se ha ejecutado. ¿La prueba?


Obviamente, el atacante "solo" dispone de los permisos y privilegios de Apache, y esto limita dónde escribir y qué hacer. También es importante recordar que los comandos deben ir con sus rutas absolutas.

El ataque es posible con cualquier sistema que permita cambiar el user-agent, por ejemplo el plugin para Firefox

Cambiando el User-Agent con un plugin de Firefox

En resumen, algo muy apetecible para crear gusanos que busquen indiscriminadamente CGIs y una vez con permisos de ejecución, busquen nuevas víctimas ellos mismos. El problema es que no solo con Apache, sino con decenas de sistemas o programas que usen Bash en algún momento del proceso, se puede ser vulnerable. Durante los siguientes días, se seguirán encontrando fórmulas ingeniosas para explotar el fallo.


Sergio de los Santos
ssantos@11paths.com

Becas Talentum para Eleven Paths en Málaga

En las oficinas de Málaga de Eleven Paths, donde se sitúa el laboratorio de la empresa, necesitamos perfiles jóvenes con talento. Así que vamos a incorporar a dos becados por Talentum en Málaga.

Para ser becado por Talentum, el requisito fundamental es estar matriculado en alguna universidad, y por tanto cursando estudios de informática o telecomunicaciones. El perfil debe ser fundamentalmente de programador en cualquier lenguaje, pero que lo domine como para poder sacar adelante por sí solo herramientas, proyectos, etc.

Habrá una entrevista y una prueba técnica para evaluar a los candidatos. Para tener más detalles sobre cómo optar a la beca, escribe con un pequeño CV a wearehiring@11paths.com.

News: Nuevo plugin de latch para sistemas basados en Unix, Linux y Mac

martes, 23 de septiembre de 2014

El nuevo plugin de latch para Unix permite agrupar la funcionalidad ofrecida por plugins anteriores como el latch-plugin-ssh o latch-plugin-auth-ubuntu, añadiendo además, la posibilidad de proteger servicios como "sudo", "su" y otros que utilicen autenticación PAM.

Hasta ahora, se disponía de un paquete de Latch para Ubuntu y otro para SSH, pero este nuevo plugin trata de ser más genérico. En el paquete del plugin, dentro de la carpeta examples/, se ofrecen ejemplos de cómo configurar diferentes servicios (sudo, ssh, el login...). Están organizados por sistemas en los que se ha probado el plugin: Debian, Ubuntu, CentOS, Fedora y OS X. En cualquier caso, es necesario configurar manualmente algunos ficheros específicos para poder integrar Latch en los servicios. Veamos cómo.

Compilando e instalando el paquete

Para poder compilar e instalar el código fuente del plugin, es necesario utilizar gcc y el make . En muchos sistemas vienen instalados por defecto, pero si no es así, se pueden instalar fácilmente con los siguientes comandos:

Para Debian/Ubuntu y CentOS/Fedora/RedHat respectivamente:

sudo apt-get install gcc make
sudo yum install gcc make

Además, son necesarias tres librerías: libpam-dev, libcurl-dev y libssl-dev. Para Debian/Ubuntu y CentOS/Fedora/RedHat respectivamente:

sudo apt-get install libpam0g-dev libcurl4-openssl-dev libssl-dev
yum install pam-devel libcurl-devel openssl-devel

En el caso de que el gestor de paquetes no encuentre alguna de las librerías y para usar las últimas versiones será conveniente actualizar el listado de paquetes disponibles.

Para Debian/Ubuntu y CentOS, Fedora o RedHat respectivamente:

sudo apt-get update
sudo yum update

Con los prerrequisitos necesarios, ya será posible compilar e instalar el paquete. Desde el directorio raíz del paquete, debemos ejecutar:

./configure && make && sudo make install

Tras esto, se habrá creado una librería dinámica "pam_latch.so" en la ruta  "/usr/local/lib/" que hay que situar en el directorio PAM de nuestro sistema operativo. Este directorio varía en función del sistema, aunque habitualmente se encontrará en "/lib/security/", "/lib64/security/" o "/lib/*/security/". En Mac OS X, el directorio PAM se encuentra en "/usr/lib/pam/".

sudo mv /usr/local/lib/pam_latch.so $PAM_DIR

Listado de librerías dinámicas PAM en Ubuntu 13.10

También hay que mover otros dos archivos binarios (latch y latch-shell), que tras la instalación se encontrarán en /usr/local/bin/. El siguiente paso es modificar los permisos con estos dos comandos:

sudo mv /usr/local/bin/latch /usr/local/bin/latch-shell /usr/bin/
sudo chmod 4755 /usr/bin/latch /usr/bin/latch-shell

Archivos binarios de Latch en /urs/bin/

Y por último, hay que configurar el servicio que se desea proteger. Para ello, nos situamos en la carpeta /etc/pam.d/ (donde se encuentran todos los archivos de configuración PAM), y editamos el fichero de configuración correspondiente. Veamos el ejemplo concreto para Ubuntu, aunque el proceso es similar en el resto de sistemas operativos.

Ejemplo: Login en Ubuntu 13.10

Para proteger el login en Ubuntu 13.10, hay que modificar tres ficheros: lightdm-autologin, lightdm y login. En primer lugar, es recomendable hacer una copia de seguridad de todos los ficheros que vamos a modificar, y así en el caso de querer desinstalar el plugin, será posible restaurar la configuración anterior fácilmente.

Abrimos los ficheros y añadimos nuestro módulo de autenticación de Latch a la configuración. Generalmente, se debe añadir justo después del módulo PAM que autentica:

auth required pam_latch.so config=/etc/latch/latch.conf accounts=/etc/latch/latch.accounts operation=login otp=yes

Es importante destacar que si nos fijamos en la variable "operation", hemos puesto la etiqueta "login". Esta etiqueta es la que utilizaremos cuando configuremos el plugin más adelante.

Fichero de configuración PAM lightdm después de añadir el módulo PAM de Latch

Podemos fijarnos en la carpeta examples/ubuntu/etc/pam.d/ para ver cómo configurar el resto de ficheros.

Configuración del plugin

Una vez completada la instalación, debemos configurar nuestro plugin. Para ello, es necesario en primer lugar obtener el "Application ID", el "Secret" y crear las operaciones necesarias para el plugin. En este caso, únicamente vamos a crear una operación (Login), pero es probable que en el futuro queramos crear más operaciones para así proteger cada uno de los servicios con un cerrojo ("latch") independiente.

Para obtener el "Application ID" y el "Secret" (fundamentales para integrar Latch en una aplicación), es necesario contar con una cuenta de usuario desarrollador en la página de Latch accediendo a la sección "Área de desarrolladores". Activada la cuenta, el usuario ya está en disposición de crear aplicaciones con Latch y acceder a la documentación para desarrolladores, incluyendo los SDKs y los plugins existentes. Para ello el usuario debe iniciar sesión en la página web de Latch y acceder de nuevo a la sección "Área de desarrolladores", desde donde podrá observar sus aplicaciones, a través de la sección "Mis aplicaciones" del menú lateral. Desde el botón "Añadir una nueva aplicación", el usuario indicará el nombre que desea que aparezca en la aplicación móvil.

Al crear la aplicación, se muestran dos datos fundamentales: el "ID de aplicación" y el "Secreto". Además existen otros parámetros adicionales entre los que están el icono de la aplicación que aparecerá en el dispositivo del usuario, si se incluirán operaciones internas (en caso de que se crearan) y si la aplicación va a soportar o no OTP (One Time Password). En este ejemplo añadimos una operación (a la que hemos llamado Login) y establecemos el OTP como opcional. El ID que aparece es el que tendremos que añadir dentro del fichero de configuración "latch.conf".

Detalle de la página donde se añade la nueva aplicación, tras crear la operación "Login"

Una vez finalizada la configuración y guardados los cambios, la nueva aplicación aparecerá en el listado de aplicaciones del usuario. El desarrollador podrá editarla en el momento que desee. El ID de la aplicación aparecerá tachado, pero su valor sigue siendo válido y también debe ser utilizarlo para configurar nuestro plugin.

Detalle de la página que nos permite editar la aplicación que acabamos de crear.

Edición del fichero de configuración "latch.conf"

Una vez que ya tenemos nuestros datos de configuración, abrimos el fichero de configuración "latch.conf" que tras la instalación se  ha creado en /etc/latch/, y lo editamos con los parámetros obtenidos.

Fichero de configuración "latch.conf" tras la instalación del plugin

Para este ejemplo, únicamente será necesario configurar el app_id, el secret_key y la operación que hemos creado (login) con su "OperationId" generado previamente.

Detalle de las operaciones predefinidas por defecto en el fichero de configuración de Latch

Usando el plugin

Para empezar a utilizar latch en nuestro sistema, es necesario en primer lugar parear nuestra cuenta. Necesitamos lógicamente tener descargada la aplicación de Latch en el móvil para Android, iPhone o Windows Phone y después seguir los siguientes pasos:

  • Desde la aplicación móvil de Latch, generamos el código de pareado, presionando previamente sobre "añadir nuevo servicio" en la parte inferior de la aplicación.

Captura que muestra cómo generar un nuevo código de pareado en la aplicación móvil

  • En el equipo, abrimos un terminal y ejecutamos el comando "latch -p ", utilizando el código de pareado generado en el paso anterior. 

Terminal en el que se ejecuta el comando de pareo de cuenta de Latch.

Ahora el usuario ya puede bloquear y desbloquear su login, así como configurar la autenticación con una contraseña de un solo uso, añadiendo una protección extra al acceso a nuestro sistema. 



Pantalla de autenticación en Ubuntu 13.10 con la opción OTP de Latch activada,
tras haber introducido la contraseña correctamente
Para desparear la cuenta, abrir un terminal y ejecutar el comando "latch -u". 


Iván Martín Vedriel
ivan.martin@11paths.com

El XSS universal: Un desastre contra la privacidad de Android

jueves, 18 de septiembre de 2014

"No podía creerlo, pero después de varias pruebas, parece que es verdad: en el navegador de Android es posible cargar JavaScript arbitrario en cualquier página". Con esta introducción de Joe Vennix, del equipo de Metasploit, se presenta el último "desastre de privacidad" en Android (ha habido varios, al menos clasificados como desastres, y Joe ha desarrollado exploit para algunos...). Pero este es un poco especial, por su sencillez y alcance.

Rafay Baloch lo descubrió a principios de septiembre. Un fallo en el navegador por defecto de Android que permite eludir la política de SOP (Same Origin Policy) en las páginas. A efectos prácticos, significa que si se visita una web de un atacante con el navegador por defecto, el atacante podría tener acceso a toda la información de cualquier página. No solo la información explícita sino obviamente a las cookies (si no están protegidas) y por tanto, pueden robar las sesiones de las webs.

¿SOP?

La política del mismo origen en los navegadores es el fundamento de su seguridad. Básicamente (excepto objetos con "src", y el "location") significa que el JavaScript de una página no puede mezclarse con otra. Está restringido a la web que lo lanza y no puede salir de ahí. Si lo hiciera, tendría acceso prácticamente al control total de cualquier otra web.

El "truco" en este caso, estaba en introducir un carácter nulo al principio de la declaración del javaScript.
Por ejemplo así:



Ocurre que muchas páginas impiden en su propio código que sean llamadas por un iframe, y abortan su ejecución si se saben que son llamadas así. Sin embargo, se solucionó rápido. Usando "sandbox" u opciones x-frame es posible eludir esto. Es más, ya lo han sacado en un módulo de mestasploit que hace el XSS completamente universal.



¿Es tan grave?

Otros problemas previos (que también fueron muy graves), también fueron sencillos de explotar, pero este es grave por lo sencillo de entender y explotar. Afecta a cualquier versión menos la 4.4, lo que viene siendo un 75% de los Android actualmente en activo. También es grave que exista ya un sencillo módulo de metasploit, y que sea tan fácil de configurar. El atacante solo debe "obligar" a la víctima a visitar una web. Y debe hacerlo con el navegador por defecto... que es el que la mayoría usará. De hecho, parece que se usa tanto como Chrome para móviles.

Fuente: www.netmarketshare.com


En cualquier caso, si la web utiliza la protección "HTTPonly" para la cookie, en principio no podría ser robada por JavaScript, pero sí se podría acceder al contenido de una web (aunque estuviera cerrada la pestaña, basta con que la sesión se encontrase activa). Esto implicaría, que si se tiene la sesión abierta, y se visita una web del atacante, este podría leer correos si se consultó el webmail hace poco, datos bancarios si la sesión del banco aún está abierta, etc.

Obviamente, el usuario debe utilizar otro navegador para protegerse ahora mismo, o esperar un parche... cosa que, como de costumbre en los móviles, es complicado que ocurra a corto plazo.

Los comandos en metasploit para que un atacante prepare una página para robar el contenido de una web, serían tan sencillos como estos:



Otros desastres en Android

Este es el enésimo fallo en Android que "afecta a la inmensa mayoría de dispositivos Android". En realidad, siempre que se encuentre un fallo en cualquier plataforma, afectará a una inmensa mayoría de esos dispositivos... pero es cierto que con Android se es más propenso a utilizar estos titulares, con porcentajes o números incluidos. Recordemos brevemente algunos de ellos:


Aun así, parece que todavía no se ha detectado que estos fallos hayan sido explotados de forma masiva por atacantes.

Sergio de los Santos
ssantos@11paths.com

Faast: La importancia de un buen mapa de activos

martes, 16 de septiembre de 2014

Uno de los puntos destacados del servicio de pentesting persistente Faast es su potente fase de descubrimiento. Y es que, además de ser un completo escáner de vulnerabilidades capaz de detectar una gran variedad de problemas de seguridad, Faast permite "mapear" detalladamente todos los activos que una organización expone (conscientemente o no) en Internet.

Cuando se trata de organizaciones grandes, este número de activos suele ser muy elevado, con lo que el volumen de información que se debe manejar es enorme. ¿Cuál es la mejor manera de representar esa información? Presentada por sí sola, sin estructura o clasificación, aporta poco al servicio de pentesting, mientras que una presentación ordenada y precisa, potencia la eficacia del estudio y del análisis.

En Faast se ha optado por tomar como punto de partida una de las características más apreciadas por los usuarios de la herramienta de análisis FOCA: su mapa de activos.

Mapa de activos de la FOCA

En él, se representa de forma jerárquica el "sitemap" del dominio analizado, con todos sus subdominios. Desplegando un dominio específico, es posible acceder a información extra, como los directorios y ficheros que contiene.

Otra vista del mapa de activos en FOCA

Con las virtudes de la FOCA en mente, se decidió darle una vuelta de tuerca a su mapa de activos para así mostrar al usuario, de forma sencilla e intuitiva, toda la información obtenida en la fase de descubrimiento, sin importar la cantidad de datos que se manejasen.

En la figura de debajo se puede observar la vista del mapa de activos en Faast. En la parte izquierda muestra el árbol de dominios. Es una estructura jerárquica que, tomando como raíz el dominio base escaneado, muestra todos los subdominios encontrados.

Mapa de activos en Faast

Además, para cada subdominio, se muestra la lista completa de URLs encontradas, identificando si se trata de directorios o archivos, y mostrando los parámetros por separado.

Mapa de activos desplegado en Faast

Desplegando un dominio del árbol, se muestra en la parte derecha de la vista una tarjeta que resume de forma escueta todo los activos que se han encontrado en él. En la parte superior, en primer lugar, se identifica el sistema operativo, así como las direcciones IP asociadas al dominio.

Resumen del mapa de activos

La tabla central muestra los distintos servicios de red que se encuentran activos en el dominio, además del puerto en el que se encuentran. Por último, la tabla inferior recoge información adicional encontrada en el dominio, como rutas internas, direcciones de correo electrónico o nombres de usuarios.

Cristóbal Bordiú
cristobal.bordiu@11paths.com

IcoScript, el malware con un sistema de comunicación más que curioso

viernes, 12 de septiembre de 2014

IcoScript es un RAT (sistema de administración remota) descubierto en agosto por G-Data más o menos normal... excepto por su forma de contactar con su servidor y recibir órdenes. La novedad consiste en que, en vez de comunicarse con su C&C directamente, lo hace con mails creados y recibidos a través del correo web de Yahoo!, lo que implica pasar bastante desapercibido entre el tráfico "habitual". Veamos más detalles.

Desde hace años, el malware no funciona de forma "standalone". No tiene sentido. Por varias razones. Comunicarse con el exterior le permite:

  • Recibir órdenes (en el caso de los RATs).
  • Propagarse (lo creamos o no, esto está en desuso).
  • Obtener una configuración dinámica que le permita funcionar incluso cuando las condiciones cambian.
  • Y lo más importante: deben dejar en algún punto el "botín" y enviar a los atacantes los datos (cualesquiera que sea su naturaleza) robados.

Para conseguirlo, el proceso habitual fue, en principio y durante años, que el atacante se conectara a la máquina. Desde 2004, era el sistema infectado el que se conectaba a través de diferentes puertos al sistema. Poco más tarde, se estandarizó el tráfico HTTP para pasar desapercibido y sortear cortafuegos. De nuevo, no mucho más tarde, el cifrado (con estándares o no) de ese tráfico HTTP. En seguida, vino el uso de dominios cambiantes, dinámicos, FastFlux.... todo para sostener la infraestructura en el tiempo y que no se dependiese de un único punto de fallo para el malware. En los últimos tiempos, se ha popularizado la comunicación P2P entre malware y el uso de la red TOR. Estos métodos hacen que sea muy difícil que caiga la infraestructura, pero no oculta especialmente la actividad del malware, que puede ser detectada de forma relativamente "sencilla" analizando tráfico sospechoso o direcciones de destino poco habituales.

Método "tradicional" de comunicación con un C&C


IcoScript lo que hace es trabajar de forma original en dos puntos muy concretos: intentar que el tráfico pase desapercibido y conseguir que la infraestructura sea "imposible" de tirar, pues usa el correo web de Yahoo!.

Cómo exactamente

Lo que hace el malware es aprovechar Internet Explorer para visitar Yahoo! Mail e interpretar los correos que le envía el atacante, y a su vez enviarle a él la comunicación. El esquema sería el siguiente:

Esquema del método de comunicación de IcoScript

Para conseguirlo, internamente en el sistema infectado, se comunica con Internet Explorer a través de una instancia COM con el navegador. Esto permite que, de cara al sistema, sea el propio Internet Explorer el que realiza la conexión con Yahoo! Mail, recoja la información, cree los correos... El troyano solo tiene que construir las URLs, buscar los TEXTAREA, rellenarlos, enviar... Todo de forma "invisible" en el sistema.

Con esto consigue algo muy interesante, y es que, de cara a los IDS, forenses, etc, la actividad realizada sea de lo más "normal". Apenas se detectará que a través del navegador se ha visitado Yahoo! Mail y enviado correos a un atacante... y solo si se revisan los logs... Esto le ha permitido pasar desapercibido al menos desde 2012.

Con este método, resulta imposible bloquear un dominio "desconocido" (a través de lista blanca o negra) con el que se comunique el malware.

Otros detalles

El malware utiliza un archivo .ico (con el icono de Adobe Reader) que en realidad contiene, ofuscado, código scripting inventado por los atacantes. El lenguaje hace que las variables se compongan de acciones, pasos... Así consigue, poco a poco, ir a la página de http://mail.yahoo.com, y a través de comunicación COM con el navegador, rellenar el usuario, contraseña, entrar, comprobar el correo... y recibir órdenes. Lo hizo con Yahoo!, pero nada impide intentarlo con otros servicios de correo web.

Utiliza los caracteres "<<<<<<<<"COMANDO">>>>>>>>" en los correos para que el malware sepa qué hacer exactamente. Dado que el flujo de comunicación con Yahoo! se hace por gzip, y solo se descomprime en el navegador, en la red no se vería nada de eso si se intenta detectar, puesto que se comprime fácilmente.

De cara al usuario, solo sería necesario "una instancia" de Internet Explorer en el sistema, que estaría llevando a cabo toda la comunicación. El troyano que lo ha abierto, podría estar oculto en otro proceso cualquiera, más oculto aún como rootkit... De cara al IDS o los detectores en la red, se estaría enviando un simple correo por Yahoo! Ingenioso, realmente.


Sergio de los Santos
ssantos@11paths.com

Ocho siglas relacionadas con las vulnerabilidades (y VII): CPE

miércoles, 10 de septiembre de 2014

Para finalizar con esta serie de entradas asociadas a las vulnerabilidades, el MITRE dispone de otra iniciativa llamada Common Platform Enumeration (CPE). En resumen, permite identificar con un nombre único y estándar los sistemas, plataformas y software de una manera muy detallada.

Las necesidades que el CPE se encarga de satisfacer son:
  • Un formato estandarizado para referirse a productos y plataformas que pueda ser utilizado por otras herramientas.
  • Un conjunto de procedimientos para la comparación de nombres.
  • Un lenguaje para la construcción de "declaraciones de aplicabilidad", que combinan un CPE con operadores lógicos simples.Un diccionario CPE y una noción general para la interpretación de los nombres CPE contenidos en él.

Esta iniciativa puede llegar a parecer un tanto simple a primera vista. ¿No tienen ya los productos hardware o software un nombre perfectamente definido? Sí, pero no pueden ser tratados a nivel de programación, y ciertos nombres (si no se conoce específicamente el producto) no permiten saber, a simple vista, si se trata de un software, hardware, sistema operativo, aplicación, etc. Usando CPE esto es posible, entre otras muchas cosas. Gracias a esto se puede saber, de forma totalmente unívoca y exacta, por ejemplo qué versiones, ediciones o en qué idiomas, un producto se ve afectado por una vulnerabilidad.

Obviamente, CPE puede integrarse dentro del Common Vulnerability Reporting Framework (CVRF), utilizada para reportar toda aquella información asociada a una vulnerabilidad. Dentro de este framework, se utiliza el CPE para hacer referencia a tecnologías, herramientas, sistemas o plataformas específicas con la mayor exactitud posible.

Aunque este diccionario es propio del MITRE, en la actualidad, el National Institute of Standards and Technology (NIST) mantiene una versión autorizada para distribución como parte de su iniciativa U.S. National Vulnerability Database (NVD), a la vez que alberga todos los documentos de especificación y aplicabilidad correspondientes al CPE.

La versión 2.3

Creada ya a mediados de 2011, introducía cambios interesantes. La versión 2.2 mantenía una estructura "simple" que se fundamentaba en este esquema:

cpe:/ {part} : {vendor} : {product} : {version} : {update} : {edition} : {language}

En el que por ejemplo,

cpe:/o:microsoft:windows_xp:::pro

Representaba a los Windows XP Profesional en cualquier versión, lenguaje o edición. También existía un diccionario en XML en el que se almacenaba toda la información de productos, para "oficializar". La versión 2.3 CPE, sin embargo, creó un modelo más rico y complejo, además de tener que mantener compatibilidad hacia atrás. Si anteriormente se basaba en el concepto de URI, en ella se introdujo el concepto de Well Formed CPE Name o WFN. El WFN viene a ser algo así:

wfn:[part="a",vendor="microsoft",product="internet_explorer",
version="8\.0\.6001",update="beta"]

O por ejemplo,

wfn:[part="a",vendor="microsoft",product="internet_explorer",
version="8\.*",update="sp?",edition=NA,language=ANY]

Para referirse a Microsoft Internet Explorer 8.* SP? (sin edición y en cualquier lenguaje).

Los campos que puede manejar son bastante explícitos.

Compatibilidad hacia atrás

En el documento del NIST, se especifica cómo pasar de WFN a formato URI "tradicional". Por ejemplo, el WFN anterior de Internet Explorer 8.0.6001 quedaría:

cpe:/a:microsoft:internet_explorer:8.0.6001:beta

Para conseguir traducir todo WFN hacia el formato 2.2, se ha tenido que "inventar" otra fórmula donde el CPE contiene "subcampos" dentro de los ya conocidos ":" pero estos separados por la virgulilla "~". Por ejemplo, supongamos que tenemos el producto HP Insight Diagnostics 7.4.0.1570
Online Edition para Windows 2003 x64 y su WFN sería:

wfn:[part="a",vendor="hp",product="insight_diagnostics",
version="7\.4\.0\.1570",update=NA,
sw_edition="online",target_sw="win2003",target_hw="x64"] 

Ahora se traduciría, manteniendo la compatibilidad hacia atrás en la versión 2.2, de CPE de esta forma:

cpe:/a:hp:insight_diagnostics:7.4.0.1570:-:~~online~win2003~x64~

En el que se "empaquetan" bajo la virgulilla los campos que no existían (o para las que se "reciclaban" campos) en la versión 2.2 "pura" del CPE (son sw_edition, target_sw y target_hw)

Otra fórmula

Pero también se define otra fórmula para asociar el WFN a un formato, que si bien se parece al CPE tradicional (una URI) y se representa con el mismo espíritu, resulta en un formato ligeramente diferente. El ejemplo anterior, sería:

cpe:2.3:a:microsoft:internet_explorer:8.0.6001:beta:*:*:*:*:*:*

En el que se deja más claro que el CPE es de la versión 2.3 y que permite especificar más atributos con cualquier valor (el asterisco). Otro ejemplo. El WFN:

wfn:[part="a",vendor="hp",product="insight",
version="7\.4\.0\.1570",update=NA,
sw_edition="online",target_sw="win2003",target_hw="x64"]

Se traduciría en, "formato URI 2.3":

cpe:2.3:a:hp:insight:7.4.0.1570:-:*:*:online:win2003:x64:*

El "guión" hablaría de que el "update" está "NA" (no aplica), y los asteriscos a que este CPE casa con cualquier valor.

Para mayor información acerca de las especificaciones de los nombres de CPE se puede consultar la documentación ofrecida por el NIST.

Entre algunas de las compañías que implementan o cuyas herramientas permiten implementar esta iniciativa a través de plugins, se encuentran: Dell, Hewlett-Packard, McAfee, Microsoft, Qualys, Rapid7, Symantec, VMware...

* Ocho siglas relacionadas con las vulnerabilidades (I): CVE
Ocho siglas relacionadas con las vulnerabilidades (II): CWE y CAPEC
Ocho siglas relacionadas con las vulnerabilidades (III): CVSS
Ocho siglas relacionadas con las vulnerabilidades (IV): CWSS
Ocho siglas relacionadas con las vulnerabilidades (V): CVRF
* Ocho siglas relacionadas con las vulnerabilidades (VI): CWRAF


Umberto Schiavo
umberto.schiavo@11paths.com

¿Firefox implementa un sistema de certificate pinning?... no del todo

viernes, 5 de septiembre de 2014

Ya hemos hablado de certificate pinning en el blog (e incluso "en directo" en la RECSI en estos días). Chrome era el único navegador que, además de ser el primero, implementaba el "pinning" de serie. Internet Explorer se apoya por ahora precariamente en EMET y Firefox en un addon llamado Certificate Patrol. Pero desde su versión 32, según los titulares, comenzará a "pinear"... pero esto es solo el comienzo y aunque ha sido anunciado a bombo y platillo, no es del todo cierto...

¿En qué quedamos según estos titulares y la prueba técnica?... ¿Firefox 32 suporta Public Key Pinning o no?

Brevemente, el "pineo" de certificados propone que el navegador "recuerde" cuáles son los certificados válidos de una web, para que, en el caso de robo o creación ilegítima (y posterior MiTM), el usuario sea alertado de que no se está conectando al sitio correcto aunque la negociación SSL sea válida. Varios incidentes muy famosos han contribuido a que esta opción sea cada vez más utilizada. Firefox, en su versión 32, ha implementado varias mejoras. Para empezar, ha eliminado de su lista de certificados confiables varios creados solo con claves de 1024 bits. La lista de Firefox es totalmente diferente a la de Windows (y Chrome), y bastante más estricta a la hora de elegir "certificados de confianza", con lo que, con este paso, se vuelve todavía más paranoica. Con respecto al "pinning", lo que ha hecho es complementar lo que ya tenían (HSTS) con el PKP (Public Key Pinning). Pero, cuidado, hay dos "tipos" de PKP y Firefox solo ha implementado una parte... de ahí la confusión. Veamos qué es cada cosa.

HSTS

El estándar HTTP Strict Transport Security o HSTS. Se trata de una especificación que permite obligar a que, en una página, se use siempre HTTPS aunque el usuario no lo escriba en la barra del navegador. Para ello, el servidor que lo desee debe enviarle una cabecera al navegador, del tipo:

Strict-Transport-Security: max-age=16070400; includeSubDomains

La primera vez que visita la web, recuerda que a partir de entonces y durante el tiempo especificado en max-age, debe hacerlo por HTTPS. Poco más que añadir sobre esta tecnología.

Public key pinning dinámico

Esto también son unas cabeceras que permiten a un servidor indicarle al navegador cuáles son sus certificados "habituales" y por cuánto tiempo debe recordarlos. Si alguna vez se produce un ataque de hombre en el medio y suplantación de certificados, el navegador se quejará de que no eran los mismos que recuerda que le indicó el servidor. Así, los dueños de los sitios pueden declarar qué certificados son realmente suyos.

Ejemplo de cabeceras de HSTS y Public Key Pinning sobre HTTP devuelto por una página

¿Y cómo funciona exactamente?

Imaginemos que el servidor A mantiene una cadena de certificados "normal", con su CA1, CAInt, y CRaíz. El administrador es cuidadoso, y decide hacer uso de PKP. Le indica a su servidor o su página que devuelva las cabeceras correspondientes declarando sus certificados. Para ello tiene que calcular la codificación base64 del sha256 del atributo SubjectPublicKeyInfo del certificado codificado con DER (parece difícil pero no lo es). Usar el SubjectPublicKeyInfo (SPKI) permite que el certificado cambie aunque se mantenga la clave pública dentro, y por tanto es más flexible. 

Así que le dice a su servidor web o programa que añada estas cabeceras en sus repuestas HTTP:

Public-Key-Pins: max-age=31536000;
pin-sha256=base64(sha256(SPKI(CA1));
pin-sha256= base64(sha256(SPKI(CAInt);

Donde, en realidad, está "pineando" dos de los tres certificados de su cadena de certificación, y avisando al mundo de que, si alguno cambia en otra visita, es necesario sospechar... excepto el "hoja". En algún momento, un usuario los visita, y el navegador (si implementa el PKP dinámico) los recuerda. Pero imaginemos que en algún momento posterior el usuario es atacado, y visita sin querer A', que resulta pertenecer a un atacante y que usa otros tres certificados diferentes (CA1', CAint', y CRaíz') en su cadena de certificación. El navegador de la víctima, antes de establecer comunicación ni mostrar nada de ese servidor, se conecta y se trae los certificados de A'. Calcula los hashes de la cadena, y se mueve por esta regla:

"Si los pines (hashes que representan a los certificados) de la cadena de certificados del sitio que visito, hace intersección con los hashes que recuerdo que me envió hace tiempo, todo está correcto. Si no, mostraré una alerta".

Fallo de pinning en Firefox.
Fuente: http://monica-at-mozilla.blogspot.com.es/2014/08/firefox-32-supports-public-key-pinning.html

O sea, algún elemento de estos dos conjuntos:

  • base64(sha256(SPKI(CA1)), base64(sha256(SPKI(CAInt))
  • base64(sha256(SPKI(CA1')), base64(sha256(SPKI(CAInt')) , base64(sha256(SPKI(CRaíz'))

Debe ser común para que no haya problemas. En resumen, todo va bien si el conjunto de certificados de A (legítimo) intersecta con el de A' (atacante).

A partir de aquí, cabe reconocer que hay escenarios poco probables pero posibles para eludir la seguridad de esta solución, y que el dueño del servidor debe tener cuidado para no generar demasiados falsos positivos. PKP, por ejemplo, no protege del compromiso de claves privadas de certificados intermedios, por ejemplo, puesto que la intersección se daría en muchos casos. Si el administrador del sitio es muy paranoico y "pinea" solo el certificado hoja, el ataque es mucho menos probable, pero se eleva la cantidad de potenciales falsos positivos. Así que habitualmente, lo que hacen es (además está muy recomendado por el RFC) meter un certificado de respaldo para no "bloquearse" por si envían una cabecera que obliga a recordar a los navegadores un certificado durante demasiado tiempo pero poco después expira o se invalida por lo que sea.

PKP "incrustado"

Pues simplemente, es lo mismo que ya se ha explicado pero en este caso los pines (la codificación en base64 del sha256 del SPKI del certificado)  no los envía dinámicamente el servidor, sino que son incrustados en el código del navegador. Así los "recuerda", y el tiempo durante el que los recuerda viene determinado por actualizaciones del programa. Esto no es ningún problema en sí, solo que a largo plazo es insostenible y proporciona muy poca flexibilidad y potencia. Y esto es lo que ha hecho, en su versión 32, Firefox.

Conclusiones

En rigor, es cierto que Firefox sí ha implementado Public Key Pinning, pero no Public Key Pinning sobre HTTP. Eso es algo que se menciona en la nota de prensa como posibilidad, pero no queda totalmente claro que será algo que se hará a futuro. Y si nos fijamos no solo en que en la versión 32 ha hecho un PKP "no dinámico" sino que además ha "pineado" solo una pequeña parte de dominios importantes... la cosa queda en un comienzo prometedor, pero nada definitivo para Firefox como los titulares parecen comunicar.

Y es que en esta versión 32, solo se "pinean" (incrustados) los dominios de Twitter y algunos de la propia Mozilla. En el futuro (quizás en su versión 33) meterán en el código los certificados de Google, Dropbox y en definitiva, todos los que ya implementa Chronium en su código a partir de la versión 34, que no son pocos.

En resumen, los titulares inducen a error si no se especifica que el PKP será "built in" (incrustado) y que por ahora se incrustan muy pocos dominios. El objetivo final, más adelante (en un futuro no determinado) es implementar PKP dinámico, y es el camino que ahora comienza Firefox... la noticia no es, precisamente, que lo haya concluido.

Sergio de los Santos
ssantos@11paths.com

QA: Pruebas para asegurar la calidad del producto software (I)

miércoles, 3 de septiembre de 2014

Las aplicaciones (en general cualquier mecanismo diseñado e implementado por un humano) son propensas a tener fallos. A veces, pueden contribuir al fracaso de cualquier proyecto de software, e impactar de forma negativa en toda una empresa. No parece "justo" que la imagen de toda una compañía se degrade por errores que pueden ser subsanados, y a los que el código es tan "propenso" en general. Los tiempos de desarrollo, los entornos de programación, las diferencias entre versiones... todo influye para que, incluso con la máxima dedicación, puedan darse fallos que empañen la imagen y a veces la reputación, de una organización. Surge por tanto la necesidad de asegurar en lo posible, la calidad del producto.



Pruebas de software

Principalmente se debe verificar que se cumplan con las especificaciones planteadas desde un inicio por el analista o el propio cliente, y/o eliminar los posibles errores que se hayan cometido en cualquier etapa del desarrollo. Hace años (y todavía en entornos pequeños), estas pruebas se realizaban de manera relativamente informal, como podría ser la generación de informes que pasaban entre departamentos. Pero hoy es, en muchos aspectos, una de las etapas críticas dentro del ciclo de vida del software. Existen, de hecho, diferentes metodologías para llevar a cabo las pruebas de calidad de manera óptima, y que tienen en cuenta la complejidad de trabajar con diferentes lenguajes de programación, sistemas operativos, arquitecturas hardware, etc. Debido a esto último, el proceso de testing debe basarse en metodologías o métricas generales que revisen los aspectos fundamentales del sistema, desde el seguimiento de errores, automatización de pruebas unitarias, etc.

Las pruebas de software son las investigaciones empíricas y técnicas cuyo fin es proporcionar información objetiva e independiente sobre la calidad del producto. Esta actividad forma parte del proceso de control de calidad global. Las pruebas son básicamente un conjunto de actividades dentro del desarrollo de software y dependiendo del tipo de pruebas, estas actividades podrán ser implementadas en cualquier momento del proceso de desarrollo.

Para conseguirlo, en realidad no existen las "mejores prácticas" como tal, debido a que cada práctica puede ser ideal para una situación pero completamente inútil o incluso perjudicial en otra, por lo que las actividades de testeo, técnicas, documentación, enfoques y demás elementos que condicionarán las pruebas a realizar deben ser seleccionados y utilizados de la manera más eficiente según contexto del proyecto.

¿Por qué es necesario hacer pruebas?

La labor de desarrollar software en una empresa (ya sea como producto o herramienta interna) trae consigo la necesidad de asegurar que el trabajo realizado se acerca (en lo posible) a la perfección en cuanto calidad y desarrollo seguro. Evidentemente, esto redunda en la satisfacción del equipo que logra los objetivos como por parte del cliente que obtiene el mayor beneficio de un producto finalizado.

Además, como toda buena inversión, ahorra tiempo a largo plazo. Si trasladamos por ejemplo los conceptos al entorno móvil, para asegurar el correcto funcionamiento de las aplicaciones en cada tipo de terminal y sistema operativo, el equipo de pruebas debe realizar diversos test a diferentes niveles (como veremos en siguientes entregas). Excepto Google Play, las grandes compañías de distribución de apps (AppsStore y Microsoft Marketplace) suelen someter a diversas pruebas las apps candidatas, para comprobar que se encuentran dentro de unos umbrales mínimos de calidad. Este proceso puede ser de varios días antes de recibir el visto bueno o el rechazo, con lo que el proceso debería volver a comenzarse. Esta es una de las razones por las que someter cualquier aplicación a una buena batería de pruebas de forma interna.

¿Cuándo y cómo empezar el proceso de testing?

Siguiendo el proceso de desarrollo software, tras la realización del análisis, diseño y en algún punto del desarrollo de la aplicación debe iniciarse la etapa de pruebas. Para esto es necesario un ambiente aislado del de desarrollo y el de producción, es decir, debería simularse la ejecución de la aplicación en un entorno idéntico a donde se va a ejecutar. Esto incluye la mayor muestra posible de sistemas "estándar" de usuario, en el caso de que se trate de una aplicación destinada al público en general, donde es imposible simular todos los escenarios.

Un aspecto importante para todas las empresas debe ser el tener un buen equipo de testers que cuenten con las herramientas necesarias para realizar las labores de pruebas de una manera eficiente, o bien un conjunto reducido de testers experimentados que lleven la búsqueda de fallos con la metodología con la que están habituados trabajar y en el menor tiempo posible.

Otra práctica habitual (más informal pero bastante difundida) es distribuir una versión beta y que los propios usuarios sean los que encuentren los fallos y los reporten. Aunque esto conlleva desventajas, como la complejidad para que los usuarios reporten de manera adecuada el fallo (descripción del entorno, pruebas de concepto...) o simplemente a la pérdida de profesionalidad de todo el proceso en sí. Además, los betatesters, pueden pasar por alto test importantes como "pruebas de estrés", "test unitarios"..., que detectan fallos a nivel modular.

Una recomendación importante es que los desarrolladores de una aplicación no pueden ser a su vez testers de esa aplicación. Ser juez y parte hace que se pierda objetividad debido a la presunción de que su desarrollo es totalmente fiable, a la consideración de que determinados elementos no son relevantes a verificar, etc. Por ello es necesario que el equipo de testeo se encuentre totalmente desligado del equipo de programación. En este sentido, surge también una alternativa bastante interesante que es la realización de testeo cruzado entre equipos de trabajo, es decir, un equipo de desarrollo se encarga de realizar las pruebas sobre el software creado por otro equipo y viceversa. Aunque según disponibilidad de personal, siempre será mejor un equipo especializado en realizar estas labores.

En las siguientes entregas se irán comentando más y mejor las pruebas a realizar y su importancia.

* QA: Pruebas para asegurar la calidad del producto software (II)

Jhonattan Fiestas
jhonattan.fiestas@11paths.com

Eleven Paths en la XIII Reunión Española sobre Criptografía y Seguridad de la información (RECSI)

lunes, 1 de septiembre de 2014

Esta semana, los aficionados a la criptografía y seguridad informática en general tienen una cita en la XIII Reunión Española sobre Criptografía y Seguridad de la información (RECSI) que se celebrará en Alicante del 3 al 5 de septiembre.

La conferencia RECSI, de celebración bienal, es una de las conferencias más antiguas y de prestigio en España. Una conferencia que reúne a expertos de mundos dispares: en esta edición se profundizará en multitud de temas que irán desde la seguridad en dispositivos móviles hasta el criptoanálisis, pasando por protocolos criptográficos, seguridad en redes, nuevas amenazas y mecanismos de defensa, privacidad, etc.

Entre todas las ponencias destacadas de estas jornadas es reseñable la ponencia invitada del Dr. Moti Yung (Google) reconocido con el premio Distinguished Lecturer in Cryptography de la International Association for Cryptologic Research (IACR). Experto en criptografía y conocido, además de por sus investigaciones, por acuñar los términos de criptovirología ya en 1996 o cleptografía.

En esta edición, Eleven Paths presenta dos trabajos fruto del departamento de investigación liderado por el Dr. Antonio Guzmán.

  • Contramedidas en la suplantación de autoridades de certificación. Certificate pinning. Autores: Dr. Alfonso Muñoz, Dr. Antonio Guzmán y Sergio de Los Santos. Será el jueves 4 de septiembre de 16:30 a 17:30, con el Dr. Alfonso Muñoz como ponente.

    En esta ponencia se hablará sobre los ataques actuales a las tecnologías basadas en infraestructuras de clave pública y de autoridades de certificación. Se profundiza en el análisis de nuevas arquitecturas de protección, y se analizan las características más relevantes en las implementaciones de certificate pinning extendidas en Internet.
  • Gestión de identidades digitales basada en el paradigma de la reducción de tiempo de exposición. Autores: Dr. Jose María Alonso, Dr. Antonio Guzmán y Dr. Alfonso Muñoz. Será el viernes 5 de septiembre de 11:30 a 12:50 con el Dr. Alfonso Muñoz como ponente.

    Esta ponencia muestra de manera formal los principios conceptuales, estadísticos y técnicos de la tecnología Latch, profundizando en resultados específicos de su implantación en el mundo real. 

La conferencia RECSI es el lugar adecuado para, desde el punto de vista criptográfico, conocer cómo proteger sistemas y sobre todo para comprobar sus potenciales problemas y vulnerabilidades. De hecho, ya lo adelantaba Manuel Machado hace mucho tiempo: "Fatigas, pero no tantas que a fuerza de muchos golpes hasta el hierro se quebranta".

Dr. Alfonso Muñoz
alfonso.munoz@11paths.com