Atak, un worm che ama la (sua) privacy

Il nuovo worm, benché scarsamente diffuso, ha attratto l'interesse degli esperti di sicurezza per alcune sue particolarità, fra cui la capacità di contrastare i tentativi di analizzare il suo codice

Roma - Negli scorsi giorni alcuni laboratori di antivirus hanno segnalato l'esistenza di un nuovo mass-mailing worm, Atak, la cui azione non si discosta molto da quella dei più comuni vermicelli delle e-mail: riversare sulla Rete quante più copie possibile di se stesso. Ciò che ha destato l'attenzione degli esperti sono le tecniche impiegate da questo worm per celarsi ad "occhi indiscreti".

Sebbene sia comune, fra i virus, impiegare tecniche, dette in gergo di "offuscamento", per rendere più difficile la comprensione del codice e degli algoritmi utilizzati, Atak sembra aver decisamente affinato tali misure di difesa.

Oltre ad adottare un efficace meccanismo di cifratura, il vermicello è infatti in grado di accorgersi se qualcuno, come un laboratorio antivirus, tenta di analizzare il suo codice attraverso strumenti come i debugger. Nel caso in cui ritiene di essere "spiato", il worm smette di funzionare e chiude automaticamente il suo processo.
La società di antivirus Panda Software ha poi spiegato che Atak è particolarmente difficile da riconoscere perché è un worm "discreto": non visualizza alcun messaggio o avvertimento che indichi la propria presenza nel sistema.

Un'altra particolarità di questo virus, stando ad alcune analisi, sembra essere quella di rilevare la presenza nel sistema di eventuali "rivali" e disattivarli: una caratteristica che in passato è stata utilizzata anche da altri worm.

Atak è stato scritto in C++ e, non compresso, ha una dimensione di circa 58 KB. Le e-mail generate da questo worm sono identificabili dall'oggetto "Read the Result!" o "Important Data!" e dal messaggio "Authorized Researcher Only".
TAG: sicurezza
46 Commenti alla Notizia Atak, un worm che ama la (sua) privacy
Ordina

  • - Scritto da: Akiro
    > 8 )
    >
    > Fan Linux
    TrollTrollTrollTrollTroll
    non+autenticato
  • > TrollTrollTrollTrollTroll

    se lo dici tu...
    Akiro
    1902
  • Anti-debugging in Win32 - Lord Julus -1999
    http://vx.netlux.org/lib/vlj05.html

    Win32 Anti-Debugging tricks - Billy Belcebu
    http://library.succurit.com/virus/ANTIDEBG.TXT

    Linux anti-debugging techniques (fooling the debugger) - Silvio Cesare - January 1999
    http://vx.netlux.org/lib/vsc04.html

    un sito interessante per i programmatori in "erba"A bocca aperta (e non solo)
    http://www.secureprogramming.com
    non+autenticato
  • è bene ricordare che è o era legato a scientology
    oltre al fatto che alcune versioni impestavano di spyware
    e che altre ne rendevano oltremodo difficile la disinstallazione e andavano in conflitto con molti altri software
    spero che le difficoltà di analisi siano dovute alla concezione del virus e non al talento degli analisti
    non+autenticato

  • - Scritto da: Anonimo
    > è bene ricordare che è o era
    > legato a scientology

    NAAAAAAAAAAAAAAAA!!!!

    Questa proprio non la sapevo !!!

  • > è bene ricordare che è o era
    > legato a scientology
    > oltre al fatto che alcune versioni
    > impestavano di spyware
    > e che altre ne rendevano oltremodo difficile
    > la disinstallazione e andavano in conflitto
    > con molti altri software
    > spero che le difficoltà di analisi
    > siano dovute alla concezione del virus e non
    > al talento degli analisti

    Forse ti confondi con il nortonA bocca aperta
    non+autenticato
  • > è bene ricordare che è o era
    > legato a scientology

    Sei sicuro? Hai qualche link?

    Sono assolutamente contro, disdico immediatamente la licenza e mi compero Avast.
    4751
  • sembra che vi stupite...... anche un pò di anni fa i love you ha fatto strage..... e negli ultimi anni virus del tipo netsky continuano a girare anche dopo mesi che sono stati scoperti ( io ne ricevo 30 al giorno di spam contenente netsky) è normale che i virus diventino sempre più raffinati,è l'evoluzione.
  • ...come farebbe a opporsi a un debugger?
    Cioe`, a casa mia un debugger funziona eseguendo normalmente in "trace", ovver eseguendo un istruzione per volta del programma da spulciare. Ma il programma oggetto dell'indagine non viene eseguito affatto previo consenso di chi sta controllandolo, centellinando le istruzioni, tramite il debugger, e quindi? Boh? Come funzionerebbe, sarei curioso di sapere... da un post di sotto leggo un riferimento a un API "IsDebuggerPresent", ma... una chiamata ad una API e` un'istruzione, possibile che chi debugga non si accorga di quel che il worm tentera` di fare con tale chiamata PRIMA che la faccia, e quindi chi debugga semplicemente non possa saltare quell'istruzione? Nei debugger si puo` fare di tutto, a meno che non mi sia perso qualcosa di recente e/o che la stupidaggine dei sistemi di sviluppo di oggi sia peggiorata piu` di quanto pensassi.
    non+autenticato
  • Non ne sono sicuro, ma provo a risponderti:
    Essendo compresso, prima va decompresso, e questo implica che deve essere eseguito. L'algoritmo di decvompressione (e soprattutto il codice che lo esegue) non è certo winzip, ma qlc di modificato all'uopo. Ecco perchè se si incomincia a fare debugging non si può proprio disassemblare!
    Inltre (ma è una mia ipotesi) se utilizza sw auto modificante (cioè modifica il codice stesso intanto che si esegue) proprio il disassembler non funziona più (o meglio: una gran confusione e non capisci più nulla!).
    Tieni conto che i micro hanno anche delle istruzioni "in più" che possono essere eseguite solo in modalità SV (superVisor). Niente di più facile che il codicillo usi qualche trucco in questo senso.
    Per qusto chiederei alla redazione se è possibile trovare qualche link a questa notizia!
    Grazie.
  • > Non ne sono sicuro, ma provo a risponderti:
    > Essendo compresso, prima va decompresso, e
    > questo implica che deve essere eseguito.

    ... fermati qui e lascia perdere. Se le cose non le sai forse faresti meglio a tacere

    > Inltre (ma è una mia ipotesi) se
    > utilizza sw auto modificante (cioè
    > modifica il codice stesso intanto che si
    > esegue) proprio il disassembler non funziona
    > più (o meglio: una gran confusione e
    > non capisci più nulla!).
    azzo una NUOVA tecnica!
    La prima volta che l'ho vista girava su un apple II
    non+autenticato

  • - Scritto da: Alex¸tg
    > ...come farebbe a opporsi a un debugger?

    ti parlo in merito al buon vecchio assembler x86 puro (niente a che vedere con api windows et similia):

    1) il debugger usa una chiamata ad un interrupt (il 3 credo, sono anni che non lo uso).. il software basta che lo reindirizzi e il debugger va' a farsi friggere.. in pratica il software si accorge che lo stai eseguendo tramite un debugger perche' il debugger si antepone alla cpu nell'esecuzione dell'istruzione assembler.. e per anteporsi deve usare un interrupt.

    2) il disassembler (programma che dal compilato riporta il sorgente assembler) e' sempre stato un fallimento per quanto riguarda l'analisi di virus polimorfici, soprattutto se criptati.. chi conosce l'assembler sa cosa significhi una modifica nello stack del codice da eseguire..
    non+autenticato
  • > in
    > pratica il software si accorge che lo stai
    > eseguendo tramite un debugger perche' il
    > debugger si antepone alla cpu
    > nell'esecuzione dell'istruzione assembler..
    > e per anteporsi deve usare un interrupt.

    eeeeh???
    non+autenticato
  • proprio così
  • > 1) il debugger usa una chiamata ad un
    > interrupt (il 3 credo, sono anni che non lo
    > uso).. il software basta che lo reindirizzi
    > e il debugger va' a farsi friggere.. in
    > pratica il software si accorge che lo stai
    > eseguendo tramite un debugger perche' il
    > debugger si antepone alla cpu
    > nell'esecuzione dell'istruzione assembler..
    > e per anteporsi deve usare un interrupt.

    Il debugger dovrebbe funzionare così:
    viene attivato impostando un flag (TRACE ad esempio) la cpu così dopo ogni istruzione genera un interrupt specifico. L'interrupt esegue il suo handler il cui indirizzo è in una tabella.

    Ma come fa il virus a modificare l'indirizzo dell'handler dell'interrupt?
    Queste sono operazioni che di solito fanno fatte in modalità supervisore della CPU. Solo l'OS dovrebbe essere in grado di farle.

    Se qualcuno ha le idee più chiare si faccia avanti
    :|
    non+autenticato
  • > Ma come fa il virus a modificare l'indirizzo
    > dell'handler dell'interrupt?
    > Queste sono operazioni che di solito fanno
    > fatte in modalità supervisore della
    > CPU. Solo l'OS dovrebbe essere in grado di
    > farle.
    >
    > Se qualcuno ha le idee più chiare si
    > faccia avanti
    >Deluso
    GOOGLE le ha chiarissimeSorride
    non+autenticato
  • Perché non posti qualche link, visto che li hai trovati?
    non+autenticato
  • > Perché non posti qualche link, visto
    > che li hai trovati?

    Perchè è meglio se i bambini imparano a camminare da soli!
    E poi giocare con le pistole non è un passatempo per i bravi bambiniA bocca aperta
    non+autenticato

  • - Scritto da: Anonimo
    > > 1) il debugger usa una chiamata ad un
    > > interrupt (il 3 credo, sono anni che
    > non lo
    > > uso).. il software basta che lo
    > reindirizzi
    > > e il debugger va' a farsi friggere.. in
    > > pratica il software si accorge che lo
    > stai
    > > eseguendo tramite un debugger perche' il
    > > debugger si antepone alla cpu
    > > nell'esecuzione dell'istruzione
    > assembler..
    > > e per anteporsi deve usare un interrupt.
    >
    > Il debugger dovrebbe funzionare così:
    > viene attivato impostando un flag (TRACE ad
    > esempio) la cpu così dopo ogni
    > istruzione genera un interrupt specifico.
    > L'interrupt esegue il suo handler il cui
    > indirizzo è in una tabella.

    Si, questo e` l'altro modo (a parte l'infilare un breakpoint, una chiamata all'interrupt 3) di farlo funzionare. Sfrutta la circuiteria specificamente aggiunta dall'architettura i386 in poi.

    > Ma come fa il virus a modificare l'indirizzo
    > dell'handler dell'interrupt?
    > Queste sono operazioni che di solito fanno
    > fatte in modalità supervisore della
    > CPU. Solo l'OS dovrebbe essere in grado di
    > farle.

    Gia`, in entrambi i casi non e` possibile raggiungere la IDT.
    La IDT e` la tabella dei descrittori degli interrupt, ovvero la tabella che contiene indirizzi e diritti di accesso al codice che reagisce a ogni vettore di interrupt. Pero` la IDT si trova in una delle parti della memoria che il sistema protegge. Per arrivarci si dovrebbe ottenere un CPL (Curret Privilege Level) pari a zero, mentre le applicazioni e i worm girano a CPL=3. E naturalmente non e` possibile: ecco, la vera innovazione per un virus sarebbe riuscire a fare questo, ma non ho idea di come potrebbe riuscisci. Oddio, poi, sfruttando le falle dei buffer overrun ci sono riusciti in molti, ma non certo ALL'INIZIO del proprio codice, ergo ci sarebbe tutto il tempo che vuoi per arginare la chiamata che sappiamo andare a bersagliare un'area vulnerabile del sistema operativo in cui si verifichera` un buffer overrun.

    > Se qualcuno ha le idee più chiare si
    > faccia avanti
    >Deluso

    Credo di aver capito che a ogni modo si parli di espedienti noti per aggirare il debugging quando il tecnico che fa il debugging non e` abbastanza esperto, ovvero di vecchi trucchi. Io invece avevo sospettato che il virus avesse trovato un modo certo per evitare di venire studiato... devo aver frainteso, insomma.
    non+autenticato
CONTINUA A LEGGERE I COMMENTI
Successiva
(pagina 1/2 - 8 discussioni)