Historias
Slashboxes
Comentarios
 

Nuevas herramientas para explotar el bug de Debian/OpenSSL

editada por deal el 20 de Julio 2008, 12:22h   Printer-friendly   Email story
desde el dept. open-ssl
pobrecito hablador nos cuenta: «Luciano Bello, el descubridor del problema en el PRNG del paquete OpenSSL de Debian, junto a Maximiliano Bertacchini y Paolo Abeni, ha desarrollado un parche para wireshark que permite descifrar las comunicaciones SSL que se hayan realizado con versiones vulnerables de este paquete.»

Historias relacionadas

[+] Debilidad criptográfica en los paquetes openssl de Debian 87 comentarios
Luciano Bello, desarrollador argentino de Debian, ha descubierto que el generador de números aleatorios del paquete openssl de Debian es predecible (DSA-1571-1), lo que implica una debilidad criptográfica bastante importante. Las claves afectadas incluyen las claves SSH, OpenVPN, DNSSEC, y las usadas en los certificados X.509 y en las sesiones SSL/TLS. Las claves generadas con GnuPG o GNUTLS no está afectadas. La primera versión afectada por este problema es 0.9.8c-1 (sarge no está afectada). Para la distribución estable, estos problemas ya han sido corregidos en la versión 0.9.8c-4etch3. El proyecto Debian ha deshabilitado las conexiones con clave ssh como medida de seguridad en su infraestructura interna como respuesta.
Actualización: 05/13 17:11 GMT por inniyah: Zak B. Elep enlaza en su bitácora con un programa que permite comprobar fácilmente si nuestras claves públicas OpenSSH o OpenVPN son lo suficientemente débiles como para que necesiten ser reemplazadas. Además indica cómo regenerar las claves RSA y DSA del servidor openssh-server, lo que es bastante recomendable.
Actualización: 05/13 20:21 GMT por inniyah: Resumen para el usuario final de los programas afectados y cómo afrontar el problema.
Actualización: 05/14 07:48 GMT por inniyah: Erich Schubert plantea en su bitácora dudas muy serias sobre si el problema es realmente de Debian o si confiar en los contenidos de la memoria no inicializada es más bien un fallo de diseño de los propios desarrolladores de openssl que, por otra parte, tampoco vieron ningún problema en el parche propuesto por Debian. Aigars Mahinovs da más pistas de cómo se ha podido llegar a esta situación.
Actualización: 05/15 15:06 GMT por inniyah: H. D. Moore, creador del proyecto MetaSploit, ha publicado un artículo sobre la extensión del problema. Ya han aparecido exploits que aprovechan esa vulnerabilidad. Se deben considerar comprometidas todas las claves DSA que hayan sido usadas alguna vez en un sistema afectado, tanto para firma como para autentificación.
Este hilo ha sido archivado. No pueden publicarse nuevos comentarios.
Mostrar opciones Umbral:
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.
  • ermmm

    (Puntos:1)
    por xico1984 (34892) el Domingo, 20 Julio de 2008, 12:35h (#1066307)
    ermmm y esto no se podría considerar software maligno? Porqué se publica? No lo entiendo!
    • Re:ermmm

      (Puntos:4, Informativo)
      por sorrill (13858) el Domingo, 20 Julio de 2008, 12:58h (#1066312)
      ( http://barrapunto.com/ )
      Cierto, no lo entiendes.

      La seguridad por obscuridad no sirve de nada, que tu no sepas que existe ese problema y esa facilidad para explotarlo solo te hace mas vulnerable.

      Si por un casual tienes backups con cifrado basado en un Debian vulnerable con esta noticia serás mas consciente aún de lo grave del problema y quizá decidas tomar las medidas oportunas para proteger esos datos.

      Esconder la cabeza debajo de una piedra no soluciona el problema, gritar el problema a los cuatro vientos tampoco lo soluciona pero evita que te olvides que debes hacer algo para evitar que alguien lo utilice de forma malintencionada.

      Ya se ha dicho que Debian tenía este problema, ya se ha dicho como solucionarlo, ahora se dice lo fácil que es explotarlo tanto en sistemas vulnerables actuales como en todos aquellos datos generados en sistemas vulnerables.

      [ Padre ]
      • Re:ermmm de xico1984 (Puntos:1) Domingo, 20 Julio de 2008, 16:26h
        • Re:ermmm de xico1984 (Puntos:1) Domingo, 20 Julio de 2008, 16:32h
          • Re:ermmm de sorrill (Puntos:2) Domingo, 20 Julio de 2008, 16:48h
    • madre mia de xico1984 (Puntos:2) Domingo, 20 Julio de 2008, 16:13h
      • Re:madre mia de xico1984 (Puntos:1) Domingo, 20 Julio de 2008, 16:16h
    • 2 respuestas por debajo de tu umbral de lectura actual.
  • por lucianobello (16581) el Lunes, 21 Julio de 2008, 17:11h (#1066595)

    habrá que leerse la definición de parche, porque yo lo llamaría plugin
    Es un .diff que se aplica con el comando patch. Para mí que tiene sabor a parche.

    Seguro que esa herramienta ya existía de ante
    No tengo forma de saber que una herramienta que haga lo mismo existiese antes. En particular esta, estoy seguro que no.

    De hecho, a mi me da la sensación de que estos descubridores del bug han podido hacer uso de ese "parche" antes de publicar el bugs del openssl de debian y una vez habiendo sacado el partido suficiente, publicar el fallo y el parche para explotarlo.
    irony mode on
    ufff.. ya me estaba aburriendo de hacerme de números de tarjetas de crédito.

    Lo lógico en estas circunstancias es publicar un parche para arreglar el problema y no uno para explotarlo.
    En lo personal, estoy convencido que explotar un bug es parte del ciclo de vida de un fallo. Es la forma de llevar a la práctica algo que se intuye desde la teoría. Sabemos que un PRNG sesgado puede hacer que una conexión cifrada sea descifrada. Pero no podemos estar seguros hasta que desciframos una conexión cifrada con un PRNG sesgado.
    Creo que un disclosure responsable implica no sacar un exploit sin el parche. Pero a pasado tiempo ya desde que el parche está accesible.
    Para ser sincero.. estoy algo aburrido de las teorías conspirativas y de las dudas sobre la seguridad en el software libre... creí que ya habíamos superado eso...
    [ Padre ]
  • 2 respuestas por debajo de tu umbral de lectura actual.