Newsgroup: it.comp.sicurezza.windows
Titolo: bypassare firewall

Sento spesso dire che un firewall č bypassabile. Come (dove trovo info)?
ZoneAlarm č bypassabile? Grazie

 info)? ZoneAlarm è bypassabile?
Si tratta di tecniche di hacking...non mi pare il caso...:)
-- 
PGP FP: B61A F1FA 9B99 A3BD 5D2B 6D99 8D3A 5C92 3525 3509

Dimmi almeno dove trovare info. Non mi interessa la parte pratica, vorrei
solo sapere come č possibile in teoria. In ogni caso, ZoneAlarm č
bypassabile oppure no?

 ZoneAlarm è bypassabile oppure no?
Info direi di partire dal sito per eccellenza che tratta hacking, 
ovvero 
www.astalavista.com
 e puoi approfondire anche su:
www.esecurityonline.com
www.securityfocus.com
www.ciberarmy.com
ce ne sono ovviamente molti altri, ma direi che per ora siano 
sufficienti.
Tecniche per bucare ZA? 
Diciamo (per quel poco che ne so...) che aggirare un firewallc 
onfigurato bene è estremamente difficile, oltretutto farlo per
ottenere qualcosa da un utente normale non ha molto senso.....
Diciamo che cmq ogni firewall ha dei punti di vulnerabilità, la
maggior parte di questi però è dovuta a cattiva configurazione
dello stesso..E' invece relativamente facile ottenere attacchi
di tipo DOS (non il sistema operativo! ma Denial Of Service)..
Una soluzione tipo di attacco riguarda l'incapsulamento ICMP
ovvero la possibilità di impacchettare dati reali nell'intesta-
zione ICMP di un pacchetto e questo è di norma sempre possibile
considerando che, sempre di norma, almeno ICMP echo reply e ICMP
reply sono sempre disponibili.....
Insomma.....forse sto andando oltre.....
ciao


 ZoneAlarm è bypassabile? Grazie
La tecnica è di sfruttare come cavallo di troia un programma che sia 
considerato 'autorizzato' dal firewall. Se il programma in questione 
permette di venir 'comandato' ad altre applicazioni ecco che il 
firewall potrà venir ingannato.
-- 
News2000 1.5ß Version 
http://socket2000.8m.com

 che il firewall potrà venir ingannato.
QUello che dici non ha nulla a che vedere con il bypassare un firewall,
tu aprli invece di lameraggio da strapazzo, cosa ben diversa...
Naa...


Un attacco Dos smurf non viene retto da nessun firewall, per esempio...

 
SI beh....mandare pacchetti echi agli indirizzi di broadcast non è
forse una finezza ma funziona :)


 ZoneAlarm č bypassabile? Grazie
Cercare fra i vecchi post no, eh?
-- 
Pierluigi De Rosa (
tho...@durin.khazad-dum.net
).
<<      LINUX: the choice of a GNU generation     >>
<<   For my real address... ask the Balrog.       >>
* Sostenete la Lega per la Soppressione dei Troll *

 tu aprli invece di lameraggio da strapazzo, cosa ben diversa...
Tu dici che così non è bypassare un firewall? Intendi dire che 
bypassare significa eluderlo completamente? Basta mettersi daccordo 
sul significato di bypassare... Sentiamo cosa intendi tu per 
bypassare, su.


 bypassare, su.
Nel momento in cui tu installi un server (un trojan) ed informi il 
firewall che la porta di quel server deve poter comunicare, in questo
caso non hai bypassato il firewall, ma hai creato una regola per 
esso...o forse mi sbaglio? Se invece il trojan in questione non è
stato messo volontariamente, il firewall quantomeno ti segnala una
connessione in listening su una certa porta.....i casi ora sono due:
1) sei consapevole che potresti prenderlo nel c*lo e ti piace..
2) non ne sei consapevole ma ignori anche la possibilità di imparare
   qualcosa...
dai non te la prendere :) i miei sono solo appunti....
ciao :)


 connessione in listening su una certa porta.....i casi ora sono due:
Un trojan non deve necessariamente rimane in ascolto... 


 considerato 'autorizzato' dal firewall), per fare le cosacce sue... 
Questa mi torna nuova...


> considerato 'autorizzato' dal firewall), per fare le cosacce sue... 
C'era un interessante articolo non ricordo dove, che spiegava come 
TUTTI i firewall soffrono di questo 'piccolo' problema.  A meno di 
non autorizzare ogni sessione tutte le volte o di blindare 
pesantemente le porte di ogni singolo processo autorizzato... C'era 
pure da scaricare un piccolo sorgente C...
eccolo qua... L'ho trovato.
..This program will penetrate every firewall currently on the market
that claims to offer "outbound" protection, because it does not send 
or receive data itself. Instead, it uses a hidden Internet Explorer 
window to do it. And, of course, everybody allows Internet Explorer 
to send and receive data, otherwise using the Internet would be a big
pain in the you-know-what...
http://tooleaky.zensoft.com/


 pain in the you-know-what...
Interessante...



Rimane solo un piccolo problema in questa trattazione....che il trojan devi
averlo a bordo...., mentre mi sembra che la domanda iniziale concernesse il
"bucamento" del firewall di un computer pulito...
Cazz..., se hai un trojan a bordo č come se blindassi la porta di casa e
mettessi la chiave sotto lo zerbino..
:-))
stinger

onfigurato bene è estremamente difficile, oltretutto farlo per
Se poi e' installato su un win98SE, e' una caxxata. Esperienza
personale (BTW, mi han pure risposto quelli della ZoneLabs,
rinviandomi al manuale di ZA stesso. ROTFL molto mogio)
-- 
HappyCactus - Registered Linux User #209744
http://utenti.tripod.it/happycactus
Cannot delete files, disk full. Try to delete some file.

firewall potrà venir ingannato.
Una parola di esempio: magistr.


Un trojan non deve necessariamente rimane in ascolto... 
Infatti, e l'attaccarsi ad un processo gia' autorizzato e' solo UNO
degli esempi...


 Se poi e' installato su un win98SE, e' una caxxata. 
Se devo proprio essere sincero con te a me risulta più facile con
w2k che non con w98.....ndr :)


w2k che non con w98.....ndr :)
Davvero? hai esperienza diretta? 
Ho provato su XP Pro e, impostando in una certa maniera ZA non
riuscivo ad "uscire".... mentre con w98se la cosa era banale, anche
con quell'opzione attivata (che peraltro non e' una opzione di
default...)


 Davvero? hai esperienza diretta? 
Ma no, ma cosa dici...io sono un bravo ragazzo sai :)) Infatti io non 
userei mai NAT per condividere risorse su w2k, men che meno userei un
client ldp...:)


 "bucamento" del firewall di un computer pulito...
Non diceva così la domanda. Chiedeva se zonealerm fosse bypassabile. 
Che senso ha bypassare un computer 'pulito' dall'interno? Oddio, 
forse ha senso dall'esterno, ma su questo punto è meno probabile di 
prima...


 [cut]
c'era anche un'altra cosa del genere ... ('whatsecurity' o qualcosa del
genere se non ricordo male)
Il problema e' che si tratta di trojan ... e' chiaro che riescano a
'penetrate *every* firewall on the market' ...
Comunque sia, la maggioranza dei personal firewall soffrono di qualche
bug piu' o meno noto. Esistono vari exploit cha vanno dal far crashare
il fw, al crashare dell'os e piu' pericoloso, non verificare le regole
d'autorizzazione. Questo per gli application filtering. Ma del resto
nemmeno i packet filtering non sono totalmente esenti da falle e non se
la stanno passando benissimo negli ultimi tempi ... (non so se avete
seguito alcune recenti discussioni)
Saluti,
Lord Knight
-- 
" Workaround / Solution:
  Disable Active Scripting and never turn it on.
  Better, do not use IE in hostile environments such as the internet. "
  Georgi Guninski's Advisory about IE (in)security ...

 (autorizzati) con l'algoritmo MD5 (o altro algo one-way).
Non centra nulla. L'eseguibile 'firmato' rimane inalterato, perchè il
trojan non lo modifica. Lo comanda... Quello di cui parli è un altro 
test che svolgeva un tool di Gibson, appunto per testare se il 
firewall 'firmasse' gli eseguibili o meno...


client ldp...:)
Io qualche esperimento sul mio ZA l'ho fatto, pensavo stessimo
parlando della stessa cosa...
Un HappyCactus che forse ha perso il filo


prima...
Ha senso: pensa ad una backdoor che "contatta" il suo creatore...


(autorizzati) con l'algoritmo MD5 (o altro algo one-way).
E ricalcolano la checksum ad ogni accesso ai socket? mi sembra un po'
pesante...
IMHO il problema e' che le API di accesso agli spazi di indirizzamento
dei processi sono liberamente accessibili...
HappyCactus che la soluzione ce l'avrebbe, forse...


 Un HappyCactus che forse ha perso il filo
NO no..è che ogni tanto mi lascio andare.....:)


 Ha senso: pensa ad una backdoor che "contatta" il suo creatore...
Oddio. allora il computer non è 'pulito', convieni?


 pesante...
Non, solo al PRIMO accesso durante la stessa sessione.


 
La firma dell'eseguibile protegge dalla sostituzione completa o dalla 
modifica dei singoli file, non può rilevare il fatto che un altro 
processo ha inserito un hook dentro l'eseguibile a runtime (senza 
modificarne in alcun modo il binario) o ha registrato un estensione 
invisibile(IE, ad esempio, permette di aggiungere barre di ricerca e 
altri "accessori" che sono gestiti tramite oggetti COM) che verrà 
caricata e potrà accedere ai socket utilizzando lo stesso processo. 
Oltre all'eseguibile principale andrebbero quindi firmate anche tutte 
le DLL che possono essere caricate a runtime e che non devono 
necessariamente essere caricate all'avvio o prima di effettuare una 
chiamata ai socket.
Oltre a firmare i singoli moduli (e magari intercettare le chiamate a 
LoadLibrary/Module) è necessario un controllo (periodico o a ogni 
richiesta di connect) sull'elenco dei moduli caricati poichè, come 
dicevo prima, è possibile "iniettare" una propria DLL all'interno dello 
spazio di indirizzamento di un altro processo.
Un trojan particolamente furbo poi potrebbe "redirigere" le chiamate 
alle API effettuate dal processo-firewall (tutte le API sono funzioni 
importate da DLL) e, ad esempio, far puntare le CreateFile indirizzate 
all'eseguibile "truccato" a una copia dell'originale per fare in modo 
che i checksum rimangano sempre corretti.
-- 
Valter Minute
min...@inwind.it
 (the reply address of this message is invalid)

Oddio. allora il computer non è 'pulito', convieni?
Uhm, si. :)


Non, solo al PRIMO accesso durante la stessa sessione.
Intendi una sorta di "stateful inspection", pero' relativa
all'immagine del sorgente? mi sembra comunque pesante, immagina
applicato ad un client web che non supporti la connection
keep-alive... 
Anche se, in effetti, funzionerebbe...


che i checksum rimangano sempre corretti.
Naturalmente occorre che il processo FireWall sia nato "a monte" del
processo trojan, altrimenti casca tutto a catafascio!


 
Il processo trojan può anche partire dopo il firewall, deve solo 
"agganciarsi" al FW prima che il processo "infettato" faccia una 
qualsiasi richiesta di connessione e se ha sostituito completamente 
l'exe questo non dovrebbe essere un grosso problema.
A meno che il FW non controlli tutti i processi attivi (ma in questo 
caso dovresti "validare" tutti gli exe che possono essere in 
esecuzione...).
Ovviamente su win9X è tutto molto più semplice che su windows NT/2000 
dove il firewall potrebbe essere un servizio e l'utente che esegue il 
trojan potrebbe non avere diritti da administrator.


trojan potrebbe non avere diritti da administrator.
Si, in un mondo perfetto. Se tutti usassero 2k da users, anziche' da
admin, le infezioni da virus come magistr sarebbero MOOOLTO minori...
Ma, si sa, non si puo' cavar sangue dalle (teste di) rape.


 
Non è necessario modificare lo spazio di indirizzamento per agganciarsi 
a un processo (se non redirigi le chiamate alle DLL) e credo che le 
funzioni di hook non siano intercettabili se non da dentro il processo 
"attaccato" (ma su questo potrei sbagliarmi).
Tieni però presente che rimane il caso di oggetti COM caricati in modo 
legittimo (vedi l'esempio delle barre).
Senza contare che è possibile che un processo "cattivo" si sostituisca 
a un oggetto COM regolare (ma questo lo puoi evitare facendo lo scan di 
tutti i moduli).


DLL che caricano IE o Outlook).
Scusa depends è un programma di WinZozz o.... ?

tutti i moduli).
Appunto, a questo dovrebbe servire l'integrity check iniziale...
Comunque, IMHO, la soluzione sarebbe quella di "Blindare" quanto piu'
possibile le API "pericolose", fornendo a Win98 quei controlli che
sono stati implementati su NT/2k...
[1] In realta' l'indirizzo di ritorno, per cui mi sovviene un
ulteriore metodo per aggirarlo....


mirkot...@libero.it
 (Realtebo) wrote in
news:3c56d921...@powernews.libero.it
: 

E' un programma per windows e riporta (c) microsoft (se è quello che 
intendi con WinZozz).
Per maggiori info: 
http://www.dependencywalker.com/


 
Il problema, soprattutto nel caso di un'applicazione estremamente 
modulare come IE, è che blindare troppo rischia di impedire alcune 
funzionalità (già mi vedo gli utenti imbufaliti perchè non funziona la 
barra di google :)).


barra di google :)).
In effetti io pensavo solo di blindare certe API: la openprocess, ad
esempio, e la virtualnonmiricordocosa()... ;)


 Anche se, in effetti, funzionerebbe...
POtrebbe limitarsi a controllare gli attributi del file, data, ora, 
etc...


 
Non preoccuparti, gli script kiddies si sono già addormentati due 
messaggi fa :)
Comunque, se per indirizzo "valido e buono" intendi un indirizzo di 
ritorno che non provochi comportamenti anomali (non necessariamente GPF) 
del programma "ospite", diventa evidente che il trojan è vincolato 
pesantemente alla versione del programma stesso.
Al limite continuiamo via e-mail.


etc...
Troppo facilmente taroccabili.


 Al limite continuiamo via e-mail.
Perche'?
Mi sembrate assolutamente IT.
O avete qualcosa contro la full disclosure? :-)
(come tu giustamente dicevi, questa non e' roba da kiddies)

Al limite continuiamo via e-mail.
Volentieri, il mio indirizzo e' <quasi> valido,
happycactus(at)genie(punto)it


 
In realtà si tratta di "mascherare" una CALL usando l'istruzione RET 
della funzione winsock come salto per richiamare una funzione che sai 
già essere innocua.
Avere l'indirizzo della window-procedure è molto semplice ed 
effettivamente si potrebbe preparare lo stack per passargli un WM_NULL 
o altro messaggio innocuo che può essere "digerito" dalla wnd procedure 
senza troppi problemi.
Non è però detto che le chiamate a winsock arrivino dallo stesso modulo 
che contiene la window procedure. 
E' comunque vero che questo giochino permetterebbe di realizzare trojan 
più indipendenti dalla versione dell'eseguibile e di ingannare il check 
del singolo modulo.
Altra soluzione potrebbe essere quella di far puntare l'indirizzo di 
ritorno a una RET trovata "a caso" dentro il modulo che richiama la 
winsock (anche se in questo caso il trojan dovrebbe analizzare 
l'eseguibile del modulo da usare come "chiave").
Queste considerazioni rendono quindi impraticabile l'ipotesi di fare un 
check solo del modulo chiamante e riportano alla necessità di fare un 
check completo di tutti i moduli caricati (lento e complicato).
Senza contare che eventuali controlli di questo tipo potrebbero rompere 
le scatole a programmi che eseguono operazioni di questo tipo per scopi 
assolutamente leciti. 
ATL, ad esempio, esegue il "thunking" delle window procedures creando 
in memoria il codice necessario a sostituire sullo stack l'HWND della 
finestra con il puntatore "this" della classe collegata e richiamare la 
wndproc virtuale. E' un metodo sicuramente non elegantissimo (anche se 
bisogna mettersi d'accordo sul concetto di eleganza :)), ma molto più 
efficace del metodo "tradizionale" di memorizzare il puntatore nel long 
GWL_DATA e recuperarlo ad ogni messaggio (cosa che rende impossibile, 
tra l'altro, il subclassing, se non ricorrendo alle properties che però 
sono ancora più lente di GetWindowLong...).


sono ancora più lente di GetWindowLong...).
Vabbe', capirai... neanche windows fosse un realtime...


 
Questo è vero, ma ATL è supportato anche per windows CE che è realtime.
Penso che, quando non introducono possibili problemi di stabilità o 
complicazioni inutili del codice, questi "trucchi" abbiano una ragion 
d'essere; soprattutto in un framework generico (che potrebbe anche 
essere utilizzato in contesti dove le prestazioni "velocistiche" sono 
importanti).


importanti).
Il problema e' che il "trucco", essendo tale, non ha garanzia di
funzionare su sistemi futuri, e anche il supporto da parte della casa
madre nelle versioni successive del S.O. non da' garanzia che non
generi una qualche falla nella sicurezza, IMHO.


 
Il trucco di ATL non presenta questi problemi, credo. E limitare la 
possibilità di generare codice in memoria ed eseguirlo (come fa ATL) 
renderebbe impossibile la vita alla JVM e al CLR di .net...


renderebbe impossibile la vita alla JVM e al CLR di .net...
Si, senza dubbio lo renderebbe piu' complesso. La compilazione JIT,
come ti ho spiegato prima, IMHO non e' un problema, il CLR di .net non
lo conosco ma credo che oramai anche i sassi sappiano come la pensa
HappyCactus a tal riguardo! ;)
ciao


 
I miei problemi con JBuilder riguardavano soprattutto l'instabilità 
dell'IDE, i tempi bibilici di rebuild (e spesso non rebuildava in modo 
corretto ed era necessario dare un rebuild-all) e il ritardo 
nell'aggiornamento a JDK 1.2 e 1.3 e relative classi.
[.net]


corretto ed era necessario dare un rebuild-all) 
beh, si, la ide e' paurosa, in effetti.
Giusto l'altro giorno ha deciso di caricarmi un file vecchio,
sostituendo quello nuovo che stavo editando... facendomi perdere ore
di lavoro... 
E poi mi sa che son molto lenti con le patch...


 
Con utenti diversi?
[borland...]


Con utenti diversi?
Si, almeno... io non sono stato in grado di farlo funzionare
decentemente. Premetto che l'ho usato pochissimo, e magari l'ultima
versione di ZA evita il problema (mi pareva fosse la 2.6 e
qualchecosa)... In ogni caso venivano visualizzati talvolta gli alert
sui desktop sbagliati, per cui il PFW andava in blocco... sembrava una
condizione simile ad una race condition, ma non ho approfondito troppo
la cosa...


Sto attentamente seguendo questo scambio fra te e Valter Minute e devo
ammettere che avevo sottovalutato la competenza di alcuni di voi, competenza
che valuto veramente molto molto elevata.
Complimenti.
Volendo indicare un buon testo per lo studio del C++, ad uno che comunque
conosce il C ed un po di Assembler, cosa consigliereste ?
Saluti.

conosce il C ed un po di Assembler, cosa consigliereste ?
Io ho studiato il Lipmann, ma ti consiglio vivamente solo la versione
inglese, perche' quella italiana ha una traduzione orripilante....
(BTW, conosco chi ha collaborato ad essa... BRRR!)
Il libro pero' non e' un gran che', e' abbastanza confuso in certi
aspetti.... sinceramente ora come ora non me ne vengono in mente
altri...


 
"Thinking in C++" di Bruce Eckel.
Lo puoi scaricare da 
www.eckelobjects.com
.
Se non ti piace, perlomeno non potrai accusarmi di averti fatto buttar 
via dei soldi :)
