Facilitare la visibilità di Netflow sul traffico SSL

4

In un handshake SSL, il nome host è visibile la maggior parte del tempo in quanto è necessario per convalidare il certificato su HTTP. Netflow è quindi in grado di raccogliere il nome comune dallo scambio di certificati, che rivela il nome host .

Un server C & C sarebbe meglio usare un certificato autofirmato usando IP come nome comune (poiché i provider legittimi non consentono tale ) con un IP statico e nessun nome di dominio, in modo che quando visualizza query Netflow, vede solo indirizzo IP ? Poiché gli IP C & C cambiano frequentemente, sarebbe difficile per qualsiasi indagini per estrarre qualsiasi metadati da questo. Inoltre, certificati SSL e nomi di dominio lasciano tracce su whois e potrebbero essere briciole di pane per le indagini. Il certificato è tra i server senza interazione con l'utente e la sicurezza non è la chiave, quindi l'autofirmazione è accettabile.

    
posta George 22.01.2018 - 15:30
fonte

1 risposta

3

Mentre un client C & C nasconderebbe il suo vero bersaglio non usando SNI sarebbe sospettoso soprattutto perché non usa SNI con HTTPS mentre tutti gli altri lo fanno. Potrebbe essere meglio quindi affermare che si collega ad un target innocente impostando l'estensione SNI di conseguenza ma in realtà collegandosi al server C & C. Ciò richiede solo un po 'di giocherellare nello stack TLS e non è molto più difficile da fare per un utente malintenzionato esperto.

Tuttavia, poiché il certificato del server viene inviato dal server in chiaro con un handshake TLS completo, è ancora possibile verificare se il certificato restituito dal server corrisponde al nome fornito in SNI ed è anche emesso da una CA attendibile. Per evitare ciò, il client C & C potrebbe provare a simulare una connessione ripresa ogni volta. Per fare questo è più necessario manipolare lo stack TLS, quindi potrebbe essere più semplice utilizzare un protocollo che assomigli a TLS per ingannare il rilevamento, ma non è un vero TLS. Penso che questo sia ciò che Skype ha fatto almeno in passato per bypassare i firewall e forse lo fa ancora oggi.

Un altro approccio sarebbe utilizzare dominio fronting , ovvero (mis) usare un sistema che serve più domini sul stesso indirizzo IP, serve il certificato basato sull'estensione SNI nell'handshake TLS ma serve il contenuto effettivo basato sull'intestazione Host che è crittografata in TLS e quindi non accessibile durante l'ispezione passiva. In questo caso sembra che il client si connetta ad un sito innocente mentre in realtà si connette al suo master C & C.

Se l'attaccante controlla parti rilevanti del server (ad esempio perché è stato dirottato) potrebbe anche (continuare a) servire un sito per lo più innocente e quindi utilizzare solo un percorso specifico per la comunicazione C & C. Poiché il percorso dell'URL non è visibile durante l'ispezione passiva di HTTPS, probabilmente sembra che il client stia semplicemente accedendo a dati innocenti su questo sito.

Ancora, SNI non è l'unica cosa che può essere rilevata con l'analisi passiva. La stretta di mano del client mostra anche il tipo di cifre che supporta e le preferenze e una varietà di estensioni TLS e il loro ordine. Inoltre, anche se il traffico è crittografato, sono visibili anche gli schemi significativi del traffico come le dimensioni di richiesta e risposta o i tempi. Questo può anche essere usato spesso per impronte digitali del client e quindi per distinguere il tipico browser da altri client e forse i client C & C conosciuti. Cisco ha fatto ricerca interessante in quest'area.

    
risposta data 22.01.2018 - 16:43
fonte

Leggi altre domande sui tag