Controllare i registri per l'utilizzo dell'uso di Heartbleed?

Naviga le tue risposte
10

Secondo articoli come il seguente , è apparentemente possibile controllare i registri per richieste heartbeat corrispondenti ai payload descritti nell'exploit Heartbleed.

È qualcosa che qualsiasi operatore di server può controllare nei propri registri (a livello di server, qualsiasi distribuzione Linux standard)? In tal caso, quali registri devono essere controllati e per quale motivo?

    
posta Jon L. 11.04.2014 - 13:26
fonte

1 risposta

11

Dai registri di accesso di un servizio (nginx, Dovecot, ecc.), non puoi vedere se sei stato colpito o meno. A meno che tu non abbia precedentemente acquisito tutto il traffico SSL, non puoi vedere se sei stato attaccato in passato.

Il pattern da abbinare in una cattura di pacchetti è molto semplice:

  1. Viene inviata una richiesta di heartbeat dannosa.
  2. Viene restituita una risposta heartbeat eccessivamente lunga (per versioni con bug).

Se la richiesta Heartbeat non è crittografata (cioè è stata inviata prima che l'handshake sia completata), i dati nel livello di trasporto (UDP, TCP o un livello specifico dell'applicazione aggiuntivo) sono: 

18       # Content Type Heartbeat 
vv vv    # TLS version (e.g. 03 01 is TLS 1.0, 03 03 is TLS 1.2)
ll ll    # Record length (length of the following data)
01       # Message type (1 = request, 2 = response)
xx xx    # Payload length
[payload]
[at least 16 bytes of padding]

Se il payload non è esattamente la lunghezza xx xx (big-endian), allora probabilmente sei stato attaccato. Avrebbe successo se si ottiene una risposta: 

18 vv vv    # Same record layer header
ll ll       # Length of following data
02
xx xx       # Same length as requested
[data of length xx xx]

Un comando di esempio (che richiede root) che cattura tutti i dati futuri dall'interfaccia di rete eth0 fino all'interruzione: 

tcpdump -i eth0 'tcp port 443' -w ssl.pcap

Puoi utilizzare Wireshark per esaminare il file ssl.pcap . Il filtro di visualizzazione ssl.heartbeat_message mostra tutte le richieste e i messaggi Heartbeat. Nota: a volte il filtro SSL non viene applicato. In tal caso, fai clic con il pulsante destro del mouse su un pacchetto, fai clic su Decodifica come .. e seleziona SSL . Poiché git commit 3f81af22e0116a2f83c0298de7874959b3967da2 (11 aprile 2014), puoi anche utilizzare il filtro esperto ssl.heartbeat_message.payload_length.invalid per indirizzare le richieste heartbeat malformate (se non crittografate).

Come per gli heartbeat crittografati ... non è normale vedere gli heartbeat, quindi quando ne hai uno per le connessioni TCP, diventa già sospetto. Alcuni suggerimenti per heartbeat crittografati che potrebbero aiutare:

  • Una richiesta di heartbeat seguita da gigantesche risposte heartbeat è un segno di un server vulnerabile che è stato sfruttato con successo.
  • Una richiesta di heartbeat non seguita da una risposta heartbeat può segnalare un tentativo di sfruttare il server, ma il server viene riparato e non risponde.
  • Una richiesta di heartbeat seguita da un avviso crittografato potrebbe segnalare un tentativo di sfruttare il server, ma il server non esegue OpenSSL e rifiuta la richiesta non valida.
  • Un gran numero di battiti cardiaci successivi (anche se piccoli) può avere successo con tentativi di sfruttamento con lunghezze di carico ridotte.
risposta data 11.04.2014 - 14:37
fonte

Leggi altre domande sui tag

Generazione e protezione dei codici delle carte regalo Come faccio a segnalare una vulnerabilità a una grande organizzazione che non crede che abbia un problema?