De MD5, colisiones, presidentes de EE.UU. y PS3
Ayer Lunes comentaron en Barrapunto ( y previamente en meneame ) acerca de una predicción sobre el resultado de las próximas elecciones de los Estados Unidos realizada por unos investigadores de la universidad donde estoy ( TU Eindhoven ), concretamente Benne de Weger ( profesor de Cryptography 2, a parte de haber dado este año la parte de RSA de Cryptography 1 ) junto con Marc Stevens y Arjen Lenstra.
Lo que han hecho ha sido crear varios documentos PDF con las posibles predicciones, pero que todos tengan el mismo hash MD5 (es decir, encontrar colisiones en MD5). Aquí voy a explicar sin entrar en mucho detalle y lo mejor que pueda qué es lo que han hecho para quien esté interesado y no tenga ganas/tiempo de leer el documento.
Antes de empezar, conviene conocer un par de términos (enlace a Wikipedia en inglés): hash collision y hash function (ver también el enlace a función hash criptográfica) . Desde allí se puede ir también a la versión española 🙂
Asumiendo que ya conocemos qué es un hash y qué es una colisión, cabe mencionar que generalmente las funciones de hash funcionan en base a varias iteraciones sobre una función de compresión, utilizando en cada iteración un bloque de datos del mensaje y un valor de hash intermedio ( IHV, Intermediate Hash Value ). El valor obtenido con el último bloque del mensaje (al que probablemente se haya añadido relleno para que sea múltiplo del tamaño de bloque ) es el hash buscado.
Pese a que en 2004 ya se publicó cómo obtener colisiones con MD5 ( prof. Xiaoyun Wang ), en este caso se trataba de mensajes aleatorios, lo cual hace que aunque dos mensajes tengan el mismo hash, probablemente solo uno de ellos tenga cierto significado. En el caso del nuevo ataque, que describen como chosen-prefix collisions, el documento puede tener una parte inicial arbitraria, siempre que a partir de cierto momento todos los documentos sean iguales.
Lo que describen en su paper Benne de Wenger y sus co-autores es un mensaje con los 3 siguientes campos:
- Un prefijo cualquiera
- Un relleno aleatorio, para que el tamaño de los 3 campos sea múltiplo del bloque
- Una cadena elegida de forma que la diferencia entre IHVs en este campo tenga ciertas propiedades
Con esto, la diferencia entre IHVs conseguida no es nula, pero es posible obtener una colisión mediante lo que ellos llaman near-collision blocks, consturidos para reducir estas diferencias.
A partir de aquí, tenemos dos documentos con un hash idéntico, aunque con cierta basura, y podemos añadir lo que queramos detrás siempre que sea igual para ambos archivos.
Lo que han hecho en este caso, es poner esa basura en una imagen oculta dentro del PDF, y aunque no he examinado los documentos, supongo que la parte final idéntica en todos cierra la imagen y añade todos los campos que necesite el formato PDF (que desconozco) para tener un documento válido.
La mejora de este método frente a lo descrito en el CITS, es que en el nuevo método no es posible encontrar rastros de que existe el documento fraudulento, mientras que en el anterior el documento postscript contenía dos bloques de contenido y se podía ver el otro documento.
¿Y qué tiene que ver la PS3 con todo esto? Pues simplemente que han usado una PS3 con sus múltiples cores para realizar los cálculos, además de un PC quad core. En su paper inicial comentan que les tomó unos 6 meses de trabajo con miles de PCs para encontrar las colisiones, pero con la técnica nueva unos 2 días son suficientes, usando una PS3 y un PC quad core.
Smart cards: normas y comunicación con el terminal
Vamos a seguir comentando un poquito más acerca de las smart cards, las tarjetas inteligentes de las que empecé a hablar hace casi un mes. En este post voy a comentar algo que en principio no tiene mucho que ver con la seguridad de los sistemas con estas tarjetas, pero que conviene conocer: los estándares que definen las características de estas tarjetas y la forma de comunicarse con el exterior.
El estándar actual de smart cards (de contacto, para RFID hay otros estándar) es la familia ISO 7816, que define básicamente todo lo que se pueda imaginar relacionado con las tarjetas:
- 7816-1: Carcaterísticas físicas
- 7816-2: Dimensiones y contactos de las tarjetas
- 7816-3: Señales eléctricas y protocolos de transmisión.
- 7816-4:Conjunto de comandos estándar
- ...
Hay más, hasta 15 según la wikipedia, pero aquí simplemente voy a comentar ciertas características y el formato de los mensajes.
Microkernels, hypervisors y seguridad por Hendrik Tews
Después de estar jodido el fin de semana con un trabajo para HW & OS Security, en el que me tuve que encargar de mi parte del código y gran parte del resto, además de hacer todo el testing, el lunes fui a la clase de dicha asignatura habiendo dormido algo así como 3 horas. Además, el sábado tuvimos en casa cena de despedida de Javi que ya se nos ha ido a España (ya le tocaba, llevaba aquí desde septiembre de 2006), y luego evidentemente salimos por ahí... Total, que al final había dormido desde el viernes bastantes horas menos de las que tocaba, pero creo que valió la pena porque la clase estuvo bastante interesante.
Vino Hendrik Tews, que trabaja en la universidad de Dresden en el tema del que nos estuvo hablando: microkernels e hypervisors. Como la mayoría de la gente que ha leído un poquito sobre sistemas operativos sabe, se suele hablar de dos grandes tendencias en el diseño de sistemas operativos: los nucleos monolíticos y los microkernels o micronúcleos.
Los primeros son una gran pieza de software que provee toda la funcionalidad necesaria en el sistema operativo, funcionando en modo privilegiado. Por el contrario, los microkernels tratan de minimizar el código que funciona en modo privilegiado, proporcionando las tareas necesarias y una interfaz para acceder a ellas desde espacio de usuario.
Esta minimización de las aplicaciones en espacio de kernel permite que un fallo en un cierto driver no influya en todo el sistema operativo y se venga abajo. Por ejemplo, una simple imagen de un sistema de ficheros en linux puede hacer que se venga abajo el sistema (de ello se habló en meneame via eyeideas que enlazaba aquí, pero a parte de esa cosa tan tonta que muchos consideran una feature, esta imagen echaba abajo cualquier kernel anterior a 2.6.22 según las pruebas que hice la semana pasada).
En el caso de un sistema basado en microkernel, el driver del sistema de ficheros se vendría abajo, el usuario (o el propio SO) se daría cuenta y lo volvería a iniciar. Nada de una caída de la maquina completa.
Además de microkernels, como he dicho, también hablo de hypervisors , qué son, cómo implementarlos sobre IA32 y algunas cosillas interesantes más. También nos ofreció una demo con el TuDOS CD Demo en la que pudimos ver cómo el típico xeyes no era capaz de seguir el ratón cuando éste estaba fuera sobre una de las aplicaciones aisladas por el servidor gráfico seguro que incorpora. Es fácil imaginar que si no puede obtener la posición del ratón, tampoco será capaz de obtener las teclas pulsadas por ejemplo.
A quien le interese minimamente el tema le recomiendo descargar las transparencias de la lecture. De momento he puesto el link desde la página de mi profesor, pero si por alguna razón dejara de funcionar y alguien lo quiere que me avise y lo subiré aquí.
Smart cards: Introducción
Puesto que este cuatrimestre estoy haciendo una asignatura basada al 90% en smart cards, aprovecho para contar aquí algunas cosillas de las mismas que tal vez resulten de interés :). En este primer artículo veremos qué es exactamente una smart card, comentando sus principales bloques funcionales y para qué se pueden utilizar. Más adelante comentaré algunas peculiaridades de la programación de smart cards usando la plataforma JavaCard.
Arquitectura típica de una smart card
Básicamente una smart card es un computador embedido en un pequeño chip, capaz de almacenar y procesar de forma segura datos. Generalmente se divide en varios tipos de smart cards, en función de sus posibilidades:
- Tarjetas de memoria: almacenan datos que pueden ser leídos a posteriori, posiblemente con cierto control de acceso o con mecanismos de memoria destructiva ( write-only ). Toda la funcionalidad de estas tarjetas está en una memoria ROM, de forma que siempre responden de la misma forma a una instrucción (leyendo la dirección de memoria correspondiente).
- Tarjetas con microprocesador: Además de almacenar información, estas tarjetas incorporan un microprocesador para el tratamiento de dicha información mediante el software correspondiente.
A veces se incluye (vease tarjetas inteligentes en wikipedia) otro tipo de tarjetas llamado tarjetas criptográficas, que incluye además un coprocesador criptográfico capaz de realizar cifrado utilizando por ejemplo RSA, DES o triple DES. Sin embargo yo este tipo lo incluiría en el grupo de tarjetas con microprocesador.
Aquí me centraré en las tarjetas con microprocesador, puesto que las podemos programar y son capaces de ofrecer funciones de seguridad bastante interesantes. Generalmente estas tarjetas llevan 3 tipos de memoria:
- ROM: Incluye el sistema operativo de la tarjeta.
- EEPROM: El disco duro de estas tarjetas.
- RAM:Espacio de trabajo donde encontramos la pila, variables temporales como claves criptográficas válidas durante la sesión actual, etc.
Según los datos que yo tengo de la asignatura HW & OS Security , una tarjeta actual típica puede tener unos 512 bytes de RAM, 16K de ROM y 64K de EEPROM. En principio se usaban SO propietarios y cada tarjeta se programaba con su propia API en C, pero actualmente existen sistemas como JavaCard que ofrecen una API común que los fabricantes pueden implementar en sus tarjetas. Más adelante veremos cómo realizar aplicaciones básicas con JavaCard ;).
Aplicaciones de las smart cards
Para finalizar con este post introductorio simplemente voy a comentar algunas de las aplicaciones comunes de las smart cards.
- Firma digital: Puesto que las tarjetas son capaces de realizar funciones criptográficas, pueden utilizarse para firmar documentos digitalmente. Simplemente se almacenan en la tarjeta las claves criptográficas correspondientes al usuario (clave privada RSA por ejemplo) y cuando se le pasa un documento a la tarjeta ésta lo firma. El problema que puede surgir aquí es que realmente no sabemos lo que se está mandando a la tarjeta para firmarlo, así que habría que autenticar de alguna forma el terminal usado.
- Dinero electrónico: Se pueden utilizar estas tarjetas como monedero electrónico. Por ejemplo, en Holanda tienen el sistema Chipknip.
- TV de pago: televisiones como Digital+ utilizan este tipo de tarjeta para identificar al usuario. La tarjeta se introduce en el decodificador y con ella se tiene acceso al contenido de pago, mediante claves de cifrado contenidas en la tarjeta.
inotify: notificación de eventos del FS en Linux
Mucha gente a día de hoy usa sistemas de búsqueda rápida de ficheros como Beagle (Linux y otros unix - web oficial no disponible ahora mismo) o Spotlight (OS X), que devuelven resultados de manera prácticamente instantánea. ¿Cómo funciona un software de este estilo? La idea que nos viene a todos a la mente es indexando los directorios en los que se quiere buscar para que todo vaya rápido, pero indexar cada cierto tiempo los directorios es poco eficiente y se debería buscar un compromiso entre la reducción de rendimiento producida por el indexado y la latencia con la que aparecen los archivos en el sistema de búsqueda.
Es aquí donde sistemas de notificación de eventos del sistema de ficheros pueden ser útiles. Inotify es un subsistema del kernel Linux que ofrece la posibilidad de escuchar en ciertos ficheros/directorios para recibir notificaciones de eventos en los mismos. Viene por defecto en el kernel desde 2.6.13 :).
Los artículos Intro to inotify ( en Linux Journal, por Robert Love) y Monitor Linux file system events with inotify (IBM developerWorks) ofrecen una introducción bastante maja a inotify y su uso, así que no voy a comentar mucho sobre ellos aquí. Lo que sí voy a hacer es dejaros una pequeña utilidad ( watch.c , correspondiente a un ejercicio de la asignatura que está alimentando este blog últimamente) que escucha en $HOME y /tmp y notifica de los cambios.
Un pequeño fallo que le veo a inotify es que no proporciona la posibilidad de escuchar un directorio y todos sus subdirectorios de forma recursiva, pero eso no es tarea del subsistema del kernel, sino de algún wrapper que funcione sobre ello, por ejemplo dentro de la libc o de una hipotética libinotify. A falta de dicho wrapper, hay que hacer una función recursiva que añada watches a todos los subdirectorios (ver el código).
La mayor parte de la aplicación se concentra en la función report() que muestra la información de los eventos y actúa en consecuencia (eliminando watches en caso de borrado, actualizándolos en caso de cambios de nombre o movimientos de directorios, etc.), aunque no tiene mucha complicación.
Además decidí usar una lista enlazada para almacenar los watches, tanto los paths como los watch descriptor correspondientes.
Finalmente, notar el uso del campo cookie de la estructura inotify_event que permite sincronizar los eventos IN_MOVED_FROM e IN_MOVED_TO. De esta forma es posible saber si dos de estos eventos están relacionados (es el mismo archivo) o no. Además, inotify generará esos eventos de forma consecutiva, con lo que simplemente habrá que comprobar si el evento siguiente a un IN_MOVED_FROM es su correspondiente IN_MOVED_TO o no (comprobando la cookie ) y actuar en consecuencia.
La verdad es que me ha parecido curioso el tema de inotify y creo que la utilidad ha quedado bastante maja 🙂
Shamir’s secret sharing: Secretos digitales compartidos
Con este post voy a salirme un poco de lo que viene siendo la temática habitual para meterme en otra un poquito más freak si cabe: la criptografía. No vamos a hablar de ningún algoritmo de cifrado ni de ningún criptosistema, sino de una técnica para compartir secretos digitales.
¿Qué es eso de compartir secretos? Imaginemos que somos parte del comité ejecutivo de una compañía que ha creado un producto revolucionario y desea que sus detalles se guarden en secreto, pero nuestro comité ejecutivo desea poder acceder a dicho secreto. Sin embargo, no queremos que un único miembro de dicho comité pueda acceder al secreto, sino que haya un determinado número de miembros presentes para dicho acceso. De esta forma, si un miembro por la razón que sea intenta acceder al secreto solo, el acceso será denegado.
Cómo podemos conseguir eso? Todos sabemos que para crear una recta sólo necesitamos dos puntos, una parábola 3, etcétera. Por tanto, una forma sencilla conocida como el esquema de Shamir (en inglés) se basa en el hecho de que con k+1 puntos de un polinomio somos capaces de reconstruir el polinomio entero. Para ello, se usa la interpolación polinómica de Lagrange , y en base a un determinado número de puntos se obtiene el polinomio.
Así pues, lo que habría que hacer para un esquema de secretos compartidos con n usuarios totales y un mínimo de k para obtener el secreto es lo siguiente:
- Codificar el secreto como un entero, S.
- Elegir un polinomio de grado k-1, f(x)=S+a·x + b·x^2 + ...
- Obtener n puntos de dicho polinomio y repartirlos a los n usuarios.
Así pues, cada usuario tiene su punto, y el polinomio se mantiene en secreto. Cuando se juntan k o más usuarios, simplemente aplican la fórmula de interpolación de Lagrange sobre esos puntos, y obtienen el término independiente del polinomio: nuestro secreto.
Este esquema se puede usar por ejemplo para el acceso a un sistema, siendo el secreto el password de acceso y teniendo cada usuario su propia clave. De esta forma, se proporcionan tres claves al sistema y éste reconstruye el polinomio mediante la fórmula de interpolación de Lagrange. Si el término independiente coincide con el esperado el acceso es permitido, y si no es denegado.
Un ejemplo simple e interesante de lo que pueden dar de sí las matemáticas, aplicando cosas sencillas que la mayoría conocemos de forma inteligente 🙂
Namespaces: una visión distinta del árbol de directorios para cada proceso
Sigo dando la coña con los ejercicios de Linux Kernel & Hackers Hut como viene siendo habitual 😛 Esta vez le ha tocado el turno a los namespaces. Es de sobra conocido el concepto de los chroot, que se viene utilizando desde hace mucho tiempo: cambiamos el directorio raiz de nuestro proceso (y todos los hijos que cree éste) por otro distinto, restringiendo su visión del árbol de directorios.
Esto se puede hacer desde la consola con la utilidad chroot o con la propia llamada al sistema chroot. Para ejecutar algo en un chroot necesitaremos tener disponibles dentro del mismo tanto los ejecutables como las librerías de las que dependa, o bien compilarlo de forma estática. Con esto y usando los mínimos privilegios para un servicio dado podremos reducir el impacto de una posible vulnerabilidad en dicho servicio.
Pues bien, el tema de los namespaces, aunque relativamente similar, es algo distinto. El namespace es el concepto que tiene un proceso dado del árbol de directorios. En un principio, todos los procesos comparten dicho concepto, heredándolo de init. Sin embargo, desde 2.4.19 el núcleo de linux incluye la posibilidad de ejecutar nuevos procesos con una copia del namespace de su padre.
¿Y en qué influye esto? Pues en que a partir de ahora, si nuestro proceso realiza un mount sobre un directorio cualquiera, solamente él y sus hijos lo podrán ver, pues son los únicos que tienen acceso a dicho espacio de nombres. Si desde otro proceso se monta cualquier dispositivo (o directorio usando --bind ) sobre un directorio dado, nuestro proceso tampoco lo verá.
Un ejemplo de uso sería montar un /tmp diferente para cada nueva sesión de usuario (por ejemplo un bind de /tmp/uid sobre /tmp en el namespace del usuario), de forma que no puedan ver los ficheros temporales de otros usuarios.
Se pueden ver varios ejemplos en este artículo de IBM developerWorks. Los artículos muestran como aplicarlo el login usando PAM; no los he probado, quizás un día de estos que tenga menos trabajo...
Para acabar, comentar que la forma de crear un proceso con una copia del namespace de su padre es llamando a clone() [similar a fork()] con el flag NEW_NS. Está todo explicado en el man de clone ;).
Empiezan las clases: get your hands dirty!
Entre la semana pasada y ésta ya he empezado las clases de todas las asignaturas que tengo este cuatrimestre. La verdad es que la cosa está bastante interesante, pero tiene pinta de que debemos trabajar muuucho en casa porque son pocas horas de clase para muchos créditos. Lo bueno de esto es que te obliga a practicar bastante, a hacer programillas y supongo que aprenderé bastante con ellos: get your hands dirty! 😀
En Web Information Systems no tenemos examen, y cuando acabamos un tema la semana siguiente no hay clase porque nos manda un trabajo corto, y al final se hace un trabajo largo y entre todos ellos se saca la evaluación de la asignatura. Básicamente está orientada a la web semántica: RDF, RDFS, ontologías y esas cosas.
En Criptografía 1 empezamos el viernes con algunos ejemplos de criptografía clásica: César, Vigenère, criptoanálisis de los mismos ( por ejemplo con análisis de frecuencias, buscando repeticiones en el texto cifrado para determinar el tamaño de la clave, usando el método de kasiski... ) y alguna cosilla más. Pero ahora viene lo bueno: secuencias con registros de desplazamiento, cifrado de bloque, teoría de la información de Shannon, compresión y un largo etcétera. Si alguien está interesado, aquí está el libro en pdf y en formato Mathematica NoteBook. Yo lo compré en papel por 25€... la verdad es que es un buen tocho.
En Linux Kernel & Hackers Hut como su nombre indica hablamos de Linux y de hackers. En la parte de Linux parece ser que vamos a ver más o menos los distintos subsistemas del kernel y cómo funciona; programaremos módulos como ejercicio semanal, en teoría en grupos de 1 a 4 personas aunque yo de momento no conozco a nadie así que cabe la posibilidad de que lo haga solo xD. En la parte hackers pues no sé muy bien lo que piensa dar, pero en las notas viejas que tiene hay un repaso a un poco de todo, desde SQL Injection a overflows, shellcoding y tal... aunque en la introducción dijo que tuvo que quitar cosas debido a problemas legales o_0.
Finalmente, en Hardware & Operating System Security vamos a centrarnos bastante en el tema de SmartCards y RFID, programando aplicaciones con JavaCard y según dijo en la primera clase, a tratar de hacer reversing sobre el protocolo usado por las máquinas de café que hay aquí, que usan una SmartCard para el cobro... y quién sabe si sacar café gratis 🙄 .
La verdad es que la cosa pinta interesante... ya iré comentando cosas que me parezcan curiosas por aquí 🙂
~tuxed/bookmarks #1
Estreno con esta entrada lo que espero que sea una serie de entradas sin periodicidad alguna (osea que aparecerán cuando me acuerde 😉 ) con enlaces a páginas interesantes que me vaya encontrando por ahí.
Vamos a empezar con algunos blogs dedicados a la seguridad que empecé a leer hace un tiempo y quería postearlos, pero que se ha ido retrasando debido a exámenes y otras ocupaciones que he tenido ( amén de la pereza que suele imperar en mí :oops:).
- 48bits.com : Excelente blog en español sobre seguridad informática. Publican artículos interesantes sobre exploits propios, alguna prueba/reto, etc. Colaboran varios profesionales de esto.
- 514 : Blog similar al anterior, en el que escribe entre otros A. Tarascó
- Sergio Hernando : Blog de Sergio Hernando sobre seguridad y auditoría de sistemas.
De momento vamos a dejarlo con estos tres, aunque conforme vaya acordándome iré añadiendo más enlaces que considere interesantes 😉
Así los tengo por si algún día se me olvidan... que yo con los bookmarks no me llevo muy bien 🙄
XSS en la web de la OPII
El otro día de casualidad me encontré con otro ejemplo más de lo que no se debe hacer en una aplicación web dentro de las páginas de la Universidad Politécnica de Valencia. Si en otro post hablaba de un problema de cookies y robo de sesión en la intranet de alumnos de la UPV, esta vez se trata de dos XSS en las páginas de la Oficina de Programas Internacionales de Intercambio (o algún nombre similar 😀 ).
Estaba yo mirando mis datos de la beca Erasmus cuando me tuve que ir a comer, y al volver me encuentro con que la sesión había expirado y la URL era del tipo error.asp?msg=mensaje , y el mensaje aparecía en el cuerpo de la página. Un claro ejemplo de XSS temporal si no se filtra adecuadamente el mensaje.
Además de éste, mirando las páginas de la opii que tenía en la barra de direcciones de mi firefox, me encontré con otra URL similar, pero esta vez metían el mensaje en un alert() de JavaScript y sólo era necesario cerrarlo con '); para salirse del alert y seguir añadiendo código JavaScript.
Les avisé y en un día tenía respuesta vía mail con un agradecimiento e informándome de que se habían corregido ambos fallos.
En fin, como decía antes, un ejemplo más de qué NO se debe hacer. Al menos esta vez fueron rápidos en corregirlo.