Re: Executable code was detected

> > quindi non soffre delle limitazioni di cui parli
>
> Non vero.

Riporto testualmente la frase di koba a cui mi riferivo:

koba> Uno dei (vari) grossi limiti di snort (e di altri ids) e' che non
koba> segue il flow del traffico, si limita ad analizzare i singoli
koba> pacchetti                                ^^^^^^^^^^^^^^^^^^^^
      ^^^^^^^^^
Koba dice che snort analizza i singoli pacchetti e la mia risposta era
riferita a questa affermazione, non al fatto che, comunque, un nids fa
un riassemblaggio che potrebbe non essere lo stesso fatto dagli host a
cui il traffico e' diretto. Snort non analizza i singoli pacchetti, a
meno che non venga configurato per farlo. Che sia soggetto a possibili
azioni di evasione e inserzione, poi, e' un problema diverso.

> all'IDS arrivi qualcosa che per esempio si legge "ATTrACCO",facendo in
> modo che il pacchetto contenente la lettera r arrivi soltanto all'IDS

"insertion".

> giocando con le flag del TCP. Per esempio č molto difficile che gli IDS di
> rete perdano tempo a controllare i checksum dei pacchetti,

E' vero, ma snort dovrebbe controllare i checksum, AFAIK, ma non l'ho mai
testato. Anzi... appena ho un attimo libero...

> 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

L'effettivita' di questo attacco (TTL) contro snort dipende piu' dalla
perizia di chi lo implementa che non da limitazioni del nids (min_ttl,
ttl_limit).

> troppo grande con attivato il flag "don't fragment",

E' un'attacco facilmente identificabile con una regola (dsize, fragbits,
noto l'MTU del percorso) ma potrebbe portare a vari falsi positivi. In
ogni caso il motore pattern matching non vedrebbe il contenuto del
traffico. Potrebbe essere nella wishlist di stream4 (una opzione del
tipo max_path_mtu=1500).

> sfruttare campi di
> opzione o timestamp strani o malformati per sfruttare le ambiguitā che
> esistono nelle implementazione degli stack TCP su vari sistemi operativi.

Qui c'e' poco da fare, penso. Un nids non puo' riassemblare il traffico
come farebebro "tutti" gli stack. Al limite si potrebbe pensare ad un
tuning del nids per tenere conto delle caratteristiche delle implementazioni
tcp/ip delle singole macchine monitorate, ma penso che nessuno abbia una
feature come questa. O, no?

> 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.

Yez. Come sopra.

> Č 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.

D'accordissimo.

In ogni caso tutta la precedente digressione, seppur di grande interesse,
non mi sembra che abbia attinenza con il caso in questione.

> > 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",

Non proprio. L'alert viene... uhmmm... triggerato? (che schifo, ma non mi
viene in mente altro :-)) ah, eccco: _attivato_ dalla semplice presenza di
24 caratteri 0x43 ("C") consecutivi nel payload tcp. Quel che c'e' prima e
quel che c'e' dopo non viene preso in considerazione. Con la sua conf puo'
anche essere stata una semplice pagina web con scritto CCCCCCCCCCCCCCCCC \
CCCCCCCCCCCCCCCCCCC (non le ho contate).

Il problema e' una scorretta customizzazione: se $SHELLCODE_PORTS fosse
stata settata correttamente non si avrebbe avuto quel falso positivo, per
lo meno con la revisione 3 del sid 1390. Non ho sotto mano le revisioni
precedenti.

> 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

Si, ma questo non mi sembra che risponda alla mia domanda. Il fatto che
il traffico sia piu' o meno riassemblato come puo' modificare il giudizio
su quell'alert? E poi dove hai letto che lui non ha niente che ascolti
sulla 1344? ;-)

Sono d'accordo che quello probabilmente e' un falso positivo: non ho
molta esperienza pregressa ma nel 90% dei casi in cui mi hanno sottoposto
alert di quel genere si trattava sempre di qualcuno che scaricava exploit
precompilati da qualche sito ;-). E di solito era il sistemista stesso.
In questo caso ci sono anche possibilita' piu' banali (pdf).

Questo non significa, comunque, che non valga la pena di indagare su
cosa sia successo. Questo per diversi motivi. Uno e' che cosi' salvatore
prende maggior famigliarita' con questi aspetti. Un'altro e' che se io
beccassi un mio utente a scaricare exploit gli chiedererei conto, come
minimo, di quello che sta facendo, visto che non e' conforme alle policy
aziendali. Un terzo perche' una situazione del genere puo' verificarsi
in uno scenario in cui un'attaccante ha gia' preso il controllo della
macchina con iis e sta scaricando il codice per attaccare, da li, una
seconda macchina, interna alla rete o esterna. Quest'ultimo scenario e'
il meno probabile (per vari motivi) ma non vedo perche' non verificare.

> Inoltre, se dal web server tipicamente si scaricano programmi eseguibili,
> quel messaggio saltera' fuori a rotta di collo.

A parte i problemi di customizzazione a cui ho fatto un cenno prima, a
me non e' mai successo. E se guardi il pattern penso che converrai che
non sia molto frequente negli eseguibili, mentre e' frequente nei
postscript e nei pdf, ad esempio (per rimanere nel campo dei file che
solitamente si "scaricano da internet").


Fabio


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