Re: Attacco agli stati TCP

[Risposte al posting di vecna]

>avevo detto in un
>messaggio sul thread avvenuto su devel@ riguardo la saturazione dei backlog
>della listen() (mh cioe`, spero d'averlo detto :) che un test molto simile
>l'avevo fatto con un programma che apriva connessioni e quando riceveva
>l'errore "Too many file descriptor" (1024 di default) forkava se stesso
>in modo da aprire un altro processo (con ancora 1024 possibili file
>descriptor da occupare)

Si l'avevo letto ed alcune mie considerazioni sono proprio partite
da lì [Marco Ortisi]. 


>su questo non c'e` dubbio, l'utilizzo dei RST e` solo un pagliativo per 
>superare un problema "client side" come l'uso della fork() e come si
>potrebbe fare con iptables... pensa a fare un sw che invii un SYN, legga
>in SYN ACK, risponda con l'ACK. il tuo kernel si metterebbe di mezzo 
>appena ricevuto il SYN ACK rispondendo con un RST, tu metti una rules di
>iptables che droppi tutti i pacchetti con RST in uscita ed otterrai lo
>stesso risultato.

Già fatto un sw di questo tipo modificando leggermente il codice del naptha
DoS creato con l'ausilio delle libpcap e con le libnet se non sbaglio, che
se ci fai caso si basava proprio sull'intercettazione dei pacchetti
con certi flag attivi inviandone in risposta altri che servivano
a portare avanti l'attacco e rilasciare brutalmente lo stato della
vittima in LAST_ACK. Per il fatto di bloccare i RST tramite rule iptables
è una cosa che avevamo pensato... magari un tantino modificata
nell'aspetto come è stato trattato nella sezione Double Trap dell'articolo.
La nostra preoccupazione...cioè quello che volevamo fare era di lasciare
in ESTABLISHED lo stato della vittima....ed in CLOSED quello nostro. 
Bloccare
dei RST in uscita dal firewall non era la soluzione a questo problema,
sebbene è facilmente compresinbile che l'attacco sarebbe ugualmente
andato a buon fine. 


>l'idea suggerita da antirez, quella di monitorare gli stati delle >connessioni
>a layer 5 per decidere quale uccidere puo' essere una soluzione cmq.

Quella è una idea che ci piace molto...e penso che sia stata una bella
intuizione. Mi piacerebbe poter dedicare un pò di tempo a quanto
espresso da antirez....purtroppo non si riesce a contattarlo [Brutal OT] 

>senza contare che attacchi di questo genere possono funzionare perche`
>nessun sistema ha una limitazione sul "numero di connessioni possibili
>provenienti da un ip".

Si avevamo citato una cosa simile nell'articolo. Ti diamo piena ragione. 

>P.S. scusate x la mancata risposta alla vostra email, pensavo ne aveste >avute
>gia` abbastanza :)

Eehehe ed invece ti sbagli...a parte FuSyS, il rimprovero di Raistlin
:) scut e qualcun' altro non abbiamo ricevuto molte considerazioni
in base alla serie di email che abbiamo inviato. Preferiamo essere
floddati che ignorati. Ricordalo per il futuro [frase rippata da
FuSyS] :) . Grazie 

 


[Risposte al posting di Angelo Dell'Aera] 

>Ho letto l'articolo ma onestamente credo che non vi sia nulla di nuovo
>rispetto a quanto coloro che, conoscendo il funzionamento del TCP, non 
>conoscessero già. 

Si, effettivamente chi conosce il TCP trarrà queste conclusioni abbastanza
facilmente....il fatto è che non abbiamo letto doc che ne parlassero
in modo esplicito (vala a dire termine del 3whs ed autoinvio del RST per
resettare la connessione dal lato client). Solo questa è la motivazione.
Quando si scoprirono gli effetti del syn flooding e del tool di daemon9
e del project Neptune in generale non penso che nessuno conoscesse tale 
tecnica...
solo che magari non esistavano doc precedenti che ne illustrassero
il metodo di sfruttamento. 

>Ora si può notare che, sebbene lo scenario qui sia leggermente diverso,
>la possibilità di rimanere inchiodati fino alla scadenza del timeout in
>un determinato stato è evidenziata in maniera evidente...

Infatti il nostro scopo era bloccare lo stato dello vittima in ESTABLISHED. 
Era
intuibile farlo in SYN_RCVD, era intuibile farlo in TIME_WAIT, era intuibile
farlo in LAST_ACK....noi volevo farlo in ESTABLISHED senza avere strutture
pendendi localmente. E' logico che le nostre considerazioni si sono basate
proprio su quelle fatte da chiunque (Stevens compreso) che nel corso degli
anni avesse affermato che il bloccarsi in un determinato stato TCP era
cosa fattibile. Ripeto...il nostro operato si è basato sugli studi fatti
da persone competenti molto tempo prima di noi. Ci scusiamo subito
per non essere stati chiari in questo fin dall'inizio. 

>Sul fatto che scut affermi una cosa teoricamente esatta nessuno penso
>possa dire nulla. La realtà è che probabilmente un approccio del genere è,
>almeno dal mio punto di vista, decisamente più complesso rispetto al
>vostro modo di procedere senza che ciò comporti effettivi vantaggi ai
>fini dell'attacco teorizzato. Perchè mettere le mani in kernel space 
>e doversi sobbarcare operazioni che lo stack tcp/ip di suo già esegue?
>Se la ricezione di un RST serve proprio a resettare una connessione
>perchè non fare tutto (generazione dei pacchetti e reset della connessione
>su un end) tramite raw socket da user space?
>La soluzione che scut propone mi sembra invece un'inutile complicarsi
>la vita.

Pensandoci bene hai ragione sia tu che vecna su questo punto. Lavorare in 
kernel
space in questo caso serve solo a complicare ed è meno performante...ma ci 
permetti
che è più figo eheheh? Dai scherzo. 

Grazie per le considerazioni. 

Alla prossima 

marco.ortisi@flashcom.it
xabino@freemail.it 


________________________________________________________
http://www.sikurezza.org - Italian Security Mailing List