Re: [ml] Abbattere il TCP via ICMP

Ciaps,

On Fri, Apr 22, 2005 at 10:33:58AM +0200, koba@xxxxxxxxxxxxx wrote:
> ----- Forwarded message from Dario Lombardo <dario.lombardo(at)libero.it> -----
> From: Dario Lombardo <dario.lombardo(at)libero.it>
> Subject: Re: [ml] Abbattere il TCP via ICMP
> 

<snip>

> Se provi la poc che hanno rilasciato e sniffi un pacchetto in rete 
> vedrai questo:

<snip>

> *  *  Transmission Control Protocol, Src Port: 23 (23), Dst Port: 0 (0)
>        Source port: 23 (23)
>        Destination port: 1000 (1000)
> 
> 
> Come vedi nella parte finale (payload icmp) si riporta il pacchetto che 
> avrebbe scatenato l'icmp. Anche tu dici che la faccenda riguarda il 
> fatto che l'implementazione ignora il seqnum presente in questo payload, 
> rendendo facile l'attacco in quanto ci si basa solo sulla porta. Ora la 
> domanda e': dov'e' questo benedetto seqnum? E' l'implementazione della 

   se provi a vedere il dump raw del pacchetto (i.e., non la decodifica a
   "descrizione" fatta da Ethereal), dovresti vedere anche il seqnum in
   questione (0x23484f44 in host byte order, se non erro). Probabilmente
   Ethereal non riesce a decodificare bene quello che segue perche` non c'e`
   tutto l'header TCP, ma solo, com'e` giusto che sia, i suoi primi 8 byte
   (sport, dport e seqnum); provando invece a far generare un ICMP dest
   unreach dal kernel, si vede che c'e` tutto l'header TCP [1] ed Ethereal non
   fa fatica a mostrare i suoi campi e valori.

> poc che non e' corretta? O tutti i pacchetti di proto unreachable 

   dall'ICMP ricevuto e da una sfogliata veloce al codice mi sembra che la 
   poc sia corretta, nel senso che fa quello che dice; non so se quello che
   dice e` giusto, cmq :)

> riferiti al TCP hanno questa conformazione? La domanda e' questa.

   Tutti i pacchetti ICMP destination unreachable devono includere, come
   loro payload, i primi 64 bit del pacchetto che ha scatenato l'errore,
   come da RFC 792. 

> Il dissector di ethereal visualizza correttamente il pacchetto, quindi 
> questo farebbe pensare ad un payload giusto. Ma se e' cosi' dov'e' il 
> seqnum di cui abbiamo parlato?

   vedi sopra (.

   Ah, come al solito, condite tutto cio` appena detto, con abbondante IMHO :)

bye,
GG sullivan

[1] per provare, semplicemente, ad esempio: 
    # iptables -I INPUT -i lo -j REJECT
    $ nc 127.0.0.1 22

    tcpdump -Xni lo riporta tutto, giustamente.

PS: il kernel di Linux non dovrebbe essere vulnerabile a questo tipo di
    attacco, come si puo` notare da net/ipv4/tcp_ipv4.c::tcp_v4_err(), linea
    1019 (kernel 2.4.26)... sempre se ho visto bene e non come da solito rinco
    che sono :)

-- 
Lorenzo Cavallaro `Gigi Sullivan' <sullivan@xxxxxxxxxxxxx>

Until I loved, life had no beauty;
I did not know I lived until I had loved. (Theodor Korner)

See the reality in your eyes, when the hate makes you blind. (A.H.X)

Attachment: signature.asc
Description: Digital signature