El ataque a la antigua vulnerabilidad de OpenSSL / Debian no funciona en un cuadro vulnerable

Question

El ataque a la antigua vulnerabilidad de OpenSSL / Debian no funciona en un cuadro vulnerable

#1 de Thomas Pornin (3 votos)
#2 de mikeazo (1 votos)

0

DESCARGO DE RESPONSABILIDAD: El cuadro vulnerable que estamos probando nos pertenece, y todas las acciones están bajo vigilancia, por lo que no estamos haciendo nada ilegal aquí.

Estoy probando una caja de Ubuntu 8.04, se sabe que tiene una vulnerabilidad de claves débiles de OpenSSL . El script proporcionado por Debian confirmó que el servidor es vulnerable:

$ perl dowkd.pl host X.X.X.X
X.X.X.X: weak key (OpenSSH/dsa/1024)
X.X.X.X: weak key (OpenSSH/rsa/2048)
summary: keys found: 2, weak keys: 2

Luego uso otro script proporcionado por enlace llamado debian_ssh_scan_v4.py para encontrar la huella digital y la clave pública / privada correspondiente.

$ python debian_ssh_scan_v4.py X.X.X.X
X.X.X.X:22 sshd fingerprint 4795d53ae413531f78f4d45bbd6eb929 VULNERABLE (RSA 2048 bit key, pid 26571)

$ find rsa/2048/4795d53ae413531f78f4d45bbd6eb929*
rsa/2048/4795d53ae413531f78f4d45bbd6eb929-26571
rsa/2048/4795d53ae413531f78f4d45bbd6eb929-26571.pub

La clave privada (bajo rsa / 2048 ) se obtiene de la lista de claves posibles: enlace

Sin embargo, no pude iniciar sesión en el cuadro vuln utilizando la clave encontrada (tenga en cuenta que ubuntu es un usuario válido en ese cuadro):

$ ssh -i rsa/2048/4795d53ae413531f78f4d45bbd6eb929-26571 -o PasswordAuthentication=no [email protected]
Public key 47:95:d5:3a:e4:13:53:1f:78:f4:d4:5b:bd:6e:b9:29 blacklisted (see ssh-vulnkey(1)); continuing anyway
Permission denied (publickey,password).

También intenté aplicar bruteforce todas las claves posibles (que extraje del archivo comprimido) utilizando secuencia de comandos de WarCat y ninguna de las claves pudo autenticarse.

Con todos esos resultados, ¿podría decir que la caja es segura y dice que en realidad no es vulnerable a la debilidad de la clave OpenSSL?

authentication openssl

pregunta fang 20.01.2014 - 11:37

fuente

2 respuestas

1

Dentro de /home/ubuntu/.ssh debería haber un archivo authorized_keys que tenga la clave pública permitida para iniciar sesión en esa cuenta. Si esa clave es una de las claves débiles, puede obtener la clave privada que le corresponde e iniciar sesión como ese usuario.

Por ejemplo, vea esto pero no genere una clave. Ponga una clave pública débil en authorized_keys, luego puede usar la clave privada correspondiente para iniciar sesión.

respondido por el mikeazo 20.01.2014 - 20:48

fuente

Lea otras preguntas en las etiquetas authentication openssl

¿Qué tan seguros son los nuevos TLD (.us, .io, ...) y se comparan con .com? [cerrado] ¿Se puede usar sqlmap en telnet?

score 3 · Accepted Answer

La "clave débil" significa que puede tener una copia de la clave privada del servidor . Esto le permite ejecutar un servidor falso y posiblemente hacer un ataque Man-in-the-Middle en un cliente autorizado, cuando se conecta al servidor. Sin embargo, esto no le permite iniciar sesión "por sí mismo".

Al usar un par de claves pública / privada con un cliente, está enviando esa clave pública al servidor y el servidor autorizará la entrada, o no, dependiendo de si esa clave pública está en el $HOME/.ssh/authorized_keys de la cuenta de destino . Aquí, está enviando como "clave del cliente" una copia de la propia clave pública del servidor, que no está autorizada para la autenticación del cliente, de ahí el resultado.

No aceptar su propia clave como autenticación correcta para un cliente no es nada especial en SSH; Las claves de cliente y las claves de servidor viven en mundos separados. El servidor no es consciente de que está intentando alimentarlo con su propia clave; para el servidor, esto es solo "una clave pública que no está en el archivo de destino authorized_keys ".

La caja sigue siendo vulnerable; pero hay otros tipos de vulnerabilidad que permitir conexiones fuera de lugar. Los ataques MitM son más difíciles de poner en práctica (hay que interceptar la conexión de un cliente honesto, generalmente con alguna variante en el envenenamiento de DNS), pero aún así son muy graves.