Newsgroup: it.comp.sicurezza.varie
Titolo: Ack-tunnelling

Ultimamente ho avuto il tempo per giocare con un nuovo modo per fare
tunnelling. Tunnelling non e' una cosa nuova, ICMP tunneling per esempio e'
una tecnica abbastanza 'antica'. Ecco perche' la maggior parte dei FW sono
configurati per bloccare ICMP Type 8 al Gateway. Tuttavia ci sono nuovi
metodi che a mio avviso, meritano la dovuta attenzione. Se vi dicessi che un
client puo iniziare una comunicazione con il server senza inizializzarla con
un syn packet(non e' udp, o icmp), ma semplicemente attraverso TCP segments
con la flag settata to ACK, mi credereste? Immaginate costruire un trojan la
cui comunicazione tra server e client e' basata su questa tecnica. Come
avete i vostri FW configurati? Bloccate tutte le connessioni (syn packets)
dall'esterno verso l'interno? Il problema e' che molti firewalls assumono
che un pacchetto con la flag settata a ACK fa parte di una comunicazione gia
inizializzata e quindi lasciano passare il pacchetto liberamente. Stesso
comportamento l'ho notato perfino su alcuni FW che utilizzano stateful
packet inspection. La ragione per cui questi firewalls lasciano passare i
ACK packet senza esaminarli e' dovuta a problemi di 'sovralavoro'. Infatti
in una standard TCP connection abbiamo un pacchetto con il syn flag, uno con
il syn-ack e poi centinaia se non migliaia di pacchetti con ACK. Se
dovessero essere esaminati tutti i pacchetti, il FW inizierebbe a fare
'fumo'...Morale della favola: be' quella trovatela voi... :-)
Per chi e' interessato all'argomento ci sono alcuni ottimi websites
facilmente raggiungibili via google.
Tony
--------
"They say you cant beat the system, then i'll just go around it"

ams67(kiwi) wrote:
[SuperCut]
Interessante...
Anche se non ho capito perche' un kernel con un'implementazione dello
stack TCP/IP fatta decentemente debba passare in spazio utente un
pacchetto Ack non appartenente ad una connessione TCP gia' stabilita...
anzi una connessione mai stabilita ^___^
Almeno a livello teorico, un tale pacchetto Ack dovrebbe essere scartato
dal
kernel e non raggiungerebbe mai l'applicazione. 
A meno che il trojan in ascolto riesca a catturare il pacchetto in modo
simile  ad uno sniffer (su Linux non sarebbe neanche tanto difficile...
con le
librerie giuste ^__- )
Ciao!
-- 
gen. Trimack aka gen. Puzzerstoven 
Per favore non mandatemi allegati in Word o PowerPoint.
Si veda 
http://www.fsf.org/philosophy/no-word-attachments.it.html
 
IAFo #196 -- Linux Registered User #274161

 liberamente. Stesso
Mh... A me se mi mandi un ACK il firewall non lo lascia passare...
Cioe', lo droppa placidamente (essi', ho deciso che non controllo le
connessioni che secondo lui sono gia' su, sono pigra :P)
-- 
   => Don't Let Your Fears Stand in The Way of Your Dreams !!! <=
   URL: 
http://www.delymyth.net/
 ~ E-Mail: 
DEly...@despammed.com
            => ICQ#: 8761263 - MSN: 
dely...@msn.com
 <=
          => FREE! Hardware Anti-Virus!!! - /dev/brain <=

 'fumo'...
Questo e' uno dei motivi per cui la stateful inspection diminuisce il
carico dei firewall ma anche in questo caso non e' che il traffico in
arrivo con il solo flag ACK non viene guardato: il fw verifica se non
appartiene ad una sessione established. Se appartiene ad una sessione
il pacchetto passa (il modo in cui viene valutata l'appartenenza alla
sessione varia da firewall a firewall). Se non esiste una sessione il
pacchetto viene comunque valutato in base alle acl.
Fabio

 pacchetto viene comunque valutato in base alle acl.
Esattamente, il punto e' cosa si intende per session. Per chiarire meglio la
questione ti riporto la session generata dal client/server (customizzati):
10.1.1.2 = client
10.1.1.4 = server
Il server listens port 80
Il client port 1054
Il trojan apre un command line sul server. I quattro paccketti sono stati
generati quando ho digitato un dir sul command line generato dal server.
La cosa che non ho capito e' che quando digito ed eseguo il command line dal
client: c:/client.exe Server_IP_Address, ed ottengo cosi' la remote shell,
niente viene segnalato dallo sniffer. Sembra come se la connessione non
avvenisse. L'unico modo per ottenere un output dallo sniffer e' solo
attraverso l'esecuzione di qualche comand nella remote shell (e.g. dir)
1 0.000000 10.1.1.2    10.1.1.4    HTTP    Continuation
2 0.000058 10.1.1.4    10.1.1.2    TCP       1054 > http [RST] Seq=101058054
Ack=101058054    Win=0 Len=0 (DA NOTARE il Reset)
3 0.022829 10.1.1.4    10.1.1.2    HTTP    Continuation
4 0.023261 10.1.1.2    10.1.1.4    TCP       htto > 1054 [RST] Seq=101058054
Ack=101058054    Win=0 Len=0
Ah, dimenticavo che mi hai richiesto un esempio di FW; bene, FW1 failed to
detect and block the trojan comunication. Ma come giustamente hai fatto
notare, tutto dipende da come e' configurato, anche, per quanto ne sappia,
la sua configurazione base e' tipica...
Il motivo iniziale del mio post era quello di vedere se c'era gente
interessata all'argomento. (E' inutile scrivere un post di molte linee se
poi nessuno se ne frega).
Il motivo per cui sto analizzando questo nuovo tunneling technique e' perche
sembra che si tratti di un nuovo metodo per aggirare i FW. Nuovi
worms/trojans potrebbero implementare la tecnica.
Cheers
Tony


worms/trojans potrebbero implementare la tecnica.
E gia', <gibson>con l'accesso raw disponibile in XP</gibson>...
Leonardo
-- 
Questo messaggio e' NAGWARE. Per disattivare frecciatine, giochi
di parole, volgarita' gratuite ed inviti a rileggersi i messaggi
gia' passati e/o consultare 
http://groups.google.com
, effettuare
un versamento di 25 euro come tariffa di registrazione helpdesk.

 E gia', <gibson>con l'accesso raw disponibile in XP</gibson>...
Gibson? No man, niente a che fare con lui. Per firewall non sto parlando di
Zone Alarm e di micro probes (o come li chiama lui)...
Prova a dare una occhiata al seguente link a patto che sarai tanto gentile
da spiegarci come avviene la connessione server/client (non mi pare che
www.grc.com
 appare tra i links)
http://www.google.co.nz/search?q=ACK+tunneling&ie=UTF-8&oe=UTF-8&hl=en
PS Hey, non stiamo facendo una gara a chi ne sa di piu'. La perderei
comunque con te (in molti settori IT). L'intenzione e' di capire ed
imparare.
PS2. Speriamo di non suscitare le ire dei seguaci ;-)...
Tony
--------


 la cpu o la ram.
Su questo ho i miei dubbi. Chiaramente dipende molto dall' Hardware a
disposizione.
--
Tony
--------


 Rotfl.
Bene, ridere fa bene alla salute!
Tony
--------


 del firewall piuttosto che la banda?
Bene, giocare, questo e' lo spirito giusto...
Anche questo dipende dall'hardware e dal tipo di attacco. Con un DDoS tutti
gli elementi da te citati sono relativi. Se hai un centinaio/migliaio di
'zombies' che puntano sul tuo povero firewall, c'e ben poco da fare, a parte
che mitigarlo attraverso il tuo border router o con l'aiuto dell ISP.
Tuttavia come ho detto al maresciallo Leonardo, il punto della questione non
e' come proteggersi da DoS diretti al FW, ma e' di capire come quel
client/server connection basata su ACK packet funzioni. E di nuovo vorrei
precisare che Gibson non c'entra nulla. Dopottutto mi e' completamente
'scaduto' da quando si e' arreso al diabolico 13enne, facendo diventare
l'Internet come il futuro luogo della Apocalisse.


 mi scappa da ridere.
No offense taken :-)
Comunque ridera fa veramente bene alla salute...

 analizzare uno a uno per poi decidere di scartarlo.
Non sono d'accordo:
l'analisi in questi termini può essere fatta semplicelente sulla validità
della connessione. Se il flag di ACK non è abilitato a creare uno state,
il tuo ACK viene scartato semplicemente come non appartenente ad alcuna
connessione, così come avverrebbe nel caso generico di un attacco per un
qualsiasi altro flag. 
Il carico in questo caso è piuttosto basso, e floodare di ack non ha
molte differenze rispetto a floodare di syn (per le porte chiuse si
droppa in ogni caso).
Altro discorso sarebbe se tu usassi pacchetti con ip e porte (sia
sorgenti che destinazione) appartenenti a sessioni validate per
trasmettere del traffico "stealth". In questo caso la discriminazione la
farebbe il check sulla sincronizzazione della sessione (a la pf, per
intenderci...).
Ma se hai i diritti per mettere in piedi una sessione valida, è meno
faticoso tunnelizzare dentro quella...
Se non sbaglio i conti, ve' ;-)
-- 
Emanuele Balla aka Skull
-----------------------------------------------------------------------
Besides, I think [Slackware] sounds better than 'Microsoft', don't you?
(By Patrick Volkerding)

 Nuovi worms/trojans potrebbero implementare la tecnica.
Prova a descrivere uno scenario (topologia di rete e acl del firewall)
in cui un trojano come questo funzionerebbe, mentre uno "tradizionale"
si dovrebbe arrendere di fronte al muro di fuoco. Ovviamente, firewall
stateful, se no e' evidente come questi trojani possano essere usati.
Fabio

consono (#Synk4 0 target target 80 80).
No, no. Ferma. Intendevo dire: il carico necessario ad analizzare gli
ACK non e' una cosa fuori dal mondo.
Poi sono sicuro che ci siano firewall che si fanno prendere allegri e
pimpanti per il naso. Un sistema divertente lo sto sperimentando ora,
in effetti - una cosa un po' contorta, ma in grado di far danni senza
farsene accorgere.
E' una partita a scacchi, dopotutto.


 state INVALID,NEW reject-with tcp-reset
sul firewall (che quindi necessiterà di un TCP completo e stateful 
inspection)? o sulla macchina? perchè credo la premessa sia che la 
macchina è stata compromessa. Quindi chissenefrega che TCP non lo 
permette, se abbiamo rootato la macchina lo possiamo togliere e 
metterne un altro. Ricordo un rootkit per Windows che permetteva di 
aprirsi una sessione telnet connettendosi *ad una qualsiasi porta* 
della macchina compromessa, tanto per darti un'idea
Il punto è di far passare comunicazioni "strane" (password utente, 
ecc.) da $ROOTED_BOX a $EVIL_HACKER senza che il firewall se ne accorga
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.20. C, C++ and ASM developers
                              and beta testers are welcome!

 stateful, se no e' evidente come questi trojani possano essere usati.
http://ntsecurity.nu/papers/acktunneling/
Troverai anche il client/server.
PS l'antivirus lo blocca come trojan ovviamente...
Tony
--------


 PS2. Speriamo di non suscitare le ire dei seguaci ;-)...
No problem, questi thread sono proprio quelli che m'ingrifano :-) E penso
lo stesso per altri, qui.
-- 
"Ehi, fratelli. Qui c'e' scritto che c'e' anche il tempo per combattere".
SETI@home: 148WU/8233hrs on a P166MMX :-)
SecurFaq             : 
http://securfaq.usenet.eu.org
Biancorossi Siamo Noi: 
http://www.tifonet.it/free/ancona/

> 
http://ntsecurity.nu/papers/acktunneling/
Ok, penso di aver capito: l'attacco con questo tool (ed altri analoghi)
si basa sullo sfruttamento delle acl dei firewall non-stateful che, nel
caso in cui debbano consentire lo stabilirsi di connessioni tcp o l'uso
di udp dall'interno della lan protetta all'esterno, devono accettare in
ingresso tutti gli ACK provenienti almeno da un certo numero o range di
porte e diretto verso porte > 1024. Con firewall stateful correttamente
configurati questo trojano e' inefficace, in quanto il pacchetto ACK in
ingresso deve avere uno stato per poter essere accettato. Nulla toglie,
ovviamente, che questa sia una possibilita' in piu' da sfruttare quando
ci siano condizioni favorevoli per la sua applicazione.
Fabio