Barrapunto

En una entrada anterior planteaba el interrogante de si el intercambio Diffie-Helman de una sesión SSH también sería predecible en un sistema con la vulnerabilidad introducida en el OpenSSL de Debian. Lo lógico era pensar que así sería, pero no he tenido tiempo de investigarlo más a fondo.

Pués bien, gracias a la lista de pen-test he descubierto que hay quien se lanzó a probarlo y aquí está el resultado.

Actualización: La verdad es que podía haber sido un poco más explícito. El resultado es que sí, es posible obtener las claves temporales y por tanto descifrar toda la sesión SSH, aunque es necesario que el sistema no haya sido parcheado, no basta con que tenga las claves débiles(aunque puede ser el cliente o el servidor eso no importa). Siguiendo el enlace se encuentran unos scripts(en Ruby) que explotan la vulnerabilidad y una pequeña presentación(en francés) explicando cómo funciona.

Ésto es de lo más geek que he visto en mucho, mucho tiempo. No es que me emocione el rap pero este me ha llegado.

Kill Dash Nine!! No more CPU time!!

El otro día me apresuré a afirmar que la reciente debilidad criptográfica de Debian dejaba al descubierto todas las conexiones SSH, ipsec, etc... que hicieran uso de las claves generadas en estos sistemas. En el análisis de MetaSploit parecen estar de acuerdo Any SSH server that uses a host key generated by a flawed system is subject to traffic decryption and a man-in-the-middle attack would be invisible to the users. Sin embargo tras pensar un poco en el tema, comienzo a tener mis dudas.

En IKE(Ipsec) que es lo que conozco algo mejor, es posible(no obligatorio), elegir que se realize un intercambio Diffie-Hellman para conseguir "Perfect Forward Secrecy". En este intercambio se generan unas claves "de sesión", perfectamente deshechables al final de ésta. Estas claves nunca van "completas" por la red (ver los detalles del intercambio DH) por lo que las sesiones permanecerán indescifrables por siempre jamás.

Parece raro que en un protocolo como SSH(e incluso en SSL) no se permita, aunque sea como opción. Un tcpdump muestra inmediatamente un intercambio DH y yendo a los RFC's se encuentra que sí, que SSH soporta("cumple") PFS.

Ésto parece que salva las sesiones SSH de sistemas no Debian, y de sistemas Debian ya parcheados aunque conserven las claves débiles. Lo malo es que ésto es peor que una simple revelación de clave privada, ya que se le une el hecho de que el sistema de generación de aleatoriedad es precedecible. Si los primos generados para el intercambio DH pasan por las mismas funciones, estamos igualmente jodidos, aunque impliqye un poco más de trabajo al atacante.

No queda otra que irse al código fuente. El camino parece ser el siguiente:

kexdh_server() -> dh_gen_key() -> BN_rand()
y en OpenSSL BN_rand()->bnrand()->RAN_add()->ssleay_rand_add()

Así que en este examen rápido parece que sí, aunque necesitaría un poco más de tiempo para un examen más detallado, porque no sé si las condiciones en las que se llama a a esta función son idénticas. Una prueba rápida usando el código de Metasploit, muestra que la variable MAGICPID no afecta a openssl dh de una manera tan evidente como a openssl rsa. No sé qué opinaréis vosotros sobre todo este tema. Si tenéis correcciones o análisis diferentes, por favor, hacedlos :-)

Aquí. A ver si su lectura me anima a seguir con el "Concrete Mathematics" que lo tengo un poco abandonado.

Desde uno de los blogs que sigo con más asiduidad (si cacharreais con Ciscos diariamente os lo recomiendo), he llegado a esta extraordianaria descripción de cómo Pakistan Telecom comenzó a anunciar como suyos rangos a asignados a Youtube con el objetivo de hacerlo inaccesible desde Pakistán, pero con el "pequeño" efecto lateral de impedir también el acceso a Youtube al resto del mundo.

Para los que no estéis familiarizados con BGP, deciros que es el "pegamento" que mantiene unido Internet, y permite que el enrutado sea totalmente descentralizado. Se basa en el enrutamiento entre sistemas autónomos(AS), cada uno de los cuales "publica" en determinados puntos de conexión("peers" BGP) con otros ISP's los rangos que tiene asignados administrativamente. Una vez que el tráfico llega al AS correcto, es su responsabilidad llevarlo a su destino (usando un protocolo de encaminamiento interno com OSPF, IS-IS, etc...)

El problema de la descentralización es que tienes que confiar en tus iguales, y en algún momento, por error o mala fe, alguien puede empezar a publicar por internet rangos que no son suyos. Las soluciones técnicas son complicadas además de costosas en recursos(un router con una vista BGP completa puede tener unas 250.000 entradas en su tabla de rutado).

El curso de los acontecimientos fue más o menos el siguiente.

El nombre Youtube.com resuelve como 3 ip's, todas dentro del rango 208.65.153.0/24. Todo el rango 208.65.152.0/22 es propiedad de Youtube (publicado con un prefijo de longitud 22).

En un momento dado, Pakistan Telecom comienza a publicar como suyo el 208.65.153.0/24 y el ISP "aguas arriba"(PCCW)[1] lo acepta sin pestañear. Como siempre se prefieren rutas más concretas a más genéricas, el resto del mundo empieza a enrutar ese rango hacia Pakistán (el tráfico hacia 208.65.152.0/24 y 208.65.154.0/23 llega OK, pero las ip's de la web no están en ellos).

1 hora y 20 minutos después (me puedo imaginar el pánico de los admins de Youtube), el AS asignado a Youtube empieza a publicar también el rango 208.65.153.0/24. Al haber dos rutas iguales, queda a discreción de cada ISP decidir cual usar (el AS_PATH o número de AS intermedios suele ser el factor determinante).

10 minutos después, parece que se lo piensan mejor en Yotube y empiezan a publicar (además) los rangos 208.65.153.0/25 y 208.65.153.128/25. El problema es que es habitual ignorar todos los prefijos mayores de 24(o las tablas de rutado se harían enormes), así que el efecto no es tan determinante como cabría esperar.

Una media hora más tarde, comienzan a verse que las rutas generadas desde Pakistan tienen un AS_PATH más largo(lo que se conoce como AS-prepend), lo que sugiere que PCCW está intentando hacer su ruta menos deseable.

Finalmente, PCCW toma la decisión de rechazar todas las rutas de Pakistan Telecom y todo vuelve a la normalidad.

[1] Me parece extraño que un ISP tenga una sola conexión hacia otros ISP's, tal vez Pakistan Telecom no sea muy grande, o los otros ISP's filtraron la ruta.

Android, ya está entre nosotros en forma de SDK y documentación. Aún no he tenido tiempo de instalar "la cosa", pero parece que viene completa con emulador incluido, todo muy enfocado hacia desarrolladores de aplicaciones, con anuncios de futuras "recompensas" a las mejores aplicaciones.

En concreto la información de bajo nivel que es lo que me gustaría mirar no lo he encontrado y es posible que no esté disponible todavía. Me haría ilusión llegar a ejecutar el "gPhone" en mi Nokia n770. Quién sabe si en un futuro los teléfonos móviles será tan versátiles como los PC's, con componentes más o menos "genéricos" que puedan aprovechar los distintos sistemas operativos. De momento, ya tenemos algo más que un anuncio de prensa que decía Ballmer :-)

Actualizacion:Ya he encontrado algo de más bajo nivel.

Hace bien poco que he puesto a Java a caer de un burro en algún comentario, pero ahora resulta que tengo que aprender lo máximo posible sobre J2EE/JSP/JDBC en el poco tiempo libre que dispongo, por lo que imploro a los Javeros no rencorosos que me echen una mano recomendándome algún buen libro o manual.

La razón es que me he inscrito a una oposición de programador Java(no os creáis que de verdad me apetece ponerme a programar en Java ;-).

No soy un novato, así que nada de cosas introductorias. Aunque hace mucho que no programo en este lenguaje, he seguido sus evoluciones(genéricos, etc...)y conozco la sintaxis lo bastante bien. Necesito algo que vaya directo al grano, y que me explique los conceptos y las API's más importantes de J2EE, más que algo sobre el lenguaje en sí para intentar pasar el ejercicio de test.

Bueno, vosotros diréis. Os estaré muy agradecido.

[Editado] Gracias a los que habéis respondido. Creo que con lo que me habéis comentado me vale para ir con algo y pueda luchar por aprobar el ejercicio (aunque no sueño con llevarme la plaza).

No, esta entrada no va sobre Sun, y eso que es una compañía que siempre he admirado, me gustan sus productos (SPARC y Solaris sobre todo) y cómo una empresa que sin ser MS ni IBM diseña y fabrica sus propios procesadores, su propio lenguaje y su propio sistema operativo.

Su gran lema ha sido siempre "The Network is the computer", aunque su significado ha sido siempre algo difuso según a quién preguntases. Hoy día hay una empresa que se puede decir sin lugar a dudas que lo ha hecho realidad y no, no ha sido Google sino Amazon.

Debo haber vivido en una burbuja de cristal en los ultimos dos años o así porque no entiendo cómo se me ha escapado algo tan revolucionario como los Amazon Web Services. Son una serie de servicios que virtualizan servidores, almacenamiento y paso de mensajes (casi nada), y que son facturados única y exclusivamente por uso (precios de 0,1$ por GB de transferencia por ejemplo). Para que os hagáis una idea, Smugmug está almacenando algo así como 300 TB de datos en su infraestructura de almacenamiento Amazon S3(Diapositivas). Creo que para hacerse idea de su potencia, este ejemplo es más explícito que cualquier cosa que yo pudiera escribir. Una vez leído creo que estaréis tan sorprendidos y tan deseosos de montar una empresa Web 2.0 exenta de riesgo como yo lo estoy ahora. ¿El siguiente YouTube? No hay problema, olvidaros de comprar servidores, dimensionar almacenamiento, contratar hosting etc... tan solo pensad en hacer las cosas escalables y Amazon se encargará del resto. Y si la cosa fracasa, pués se paga la factura y se cierra el chiringo. Riesgo (casi)cero porque si no hay éxito no hay gasto y viceversa.

Pero por si esto no fuera poco, han dado un paso más allá. Lo anterior lo podía concebir (un montón de blades con VMware y unas SAN FC enormes), pero han llegado al punto de imaginar un ¡cluster de humanos!. La verdad es que necesito algo de tiempo para digerirlo y asegurarme de que lo he entendido bien.

Es una entrada rápida, por si le sirve a alguien de ayuda. Hace poco compre un TiBook en Ebay y lo único que me quedaba por hacer funcionar era la PCCard Option 3G+ de Amena/Orange.

Los drivers de Option no se pueden bajar de su web sin una tarjeta "libre", pero sí de este operador filipino.

A partir de aqui, todo muy fácil. Para 3G APN: internet Usuario:CLIENTE Pass: AMENA.

No sé cuántos de por aquí tendréis que lidiar diariamente con hardware Cisco, pero para los que lo hagáis (o tengáis intención o curiosidad), existe un software increíble(con licencia GPL) llamado dynamips. Es un emulador de MIPS (y ahora también PPC) y de l resto del hardware de un buen puñado de routers Cisco, que es capaz de cargar imágenes de IOS.

Consume "un poco" de CPU y memoria, pero tampoco nada exagerado para los estándares actuales. En un AMD 3000+ con 1GB puedo poner 5 o 6 2691 con imágenes con soporte IPSEC sin problemas(sin apenas tráfico, también hay que decirlo).

Es una auténtica pasada. Si vais a preparar el CCNP(yo igual me animo dentro en cuanto pase este mes), olvidaos de simuladores estilo Boson completamente. Además, existe una herramienta llamada dynagen que permite montarse los laboratorios en un abrir y cerrar de ojos.