Newsgroup: it.comp.sicurezza.unix
Titolo: SHELCODE X86

Ciao a tutti
La mia sonda SNORT rileva spesso degli: "SHELCODE X86 UNICODE NOOP".
Di cosa si tratta, c'č qualcuno che č cosě gentile da spiegarmelo?
Grazie
Alfredo
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 Di cosa si tratta, c'è qualcuno che è così gentile da spiegarmelo?
E' un alert che viene attivato da una regola del gruppo shellcode.rules
che cerca un pattern utilizzato come NOOP negli shellcode. 
Le regole di questa classe possono attivare facilmente falsi positivi a
causa dello snort.conf di default, dove alla variabile $SHELLCODE_PORTS
viene asssegnato !80: in questo modo viene scansionato alla ricerca dei
pattern NOOP anche il traffico generato dai "download" dei tuoi client,
che potrebbero contenere quelle sequenze di byte ma non shellcode o che
potrebbero scaricare anche binari contenenti shellcode facendolo con la
consapevolezza di farlo >:->. Per ridurre il numero dei falsi positivi,
dovresti assegnare a $SHELLCODE_PORTS il valore delle porte che usi nei
tuoi server, limitando gli alert a possibili shellcode iniettati in uno
di questi (seppur tagliando via i possibili exploit diretti ai client).
L'altra alternativa e' assegnare any alla variabile, guardando tutto il
traffico e accettando un maggior numero di falsi positivi da analizzare
a posteriori. Una cosa e' certa: se hai dei server la configurazione di
default e' proprio quella piu' inutile: puo' generare falsi positivi ma
non "protegge" il server.
Se vuoi analizzare un po' piu' a fondo questo traffico, puoi pensare di
patchare quelle regole aggiungendo la direttiva tag, che ti consente di
avere un dump piu' esteso del traffico che ha generato l'alert e quindi
di poter vedere meglio cosa e' successo.
Quello che dovresti fare ora e' analizzare il dump del pacchetto che ha
generato l'alert in base a protocollo, porte, ip, ora, ecc. e vedere se
e' compatibile con lo scaricamento intenzionale di qualcosa da parte di
un client oppure l'upload intenzionale di qualche cosa su un tuo server
(compatibilmente con la tua impostazione di $SHELLCODE_PORTS).
Fabio

 di poter vedere meglio cosa e' successo.
A questa cosa non avevo proprio pensato, anche perchč sono un rospetto
con lo snort...
Per il momento ti ringrazio per i tuoi preziosi (come semopre) consigli!


 qualcosa? Un codice di un attacco? Bohhh
Scusa, l'avevo dato per scontato. Quando si usa un exploit per bucare
un server vulnerabile ad un attacco del tipo "buffer overflow" spesso
si inserisce una serie (sled) di NOOP prima della parte di codice che
attua le operazioni desiderate (lo "shellcode", in generale). Il NOOP
e' una istruzione che in un eseguibile non fa... niente, ma viene qui
inserita per semplificare la scritura d'un exploit (per dover "mirare
il return code" meno accuratamente e, gia' che ci siamo, per riempire
il buffer) [1].
Snort cerca d'intercettare un attacco BOF cercando queste sequenze di
istruzioni NOOP, la cui presenza nel normale traffico e' generalmente
poco comune ed e' spesso sintomo del passaggio d'un exploit di questo
tipo. Nondimeno e' possibile avere falsi positivi qualora il traffico
legittimo contenga queste sequenze per altri motivi o quando l'utente
stesso stia scaricando degli exploit binari precompilati (in funzione
della conf, come da post precedente).
Fabio
[1] una trattazione piu' esaustiva di questi dettagli va un po' oltre
    i contenuti del thread, ma si trova diverso materiale in linea. E
    poi non penso d'essere in grado d'andare oltre un certo dettaglio
    :-)

 il buffer) [1].
Piu' precisamente:
<Puntualizza>
e' una sequenza di istruzioni che oltre a non far niente e a riempire il
buffer, non contiene caratteri 0
</Puntualizza>
 :-)
Ciao
 Max

 </Puntualizza>
Si, certo: in genere uno 0x00 non deve essere presente in nessun punto,
altrimenti potrebbe essere preso per un fine stringa. Questo ha creato,
per molto tempo, la convinzione che nelle stringhe in unicode non ci si
potesse mettere codice eseguibile. E' una regola di validta' abbastanza
generale e, come tutte le regole, ammette anche le eccezioni: se cerchi 
"venetian exploit" vedrai che non e', poi, cosi' sempre vero :-) ... e,
quindi, hanno pensato bene di creare quella regola di snort.
Fabio

     :-)
Mi associo :)
Spero di non aver detto cacchiate
Ciao

...


 spessissimo!
Quanto spesso? Comunque basta guardare nei log del proxy http
se il traffico che ha fatto scattare l'allarme e' lecito.
Fabio

 se il traffico che ha fatto scattare l'allarme e' lecito.
Molto spesso (circa 20-30 segnalazioni/giorno). Il traffico è lecito
il problema è semplicemente una gestione dei falsi allarmi. Per
ovviare sarebbe  utile che snort  distinguesse il file che contiene il
codice oppure il flusso http (un pò come fa ethereal) da una
connessione diretta o "anomala". Non so se sono riuscito a spiegarmi?
In realtà quando scarichi un file pdf (per esempio) molto grande
questo viene spezzato, solo ricostruendo il flusso tramite ack e
sequenze tcp, è possibile capre a cosa appartiene ogni pacchetto.
Butto lì un dubbio che mi prometto di andare a verificare subito sulla
documentazione: se un attacco viene spezzato in più pacchetti (non
parlo di frammenti tcp ma di una separazione logica) snort lo può
rilevare solo se ha regole che identificano patern costanti nei
pacchetti? In caso contrario cambiando la diensione dei pacchetti si
può aggirare il controllo. I virus polimorfi ad esempio non sono
rilevabili (in questo caso giustamente: non è il suo lavoro!)
Saluti
Samuele

 giustamente: non è il suo lavoro!)
Si, i virus polimorfi non sono rilevabili: il principio di funzionamento 
di snort e' quello del "pattern matching" e non riesce a gestire aggeggi
polimorfici. I plugin, invece, possono fare qualcosa. In particolare, il
plugin fnord e' dedicato alla rilevazione di shellcode anche polimorfico
ed e' una futura alternativa alle regole shellcode. Quando sara' stabile
le soppiantera' ma ora non e' ancora a punto, AFAIK (e manca un'adeguata
documentazione).
Fabio