
Progetto SNIFFJOKE:

	Sviluppo di un software in grado di mettere al riparo gli utenti
	dalle tecnologie di sniffing (alias: intercettazione), o per finalita`  
	piu` ipocrite tipo "testare la sicurezza di un IDS".
	il nome e` cosi` per due motivi:
	- non esistendo sui motori di ricerca, mi era piu` facile seguire 
	  la sua vita ed avere feedback (il primo nome doveva essere "acqua"
	  e le migliaia di entry con precedenza rispetto al giocattolino 
	  mi avrebbero dato qualche problema)
	- dopo aver cercato parole insensate per giorni, l'unica logica si
	  e` rivelata inutilizzata :)

VERSIONE:
	0.1, Rilascio ufficiale: Sun Feb 18 12:34:56 CET 2007

FILE:
	0.1	README_it.txt
	0.1	ulogd_SNIFFJOKE.c
	0.1	Makefile
	0.1	description.it
	0.1	description.en

	NON cercate di installarlo usando make, non andra`.
	il readme spieghera` perche` :)

Differenza tra SNIFFJOKE e la crittografia:

	Attualmente per proteggersi dal furto di informazioni effettuato
	mediante sniffing viene utilizzata la crittografia.
	La crittografia presuppone che sia client che server parlino la 
	stessa lingua, abbiano la stessa chiave di comunicazione o perlomeno
	abbiano qualcosa di "predefinito".

	SNIFFJOKE per funzionare si basa su una caratteristica intrinseca 
	degli sniffer, ovvero che se devono leggere giga e giga di traffico,
	ricostruire le connessioni ed analizzarle, devono fare delle assunzioni!

	Le assunzioni vengono fatte affinche', il sistema di ricostruzione 
	delle sessioni, sia piu' semplice di quello presente nei sistemi 
	operativi.

	E' piu' semplice sostanzialmente per quattro motivi:
	1) deve supportare gli stack TCP/IP, ma non interamente. parecchie
	   specifiche di funzionamento definiscono come devono comportarsi
	   gli host dei due capi, ma come deve comportarsi un host nel 
	   mezzo questo non e` definito.
	2) I sistemi operativi che supportano interamente le RFC non sono
	   molti, sono fatti da software house gigantesche e non ho mai 
	   sentito di nessuna di queste che come asset aziendale abbia 
	   un grande fratellino
	3) devono ricostruire il 99% delle sessioni TCP, avendo visibilita`
	   sul traffico di un provider si vedono parecchie anomalie, sia
	   dovute ad errori che ad orrori come lo stack di rete di un
	   apple vecchio stile.
	4) quando c'e` un progetto che deve essere venduto, lo sviluppo
	   viene incentrato su quello che viene visto, sulla bellezza
	   della feature di ricerca ad analisi, di riconoscimento della
	   signature e di similitudine, ma che poi i pacchetti non siano 
	   con precisione tutti quello non lo sa nessuno, e se il tecnico
	   nerd cerca di spiegarlo al sales manager, lui lo guardera`
	   come fosse uno spettro a tre teste che parla SSL. 

	per cui: i dettagli non c'entrano.

	un antico detto giapponese dice: "e` il chiodo che sporge che viene
	picchiato". informaticamente, l'anomalia del chiodino appena visibile
	non lo fara' picchiare, il chiodo piu` evidente invece lo sara`. 
	Il sistema di intercettezione viene quindi semplificato per i 4 
	motivi di cui sopra, viene previsto per catturare il 99% del traffico
	e perderne l'1%
	Magari per gli IDS non e` cosi`, visto che la quantita` di dati 
	per la quale sono previsti e` inferiore e la possibilita` che un
	attaccante utlizzi delle tecniche di evasion e` piu` frequente.

	La semplificazione di questo sistema fa in modo che delle condizioni
	di trasmissione non usuali vengano scartate, vengano mal interpreate,
	eccetera. 

	SNIFFJOKE rende le nostre connessioni parte di quel fortunato 1%

	SNIFFJOKE funziona su linux, non e` un pacchetto fatto e finito, ma
	un codice che va complicatamente compilato, installato, per cui
	se non fate parte di quella schiera di utenti che si puo' divertire
	nel farlo o senza una buona motivazione alla privacy/al caos sulla
	rete: non vi serve.

CERTEZZA:

	nessuna!

	Questa tecnologia dal punto di vista scientifico e` vecchia, e`
	conosciuta da anni e non e` uscito piu` nulla sull'argomento dopo:

	http://citeseer.ist.psu.edu/ptacek98insertion.html

	che ha indicato alcuni limiti di funzionalita' di sniffer/IDS.
	A questi limiti, entro il possibila, gli IDS hanno cercato di ovviare
	per ovvie ragioni di sicurezza.
	Gli sniffer ed i network analyzer hanno seguito un percorso di 
	sviluppo diverso, come indicato nei 4 punti soprastanti, gli interessi
	prevalenti erano altri.

	Utilizzando sniffjoke non ci sono certezze esplicite su cosa avviene, 
	ma aumentando il campo degli attacchi d'evasione il numero degli
        sniffer che ne soffriranno aumentera'. 
	Al momento vengono implementati alcuni attacchi descritti, l'obiettivo
	da raggiungere non e' tanto l'uso di attacchi piu' o meno "certi",
	quanto un'analisi piu' approfondita di attacchi che possono funzionare
	in certe condizioni legate ai due peer, in modo da poter coprire 
	condizioni ancora piu' rare, ottenendo un livello di certezza maggiore.

	L'obiettivo e' individuare dei comportamenti dello stack TCP/IP
	differenti tra i sistmi operativi (un po' come viene fatto nella 
	OS fingerprint) in modo da poter manipolare i pacchetti ottenendo
	qualcosa di accettabile per il sistema operativo remoto (che verra'
	individuato tramite passive OS fingerprint) anche se al limite delle
	RFC. in questo modo si puo' portare all'estremo la malformazione dei
	pacchetti, ed in virtu' delle analisi esposte sopra, ritenersi 
	abbastanza protetti dall'analisi.

	Per una corretta analisi del traffico, lo sniffer dovrebbe emulare
	differenti sistemi operativi per sapere con esattezza il comportamento
	dello stack di rete. Questa tecnologia e' del tutto assente al momento 
	ed impensabile in tecnologie realtime ad alte performance.
	(almeno, nel 2007, tra 5 anni chissa'...)

	In questa 0.1 sono consapevole di alcuni suoi limiti, per cui le 
	certezze consideratele inferiori fino a che non vedrete la 
	versione almeno 1.x 

DISCLAIMER DI POSSIBILITA'

	Questo strumento non protegge da un'analisi targettizzata. se le 
	forze dell'ordine vi stanno controllando, non sara' con questo
	programma che eluderete i loro controlli. Questo strumento non puo'
	ne' serve a proteggere chi ha dei problemi piu' grossi di una 
	connessione TCP. Le analisi del traffico su un target specifico 
	non sono evitabili, sono una forma di indagine, restituiscono 
	dati analizzati da periti esperti che sanno dire tranquillamente
	quale pacchetto e' vero e quale no. 

	Secondo il libro "un'eterna ghirlanda brillante" questo e' il disco
	che distrugge il grammofono, ma si parla di strumenti digitali, quindi
	non e' un grammofono rotto un problema.

	Questo strumento protegge dalle analisi massive o dagli attacchi
	portati con motivazioni criminose, se dirette ad una massa di
        potenziali vittime e non ad un target specifico.

FUNZIONAMENTO:

	SNIFFJOKE si appoggia al framework netfilter ed al servizio in
        userspace ulogd. da questo momento lo chiamero' SNJ

	tramite iptables e' possibile specificare alcuni pacchetti che vengono
	passati ad un processo per essere analizzati o utilizzati. tramite
	una regola analoga:

	iptables -A OUTPUT -p tcp -j ULOG
	iptables -A INPUT -p icmp -j ULOG

	Questi comandi vengono avviati automaticamente da SNJ (e quando
	ulogd viene spento, vengono anche rimossi).

	Tutti i pacchetti tcp verranno passati al servizio ulogd, che a sua
	volta li proporra' ai differenti plugin registrati. SNJ e' un plugin 
	per ulogd, leggendo tramite questa sequenza i pacchetti riuscira'
	a creare ad hoc i pacchetti per l'injection.

	l'injection e` simmetrico alla nostra tramissione, essa prosegue 
	e nel frattempo i pacchetti SNJ vengono trasmessi al fine di 
	mandare lo sniffer fuori sincronia.

	di tenere traccia dei pacchetti inviati in sniffjoke non ho voglia, il
	modo piu' semplice con le feature offerte da iptables sarebbe matchare
	il process id (pid), intercettanto tutti i software con pid differente 
	a quello di sniffjoke. Questo e` impossibile o molto difficile a causa
	dell'infausto supporto del pid sull'extension netfilter.
	L'utente diventa la scelta piu` sensata e piu` comoda, sniffjoke 
	gira da root e tutto quello che e` generato dall'utente non root
	impostato per sniffjoke verra` da sniffjoke ritoccato.


INSTALLAZIONE:

	L'installazione non e` semplice per tutti coloro che vogliono 
	semplicemente provarlo :) ma chi vuole dedicare 2 minuti di tempo
	ad un progetto che potrebbe salvaguardare la sua privacy non 
	avra` difficolta`. 

	deve avere linux, e nel kernel abilitato il target ULOG del
	framework netfilter, e la "user match" extension.

	si scarica da http://www.netfilter.org l'ultima versione di ulogd,
	branch 1.x

	ulogd e` gia` in sviluppo nella branch 2.x, ma e` fermo da 2 anni 
	se non ho notato male, per cui ho supposto saggio affidarmi alla 1.x

	una volta vinto ulogd-1.24.tar.bz2 lo si sposta in una directory,
	nella quale c'e` anche sniffjoke-0.1.tar.gz, questo non e` necessario,
	ma mi viene molto piu` facile scrivere i comandi che dirivi di 
	mettere sniffjoke-x.y dentro a ulogd-1.x/ e fare make li` dentro:
	
	mv sniffjoke-0.1.tar.gz /tmp
	mv ulogd-1.24.tar.bz2 /tmp
	cd /tmp
	tar jxfv ulogd-1.24.tar.bz2
	cd ulogd-1.24
	./configure
	make 
	make install
	cd ..
	tar zxfv sniffjoke-0.1.tar.gz
	mv sniffjoke-0.1 ulogd-1.24/sniffjoke-0.1
	cd ulogd-1.24/sniffjoke-0.1
	make install

	E` NECESSARIO che sniffjoke-0.1 sia una sottodirectory di ulogd, almeno
	per questa microrelease, /tmp/ulogd-1.24/sniffjoke-0.1 e` sufficente,
	qualunque altra directory va bene, ma che sia una sottodirectory:
	deve infatti copiarsi i Makefile degli altri plugin per evitare ogni
	genere di incompatibilita` e lo fa cercandolo in ../pcap/Makefile
	una volta installato:

	vi /usr/local/etc/ulogd.conf

	commentare tutti i plugin eccetto ulogd_BASE.so, ed aggiungere:

	plugin="/usr/local/lib/ulogd/ulogd_SNIFFJOKE.so"

	piu` sotto, quando si specificano i blocchi di opzione per ogni 
	singolo plugin:

	[SNIFFJOKE]
	file="/tmp/sniffjoke.log"
	port="25,110,143,4200-4700,6777,7000"
	user="vecna"

	file e` il nome del file dove i log di SNJ finirano, 
	port e` il range di porte TCP interessate alla protezione
	user e` e` l'utente al quale verranno applicate le feature di 
	SNJ. E` necessario l'utente NON sia root, perche` per questioni
	logiche, se le sessioni vengono copiate su ULOG quando matchano
	una certa regola (nel nostro caso, che siano tcp in uscita verso
	le porte indicate) anche quando SNJ riinviera` il pacchetto 
	manipolato matchera' quella regola, ottenendo cosi' un loop.

	le porte sono divise tra "," e "-", come consueto, ogni virgola
	rappresenta una regola che verra` messa separata dalle altre, in modo
	da selezionare porte TCP destinazione differenti. Se si tratta di 
	porte continue, e' sufficiente usare il "-" in modo da includere un
	range di porte.

AVVENIMENTI DETTAGLIESCHI et MOTIVAZIONI TECNOLOGICHE:

	Quando uno sniffer legge il traffico ed effettua il tracciamento
	delle sessioni, ricostruisce il flusso TCP cercando le coppie
	ip sorgente - porta sorgente e ip destinazione - porta destinazione
	tra i pacchetti che riceve. Normalmente queste sono le descriminanti
	per associare un pacchetto al prossimo in sua sequenza. Se lo sniffer
	da ai pacchetti lo stesso tipo di controllo che viene effettuato sui
	kernel degli stack, la ricostruzione sara` la stessa. gli hack sono
	stati studiati perche` tocchino quei limit normalmente non trattati
	allo stesso modo dagli sniffer rispetto che gli stack.

	http://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Caswell.pdf

	In dettaglio i tipi di "hack" che vengono applicati sono:

	-- FAKE CHECKSUM RESET,
	Si invia un pacchetto reset facente parte della sessione TCP corrente,
	se tutto va bene la connessione viene chiusa, non volendolo, il
        checksum del pacchetto e` errato, in modo che se lo sniffer non
        verifica i checksum verra` illuso del reset.

	-- FAKE CHECKSUM FIN,
	Stessa cosa, ma con fin anziche` reset

	-- FAKE CHECKSUM SEQ,
	Sempre un pacchetto con checksum errato, nella speranza lo sniffer
	non verifichi, ma con un sequence number insensato, nella speranza
	non faccia verifiche appropriate ed esca di sequenza

	-- FAKE POSTSTY SEQ,
	All'interno di una sessione gia` stabilita, si simula l'apertura
	di una nuova sessione con un pacchetto syn, nell'eventualita` 
	non venga considerata la vecchia sessione e sia assegnata la nuova
	(completamente fuori sequenza)

	-- EVIL TCPTRUNCATE,
	Un pacchetto tcp solo parzialmente valido, nel caso le verifiche
	non siano sufficienti, puo' causare desincronizzazione nello sniffer

	-- SNIFFJOKE GAME,
	randomiza i valori dei flag TCP riservati (res2 e res1 su linux)

	-- SNIFFJOKE GAME 2,
	prova a mettere la dichiarazione dell'header TCP differente dalla
	realta`, aumentandola come se avesse opzioni.

	-- EXPIRE RESET,
	Pacchetto completamente valido ma inviato con ttl sufficientemente 
	basso in modo che scada un hop prima della macchina destinataria,
	cosi` facendo chi legge il traffico sulla rete lo interpretera` 
	correttamente e l'host destinatario non lo ricevera`

	Facendo injection nel proprio traffico di pacchetti che devono 
	essere ignorati dal sistema operativo remoto, si deve venire a 
	certi compromessi. Il primo e` che bisogna essere certi del fatto
	che vegano ignorati, perche` se sniffjoke iniziasse a mandare pacchetti
	reset ogni tanto, tu utilizzatore probabilmente te lo toglieresti
	rapidamente dalle tables.

	Inoltre, la ricezione di pacchetti con il checksum scorretto,
	pacchetti duplicati ed altre anomalie, per lo stack TCP/IP 
	rappresentano un'anomalia. per quanto ignoranti nella transazione
	sono considerai dallo stack in quanto tali e considerati 
	all'interno degli algoritmi di congestione, che presupponendo dei
	problemi sul link rallenta la quantita` di dati trasmessi.

	SNIFFJOKE funziona su questa logica:

	[+] ricevo il pacchetto da ulog
	e` icmp o tcp ? 
		se e` tcp continua
		se e` icmp vai a "gestione icmp"
	e` una nuova connessione ?
		si: inizio a tenerne traccia
		no: ne trovo la traccia
	la traccia mi dice cosa fare del pacchetto:
		se applicare un ttl specifico 	[1]
		se non fare nulla		[2]
		se non inviare il pacchetto	[3]
		se applicare un hack specifico	[4]
	invio o non invio il pacchetto

	[+] gestione icmp:
	e` un icmp di tipo "time exeeded" ?
		si: contiene una sessione tcp nostra ? 
			si: allora ho raggiunto il limite del ttl
			no: lo ignoro
		no: lo ignoro
	
	[1]: ogni sessione mediamente e` composta da N pacchetti, il TTL
	     di partenza e` fisso, 64, 128 in alcuni casi 255. sniffjoke 
	     decrementa per il pacchetto inviato "in parallelo" ogni
	     volta il ttl, in modo da individuare durante la discesa
	     verso 0 il numero di hop che lo separa dall'host. 
	     quando riceve il primi time exeeded significa che non ha
	     raggiunto l'host ed e` al ttl massimo per non raggiungerlo,
	     questa informazione e` rilevante per l'hack piu` efficace.

	[2]: nel caso il pacchetto abbia flag SYN/ACK/FIN/RST, non si
	     applicano modifiche, sull'ACK ho da fare test.
	
	[3]: se ho gia` applicato tutti gli hack, se ho gia` trovato il
	     ttl minore ed usato l'hack del reset expire, non serve
	     continuare.

	[4]: in sequenza vengono provati tutti gli hack, in modo che
	     qualunque sia ad avere effetto, durante i primi pacchetti
	     venga utilizzato per desincronizzare lo sniffer/IDS.

DOVE USARE SNIFFJOKE ?

	Le sessioni rapide con un host sono svantaggiate, perche` 
	inizialmente vengono rallentate dalle injection e dalle 
	conseguenti reazioni del sistema operativo remoto. In un
	futuro sviluppo potrei tenere traccia del ttl minore per ogni
	host, come potrei implementare la passive os fingerprint per
	selezionare meglio gli hack da applicare.

	le connessioni sul quale SNJ puo' avere effetto sono tutti
	i tipi di instant messaging, poiche`, sia peer to peer o
	server based, una volta stabilita la connessione essa rimane,
	inoltre, un rallentamento in un sistema di messaggi bulk non 
	viene molto percepito. allo stesso modo l'invio di email puo'
	goderne. web no, purtroppo per il suo funzionamento di connesioni
	minime, rapide, verso molti host, rischia di rallentare 
	eccessivamente e di non dare la possibilita` di godere di tutti 
	gli hack all'utente.

FUTURI et FUTILI SVILUPPI:

	Questo software rappresenta l'implementazione pratica di una 
	tecnica nota da tempo, ma mai resa comodamente utilizzabile.

	Aggiunge ad essa la soluzione del problema di sapere a quanti
	hop di distanza c'e` l'host remoto

	Aggiunge l'uso degli sniffjoke games, che non assicurano nulla,
	ma plausibilmente possono dare problemi di tracciamento 
	allo stesso modo.

	Gli IDS attuali tengono traccia di checksum e di altri 
	fattori, sicuramente non possono tenere traccia del TTL,
	per cui tutto sta` a vedere il singolo comportamento 
	degli IDS/sniffer in seguito alla lettura di un reset. 

	Futuri sviluppi comprendono una strada peculiare:

	Spulciare i differenti comportamenti su OS diversi.

	Utilizzando tecniche di OS fingerprint (passivo o attivo, 
	tanto i pacchetti li forgiamo noi) diventa plausibile conoscere
	il sistema il sistema dell'endpoint.

	Se parallelamente dovessi individuare dei pacchetti che,
	rispettando le RFC e quindi plausibilmente interpretati 
	correttamente dagli sniffer/IDS, possano portare ad un 
	comportamento inusuale sull'host remoto, questa anomalia potra`
	essere sfruttata come tecnica di IDS-evasion.

	Se infatti l'host remoto dovesse considerare per valido
	qualcosa che non lo e`, diverrebbe comodo inviare dati
	solo in quel modo (anche se con un'implementazione di tipo
	parellelo com'e' ULOGD non puo' andare).
	Se invece dovesse considerare non valido qualcosa che lo e`,
	e` un buon modo per mettere dentro FIN, RST e sequence number
	non validi :)

	In ogni caso, su delirandom.net postero` studi, casi d'uso
	e test. su s0ftpj.org si trovaranno le release stabili.

AUTORAZIONE:

	Claudio Agosti <vecna@delirandom.net>
		       http://www.s0ftpj.org 		- s0ftpr0ject 
		       http://www.delirandom.net	- me

	L'autore ha sviluppato questo codice gratuitamente, dagli
	almeno feedback!

AUTORITA':

	Licenza GPL in seguito ad eredita' diretta

RINGRAZIAMENTI:

	Stefano Zanero <raistlin@s0ftpj.org>
	Michele Ciciotti <hackbunny@reactos.org>
	Yvette Agostini <vodka@s0ftpj.org>
	Alessio Orlandi <nail@s0ftpj.org>
	Guido Bolognesi <zen@kill-9.it>
