Versión n-esima del !bug gravísimo que hará que se acabe Internet! Yo mismo he sufrido un pequeño shock cuando he leido que se había descubierto una vulnerabilidad en OpenSSH que permitía descifrar la información enviada, creo que aún me duran los sudores frios, ya que OpenSSH, debido a su calidad y al tratarse de software libre y gratuito, es ampliamente utilizado para la gestión de practicamente todo lo que se gestione por línea de comandos, además de utilizarse ampliamente para tunelizar a través de él conexiones a las que no es posible aplicarles ningún tipo de cifrado, por eso una vulnerabilidad que permite descifrar el contenido de las sesiones de OpenSSH sería sencillamente terrorífica.
Sin embargo, soy consciente de lo sensacionalistas que son algunos medios, incluso en los últimos tiempos la prensa especializada en seguridad (todo se pega...), así que me he dedicado a pegar un vistazo a que decía el propio Advisory de OpenSSH y SecurityFocus, dos sitios que es de esperar que no tengan los tintes sensacionalistas que tienen otros medios.
La vulnerabilidad consiste en un fallo en el modo de cifrado CBC de varios de los algoritmos establecidos por defecto que, según cuentan los descubridores de la vulnerabilidad, permite obtener hasta 4 bytes de la información cifrada en la sesión por medio de observar el comportamiento que tiene el servicio ante diferentes errores al cerrar la sesión.
Sin embargo, según dice OpenSSH, para realizar un ataque efectivo contra una sesión interactiva sería necesario matar la conexión SSH unas 11356 veces para obtener información útil, por lo que evidentemente cualquier administrador debería suponer que algo raro está pasando (si antes no muere de viejo intentando hacer un ps :P). El único riesgo que parece más factible son aquellas conexiones automatizadas que siempre envían la misma información, como por ejemplo un scp programado entre dos máquinas (algo bastante común), que podría ser interrumpido sistemáticamente hasta conseguir recuperar el fichero transmitido (a golpe de 4 bytes cada vez), aunque según el Advisory de OpenSSH, serían necesario muchos días para recuperar un fichero pequeño, a un ritmo de 44 bits recuperados por hora, por lo que explotar este ataque se hace complicado.
En resumen, la vulnerabilidad existe y es posible desencriptar el tráfico parcialmente, por lo que deberiamos actualizar a la última versión de OpenSSH (que básicamente establece AES como algoritmo de cifrado por defecto, que ya no sufre esta vulnerabilidad) y evitar el peligro, sin prisa pero sin pausa. Sin embargo, es una vulnerabilidad difícil de explotar, o mejor dicho, difícil de obtener información de ella, por lo que no es algo que yo personalmente vaya a incluir en mi "arsenal" de herramientas de pentesting, a menos que algún trabajo concreto lo requiera.
Sin embargo, soy consciente de lo sensacionalistas que son algunos medios, incluso en los últimos tiempos la prensa especializada en seguridad (todo se pega...), así que me he dedicado a pegar un vistazo a que decía el propio Advisory de OpenSSH y SecurityFocus, dos sitios que es de esperar que no tengan los tintes sensacionalistas que tienen otros medios.
La vulnerabilidad consiste en un fallo en el modo de cifrado CBC de varios de los algoritmos establecidos por defecto que, según cuentan los descubridores de la vulnerabilidad, permite obtener hasta 4 bytes de la información cifrada en la sesión por medio de observar el comportamiento que tiene el servicio ante diferentes errores al cerrar la sesión.
Sin embargo, según dice OpenSSH, para realizar un ataque efectivo contra una sesión interactiva sería necesario matar la conexión SSH unas 11356 veces para obtener información útil, por lo que evidentemente cualquier administrador debería suponer que algo raro está pasando (si antes no muere de viejo intentando hacer un ps :P). El único riesgo que parece más factible son aquellas conexiones automatizadas que siempre envían la misma información, como por ejemplo un scp programado entre dos máquinas (algo bastante común), que podría ser interrumpido sistemáticamente hasta conseguir recuperar el fichero transmitido (a golpe de 4 bytes cada vez), aunque según el Advisory de OpenSSH, serían necesario muchos días para recuperar un fichero pequeño, a un ritmo de 44 bits recuperados por hora, por lo que explotar este ataque se hace complicado.
En resumen, la vulnerabilidad existe y es posible desencriptar el tráfico parcialmente, por lo que deberiamos actualizar a la última versión de OpenSSH (que básicamente establece AES como algoritmo de cifrado por defecto, que ya no sufre esta vulnerabilidad) y evitar el peligro, sin prisa pero sin pausa. Sin embargo, es una vulnerabilidad difícil de explotar, o mejor dicho, difícil de obtener información de ella, por lo que no es algo que yo personalmente vaya a incluir en mi "arsenal" de herramientas de pentesting, a menos que algún trabajo concreto lo requiera.
.png "English"){kind=small}
Entradas
6 comentarios :
Hola,
He estado leyendo el advisory de openssh y la verdad es que es todo menos preocupante ...
"The new component seems to be an attack that can recover 14 bits of
plaintext with a success probability of 2^-14, though we suspect this
underestimates the work required by a practical attack."
También es cierto que esto es algo que sucede con muchos exploits, que simplemente se quedan en "algo teórico", sin más.
Eso sí, hay que estar al día. Gracias por la info!!!
Saludos,
Eduardo.
Yo soy un paranóico con esto de la seguridad, así que no me hace ninguna gracia que alguien pueda descifrar ni tan siquiera un bit de un mensaje cifrado, pero siendo realistas...
En cualquier caso nunca está de más saber como funcionan los ataques que van por ahí, aunque sean teóricos, por ejemplo podemos hacernos una regla de Snort que detecte muchos cierres de conexión de una misma comunicación en un determinado espacio de tiempo y así detectar intentos de este ataque o de posibles ataques similares no documentados que obtengan mejores resultados.
Lo que está claro es que el saber no ocupa lugar :)
Me recuerda a un paper que leí recientemente. En este se explica una nueva técnica teórica sobre la colisión en SHA-1. Con este método se puede reducir la complejidad de la misma a 2^52, antes se había reducido a 2^63.
Si bien aunque aún no es explotable, la tendencia es preocupante. Cuando el río suena...
http://eurocrypt2009rump.cr.yp.to/837a0a8086fa6ca714249409ddfae43d.pdf
@Rafael: sí, algo así pasó con el algorítmo MD5. Primero, unos artículos que eran mera teoría, luego una colisión .... y a día de hoy es totalmente inseguro.
Pues no me apetece mucho reinstalar los openssh ... uff ...
@Eduardo: tienes otra opción, realmente lo que han hecho los de OpenSSH es cambiar los modos de cifrado por defecto, pero eso mismo lo puedes hacer tú cambiando el sshd_config con la siguiente linea:
Ciphers aes128-ctr,aes256-ctr,arcfour256,arcfour,aes128-cbc,aes256-cbc
Eso pone en el Advisory de OpenSSH, aunque yo no lo he probado, por eso te recomiendo que tires de manual del OpenSSH y lo pruebes primero en un entorno que no esté en producción.
Para los clientes lo mismo, la misma linea en el ssh_config evitará que tu cliente acepte conectarse mediante otros modos que no sean los de la lista, que están libres de la vulnerabilidad.
Suerte!
Sí, pero son 200 servidores. Y es viernes, tío, que los viernes no son para trabajar ... jeje ...
También salió hace poco una vulnerabilidad para openssl, hemos encontrado varios fallos en los puestos de trabajo de un cliente, otro tenía el webdav, hay varios ftp pululando ... etc ...
Vamos, que estas cosas llevan su tiempo, son unas cuantas y es también cuestión de prioridades. Aparte, tienes que "luchar" con los admins.
Saludos,
Publicar un comentario