Quali clienti si sono dimostrati vulnerabili a Heartbleed?

In effetti, si , i clienti sono vulnerabili. Finora l'attenzione si è concentrata sui server poiché sono molto più aperti allo sfruttamento. (Quasi) tutti possono connettersi a un server HTTP / SMTP / ... pubblico.

Questo blog descrive come funziona il bug (menziona dtls_process_heartbeat() , ma tls_process_heartbeat() è influenzato allo stesso modo). Questa funzione è utilizzata sia per client che per applicazioni server, quindi anche i client dovrebbero essere vulnerabili.

Secondo RFC 6520, i battiti del cuore non dovrebbero essere inviati durante le strette di mano. In pratica, OpenSSL accetta i battiti cardiaci subito dopo l'invio di un ServerHello (questo è ciò che fa ssltest.py di Jared Stafford). Dopo ulteriori test, ho scoperto che i server possono abusare dei client inviando un Heartbeat a destra dopo inviando anche ServerHello. Attiva lo stesso bug.

Un proof of concept può essere trovato nel mio repository all'indirizzo link . Dal suo README:

The following clients have been tested against 1.0.1f and leaked memory before the handshake:

• MariaDB 5.5.36
• wget 1.15 (leaks memory of earlier connections and own state)
• curl 7.36.0 (https, FTP/IMAP/POP3/SMTP with --ftp-ssl)
• git 1.9.1 (tested clone / push, leaks not much)
• nginx 1.4.7 (in proxy mode, leaks memory of previous requests)
• links 2.8 (leaks contents of previous visits!)
• KDE 4.12.4 (kioclient, Dolphin, tested https and ftps with kde4-ftps-kio)
• Exim 4.82 (outgoing SMTP)

È stato dimostrato che 64 KiB di memoria (65535 byte) possono effettivamente essere restituiti. È stato anche dimostrato che i client ( wget , KDE Dolphin, ...) possono perdere dati come richieste precedenti contenenti eventualmente password.

Ho scritto un modulo Metasploit per testare questo , attualmente in fase di revisione, ma dovrebbe colpire il ramo principale relativamente presto . La prima versione viene unita al ramo principale a questo punto.

link

Diversamente dall'attacco lato server, è necessario implementare la maggior parte di TLS poiché la risposta heartbeat è crittografata rispetto alla chiave di sessione SSL. Ho provato con wget, curl e la riga di comando openssl. Un aspetto interessante è che contro wget e openssl (1), l'attacco ha esito positivo indipendentemente dalla convalida del certificato. Il binario curl richiede -k o un certificato valido per mantenere la sessione aperta abbastanza a lungo per il corretto funzionamento dell'attacco. Contro questi test relativamente sintetici, ho potuto rilevare in modo affidabile la chiave di sessione TLS (AES-128-CBC), ma questo non fornisce molto dal momento che il server conosce la stessa chiave durante l'handshake.

EDIT1 : sembra che il codice di pacemaker esegua questo senza eseguire l'handshake TLS completo (ancora meglio!). Sarei interessato a tutti i risultati dei test che le persone potrebbero avere tra le implementazioni. IOW, il pacemaker riesce nei casi in cui il client si disconnetterebbe altrimenti a causa di un certificato autofirmato?

EDIT2 : il metodo @Lekensteyn utilizza in pacemaker (invia un heartbeat dopo il Server Hello) è un approccio migliore perché la convalida della CA non è un problema. Ho inviato un nuovo PR di Metasploit che è impostato su questa modalità e preserva il percorso del codice di negoziazione TLS utilizzando l'opzione NEGOTIATE_TLS (imposta NEGOTIATE_TLS true per la modalità precedente). Puntelli su @Lekensteyn!

È è possibile sfruttare l'errore nei client. Questo tester può essere utilizzato per fornire un URL "malvagio" a client arbitrari e vedere se abboccano o meno. Ho trovato 3 primi 100 siti web (non li chiamerò qui) che recuperano URL utilizzando client vulnerabili dal 2014-04-09.

Se disponi di un dispositivo Android, puoi installare una delle app Heartbleed che verificano la vulnerabilità, come questa:

link

Ho provato questo su due telefoni Android, uno con 4.3 e uno con 4.4, ed entrambi sono vulnerabili, ma per entrambi OpenSSL non è usato, quindi tutto va bene ....

Quindi tutto è OK. Ottimo quindi, nessuna app utilizza OpenSSL. Ma cosa succede se installo un'applicazione che la usa? Verrò avvisato? Immagino di no!

Il telefono 4.4 è nuovo di zecca di Sony, e dopo averlo prima scaricato scarica un aggiornamento di sistema, ma suppongo che non sia abbastanza importante per essere corretto?!