Does Heartbleed significa nuovi certificati per ogni server SSL?

60

Se non hai sentito parlare del bug Heartbleed , è qualcosa da dare un'occhiata immediatamente. Significa essenzialmente che un utente malintenzionato può sfruttare una vulnerabilità in molte versioni di OpenSSL per poter accedere alla chiave privata di un server. Non è una minaccia teorica, è una minaccia dimostrabile e riproducibile. Vedi il link sopra per maggiori informazioni.

La domanda che ritengo la maggior parte delle organizzazioni si stia chiedendo è la seguente:

Ogni azienda ora ha bisogno di creare nuovi keypair pubblici / privati e chiedere alla CA di invalidare i keypair con firma originale?

    
posta Naftuli Kay 08.04.2014 - 05:10
fonte

4 risposte

61

Significa molto più dei nuovi certificati (o meglio, nuove coppie di chiavi) per ogni server interessato. Significa anche:

  • Patching dei sistemi interessati su OpenSSL 1.0.1g
  • Revoca dei vecchi keypair che sono stati appena sostituiti
  • Modifica di tutte le password
  • Invalidazione di tutte le chiavi e i cookie di sessione
  • Valutare il contenuto reale gestito dai server vulnerabili che potrebbero essere stati trapelati e reagire di conseguenza.
  • Valutare qualsiasi altra informazione che potrebbe essere stata rivelata, come gli indirizzi di memoria e le misure di sicurezza

Riepilogati da heartbleed.com (enfasi mia):

What is leaked primary key material and how to recover?

These are the crown jewels, the encryption keys themselves. Leaked secret keys allows the attacker to decrypt any past and future traffic to the protected services and to impersonate the service at will. Any protection given by the encryption and the signatures in the X.509 certificates can be bypassed. Recovery from this leak requires patching the vulnerability, revocation of the compromised keys and reissuing and redistributing new keys. Even doing all this will still leave any traffic intercepted by the attacker in the past still vulnerable to decryption. All this has to be done by the owners of the services.

What is leaked secondary key material and how to recover?

These are for example the user credentials (user names and passwords) used in the vulnerable services. Recovery from this leaks requires owners of the service first to restore trust to the service according to steps described above. After this users can start changing their passwords and possible encryption keys according to the instructions from the owners of the services that have been compromised. All session keys and session cookies should be invalided and considered compromised.

What is leaked protected content and how to recover?

This is the actual content handled by the vulnerable services. It may be personal or financial details, private communication such as emails or instant messages, documents or anything seen worth protecting by encryption. Only owners of the services will be able to estimate the likelihood what has been leaked and they should notify their users accordingly. Most important thing is to restore trust to the primary and secondary key material as described above. Only this enables safe use of the compromised services in the future.

What is leaked collateral and how to recover?

Leaked collateral are other details that have been exposed to the attacker in the leaked memory content. These may contain technical details such as memory addresses and security measures such as canaries used to protect against overflow attacks. These have only contemporary value and will lose their value to the attacker when OpenSSL has been upgraded to a fixed version.

    
risposta data 08.04.2014 - 08:33
fonte
6

Questo è lo scenario peggiore, come descritto da Codenomicon che ha creato il sito web quotato.

La descrizione della vulnerabilità "grezza" è:

A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server. (OpenSSL)

Non sto dicendo che siano andati troppo oltre, è molto pessimo, ma:

  • Controlla la tua versione di OpenSSL (non tutte le versioni sono interessate).
  • Ancora meglio, provalo:

    openssl s_client -connect example.com:443 -tlsextdebug 2>&1| grep 'server extension "heartbeat" (id=15)' || echo safe

  • Oppure usa link

Quindi se si utilizza Perfect Forward Secrecy (PFS), i dati scambiati non possono essere decifrati, a meno che non sia stato eseguito un MITM.

Per eseguire un attacco MITM, l'hacker doveva conoscere la vulnerabilità e sfruttarla con successo. Un utente malintenzionato può tentare di accedere a pezzi casuali di memoria 64ko senza essere notato, così facendo dovrebbe essere in grado di ottenere una parte della memoria in cui è memorizzata la chiave privata.

Per rispondere alla domanda, se sei vulnerabile al bug Heartbleed. Sì, è necessario modificare le chiavi private e i certificati. E se vuoi essere sicuro, controlla circa 2 anni di file di log per assicurarti che nessuno abbia utilizzato Heartbleed sul tuo sito o esegua le operazioni già menzionate in modo semplice e sicuro.

    
risposta data 09.04.2014 - 10:11
fonte
2

Il problema dell'utilizzo del nuovo certificato / chiave SSL per tutti i server è spesso esagerato. Devi dare per scontato

  • Esiste un hacker che conosce Heartbleed prima di correggere l'openssl
  • È interessato a hackerare i tuoi server, non altri popolari siti web
  • Lui / lei ha la possibilità di estrarre la chiave privata dalla memoria del server 64K, lui / lei dovrebbe essere un hacker molto sofisticato
  • È in grado di intercettare la rete locale (utente / server) e di decrittografare il traffico

Considerate tutte le condizioni, quindi giudicate dovete aggiornare il certificato / chiave SSL.

Non sto dicendo che non dovrebbe , sto solo dicendo che a volte le persone nell'interweb ascoltano ciecamente gli altri e dicono che se non lo fai, il tuo sito sarà hackerato al 100%, è solo FUD, IMHO

    
risposta data 10.04.2014 - 05:49
fonte
0

Se la persona sta raccogliendo questi 64 KB di dati fino a quando non catturano la chiave privata, possono decrittografare tutto ciò che hanno raccolto (e raccogliere di più). È così che un utente malintenzionato può catturare nomi utente e password senza essere un MITM. Se la persona è in grado di ottenere la chiave privata, il resto è abbastanza facile.

    
risposta data 10.04.2014 - 23:00
fonte

Leggi altre domande sui tag