Sicurezza di rete lato server (windows): decriptare il traffico per analizzarlo con snort

Come tutti sanno, oggi giorno il 90% del traffico web è criptato questo rende l'utilizzo di NIDScome snortpiuttosto problematico. Anche nel caso di intrusioni il semplice log dei pacchetti, senza conoscerne il contenuto, può risultare assolutamente inutile.  Ci sono diversi modi per avere il traffico in chiaro al fine di poterlo analizzare con un software di intrusion detection: 

• il primo è semplicemente far terminare il flusso criptografico dei dati che dovrebbero arrivare al webserver prima ponendo davanti a quest'ultimo un reverse proxy. In pratica il client si collega al reverse proxy in modo criptato ma quest'ultimo si collega al webserver in chiaro. Fra il proxy e il webserver è possibile inserire un sensore per il rilevamento delle intrusioni.
• il secondo consiste nell'effettuare tutte le operazioni di monitoraggio direttamente dall'interno del webserver e quindi aumentandone il livello di logging applicativo.
• Il terzo modo consiste nell'attrezzare il nostro sensore della possibilità di decriptare il traffico.

Ognuno dei tre approccio ha vantaggi e svantaggi, ma in questo articolo ci occuperemo solo del terzo modo. 

Decriptare SSL

Prima di procedere è necessario approfondire dal punto di vista teorico come funziona la decriptazione dei dati, per fare questo potete leggere questo articolo in inglese. Per dirla in due parole ci sono due condizioni che devono essere rispettate prima di procedere:

1. Il server deve usare il meccanismo per scambio delle chiavi RSA (leggi questo articolo e l' RFC2246) e per fortuna questo è il sistema più comune usato dai webserver che usano SSL.  Mentre se stai usando DSA keypairs oppure il meccanismo di scambio chiavi Diffie-Hellman allora ti è andata male.
2. Devi poter accedere alla chiave privata RSA per copiarla sul server di sguil/snort.

L'ultimo punto significa solo la decriptazione che andremo a fare riguarda solo il traffico da e verso il server che sotto il nostro controllo. Ovviamente que sto è quello che vogliamo da un punto di vista di analisi forense della rete e della rilevazione delle intrusioni.

Adesso dove sono le chiavi ?

Ottenere le chiavi private dal nostro server per copiarle sul server dello sguil/snort può comportare un po' di lavoro. La chiave potrebbe essere conservata in un file .pem  da qualche parte nel webserver e copiarla sul server dello sguil/snort dovrebbe essere piuttosto semplice.  Tuttavia, alcuni sistemi operativi come per esempio Windows conservano la chiavi in un "certificate store" piuttosto che in .pem file.   Quindi per ottenere la chiave private abbiamo bisogno prima di tutto di esportare il certificate e la chiave insieme in un file PKCS12 (leggi quiper sapere come fare). Poi, una volta esportato il certificato, bisogna esportare la chiave usando il comando openssl nel seguente modo:

C:>openssl pkcs12 -in c:\MIOCERTIFICATO.pfx –out c:\MIO_CERTIFICATO.pem -nodes

Quando ottieni il prompt inserisci la password che hai fornito durante la proc edura di esportazione del certificato. Il file MIO_CERTIFICATO .pem ottenuto co nterrà un blocco di testo come il seguente:

—–BEGIN PRIVATE KEY—–
MISLKJWLKERJNBgkAELRJWELKASDFAASCBKcwggSjAgEAAoIBAQCvHJFIpFwXZJ0x 2DzEY2B4MDBBKSLJFWELIKFSoEGTAARh3OAP+UMedNf2t8/MVJdEEAM7TQ
<snip>
EZq3T23K3K3KSDKGSjVRorB0YGvDSLDFJSLKEJFRLWEJKSFcLCC4lGQeTg+usZmtcx4VI wGI70e4Byd+Lba01K3KS398SK=
—–END PRIVATE KEY—–

A questo punto copia il blocco di testo ottenuto e incollalo all'interno del file myExportedCertificate.pem poi salva il file sul server sensore di sguil/snort. C'è da aggiungere che windows non puo' esportare le chiavi private neppu re col software di gestione dei certificati. Ma sembra che jailbreak  possa farlo.

Avviso

Come spiegato in questo articolo in Inglese, la chiave privata del tuo server è davvero un'informazione molto sensibile. C on essa, un utente malintenzionato potrebbe decrittografare il traffico SSL del server o utilizzarla insieme al certificato del server per mascherarsi come un sito legittimo. È necessario prestare estrema attenzione alla gestione della chiave privata:

• non lasciarne copie in giro in directory temporanee,
• assicurati che non finisca accidentalmente su Internet
• assicurati che il server sgui/snort sul quale andrai a copiare la chiave sia molto ben configurato e hardenizzato. Pensa a questa chiave privata come alla combinazione per proteggere i tuoi oggetti di valore: assicurati di condividerla solo con fonti attendibili.

La perdita di una chiave privata puo' essere di gran lunga peggio rispetto al controllare il tuo traffico alla ricerca di un'intrusione potenzialmente non ancora avvenuta. Quindi fai attenzione!

Usare la chiave privata

Una volta che abbiamo la nostra chiave privata, potremmo puntare Wireshark alle directory di acquisizione del contenuto di sguil/snort. Ma questo approcci o non si presta a un monitoraggio efficiente, mentre sarebbe molto meglio se potessimo convogliare le nostre decrittazioni direttamente in sguil/Snort quasi in tempo reale, sfruttando i vantaggi di SANCP, PADS e qualsiasi altra cosa stia girando. Il software viewssld di Dmitry Plashchynski è lo strumento di cui abbiamo bisogno per decriptare i dati. Di recente sono state apportate alcune aggiunte al codice per facilitare l'integrazione con sguil/Snort e per produrre decrittazioni più ricche. Concettualmente, viewssld ha questo aspetto:

Software viewssld

viewssld ascolta su una data interfaccia tramite il solito libpcap. I frame catturati vengono quindi passati alla libreria libdssl di Atomic Labs che gestisce la decrittazione vera e propia (l'ultima versione di libdssl al momento della scrittura è 2.1.1, disponibile tramite svn qui).
L'output di libdssl è il contenuto del solo pacchetto decifrato ( quindi nessuna intestazione o cose del genere), quindi libnet viene utilizzato per creare un flusso di traffico "falso" contenente i pacchetti SSL decrittografati. Questo flusso falso viene pompato attraverso l'interfaccia di output, dove Sguil/Snort è in ascolto.
Le versioni precedenti di viewssld restituivano il solo traffico client->server (ad es. Richieste HTTP). Ma le versioni successive includono:

1. Emissione di un falso handshake TCP a 3 vie per il traffico decrittografato
2. Emissione delle risposte del server decifrate così come le richieste del client, mantenendo i numeri di sequenza TCP (falsi) correttamente aggiornati. I numeri di sequenza e altri "mobili" di intestazione TCP/IP sono ovviamente una finzione completa: poiché il traffico decrittografato ha dimensioni diverse rispetto al traffico crittografato, non è possibile utilizzare i valori "reali". Il flusso decifrato può anche essere frammentato/segmentato in modo diverso da quello crittografato, ma anche in questo caso c'è poco che puoi fare al riguardo
3. Emissione di un falso RST alla fine di ogni sessione
4. Utilizzo di un numero di identificazione (ID) IP facilmente ricercabile per tutti i frame falsi in modo da poter dire quali sono stati emessi da viewssld (54609 == 0xd551 == DSSL)
5. Emettere i frame decifrati su una porta diversa su cui sono stati catturati (es. 443->80, 465->25, 993->143, ecc.)

I primi tre punti aiutano a mantenere funzionante l'istanza SANCP di Sguil/Snort, poiché l'output di viewssld è ora un flusso TCP ragionevolmente ben formato con un inizio e una fine definiti. Il punto quattro ci ricorda che sebbene il traffico decifrato sia disponibile per Sguil/Snort, è una fabbricazione completa: non è mai esistito un tale traffico in questa forma sulla rete. Contrassegnando i datagrammi IP decifrati con un ident di 0xd551 è possibile ordinare i fatti registrati dai decrittografati.
Il punto cinque aiuta a integrare viewssld e Sguil come mostrato nel diagramma seguente:

il flusso viaggia nel modo seguente:

1. Il traffico non elaborato (frecce blu) entra nell'interfaccia di monitoraggio di Sguil.
2. Questo traffico viene catturato sia da Sguil che da viewssld.
3. viewssld decifra ciò che può e lo invia all'interfaccia da cui lo ha catturato (frecce rosse). Ciò è reso possibile solo utilizzando una porta TCP diversa per i frame decrittografati: se utilizzasse la stessa porta, rientrerebbe in viewssld.
4. Il flusso falso di SSL decifrato viene raccolto da Sguil.

Sguil/SANCP/Snort/PADS/ecc. quindi vedono sia il traffico crittografato che quello decifrato, come mostrato nello screenshot qui sotto. Sullo sfondo puoi vedere una query SANCP con due righe di risultati. La prima riga è il traffico SSL grezzo catturato da Sguil sulla porta 443; la seconda riga mostra Sguil che cattura l'output del flusso decifrato falso corrispondente da viewssld sulla porta 80. Le due finestre di trascrizione raccontano il resto della storia:

Ho testato viewssld con HTTPS, SMTPS, POP3Se IMAPS: tutti funzionano come previsto. Un file viewssld.confdi esempio per questi quattro protocolli potrebbe essere simile a questo:

# PID-file percorso(default: /var/run/viewssl.pid)
pid = /var/run/viewssl.pid
# rendi demone ? on/off (default: off)
daemon = on
# loglevel 0-10 (default: 0)
loglevel = 10
# SSL protocols to decrypt
[webserver]
src = eth1
dst = eth1
ip = 10.11.12.13
port = 443
key = /etc/viewssld/webserver.key
dsslport = 80
[mailserverSMTP]
src = eth1
dst = eth1
ip = 20.30.40.50
port = 465
key = /etc/viewssld/mailserver.key
dsslport = 25
[mailserverIMAP]
src = eth1
dst = eth1
ip = 20.30.40.50
port = 993
key = /etc/viewssld/mailserver.key
dsslport = 143
[mailserverPOP3]
src = eth1
dst = eth1
ip = 20.30.40.50
port = 995
key = /etc/viewssld/mailserver.key
dsslport = 110

Notare come le interfacce src e dst siano le stesse in tutti i casi e che sia specificata la porta non-SSL (dsslport=) così come la porta SSL (port=).

Secondo avviso

Ci sono un paio di cose da considerare quando si utilizza viewssld su un sensore Sguil:

1. La decrittazione di SSL ha un costo computazionale importante. Se la CPU del tuo Sguil/Snort è normalmente molto occupata, il carico computazionale associato alla decrittazione potrebbe spingerla oltre ogni limite.
2. Il processo di decrittazione è molto sensibile alla perdita di pacchetti. Se viewssld perde un pacchetto, la decrittazione del flusso si fermerà a quel punto; se manca l'handshake SSL all'inizio di una sessione crittografata, non decrittograferà assolutamente nulla.
3. Ora stai archiviando sia il traffico crittografato che decrittografato, quindi potrebbe esserci un impatto sull'utilizzo dello spazio disco.