Re: Attacco agli stati TCP

On Sat, 29 Jun 2002 10:31:40 GMT
marco.ortisi@flashcom.it wrote:

>
>Salve a tutti, 
>
>su devel@sikurezza.org abbiamo già postato un messaggio il 17/06/2002
>(http://www.sikurezza.org/devel/msg00164.html)
>dove facevamo riferimento ad un articolo da noi scritto
>(http://securitysystem.flashcom.it articolo 0x0c.txt). 
[snip]

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à. 
Voglio a tal proposito citare ciò che Stevens nel 1994 scriveva nel suo
"TCP/IP Illustrated vol.1" a proposito dello stato FIN_WAIT_2.

"In the FIN_WAIT_2 state we have sent our FIN and the other end has 
acknowledged it. Unless we have done a half-close, we are waiting for 
the application on the other end to recognize that it has received an 
end-of-file notification and close its end of the connection, which 
sends us a FIN. Only when the process at the other end does this close 
will our end move from the FIN_WAIT_2 to the TIME_WAIT state. This means 
our end of the connection can remain in this state forever."

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. Poi se uno 
comincia a vedere come è possibile marciarci su tutto questo, ne converrete
con me, questi attacchi vengono in mente in maniera piuttosto naturale.

>scut dice che se qualcuno ha la possibilità di spoofare un indirizzo
>IP e di forgiare pacchetti a piacimento significa che ha
>i privilegi di superuser sulla macchina, quindi
>"you should also have control over the kernel tables and could
>take out the entry." 

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.


Alla prossima,

Angelo Dell'Aera 'buffer' 
<buffer@users.sourceforge.net>

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