Sniffjoke in transizione

SniffJoke 0.3 ha raggiunto in buona sostanza i suoi obiettivi:

civile) Il messaggio che cerco di veicolare è sempre lo stesso: in Internet, la sicurezza mediante il controllo non può essere ottenuta. I cittadini sono abituati a pensarlo sulla scia di ciò che veniva fatto con le reti telefoniche. I presupposti costituzionali erano rispettati. Ora la tecnologia è cambiata e questi presupposti non possono essere più rispettati. Ad esempio: solo lo stato ha il potere di violare la mia riservatezza, se lo ritiene, perché lo stato agisce nei miei interessi di cittadino. Ma Internet è dei privati, e i privati agiscono negli interessi del business (per questo, proteggersi, dovrebbe essere un dovere morale sia per se stessi che per i destinatari della nostra comunicazione). Inoltre, nelle vecchie reti, tutti i cittadini erano alla pari, ora no, chi si vuole proteggere, ha interesse a farlo, puo’ usare meccanismi matematicamente sicuri. Chi non se ne cura, non lo fa. Questo crea cittadini di serie A e di serie B, e non è un presupposto accettabile per uno strumento che viene tanto spinto per dare una maggior (percezione di) sicurezza.

personale) Superare, ed usare come obiettivo da battere, WireShark, lo sniffer più completo sviluppato dalla comunità open source. Era l’obiettivo cardine, e pure l’unico modo per dimostrare che i principi sui quali SniffJoke si basa non sono dovuti all’incompletezza di un software, ad un bug o alla sua segretezza… si basa sul fatto che: le comunicazioni online non è previsto, dalla loro stessa natura, che siano lette da un entità che intercetta il traffico, esterna a mittente/destinatario. Ok, si tratta di tecnologia, e in qualche modo qualcuno si arrabatterà per farlo e potrebbe pure raggiungere risultati, per lui, soddisfacenti.

tecnologico) sulla mailing list di wireshark (leggere tutto il thread), la discussione è iniziata analizzando SniffJoke come un programma che fa scattare un errore, un bug. Dopo un paio di scambi, si è compreso che non è un bug, ma una caratteristica intrinseca della comunicazione su IP. Il fatto che abbiano accettato la cosa così com’è, evitando di entrare in una “code war” sostiene il punto precedente.

tecnologico, bis) E’ stato implementato, sotto altra forma, per MacOSX, da Maxim Bourmistrov, e lo trovate su questa pagina: http://en.roolz.org/trafscrambler.html; Come pacchetto debian da packz: http://www.autistici.org/packz/Repo/sniffjoke_0.3-0packz1_i386.deb.

sociale) SniffJoke è un progetto che da mero hacking e sviluppo deve diventare il più possibile usabile. Lo sforzo che va fatto di miglioramento non sta più nella tecnologia di evasion (ok, può essere migliorata e lo sarà, ma…) quando nella forma di diffusione, facilità d’uso, basso impatto sugli utenti. Si parla di un software che fornisce un livello di sicurezza, analogamente alla crittografia, che non può essere percepito. Cioè, chi cifra i suoi dati, non può sapere se effettivamente qualcuno glieli sta intercettando. Ma almeno la crittografia è matematicamente certa. SniffJoke si basa su metodi empirici efficaci solo nel contesto di “sniffer passivo”. Comunque, una, per ora piccola community si sta creando attorno a SJ, io la seguirò solo per vedere come evolve il progetto. Già ora Sj è su github.com, una piattaforma di social coding che sarà d’appoggio per chi si è interessato.

sociale, bis) ringrazio molto Gianluca Costa, packz, i due “sid”, void, elvis. Chi mi ha supportato nel testing di Sj e nelle sue prove in diversi ambienti. Anche che mi ha detto: “L’ho avviato sul mio gateway, che è pieno di regole di filtro e di vpn, e mi son tagliato fuori”. ops :P vedrò se si puo’ far qualcosa per gli ambienti più estremi… sicuramente, il filtro completo degli ICMP non impatta, più di tanto, sull’analisi del TTL (se volete sapere perché, la spiegazione è sotto).

Quotes

“Mi chiamo signor Burns” – Homer Simpson

Pertanto, SniffJoke si apre sotto forma di community. Mi affido a github [http://github.com/vecna/sniffjoke/tree/master], una piattaforma collaborativa che consente facilmente il fork dei progetti. Ciò che spero avvenga è che gradualmente vengano migliorate le sue lacune. Io al massimo aggiornerò i lettori di questo blog sullo stato dei fork di cui verrò a conoscenza.

Gli obiettivi di cui ho raccolto feedback, sono:

Un sistema più elegante perché i file .css ed immagini vengano copiati in una directory, e lì usati come riferimento dal server web interno a SniffJoke (fornito dalle librerie swill). In generale, andrebbe sistemato il Makefile perché non sia separato da quello delle libswill,  e prenda come opzioni i path di destinazione di installazione. Il codice di WebIO.cc va modificato di conseguenza per indicargli quali file servire via HTTP. (è sufficente gestire dei path assoluti/relativi).

Un sistema di cache della distanza in HOP. Per chi volesse cimentarsi nel codice: http://www.delirandom.net/sniffjoke/sniffjoke-0.3/sniffjoke-src/TCPTrack.cc la sequenza attuale per ottenere il TTL è:  TCPTrack::analyze_packets_queue, legge i pacchetti in coda. possono essere ICMP di tipo TIME_EXCEEDED, TCP in uscita, TCP in ingresso. sono importanti questi 3 tipi perché: gli ICMP TIME_EXCEEDED sono significativi del test di TTL, quindi i pacchetti che spirano in transito indicano che il numero di HOP testato è ancora inferiore al necessario per raggiungere l’host destinazione. Ogni pacchetto di probe, viene generato se la sessione che sta per essere stabilita è verso un host di cui non conosciamo ancora la distanza in HOP. Allora, la funzione TCPTrack::manage_outgoing_packets verifica se è un SYN, se la sessione esiste. Se non è così, la sessione non parte e si inizia, con TCPTrack::enque_ttl_probe, a generare pacchetti SYN verso il servizio destinazione con TTL incrementale. Siccome il sequence number viene restituito nell’eventuale SYN+ACK che si va a stimolare, o nel pacchetto di ICMP TIME_EXCEEDED altrimenti generato, il sequence number è creato da un numero randomico più il TTL che sta testando. I pacchetti TCP in ingresso possono servire per due casi, se sono SYN+ACK (perché potrebbe essere la risposta al bruteforce) o se sono RST|FIN (perché sono una chiusura di connessione), altrimenti vengono passatti al kernel che se li smazzi lui; le funzioni in questione sono TCPTrack::analyze_incoming_synack e TCPTrack::analyze_incoming_rstfin. Il fatto che il sequence number contiene il TTL che sta testando, permette, sia ricevendo il SYN+ACK di risposta che ricevendo l’ICMP TIME_EXCEEDED, di verificare quale valore di TTL ha causato cosa. La funziona di creazione è  TCPTrack::enque_ttl_probe in queste due linee:

injpb->tcp->seq = htonl(ct->tf->rand_key + tested_ttl);
injpb->ip->id = (ct->tf->rand_key % 64) + tested_ttl;

Mentre la funzione di lettura è, per quanto riguarda il TCP, TCPTrack::analyze_incoming_synack ( tf-> è la struttura ttl_focus, ogni entry è relativa un host che sniffjoke segna quanto dista in TTL, puppet_port è la porta sorgente fittizzia differente da quella generata dal nostro kernel, per evitare alcuni problemi. puppet_port viene usata solo in fase di bruteforce).

if ( synack->tcp->dest == tf->puppet_port )
{
unsigned char discern_ttl;

tf->received_probe++;
discern_ttl =  ntohl(synack->tcp->ack_seq) - tf->rand_key -1;
tf->status = TTL_KNOW;

Dal valore in ack_seq ricevuto si sottrae il nostro numero random (rand_key) e 1 (valore aggiunto al sequence number quando si stimola un SYN+ACK), cosi si ottiene il valore di TTL che abbiamo sommato in fase di invio. E’ un concetto simile al token crittografico usato nel syncookies.
Per quanto riguarda gli ICMP, viene fatta un’ulteriore verifica (anche se in linea teorica sarebbe sufficente il SYN+ACK):

tf = find_ttl_focus(badiph->daddr, NULL);

if(tf != NULL && badiph->protocol == IPPROTO_TCP)
{
unsigned char expired_ttl = badiph->id - (tf->rand_key % 64);
unsigned char exp_double_check = ntohl(badtcph->seq) - tf->rand_key;

Viene estrapolato sia il valore di TTL dall’ack_seq che dal packet ID, così da fare un doppio check (superfluo ? all’inizio dello sviluppo l’inivio di pacchetti per trovare la distanza in HOP non era incrementale. si basava su incrementi di 8, poi ricevuto il SYN+ACK si partiva con incrementi di 1 dal penultimo valore usato. Pensavo di ottimizzare così l’invio di pacchetti, ma risultava meno stabile e più complesso. Alcune parti di codice derivano da quando la robustezza del guess derivava dall’ICMP). comunque:

Per aumentare l’efficenza di questo procedimento essenziale, si potrebbe salvare su file la struttura ttl_focus al momento della chiusura (o quando viene chiamata la realloc in struct ttlfocus *TCPTrack::find_ttl_focus, ad esempio). Così da tenere traccia della distanza in HOP. Sappiamo però che questa distanza cambia da location a location, pensiamo all’utilizzo di un portatile, o di un fisso con diversi provider… i valori smetterebbero di essere reali. Secondo me, la soluzione più efficacie può essere di salvare i file in relazione ai primi due hop della catena. Questi infatti sono il modo più verosimile per verificare se abbiamo cambiato location o provider (si puo’ tener traccia del mac address o dell’IP, ci sarebbe da far sperimentazione). In questo modo l’attività di bruteforce del TTL si avvierebbe solo davanti ad host nuovi, e non ad ogni riavvio di sniffjoke.

La possibilità di applicare gli hack in relazione ai servizi, alla netmask, alla destinazione. Magari anche la possibilità di selezionare l’invasività degli hack (paranoide,  leggero, medio…). Se si sceglie paranoide, si accetta plausibilmente un rallentamento perché ad ogni pacchetto verranno mandati hack randomici, se si sceglie leggero… boh, sta all’implementatore futuro :P

L’hack definitivo, che naturalmente non è implementato, perché sarebbe così efficace e così apparentemente ovvio … che mi è venuto in mente solo alla fine :P consiste in questo: quando un pacchetto con un dato di lunghezza X sta per uscire, si anticipa con un pacchetto valido, in sequenza, TTL pari a HOPCOUNT -1, payload applicativo random. Il pacchetto reale parte. Segue un pacchetto pari al primo falso, ma inviato dopo, segue un pacchetto altrettanto falso, ma con TTL che raggiunge il server, dopo aver ricevuto l’ACK. Lo sniffer vedrà 4 pacchetti, tutti e 4 con lo stesso sequence number, e un ACK transitare dal server al client, in accettazione del pacchetto. Ma di quale pacchetto ? Leggendo il codice delle libnids, tcpflow ed altri, la scelta non è specificata dalle RFC… si tiene il primo ? l’ultimo ? l’ultimo prima del transito dell’ACK con l’ack_seq corrispondente ? In qualunque di questi casi, lo sniffer si berrà un payload differente dal reale.

Il funzionamento di sniffjoke lato server. Al momento, solo se un pacchetto SYN viene visto in uscita, allora sniffjoke verifica se conosce la distanza in HOP, se no, lo ferma, inizia il bruteforce, trovata la distanza in HOP inizia l’invio. Invece, per funzionare lato server, dovrebbe ricevere il SYN (e li ? essere configurato in relazione ai servizi da proteggere ?) o aspettare l’uscita dei SYN+ACK. Il bruteforce del TTL puo’ funzionare allo stesso modo … ma è necessario rispettare la tupla (o, usando una porta fasulla, non si supera l’eventuale firewall/nat che plausibilmente ci sarà davanti al client ?), o si può fare una stima degli HOP, vedendo con quale TTL il pacchetto è arrivato e presupponendo sia iniziato a 64 ?

L’iniezione di payload fasulli coerenti con il protcollo applicativo. Quindi, se sta transitando una mail, mettere “\n\nQUIT.\n\n” e completare con dei null byte. Se è una GET HTTP, idem con “GET / HTTP/1.1\n\n” e null byte a saturare. Se il punto superiore venisse implementato, immagino che ogni sessione con porta sorgente 80 possa contenere dei fasulli “</body></html>”. Inserire dati randomici puo’ servire in fase di debug, ma per illudere i ricostruttori, la coerenza del payload applicativo puo’ destar meno sospetti.

I problemi qui descritti non ho intenzione di affrontarli. SniffJoke è ora prenda la via del software comunitario, e se qualcuno volesse divenir mantainer del progetto (ed ottimisticamente completare i punti sopra indicati, che son le maggiori lacune evidenziate in questi mesi), sarà lo sniffjoke-owner dalla prossima release. Se non ci sarà seguito, pace, sarà segno che essere sniffati ci piace :)

Le slide di hackmeeting 2009, usate per illustrare sniffjoke.