Newsgroup: it.comp.sicurezza.varie
Titolo: Ansa

http://www.ansa.it/fdg01/200404212127146865/200404212127146865.html
All'ansa ne han dette tante di buffale, che ne pensate stavolta?
-- 
L'importante e' cio' che conta
  -  scrivimi solo senza latastiera  -

 All'ansa ne han dette tante di buffale, che ne pensate stavolta?
http://www.cisco.com/warp/public/707/cisco-sa-20040420-tcp-ios.shtml
-- 
Vincenzo


http://www.internetnews.com/infra/article.php/3343561
Ciao

 All'ansa ne han dette tante di buffale, che ne pensate stavolta?
Che sia la volta buona che termini come "antispoofing" o "egress /
ingress filtering" entrino nelle procedure di configurazione degli
isp?
Fabio

 isp?
Magari..
il problema è che devi affidarti ai filtri egress degli altri, nella
fattispecie...
-- 
wash the blood from your hands
bury your secrets in the sand
and forget

 isp?
Ho dei FORTI dubbi che quanto sopra possa essere
una misura sufficiente, considera che Cisco ha rilasciato
una serie di patches, inoltre, nel caso le info postate non
bastassero, potresti anche dare un'occhiatina qui:
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt
con buona pace del thread closed/stealth e di
altre considerazioni già fatte su vari threads ...
Ciao

 fattispecie...
Be', voleva essere solo una stupidata buttata li, ma ipotizzavo che
se la situazione e' critica come qualcuno dice, patch per gli stack
a parte, ci possano essere spinte verso una maggiore collaborazione
tra carrier. Dal tuo AS arrivano pacchetti con ip sorgente che deve
appartenere a me? Eh eh eh, male, adesso io... (boh, qualcosa). Non
conosco bene, pero', le problematiche di routing a quei livelli.
Un altro aspetto e'quello per cui e' necessario che l'attaccante si
connetta, prima, ad una porta TCP del router bersaglio. Perche' mai
un router dovrebbe accettare connessioni con sorgente esterna a dei
range ip ben stabiliti, se non a pochi altri ip ben definiti? Anche
qui potrebbero esserci implicazioni che mi sfuggono, ovviamente.
Fabio

 altre considerazioni già fatte su vari threads ...
Uh, qual'e' l'attinenza con il thread citato?
Fabio

 altre considerazioni già fatte su vari threads ...
Non direi.
L'attacco a BGP in questione lo fai prendendo molto bene la mira. Non
ritengo che un attacco con rimbalzi a caso possa dare qualche speranza di
fare alcunchè...


 Uh, qual'e' l'attinenza con il thread citato?
Facevo riferimento al discorso dell'attacco "bounce" usando
zombies e pacchetti spoof, applicando quanto sopra a tale
tipo di "architettura" un'attacco del genere sarebbe abbastanza
veloce ed abbastanza distribuito da essere virtualmente "non
arrestabile" con semplice filtering
Ciao

 fare alcunchè...
Be', se questo e' il senso allora non puoi rimbalzare per definizione:
la coppia ip sorgente e destinazione e' prestabilita. Puoi solo fare i
rimbalzelli con i SYN tra i due ip tra i quali vuoi segare la sessione
ma il vantaggio di farlo non lo vedo, di primo acchito.
Fabio

 a caso possa dare qualche speranza di fare alcunchè...
Se vogliamo scherzare ok .. altrimenti direi che forse
dovresti riconsiderare tutto il discorso.. mai parlato di
rimbalzi a caso, tra l'altro tutto si basa sulla velocità di
attacco ed avendo più macchine riesci ad ottenere una
"finestra temporale" migliore per portare l'attacco ...
Detto questo, mi fermo qui; ciao
Pace & Bene

 arrestabile" con semplice filtering
Non e' applicabile, IMHO. Inoltre devi sempre completare una
connessione, almeno, quindi quell'ip non puoi spoofarlo.
Fabio

 distribuito sarebbe quasi impossibile da filtrare
Direi che stai affrontando la questione in maniera diametralmente opposta:
fare egress filtering vuol dire non far uscire quello che non viene da me.
Il peering BGP lo si fa accordandosi tra ISP. Un router non dovrebbe
accettare di inoltrare pacchetti che dicono di provenire da lui stesso (e
da una interfaccia diversa da quella in possesso di quell'ip, anche), o
inoltrare pacchetti per un AS che risultino provenire a loro volta da
quell'AS, se non in configurazioni estremamente esotiche. Se quando le vede
le filtra, l'attacco in questione è impossibile.
Il problema, come detto, è che è una cosa che devono fare (anche) gli
altri, non tu...
Non per nulla si chiama "egress filtering"
Una toppa (stupida, IMHO) proposta è giocare sul TTL dei pacchetti
implicati in sessioni di peering: di solito (salvo BGP multihop) il
peering avviene all'interno di una unica rete. Se tutti ci accordiamo su
TTL 255 e filtriamo tcp segment diretti a BGP che abbiano TTL <254...
Cmq, soluzioni ce ne sono tante... la cosa impegnativa è accordarsi tra AS
per stabilire una comune metodologia di peering...
Hola..


 "finestra temporale" migliore per portare l'attacco ...
Salvo dover azzeccare, oltre al SN da passare al target, anche quello in
uscita dal bouncer, se non faccio male i conti...
Sbaglio?!?


 uscita dal bouncer, se non faccio male i conti...
I numeri di SEQ e ACK del RST emesso dal bouncer li imporresti
tu con il pacchetto TCP da fargli resettare, ma non e' questo.
Scusate, ma forse non state considerando un pezzo: il "bouncer"
non puo' essere altro che l'altro capo della connessione che si
vuole resettare. Non esiste attacco distribuito su piu' bouncer
(ma solo da piu' sorgenti, al limite), e comunque la difficolta
di backtracing che introduci con i bounce nello scenario di cui
si e' discusso nell'altro thread, qui non e' rilevante, perche'
l'attaccato controlla anche il bouncer e quindi si riduce tutto
ad un qualsiasi altro attacco con ip spoofato, come problemi di
backtrace. Vale, invece, il problema della finestra temporale a
cui fa riferimento Obi, per cui puo' essere d'aiuto distribuire
"il carico" su vari zombie, ma non necessariamente con i bounce
(IMHO e AFAIK).
Fabio

 Sbaglio?!?
Hm .. vediamo un pò (sto pensando "a voce alta" ok ?)
partiamo da quanto descritto in questo draft:
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt
leggendo quanto sopra si evince che il successo di un
tale attacco, nel caso di UN singolo attaccante dipende
dalla velocità dato che è necessario generare un numero
decente di tentativi per poter aumentare le probabilità di
"indovinare" SN; ora, se immaginamo di applicare quanto
sopra ad un numero N di attaccanti (zombie, bot o come li
si voglia chiamare) aumenteremmo il numero di "guess"
e di conseguenza anche la probabilità di "indovinare" il
SN corretto .. ora; diciamo che ciascun attaccante oltre
ad inviare il pacchetto di attacco genera anche del traffico
"bounce" (vedi thread precedente) verso X macchine per
ciascun attaccante, questo a sua volta fa sì che il bersaglio
sia costretto a generare un maggior numero di SN e quindi
aumenta ulteriormente la probabilità di indovinare il numero
corretto "in mezzo alla tempesta"
sbaglio ?!?

 Tu devi fare ingress, per te, ed egress per gli altri. Ingress
<snip>
Si scusa.. stavo ragionando sul discorso che il _carrier_
dovrebbe farsi carico del filtraggio .. solo che se il carrier
stesso NON ha patchato i routers (mi piacerebbe sapere
quanti lo hanno già fatto ..mah..) tutto il discorso cade...
Per quanto riguarda il resto del ragionamento .. ho risposto
"sotto" a Skull; se vieni "giù in cantina" ci facciamo una birra
e continuiamo la chiacchierata :-) ok ?

 e continuiamo la chiacchierata :-) ok ?
Yum yum... io voglio una bionda [1], ma leggera, che ultimamente 
ho sbroccato un po' in questo senso :-)
Comunque secondo me ti sbagli sui bounce :-P Non puo' funzionare.
Prova a leggere con maggiore attenzione il mio post precedente (a
proposito degli ip sorgente da usare) e dimmi cosa non ti torna.
Fabio
[1] che poi, chiesta cosi', metti che l'ospite si sbagli e ti 
    porti un bel pezzo di topa dal crine paglierino...

 alla tempesta"
Forse ti sfugge che il peering -proprio perchè peering- lo fai tra 2
macchine 2.
Poichè tu devi arrivare al target con l'ip del peer con cui ha instaurato
la connessione, questo lo devi spoofare (che se hai il controllo
dell'altro router non capisco che cacchio attacchi a fare).
Dato che il tuo bouncer non può spoofare alcunchè (visto che genera
l'RST con il *suo* IP), necessariamente costui è l'altro peer della
connessione che intendi tirare giù.
Ora, quale è il *vantaggio* del "bouncer" se invece di attaccare un capo
della connessione attacchi l'altro, visto che l'obiettivo è quello di
tirare giù una comunicazione che hanno tra loro due?


 fare).
Ecco .. appunto .. ho idea che ti sia sfuggita la parte relativa
alla "injection" ed al "peer spoofing" (ossia "fingersi" un peer
legittimo per la vittima) il che imo ci riporta "in carreggiata" :-)
in caso contrario tutto l'ambaradan di cui al draft sopra non
avrebbe molto senso ... nè sarebbe (come purtroppo è) un
vero problema ...
Ok ... mi prendo una birra e torno ... :-)

 (tranne microsoft
Mica implementano il protocollo BGP.
E a quanto pare il problema risiede su questo protocollo: Finestre
ampie, connessioni TCP che devono essere permanenti, onde evitare di
dover riavviare il protocollo o l'appliance (questo almeno da quanto ho
letto nell'advisory originario).
-- 
*    HappyCactus - Linux User #209744 - BOFH Certified Engineer    *
*                         
http://www.google.com
                    *
*                                                                  *
*                           ET IN ARCADIA EGO                      *

 vuole resettare. Non esiste attacco distribuito su piu' bouncer
<snip>
Come no .. rileggi la parte relativa all'injection, il trucco sta
tutto nel presentarsi alla vittima come l'altro "peer" ...
(Vedi anche risposta a skull)

 Ok ... mi prendo una birra e torno ... :-)
Mi porti una stella?!? ;-)


 Mi porti una stella?!? ;-)
Ok .. eccola qua... bella fresca !

 letto nell'advisory originario).
Si, l'originario aveva come "target" BGP (da cui le patch di Cisco)
ma 
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt
allarga di parecchio il discorso ...

 letto nell'advisory originario).
L'impatto su BGP e' quello che si ritiene di maggiore impatto (o cosi' 
ritiene watson). Il problema e' di tutte le implementazioni di TCP che
resettano i socket con degli RST in finestra (e non sull'ACK esatto) e
con porte sorgente del client predicibili. Potrebbe essere un dns, per
i trasferimenti di zona, o qualsiasi altra connessione TCP che tu puoi
avere interesse a tirare giu' (IMHO).
Fabio

 aumentare il numero di SN generati e la probabilità di guessing
Duh? continuo a non capire (colpa mia, è il venerdì..), ma perchè al target
dovrebbe cambiare qualcosa?
I tuoi rimbalzi al massimo possono cambiare l'ISN assegnato alle nuove
sessioni aperte (cosa che in ogni caso non è, visto che gli stai mandando
RST, che vengono semplicemente scartati), ma non cambia di una virgola i
valori di SN in transito su una sessione già in atto...
Posto che comunque, far ruotare il bersaglio più veloce non mi pare
aumenti le probabilità di colpire nel segno andando alla cieca (ma in
statistica sono sempre stato una ciofeca...)
PS: grazie della birra... adesso in macchina e via per 130 KM necessari
per arrivare a casa... palloncino permettendo...


 ritiene watson). Il problema e' di tutte le implementazioni di TCP che
Mah, e' assolutamente corretto quello che dici.
Resta il fatto che la cosa continua a perplimermi, soprattutto per quel
che sento dire.
Inizialmente sembrava che fosse tutto a rischio.
Ora tutti minimizzano.
Cerchiamo di fare comunque chiarezza, che forse qualche cosa me la sono
persa (probabile: non ho avuto molto tempo per pensarci).
Il problema consiste nel fatto che per resettare una connessione occorre
che porte e IP matchino, ovviamente, e che il SN sia compreso tra SN
dell'ACK precedente e SN+WSIZE.
Ora:
SN e' un numero a 32 bit
WSIZE e' un numero a 16 bit che per le finestre larghe puo' essere
massimo.
Cio' mi dice che $ATTACKER deve azzeccare SN tale che
ACKSN<SN<ACKSN+WSIZE, ovvero ha 2^16 possibilita'.
Il problema era irrilevante con bande sufficientemente basse.
Ora che la banda larga e' alla portata di tutti, sembra che sia
possibile portare un numero sufficiente di pacchetti in tempo utile.
E' corretto?
Penso che faro' qualche esperimento, qui in lan...


 per arrivare a casa... palloncino permettendo...
Urk ... non pensavo al palloncino .. ma scusa, per risolvere il problema
potresti auto-inviarti a casa via fax o ftp o in allegato e-mail o al limite
usando .. che so .. bittorrent :-)
A propo di birra .. non c'è di che.. finchè l'impianto di raffreddamento
che ho installato funziona ... 
http://www.asciimation.co.nz/beer/
 :-)))))
Ciao & buon fine settimana !

 Penso che faro' qualche esperimento, qui in lan...
Già fatto :-) funge alla grande e bastano poche righe
di C per mettere in piedi un "coso" funzionante, occhio
solo a scrivere codice "brutto ma veloce" ;-) !!

    porti un bel pezzo di topa dal crine paglierino...
"Che gentile! Come faceva a sapere che non reggo l'alcool?"
Leonardo
-- 
"Se e' vero che Linux in se' e' gratis, non lo sono le indispensabili
interfacce grafiche (X, KDE ecc.) che consentono alle persone normali
di utilizzarlo."                    -- Jason Matusow, Microsoft Corp.

 e-mail o al limite usando .. che so .. bittorrent :-)
Qualcuno tempo fa (in questa stessa sede, se non ricordo male) proponeva
di effettuare una moltiplicazione tramite invio con UDP multicast...
E non penso a moltiplicare me (uno basta e avanza) ma la birra...
Onestamente però era una cosa che veniva meglio sotto Pasqua...
Vado a spararmi 'ste prove di GP...
-- 
the Skull says:
+---------------------------------------------------------------------+
 We are Pentium of Borg. Division is futile. You will be approximated.

 vorresti implementare..
Non mi pare cosi' difficile.
Se in input su una certa interfaccia so quali classi devono transitare,
bastano enne basic access-list, una per classe.
Il problema e' che le access-list consumano cpu e ram (ciao, Cisco).

 peering avviene all'interno di una unica rete.
Ed i peering multihop sono tutto sommato abbastanza diffusi. 
Su tre peer che ho, due sono multihop:
neighbor 213.140.31.192 ebgp-multihop 5
neighbor 212.239.96.247 ebgp-multihop 2
(c'e' un dato interessante: il peering con inet e' persistente
da soli quattro giorni, quelli con interbusiness e fastweb
da moooolto di piu'...la cosa vi suggerisce nulla? <g>)
-- 
aridateme un juniper

 E' corretto?
Yez. Anche se negli articoli della stampa generica si dice che nell'
implementazione dell'attacco ipotizzata da watson si possa ridurre 
il numero di pacchetti a 4 o 5 (alcuni dicono addirittura 1). Non ho 
letto il paper originale, ma forse combina questo attacco con i noti 
risultati sull'analisi degli attrattori strani ma, in questo caso, 
il numero presunto di tentativi dipendera' dal sistema operativo 
bersaglio, ovviamente. Potrebbe essere una bufala :-P ma mi parrebbe
una considerazione ragionevole, considerando che .
 
Fabio

 una considerazione ragionevole, considerando che .
Si parlava, genericamente, di rotazioni di bit. Non si menzionava alcun
s.o. in particolare.
Ma potrei sbagliarmi.


 (ma e' stato rilasciato?)
Si; come no.. solo che non è stato molto pubblicizzato, se ti serve
ti mando un link in priv (anche perchè _qui_ non mi pare il caso
visto che qualsiasi lamerazzo _che_non_sa_come_cercare_
potrebbe sgamarlo direttamente) detto questo, anche il link che
ho passato (quello relativo ad IETF) fornisce abbastanza infos
poi ... beh ... è tutta questione di essere creativi :-)
Ciao !
PS: quella appena scoperta è solo "la punta dell'icerberg"
        puoi crederci o no, ma ti _assicuro_ che è così, e purtroppo
        NON si tratta di un problema collegato ad un particolare O/S
        o hardware ... spero che "chi di dovere" sia MOLTO veloce
        anche se da mailing/altro nutro dei forti dubbi :-6
Ri-Ciao
-- 
* ObiWan
DNS "fail-safe" for Windows 2000 and 9X clients.
http://ntcanuck.com
Support and discussions forum
http://ntcanuck.com/net/board
408 XP/2000 tweaks and tips
http://ntcanuck.com/tq/Tip_Quarry.htm

 rilasciato?)
Quien sabe? Qualcuno su 
m...@sikurezza.org
 ce l'ha in mano: pare sia
stato rilasciato su un ciddi' da Cisco. Considerando chi e' "quel"
qualcuno direi che potremmo chiedere a un suo tesista se intercede
per noi :-)
Fabio

 per noi :-)
Se ti capitasse per le mani.... 


 Chissa' perche' ma ne ero certo ;)
Magari posto qualche risultato divertente. Forse saranno datato ma
sarei quasi pronto a scommettere che, ad anni di distanza, le cose
non saranno cambiate di molto.
Fabio

 Fortunatamente, possiamo fare a meno di intercessioni
Ottimo!
Ho finito ora di leggere il documento, e mi pare che non vi siano
novita' oltre a quelle gia' qui citate. L'unica degna di menzione e'
quella relativa alle estensioni tcp introdotte dalla rfc-1323, il
"window scaling", attraverso cui, nel caso peggiore, si riduce il numero
di pacchetti necessari per portare l'attacco, a 4.
Ma, nota il documento, pochi sistemi utilizzano tali estensioni,
generalmente quelli nelle LFN, "Long Fat Networks", reti dalla banda
molto ampia ma con ritardi notevoli (connessioni satellitari).
Ovviamente questo "mitigating factor" e' sfuggito ai redattori degli
articoli sensazionalistici.
Per il resto, il documento conferma le stime fatte e i problemi qui
riportati: da qualche secondo a qualche ora a seconda delle reti
coinvolte, problema di stimare la porta effimera. Viene anche riportata
la possibilita' eventuale di stimare l'ISN della connessione, per
ridurre lo spazio di probabilita', ma non sono state fatte prove in
proposito.
Comunque, al di la' del problema delle scaling windows, non e' possibile
ridurre piu' di tanto lo spazio di probabilita'; si sottolinea tuttavia
la minaccia costituita dalle reti di zombie, che possono mettere a
disposizione di un attaccante una banda equivalente anche una OC3.
+++
Ah, c'e' un aspetto curioso.
Il responsabile della sicurezza di Microsoft si era affrettato a
sottolineare che i sistemi windows non sono affetti da tale problema.
Guarda caso, nel documento c'e' una stima del numero di pacchetti
necessari sulla base dei parametri iniziali di default delle connessioni
nei vari sistemi operativi: dimensione iniziale della window, spazio
delle porte effimere, eccetera.
Beh, i sistemi microsoft sono i piu' penalizzati, perche' hanno una
finestra iniziale larghissima (64240, contro una linux di 5840 e una
cisco di 16384, per esempio) e un numero ridotto di porte effimere
da scegliere (un migliaio per windows, 32000 per linux, da 10000 a 48000
per i cisco)....
Insomma, ancora una volta Microsoft non si smentisce nel minimizzare i
problemi dei propri prodotti.


 sottolineare che i sistemi windows non sono affetti da tale problema.
<snip>
Momè ... non è per fare il "difensore d'ufficio" (ci mancherebbe altro)
però, se non ricordo male la comunicazione di MS era stata fatta in
relazione al "report" iniziale che indicava soltanto BGP ed in ogni
caso connex di "lunga durata" come sensibili al problema, detto
questo; mi sa che parecchia gente avrà bisogno di rimboccarsi
le maniche ed iniziare a patchare il patchabile :-)
Ciao