Newsgroup: it.comp.os.linux.sys
Titolo: Adesso potete cominciare a preoccuparvi

http://darkangel.antifork.org
 
Nella sezione "codes", scaricatevi Mood-Nt.
Spiegazione: usando le funzionalità dell'architettura x86 relative al
debugging (breakpoint e dintorni) è possibile definire un malware per Linux
che, sostanzialmente:
a) modifica la IDT e quindi le syscall
b) fa eseguire il codice che crede
c) ogni volta che rileva un tentativo di scansione delle modifiche fatte,
proprio per via di breakpoint e watchpoint, ripassa il codice originale al
chiamante, che pur essendo root quindi non vede il codice maligno ma la
versione originale
Occorre essere root per fare i passi a) e b), e peraltro il codice attuale
usa /dev/kmem (anche se forse potrebbe usare /dev/mem senza troppe
difficoltà ulteriori) ma una volta che lo si è diventati (con una semplice
escalation di privilegi, magari), il sistema è compromesso aldilà di ogni
possibilità di recupero, anzi di diagnosi innanzitutto e di recupero poi.
Uno nemmeno se ne accorge di essere infetto.
Brillante work-around: usa i server di produzione via Xen, che non
virtualizza i registri di debug. 
Commenti e sensazioni? 
-- 
Per rispondermi, togli il nome del poeta

 Commenti e sensazioni? 
non è molto diverso dai rootkit più moderni.

 Uno nemmeno se ne accorge di essere infetto.
Mah, aldilà dei virtuosismi tecnici, non mi sembra che lo scenario poi
possa cambiare molto rispetto alla situazione attuale. Già da tempo si
sa che un rootkit a kernel mode non lo becchi se non spengi la macchina
e controlli il filesystem con un boot pulito, e a quel punto credo che
pure questo lo puoi individuare.
E poi presuppone di avere root, se dai modo di arrivare a quello in
ogni caso sei "0wn3d".
Per quanto riguarda la detection uno non se ne accorge solo se il
payload non fa una mazza, altrimenti ci sono altri segnali da cui
identifichi la macchina violata (IDS, anyone?)...

 versione originale
Boh, di 'sta roba ne aveva parlato e dato dimostrazione Buffer a Moka
creedo nel 2004, non mi pare nulla di sostanzialmente nuovo...
-- 
Skull & Bones (ER6n Silver)

 identifichi la macchina violata (IDS, anyone?)...
Forse non hai capito: non puoi rilevarlo a meno che non parti da un boot
pulito, ovvero non lo rilevi agli usi pratici.
L'unica soluzione è una patch per il kernel che vanifichi l'uso dei
breakpoint nelle zone di memoria del kernel medesimo.


 creedo nel 2004, non mi pare nulla di sostanzialmente nuovo...
sbagli, non ne ha parlato, inoltre tra il dire ed il fare...
phempt

 non è molto diverso dai rootkit più moderni.
per esempio?
phempt

 pulito, ovvero non lo rilevi agli usi pratici.
Non puoi rilevarne la presenza, ma puoi rilevarne gli effetti, se ne
ha. Se viene usato per montare (come nel 99% dei casi) un IRC Bot, uno
slave per P2P, ecc. ecc. te ne accorgi sorvegliando il traffico della
macchina, con un IDS o con qualunque altro analyzer. Ma pure se è
usata semplicemente come zombi, se rilevi i pacchetti di una
connessione entrante di tipo SSH e poi ti logghi, dai un netstat e non
vedi niente un sospettino ti verrà, no?
Bye!

 
Bye!
phempt

 Commenti e sensazioni?
Una brillante implementazione di un rootkit in kernel space, i cui
principii di funzionamento sono quelli tipici del kernel space, appunto.
Quindi, al di là dell'implementazione che mi sembra interessante e ben
fatta, nihil sub sole novi, a meno che non mi sia perso qualcosa di
fondamentale.

whiplash ha scritto:

Escludendo il fatto che il meccanismo su cui si basa (quello dei 
registri di debug) gli fornisce una potenza di occultamento superiore a 
quella degli altri, direi che sia un'analisi corretta, mi trovo 
d'accordo con te. Niente di incontrastabile con quell'implementazione, 
ma comunque decisamente fastidioso.
Bye!
phempt


Vero, per il fatto di usare le funzioni di debug.
Per il resto, il comportamento (hijack della syscall table e meccanismi
di evasione dai controlli su rootkit), è tutta roba già trattata...
Poi, come dici, tra un proof of concept e una implementazione efficace
può passarci parecchio, e -altrettanto giustamente-, vederlo in funzione
è altra cosa.
Ciò non toglie che di sostanzialmente nuovo c'è (relativamente) poco.
C'è indubbiamente la dimostrazione di un concetto: stabilire la
compromissione di un sistema è sempre più difficile "da dentro" ed ha
sempre più senso farlo "da fuori". :-\
Ma anche qui...


 channel puo risultare difficoltoso accorgersene.
dipende tutto da quanto si è paranoici ;)
bye!

 
bye!
phempt

 malware di questo tipo.
Oh, ecco, questo è qualcosa di più concreto. A questo livello non sto
a questionare, che tecnincamente il robo sia estremamente raffinato non
si discute... 
bye

 quella degli altri
Siamo decisamente d'accordo, direi. :-)
Il punto è che nel post che ha dato origine al thread leggo:
: a) modifica la IDT e quindi le syscall
: b) fa eseguire il codice che crede
: c) ogni volta che rileva un tentativo di scansione delle modifiche fatte,
: proprio per via di breakpoint e watchpoint, ripassa il codice originale al
: chiamante, che pur essendo root quindi non vede il codice maligno ma la
: versione originale
il che caratterizza i rootkit in kernel space, non già  Mood-Nt.


boh, tipo adore. prova a cercare in google

Ottavio Campana ha scritto:

scusa, ma ti rigirerei l'invito, leggi gli altri post del thread.
(adore ha circa 7 anni, moderno è un parolone direi)
bye!
phempt

 d'accordo con te. Niente di incontrastabile con quell'implementazione, 
Ora ci dici come lo contrasti...non intendo a livello di codice, giusto a
livello di intuizione. 


 Ciò non toglie che di sostanzialmente nuovo c'è (relativamente) poco.
La cosa nuova è usare il supporto del microprocessore al debug per metterlo
in quel posto a qualsiasi meccanismo di ricerca di rootkit.
Non riesco a pensare ad una soluzione diversa che fare la stessa operazione
ma a fin di bene per evitare attacchi sui server di produzione, che a quel
punto perdono la possibilità di fare debug.


 macchina, 
No, perchè per rilevare il suddetto traffico, farai delle syscall, e la
tecnica usata da quell'oggetto puo' fornirti delle risposte false senza che
tu possa mai, sottolineo mai, discriminarle da quelle vere.




A NSS2006, dove l'abbiamo visto in funzione, l'abbiamo appunto visto in
funzione. 


 boh, tipo adore. prova a cercare in google
Io direi che se non sai di cosa stiamo parlando, fai meglio a non parlare.
Adore è vecchio (e fin qui, è un aspetto relativamente importante) e
sopratutto è rilevabile. Questo qui no. E non intendo "non adesso", intendo
"no" ora e per sempre: una volta che il sistema è infetto non esiste, ne
potrà esistere mai, un modulo di kernel, patch di kernel, gestione della
sicurezza, debug riga per riga, che ti permetta di scoprirlo, a meno che non
riavvi da un boot pulito.


 del genere è on the wild già da anni, che cambia?
Che usa i breakpoint per rendersi del tutto, eternamente ed infinitamente
invisibile finchè non riavvi da un sistema pulito, nel qual caso devi
sperare di sapere cosa cercare per trovarlo, comunque.


 Si, analizzando la banda rilevi se ci sono attività illecite, 
Se analizzi l'uso di banda su un firewall su cui passa il traffico, non
certo sulla macchina infetta, per i motivi detti. 


 non hai bisogno nemmeno di essere root per fare quello che vuoi.
ma siccome di solito non monitori solo la macchina dal suo interno ma
anche dall'esterno e guardi cosa fa....

 certo sulla macchina infetta, per i motivi detti. 
se hai una dmz non è una cosa così rara....

 riavvi da un boot pulito.
cosa succede se le cerco in /dev/kmem o /dev/mem? adore lo si trova
cercando in un grep sulla memoria, quale pare del tuo rootkit previene
questo?
Con i breakpoint puoi intercettare i software e modificarli, però non
puoi pensare di mettere breakpoint per tutte le possibili soluzioni.

Ottavio Campana ha scritto:

Non puoi monitorare il funzionamento dell'os dall'esterno (la questione 
dei virtualizzatori non si pone nemmeno in quanto non virtualizzano le 
estensioni per il debug dei processori). Il discorso vale per il 
traffico di rete, ma se non ne genera hai un problema.
Bye!
phempt

Zefram Cochrane (reloaded) ha scritto:

rimuovo la sua struttura per l'handling dell'eccezione di debug o 
disattivo temporaneamente la gestione corretta delle suddette per vedere
se ci sono attività illecite. Andrebbero creati dei sw appositi 
ovviamente, ma è gestibile come cosa, fermo restando che al momento non 
c'è niente di simile e che lievi modifiche al codice potrebbero rendere 
inutili anche queste soluzioni. L'ideale sarebbe scriversi un proprio 
software e tenerselo privato in modo che non possano essere apportate 
modifiche che lo rendano inutilizzabile. Come viene detto nel readme è 
proprio "un dito nel culo"
Bye!
phempt

Ottavio Campana ha scritto:

Qui sbagli in quattro punti:
* a quanto ho capito non è suo quel codice
* per ingannare il grep basta un comunissimo xor sulle stringhe, 
modifica applicabile nel giro di 5 minuti nel caso non fosse presente
* a quanto ho visto ha delle parti che prevengono anche questo genere di 
controlli arrivando perfino a modificare le informazioni che si possono 
ricavare sia dai vari *mem/kcore che dal procfs, tipo i maps. inoltre 
questo vale se non utilizza i debug registers in quanto se lo fa non 
modifica niente e pertanto il problema non si pone dato che era questo 
il caso in esame mi pare
* non modifica il software ma il comportamento del software tramite 
l'intercettazione della parte del kernel adibita alla chiamata delle 
syscall.non servono infiniti breakpoint, solo uno o due nei punti 
giusti, tanto il flusso di esecutivo del kernel deve passare di la dove 
si aggancia, non si scappa.
Bye!
phempt

> questo?
Ho visto ora, c'è inoltre da dire che non esportando simboli come i 
moduli non soffre di questo genere di problemi (grep su kallsyms/ksyms 
come adore), e configurando un pattern a piacere in fase di 
installazione/compilazione rende completamente inefficace questo genere 
di controlli
bye!
phempt

 si aggancia, non si scappa.
ma a priori non puoi sapere come modificare tutte le syscall per sapere
come non essere mai identificati.
Mi spiego, l'idea è buona e raffinata. E' difficile da trovare, ma non
credo che sia impossibile, perché chi scrive il rootkit non può a priori
predire tutte le azioni che verranno fatte per rintracciarlo.

 traffico di rete, ma se non ne genera hai un problema.
se ho una macchina intaccata che non è mai raggiunta dall'esterno allora
è un problema , ma per fortuna è minimo. :-)

Ottavio Campana ha scritto:

Si, su questo siamo perfettamente d'accordo, impossibile non è esiste, 
c'è solo l'improbabile :-)
Bye!
phempt

Ottavio Campana ha scritto:

Be dipende, ci sono anche cose come la sicurezza fisica della macchina 
da tenere in considerazione, un cracker interno potrebbe prelevare via 
chiavetta o quant'altro i dati collezionati illegalmente all'interno del 
calcolatore, ma comunque sia si, con forti politiche di controllo del 
traffico è possibile limitare di molto gli scenari pericolosi.
Bye!
phempt

 c'è solo l'improbabile :-)
passare da 0% a una qualsiasi probabilità non nulla è un guadagno
infinito :-)

 traffico è possibile limitare di molto gli scenari pericolosi.
non è legale, ma attaccare una fase al case sarebbe la soluzione
moltissimi problemi.....

 moltissimi problemi.....
Per come sono costruiti gli alimentatori da pc è probabile che sia
sufficiente (ma anche necessario), staccare il filo di terra dal pc, dal
monitor e forse da altro hardware esterno ... con il risultato accessorio
ma utile, che i continui guasti del pc impedirebbero il furto dei dati (il
lecito uso? dettagli ...).
P.S. Forse inserire piccole punte intinte del curaro su case del pc può
essere una discreta barriera ....

 lecito uso? dettagli ...).
ma poiché il case è chiuso farebbe da gabbia di faraday....

 se ci sono attività illecite.
Disattivi il registro del processore? Come, fracassandolo in modo
chirurgico? :) 


 se hai una dmz non è una cosa così rara....
Mi domando quanti sistemisti, di fronte ad un netstat pulito, penseranno di
fare un controllo sul firewall in termini preventivi (non correttivi).


 puoi pensare di mettere breakpoint per tutte le possibili soluzioni.
Le possibili soluzioni sono in numero limitato, quindi sì, puoi farlo.


 Le possibili soluzioni sono in numero limitato, quindi sì, puoi farlo.
io non credo che questo sia possibile. tutto qua.


sinceramente non penso pochi. Più che altro perché l'idea consiste non
nel partire dal netstat sull'host ma da statistiche da un'altra macchina
che fa da firewall.
Considera inoltre che gli appliance che eseguono ids non sono così rari.

 
Parecchi.
Il controllo di log e/o IDS e simili lo si fa periodicamente, non se
si sa di esser stati bucati.
Fa parte della ricerca dei sintomi, non della cura.
Almeno, e' quello che io credo essere uno dei compiti di un sysadmin.
Chiudere la stalla dopo che i buoi sono scappati puo' essere
interessante per analisi post mortem, ma ...
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net


curiosità
e tutti gli user normali che hanno un router/fw basato su distro linux? 

 e tutti gli user normali che hanno un router/fw basato su distro linux? 
Usualmente quei dispositivi non sono basati su processore x86.


 si sa di esser stati bucati.
Tu immagini di avere:
- un firewall o comunque un perimetrale che abbia un suo IDS
- una procedura che periodicamente lo controlli
Per me non è una condizione diffusa.


 Per me non è una condizione diffusa.
Mah, saro' ottimista, allora.


 Per me non è una condizione diffusa.
secondo me.