L'attacco alla vecchia vulnerabilità OpenSSL / Debian non funziona su una casella vulnerabile

Question

L'attacco alla vecchia vulnerabilità OpenSSL / Debian non funziona su una casella vulnerabile

#1 da (3 voti)
#2 da (1 voti)

0

DISCLAIMER: la casella vulnerabile su cui ci stiamo sottoponendo appartiene a noi e tutte le azioni sono sotto controllo, quindi non stiamo facendo nulla di illegale qui.

Sto testando una scatola di Ubuntu 8.04, è nota per avere una vulnerabilità delle chiavi OpenSSL deboli . Lo script fornito da Debian ha confermato che il server è vulnerabile:

$ 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

Quindi utilizzo un altro script fornito dal link chiamato debian_ssh_scan_v4.py per trovare l'impronta digitale e la corrispondente chiave pubblica / privata.

$ 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 chiave privata (in rsa / 2048 ) viene visualizzata nell'elenco delle possibili chiavi: link

Tuttavia non sono riuscito ad accedere al vuln box usando quella chiave trovata (nota che ubuntu è un utente valido su quella casella):

$ 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).

Ho anche provato a rinforzare tutte le possibili chiavi (che ho estratto dal file compresso) usando lo script WarCat e nessuna chiave è stata in grado di autenticare.

Con tutti questi risultati, posso dire che la scatola è sicura, che ha detto che in realtà non è vulnerabile al debole bug della chiave OpenSSL?

authentication openssl

posta fang 20.01.2014 - 11:37

fonte

2 risposte

1

All'interno di /home/ubuntu/.ssh dovrebbe esserci un file authorized_keys con la chiave pubblica autorizzata a ssh accedere a tale account. Se quella chiave sembra essere una delle chiavi deboli, allora puoi ottenere la chiave privata che corrisponde ad essa e accedere come tale utente.

Ad esempio, vedi questo ma non generare una chiave. Inserisci una chiave pubblica debole in authorized_keys, quindi puoi utilizzare la chiave privata corrispondente per accedere.

risposta data 20.01.2014 - 20:48

fonte

Leggi altre domande sui tag authentication openssl

Un Pattern Lock è più sicuro di una tipica password testuale? [duplicare] Quanti caratteri dovrebbe avere una chiave di sessione?

score 3 · Accepted Answer

Il "tasto debole" significa che puoi avere una copia della chiave privata del server . Ciò consente di eseguire un server falso e possibilmente eseguire un attacco Man-in-the-Middle su un client autorizzato, quando si collega al server. Tuttavia, questo non ti consente di accedere "da solo".

Quando si utilizza una coppia di chiavi pubblica / privata con un client, si invia quella chiave pubblica al server e il server autorizza l'immissione, o meno, a seconda che la chiave pubblica sia nella $HOME/.ssh/authorized_keys dell'account di destinazione . Qui, stai inviando come "chiave del cliente" una copia della chiave pubblica del server, che non è autorizzata per l'autenticazione del client, quindi il risultato.

Non accettare la propria chiave poiché l'autenticazione corretta per un client non è nulla di speciale in SSH; le chiavi del client e le chiavi del server vivono in mondi separati. Il server non è consapevole del fatto che si sta tentando di alimentarlo con la propria chiave; per il server, questa è solo "una chiave pubblica che non è nel file authorized_keys di destinazione".

La scatola è ancora vulnerabile; ma ci sono altri tipi di vulnerabilità che consentire connessioni inaspettate. Gli attacchi MitM sono più difficili da mettere in atto (devi intercettare la connessione di un client onesto, di solito con qualche variante all'avvelenamento DNS) ma sono comunque molto seri.