El supuesto último gran fallo de Internet del 2008

Desde hace dos días he leído toda clase de barbaridades acerca del supuesto “más grande ataque a la infraestuctura de internet” de los últimos tiempos. Además de desacertado (pues ya se había previsto) es completamente amarillista llamarlo así, al día de hoy (31 de diciembre) los investigadores que publicaron el ataque informan que el problema ha sido corregido por VeriSign y los potenciales afectados han sido informados.

He aquí de algunos titulares amarillistas que he encontrado:

Vulnerabilidad en la infraestructura de clave pública
El algoritmo MD5, en peligro
Researchers hack VeriSign’s SSL scheme for securing Web sites
Cómo unos hackers rompieron la seguridad del SSL usando 200 PS3

Hasta sitios que considero de respeto, como Astalavista, cayeron en el juego. Yo preferí leer el reporte orginal de los investigadores e informar breve pero verdaderamente el ataque que realizaron.

Breve introducción

Como alguna vez explicamos, una parte de la seguridad en Internet se basa en el uso de certificados digitales, que dan certeza sobre la identidad de un servidor en Internet. Un equipo de investigadores recientemente publicó una demostración de un ataque que permitió falsificar indetectablemente un certificado digital, firmado por la empresa RapidSSL (filial de VeriSign), y que los navegadores aceptan como parte del círculo de confianza.

El ataque fue factible porque la empresa RapidSSL generaba las firmas digitales, de sus certificados digitales, usando el esquema ‘MD5 con RSA’. El algoritmo MD5 ya se considera inseguro desde hace largo tiempo. Anteriormente se han realizado demostraciones impresionantes, por ejemplo el famoso caso de Nostradamus en donde generaron distintos archivos PDF que tenían el mismo hash MD5. Además desde 2005 ya se había publicado un artículo en donde se exponía cómo usar colisiones MD5 para generar dos certificados digitales distintos que produjeran el mismo hash.

El ataque

Lo que hicieron estos investigadores, para falsificar el certificado, fueron principalmente dos cosas: predecir probabilísticamente cuál iba a ser el siguiente número de serie (del certificado generado por RapidSSL) y generar una llave pública que ocasionara colisiones MD5. La parte más dificil fue construir una llave pública que ocasionara colisiones y construir la llave privada a partir de la llave pública, pues es necesario firmar con la llave privada la petición de un certificado. Se requirió el poder de un clúster de 200 PS3 para hacer los cálculos, además de gastar 657 dólares en la compra de certificados para poder predecir el número de serie.

El alcance de este ataque, como bien dicen ellos, está limitado para aquellas CA (Autoridades Certificadoras) que generen certificados firmados con MD5, y la gran mayoría actualmente firma con SHA-1. Aunque SHA-1 ya no se considera seguro no se conocen ataques de este tipo, pero ellos recomiendan que se use al menos SHA-2 para generar las firmas, porque puede ser que en poco tiempo empiecen a surgir ataques parecidos a los de MD5 y sí va a ser entonces un problema grave para todo el mundo.

En el artículo original se puede encontrar el certificado y una página web de muestra para ver el certificado en funcionamiento. Pero los investigadores se cuidaron de que nadie le dé mal uso a su trabajo, por lo que hicieron que el certificado expirara en 2004 y no publicaron la llave privada. Potencialmente, si se pudiera llevar a cabo este ataque para cualquier certificado, cualquiera podría falsificar la conexión segura de un banco (por ejemplo) y de manera indetectable si se combina con un DNS poisoning o pharming.

Ext4

Como mencioné en una entrada anterior , Ext4 ya está listo para sustituir a Ext3 y el kernel más nuevo de Linux ya incluye soporte estable para él. Los sistemas de archivos Extended (Ext, Ext2,…) han sido históricamente usados por defecto en sistemas Linux y son herederos de los viejos sistemas de archivos Unix; aunque Linux soporta otros sistemas de archivos más modernos como ReiserFS y XFS. En esta entrada voy a explicar a grandes rasgos las mejoras de Ext4 respecto a Ext3.

Ext3 supuso una mejora respecto a Ext2 al introducir journaling. El journaling es una técnica mediante la cual se lleva un registro de las actividades en el sistema de archivos y facilita la recuperación del sistema de archivos después de una interrupción abrupta (como una falla eléctrica). Cuando se borra un archivo ocurren dos procesos principales: eliminación de la entrada del directorio que lo contiene y marcado de los bloques ocupados como bloques libres en el mapa de bloques; si no se completan los dos procesos el sistema de archivos puede quedar en un estado inconsistente; además detectar y recuperarse del fallo puede toma mucho tiempo, pero con journaling esto se puede hacer de manera más eficiente y segura.

No me voy a centrar en datos sensacionalistas sobre el tamaño de archivos que ahora soporta, o la cantidad de archivos que puede contener cada directorio, ya que eso NO es un diferenciador importante a la hora de comparar sistemas de archivos. Quiero enumerar las nuevas características y mejoras conceptuales que se introdujeron:

  • Extents: Los sistemas de archivos derivados de Unix (como Ext3) mantienen un esquema de mapeo de bloques para llevar el rastreo de bloques que pertecen a un archivo, por ejemplo un i-nodo mantiene una lista de bloques de un archivo. Para archivos grandes esto es ineficiente en tiempo y espacio pues el mapa de bloques es enorme, ya que los bloques son de tamaño fijo. Un extent es básicamente un espacio de bloques físicamente adyacentes que ahora se puede utilizar en el mapeo de un archivo; esto mejora el rendimiento, reduce el espacio y reduce la fragmentación.
  • Alojamiento multibloque: Cuando Ext3 quiere escribir información a disco, el alojador de bloques decide qué bloques libres van a ser usados para escribir los datos. El problema es que el sistema de Ext3 sólo permite alojar un bloque (4 Kb) a la vez; esto no sólo es ineficiente para el tamaño de los archivos que se manejan actualmente, también impide que se pueda optimizar la asignación de bloques pues el alojador de bloques no sabe de qué tamaño es todo lo que se va a escribir. Con el alojamiento multibloque se pueden pedir muchos bloques al mismo tiempo. Esta característica ayuda a reducir la fragmentación.
  • Alojamiento retartado: Esta característica ya viene incluida en sistemas de archivos modernos como XFS, ZFS y Reiser, y consiste en retardar el alojamiento de bloques lo más posible. Lo que pasa actualmente es que cuando un proceso pide escribir a disco, inmediatamente se asigna el bloque al que se va a escribir, aún si la información va a estar en caché un tiempo o si se va esperar un tiempo antes de escribir. Este método trae desventajas como cuando un proceso está escribiendo un stream, ya que no se sabe de qué tamaño va a ser el archivo finalmente. El alojamiento retardado asigna los bloques hasta que realmente se va a escribir a disco, lo que permite optimizar el alojamiento. Esta característica se combina perfectamente con las dos anteriores: extents y alojamiento multibloque; para mejorar el rendimiento y la fragmentación.
  • Defragmentación al vuelo: Aunque con las características anteriores la fragmentación se va a reducir en la mayoría de lo casos, ahora existe la opción de defragmentar el sistema de archivos al vuelo. Esto porque en sistemas de alta concurrencia la fragmentación es un gran problema y la leyenda urbana de que Ext3 se fragmenta poco es completamente falsa para un sistema de mediana concurrencia al disco duro. Esta característica no está disponible todavía en el kernel (2.6.28) pero existe una herramienta llamada e4defrag por el momento.
  • Prealojamiento persistente: Cuando una aplicación necesite reservar espacio en disco pero todavía no tenga los datos que se van a escribir, se puede prealojar el espacio en el sistema de archivos; esto es que se construyan las estructuras internas del sistema de archivos y se reserven los bloques necesarios. Por ejemplo lo que hacen los clientes P2P es escribir un archivo relleno de ceros del tamaño del archivo que van a bajar, pero esto es sucio e ineficiente. Con el prealojamiento este problema se soluciona y además se reduce la posibilidad de fragmentación.

Además se introdujeron otras mejoras en los i-nodos y en el journal. Un efecto colateral con todas las mejoras es que el fsck ahora va a ser mucho más rápido, por lo que ya no tendremos que desesperarnos cada vez que nuestro Debian necesite hacer un chequeo de disco.


[Fuente]

[Fuente2]

2008 el año de las grandes fallas en Internet

Este 2008 fue el año de las grandes catástrofes en Internet segun Hispasec, término que me parece muy interesante y cierto pues ha habido una serie de problemas que afectan a Internet en general como en ningún otro año hubo.

  • El descuido del OpenSSL en Debian : Debian ha sido una de las distribuciones más estables y seguras, con la premisa de mantener solamente versiones estables de software, aunque viejas. En 2006 un desarrollador comentó una línea de código del paquete open-ssl para evitar algunas molestas alertas del compilador, aunque antes se asesoró con los desarrolladores de open-ssl para tener la certeza de que no estaba haciendo nada mal. El problema de comentar esa línea es que se redujo drásticamente el rango de valores para escoger llaves publicas, provocando que la “aleatoriedad” al escoger llaves ya no sirviera como medida de seguridad, y se pudieron calcular muchísimas listas que contenían todas las posibles llaves. Esta falla ya esta solucionada.
  • Kaminsky y los DNS : En julio Dan Kaminsky descubre una vulnerabilidad en el protocolo, lo que permitiría falsificar las respuestas de un DNS, y así un atacante podría apoderarse de una zona o dominio entero; y, por consiguiente el atacante podría enviar páginas falsas pareciendo correctas a miles de personas. Esta falla ya esta solucionada
  • La falla en la arquitectura del BGP : Tony Kapela y Alex Pilosov demostraron una ataque que permite interceptar el tráfico de Internet en una forma casi idetectable. Es una falla en la arquitectura del protocolo BGP (Border Gateway Protocol), que permite interceptar y hasta modificar el tráfico de Internet que no esté cifrado y sin que ninguna persona pueda darse cuenta. Esta vulnerabilidad no se basa en algún error de software, es una falla en la arquitectura del protocolo BGP, ya que este protocolo que se basa en la confianza mutua. La falla no esta solucionada, y la solución que proponen es que los routers en su comunicación usen certificados de seguridad que eviten la confianza mutua.
  • La supuesta denegación de servicio del TCP : Outpost24 presume haber descubierto una vulnerabilidad en el protocolo TCP, que podría causar una denegación de servicio a cualquier implementación del mismo. Cabe destacar que el protocolo TCP es el más importante para la comunicación en todo Internet. No se han dado detalles del problema.
  • Los avances en la inseguridad de Wireless : Este año se caracterizó entre otras cosas por empezar a sacar provecho de los GPU. Hay que señalar que un GPU es el procesador de las tarjetas gráficas. Algunas compañías aseguran poder crackear una clave WPA mucho más rapidamente mediante el uso combinado de GPU y CPU. Poco después se descubren vulnerabilidades en el algoritmo TKIP (un cifrado muy utilizado en WPA). Todo el mundo comentaba que la seguridad en redes wireless está por los suelos, pero la verdad es que el problema con TKIP ni siquiera facilita la obtención de la clave, sólo permite descifrar parcialmente los paquetes; y, para realmente obtener una aceleración impresionante en el crackeo por GPU necesitaríamos una tarjeta gráfica realmente cara, no una convencional como anunciaban esas empresas de software.
  • El clickjacking : Jeremiah Grossman y Robert Hansen, dos expertos en seguridad Web, se reunen para demostrar una vulnerabilidad basada principalmente en las etiquetas iframe. La vulnerabilidad permite a un atacante forzar a que un usuario, sin saberlo, “haga click” en un vínculo que el atacante quiera. Lo peor es que todos los navegadores son vulnerables y la única forma en la que se puede evitar es deshabilitando las etiquetas iframe en el navegador.

¡ Esperemos un mejor año !

Nuevo kernel linux (2.6.28)

Normalmente no hacemos comentarios acerca de nuevas versiones del kernel, pero esta versión es diferente pues introduce dos cambios especialmente radicales que van a alterar el mundo linux.

La primera de ellas es la elimición de la etiqueta experimental al sistema de archivos Ext4. Con lo que ahora Ext4 es una opción estable para sutituir al viejo Ext3. Veremos en un próximo artículo las mejoras respecto a Ext3.

La segunda es la mejora del manejo de memoria en tarjetas gráficas, sustituyendo la vieja administración (ineficiente) que se remonta a la década de los 80, por un nuevo sistema de administración al nivel que se merecen los poderosos y modernos GPUs que tan en boga están últimamente.

Otras mejoras menores son el soporte para para protección contra golpes, que permite desmontar las unidades de disco en caso de caída, cuyo fin es dar esa funcionalidad en laptops que cuenten con discos duros con soporte para entrar inmediatamente en suspensión y acelerómetros que indiquen la caída. También se introdujo una mejora en el manejo general de memoria para eficientar el “swapping” en sistemas con una gran cantidad de memoria; ahora las páginas de memoria se guardan en tres listas diferentes que indican que tan factible es para una página ser “swappeada”, antes sólo estaban en una lista y cada que se quería hacer “swap” había que recorrer toda la lista de páginas buscando candidatos; por ejemplo, ahora las páginas de un ramfs están en una lista especial de páginas que no pueden ser “swappeadas”.

[Fuente]

¿Qué hubiera pasado si la bomba de Hiroshima hubiera caido en México?


Muy interesante este calculador de destrucción llamado Ground Zero, en el que da a elegir entre una serie de armas de destrucción y con ayuda de google maps puedes seleccionar en que parte del mundo quieres ver, creo que es una forma para que veamos lo terribles que pueden llegar a ser estas armas de destrucción masiva, y un NO a la guerra.

Seguridad mediante obscuridad

llave bajo el tapeteHay quienes creen que si un atacante no conoce la URL de una página tienen seguridad, y en parte tienen un poco de razón; pero sólo si además de no conocer la URL, esta está protegida por contraseña y tiene tal vez algún otro mecanismo de seguridad. Aunque a lo que realmente se refiere el término seguridad mediante obscuridad es a usar la obscuridad como mecanismo para aumentar la seguridad. Yo en lo personal creo que no lo hace.

Muchas páginas de internet tienen una validación de usuario y contraseña, a veces hasta tienen SSL, a lo cual muchos dirían “esta bastante seguro”; pero cuando vemos más detenidamente la dirección a la que te lleva depués de iniciar sesión correctamente, así como todas las que le siguen, nos damos cuenta que se puede acceder ahí sin haber iniciado sesión forzosamente. Habrá algunos que no sepan que hay que cuidarse de eso, pero hay otros que garantizan que eso es seguro, además argumentado que es para facilitarle la vida a sus empleados y poder guardar en favoritos la dirección, dejando correr el riesgo y siendo algo totalmente inseguro y falso.

En cualquier momento alguien podría intentar atinarle a alguna de las páginas y no es muy difícil, pensando en que el login se encuentre en pagina.com/system/login.php, podemos intentar en users.php, o en menu.php o menu.html, cualquiera de esas páginas nos llevará a una que contenga toda la lista de links a las demas, y si su única protección es “que nadie conoce los links” estarán en graves problemas. Otra posible técnica es una búsqueda en google de “Index of” site:pagina.com, ésto nos desplegará todos los directorios que ha indexado google con sus respectivos contenidos; a menos que se configure el servidor web para negar el listado de los directorios del sitio.

Y así hay muchas razones por las cuales no debemos confiar en la Seguridad mediante obscuridad

Otro conexto en el que aplica este término es quien dice el código cerrado es mucho más seguro, cosa que para mi punto de vista es totalmente falso, y lo ha demostrado Linux. Tal vez si alguien analiza el código fuente de Linux le ayude a encontrar alguna falla, pero definitivamente no va a ser como en Windows que 10 años despues encuentran una falla crítica en Windows 98 que no se habían dado cuenta, y que ha sido heredada por todo el árbol genealógico de Windows hasta llegar a Windows Vista.

Seguridad mediante obscuridad es como dejar la llave de tu casa abajo del tapete o en la maceta, tal vez nadie la encuentre, pero tal vez sí.

¿Porque SPEI cierra a las 4?

SPEI es el Sistema de Pagos Electronicos Interbancarios de México, ¿pero porqué después de las 4 no puedes hacer movimientos? Es una buena pregunta siempre lo he querido saber, ¿qué acaso las computadoras dejan de trabajar a las 4? ¿o tal vez los servidores se gastan por estar prendidos tanto tiempo? ¿o que el enlace dedicado solo lo contratan de 8am a 4pm en dias hábiles?, ¿o hay cientos de personas revisando las transferencias interbancarias que se hacen en el día y dejan de trabajar a las 4? ¿o tal vez solo es un if(hora < 8 || hora > 16) return false;?, siempre me lo he preguntado pero tal vez es algo que nunca pueda comprender…