Re: Executable code was detected

> Non capisco cosa intendi dire e come la cosa sia correlata all'alert
> in questione. Nel senso che snort riassembla i flussi tcp

Yes


> e puo' separare le conversazioni e
> quindi non soffre delle limitazioni di cui parli

Non vero.

In linea teorica osservando tutto il traffico di rete dovrebbe essere
possibile, per un sistema arbitrariamente potente, tenendo conto della
topologia della rete e di tutte le particolarità delle macchine che la
compongono, tenere una finestra indefinita su ogni comunicazione e avere "la
comunicazione" integra.

A parte le numerose assunzioni semplificanti, questa soluzione non e' certo
la panacea di tutti i mali: come è stato dimostrato da numerosi ricercatori
può essere molto difficile se non impossibile stabilire in un punto della
rete esattamente quali dei pacchetti visti raggiungeranno un altro punto.
Su questo principio si basano i due attacchi speculari di inserzione ed
evasione dei pacchetti.

Il primo tipo di attacco sfrutta quest'idea: se l'IDS è tratto per dare
l'allarme quando osserva, per esempio, la stringa "ATTACCO", una delle
possibili soluzioni è quella di spezzettare questa stringa di modo che
all'IDS arrivi qualcosa che per esempio si legge "ATTrACCO",facendo in modo
che il pacchetto contenente la lettera r arrivi soltanto all'IDS e non al
sistema attaccato. Questo si può ottenere, ovviamente in casi particolari,
giocando con le flag del TCP. Per esempio è molto difficile che gli IDS di
rete perdano tempo a controllare i checksum dei pacchetti, e un attaccante
potrebbe prendere vantaggio di questo.  Altre ambiguità su cui si potrebbe
giocare solo il campo TTL (che potrebbe essere grande a sufficienza per
raggiungere l'IDS ma non il sistema bersaglio), utilizzare un pacchetto
troppo grande con attivato il flag "don't fragment", sfruttare campi di
opzione o timestamp strani o malformati per sfruttare le ambiguità che
esistono nelle implementazione degli stack TCP su vari sistemi operativi.

Un'ulteriore problematica deriva dalla possibilità che gli attacchi vengano
dispersi in più pacchetti mediante l'uso della frammentazione.  Ormai tutti
i principali IDS di rete hanno affrontato questo problema, ma la
ricostruzione di pacchetti frammentati si è rivelata un problema più
difficile del previsto, oltre a richiedere un dispendio di risorse poco
compatibile con le moderne esigenze di performance.  Infatti si sono notate
numerose incongruità nel modo in cui i vari stack TCP/IP affrontano i
problemi di frammenti non perfettamente rispondenti alle specifiche.

È insomma impensabile cercare di indovinare tutte le possibili
interpretazioni del flusso di pacchetti basandosi su informazioni variabili
quali la topologia della rete e tipi di sistemi in uso.

> come la presenza (o mancanza) di una analisi del flusso del traffico
> possa portare a una diversa interpretazione di questo alert.

L'idea che sta alla base di quell'alert e': "ho visto un NOP seguito da
codice macchina in questo pacchetto", e sappiamo tutti che i NOP sono usati
negli attacchi di buffer overflow perche' consentono di non dover "mirare"
esattamente il punto di esecuzione.

Tuttavia, se sulla porta 1344 non gira un servizio di rete, in realta',
sarebbe un BOF ben strano, ti pare ? Inoltre, se dal web server tipicamente
si scaricano programmi eseguibili, quel messaggio saltera' fuori a rotta di
collo.

Stefano "Raistlin" Zanero
System Administrator Gioco.Net
public PGP key block at http://gioco.net/pgpkeys


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