Il non-blog di Mario Pascucci

Sto lavorando sodo per preparare il mio prossimo errore (B. Brecht)

Articoli con tag Rutkowska

Repliche estive: “Malware batte Investigatore 2-0″ (2 maggio 2007)

Sep 15

Pubblicato da Mario Pascucci in Computer Forensics, Information security | Disattiva commenti

Questo è l’ultimo dei miei articoli del vecchio sito di ISMProfessional che, secondo me, vale la pena rileggere. Fra l’altro, l’estate è quasi andata, come calendario, anche se il caldo rende ancora i miei viaggi da pendolare molto simili ad una deportazione di massa, e le repliche di solito terminano con l’estate.

Questa volta l’argomento è presentato sotto forma di racconto alla CSI, naturalmente del tutto inventato. Come di consueto, ci rileggiamo alla fine per qualche oziosa considerazione.

Malware batte Investigatore 2-0

L’investigatore scende dall’auto, priva di insegne di riconoscimento, scortato da due uomini vestiti di scuro, piuttosto robusti.

La chiamata è giunta in tarda notte, ed ora è quasi mattina: il palazzo in cui stanno per entrare è la sede della più importante azienda di credito del Paese.

Pare che qualcuno sia riuscito ad accedere al database principale delle carte di credito, ed ha cominciato a sfruttare i dati trafugati. Le normali operazioni di gestione delle emergenze non hanno avuto l’effetto sperato, e pare che anche il centro elaborazione dati di riserva, attivato per l’emergenza, sia affetto dallo stesso problema.
Sa che sarà un lavoro delicato e complesso, ma ha con sé la valigetta con tutti i suoi strumenti di lavoro: il fido notebook con dentro tutti i software più sofisticati per l’analisi forense, un duplicatore di dischi e memorie flash ultimo modello e un gioiellino acquistato da qualche tempo: un duplicatore di memoria RAM hardware con interfaccia FireWire, che permette di acquisire il contenuto della memoria del computer mentre è in funzione e senza alterarne l’operatività.

Il direttore operativo della sede è stato molto chiaro: dieci minuti di interruzione di servizio equivalgono ad alcuni milioni di Euro di danni per le mancate transazioni, per cui i server non devono essere spenti per nessun motivo.
Arrivano in sala server principale, e si mette immediatamente al lavoro. Connette il notebook alla rete, sul segmento fra i server e il firewall che li protegge dal brodo primordiale di Internet.

Attiva prima un Intrusion Detection System ed un analizzatore di rete, ma dopo venti minuti di analisi non rilevano nulla di sospetto. Esamina i log del firewall, niente di anormale. Decide di passare al semplice sniffer e guarda il traffico di rete man mano che scorre sul video.

Qualcosa continua a solleticargli nel cervello: il viavai dei pacchetti TCP è normale, per una installazione di questo tipo, ma c’è qualcosa che non torna.

Passa ad esaminare i server. Ovviamente non può installare nulla, per non comprometterne il regolare funzionamento, ma conosce abbastanza il sistema operativo per sapere dove guardare per scovare un intruso.
Non ci sono processi estranei, né servizi sconosciuti. I driver delle principali periferiche sono in ordine. L’elenco delle applicazioni installate corrisponde perfettamente ai file sparsi in giro per il disco di sistema, ed ovviamente alle specifiche di installazione dell’applicazione principale.

Trova finalmente una discrepanza: ci sono installati DUE protocolli TCP/IP. Non se ne era accorto subito, il secondo era in basso, e lo nota dopo aver fatto scorrere in basso l’elenco.

Ricorda di aver letto qualcosa in merito. Sfoglia rapidamente la documentazione sul notebook e trova quello che cercava: una presentazione che parlava di malware invisibili. Ma questo ha lasciato qualche traccia, quindi forse non è del tipo III, non sfrutta la virtualizzazione per nascondersi.

Il problema rimane: non può spegnere il server, e non può installare nulla, per cui non può scoprire dove si è infilato l’intruso.

Sa che è là, da qualche parte nella memoria del computer… Aspetta! La memoria!

Apre la valigetta e prende il gioiellino, il duplicatore di RAM. Ora potrà analizzare con calma tutto il contenuto della memoria, trovare l’intruso ed analizzarne il codice: è questione di ore, e potrà consegnare abbastanza dati al direttore della sede per individuare chi si nasconde dietro l’operazione.

Inserisce il connettore sulla porta FireWire del server, inserisce un pen drive da 16G, su cui il duplicatore scriverà il contenuto della memoria e preme il tasto che avvia la copia. Immediatamente il server si blocca completamente: dopo pochi secondi il sistema di controllo dei servizi di rete lancia l’allarme per la caduta dei servizi. Rivoli di sudore scorrono sul volto dell’investigatore, nonostante la sala sia condizionata e mantenuta a 20 gradi.

Il tecnico responsabile fa iniziare la procedura per instradare tutti i servizi verso il centro di elaborazione di riserva. Il tutto è durato meno di un minuto, ma la telefonata del direttore della sede arriva poco dopo: non saranno ammessi altri errori.

Il server si è bloccato talmente male che riaccendendolo impone un controllo completo di integrità al filesystem. Ma il peggio deve ancora venire: il database si è corrotto, e occorre replicarlo da quello di riserva, ora diventato principale. Ci vorranno ore.

L’investigatore, le mani un po’ tremanti, sfila il pen drive dal duplicatore di memoria e lo inserisce nel notebook: dei quattro gigabyte di RAM del server ha replicato meno di un gigabyte. E dentro non c’è nulla di utilizzabile: la struttura di dati compromessa dal malware punta allo spazio di memoria subito dopo dove si è bloccata la duplicazione.

Non può essere che una maledetta sfortuna. Imprecando fra sé, l’investigatore va a parlare col tecnico responsabile, chiedendogli se può duplicare la memoria dal server del database di riserva. Ovviamente il tecnico rimane dubbioso: e se è stato il gioiellino a bloccare il server?

L’investigatore insiste, e gli propone di provarla su altri server non critici, per dimostrare che è stato solo un caso. Insieme inseriscono il duplicatore su quattro differenti server, e su tutti l’operazione termina senza alcun problema. I server continuano il lavoro come se niente fosse.

Il tecnico si convince, anche se è ancora un po’ titubante. Squilla di nuovo il telefono, sono arrivati altri rapporti di transazioni fraudolente: chi sta trafugando i dati sta ancora operando indisturbato: è la prova che anche il server nel centro di elaborazione di riserva è compromesso. Questo fa decidere il tecnico: però vuole aspettare almeno che finisca la duplicazione dal database di emergenza.

Si spostano nell’edificio adiacente: la sala server è la metà dell’altra, ma è posizionata sotto il livello stradale, con spessi muri di calcestruzzo.

L’investigatore inserisce di nuovo il duplicatore sulla porta FireWire del server, ma questa volta è meno deciso. Non vuole perdere i dati dal pen drive usato in precedenza, per cui usa un altro pen drive, un po’ più vecchio ed un po’ più lento dell’altro.

Preme il tasto di avvio della copia. Passano i secondi, e pare funzionare tutto. Il pen drive è lento, maledettamente lento.

Sullo schermo del server si vede lo screensaver con il logo del sistema operativo che dovrebbe fluttuare, ed invece è inesorabilmente immobile. Anche il server di riserva si è bloccato. E stavolta non ci sono più riserve. Il tecnico freneticamente lo riavvia, ma non c’è nulla da fare: filesystem e database corrotti. Devono fermare il servizio e ripristinare lo stato dei database: per fortuna c’è la copia dei dati, fatta appena prima. Ma nelle due ore che serviranno a ripristinare il database l’azienda di credito perderà milioni di Euro. E l’investigatore non solo quelli…

Stavolta ho cambiato modo di presentare l’argomento. Il racconto è completamente inventato, ma li elementi che fanno fallire il povero investigatore ipertecnologico sono tutti reali. La nostra amica Joanna Rutkowska ha colpito ancora.

Si parla della possibilità di duplicare il contenuto della memoria di un computer mentre è in funzione e senza interferire con la sua operatività: esistono in commercio schede per bus PCI che fanno questo, ed è possibile usare una porta FireWire per fare la stessa cosa, con la differenza che nel caso delle schede PCI occorre inserirle prima di poterle utilizzare, e quindi spegnere il computer, a meno di schede di tipo PCI-Hotplug.

Questo permette di duplicare il contenuto della memoria ed esaminarlo con calma, rilevando tutti i tipi di malware possibili, dato che viene usato un accesso DMA diretto, senza passare per il processore.

Ma, anche se per ora solo su hardware AMD, i malware possono sfruttare un trucco per arrivare a tre differenti comportamenti tesi ad impedire l’acquisizione della zona di memoria dove sono annidati:

  • bloccare il computer
  • far leggere valori senza senso (tutti 0×00 o 0xff)
  • far leggere valori arbitrari a scelta.

Tutti e tre questi comportamenti sono fattibili, e con grado di complessità crescente. I primi due sono stati implementati e dimostrati, il terzo è stato solo ipotizzato, ma già così è sufficiente per rendere inutile l’uso di questi miracolosi marchingegni.

C’è di peggio: l’attuale implementazione lascia fuori tutte le architetture non AMD, dato che sfrutta un comportamento legale ed atteso della tecnologia HyperTransport, ma a partire dal 2008 sia Intel che AMD rilasceranno processori ed architetture che supporteranno una tecnologia analoga per la gestione delle periferiche, e che sarà parte della tecnologia di virtualizzazione. Ingannare i duplicatori di RAM sarà un gioco da ragazzi. Duplicatori che ancora sono praticamente inesistenti in commercio in versione PCI, e del tutto ipotetici in FireWire (esiste un software dimostrativo, vedere nei riferimenti).

Il messaggio finale di Joanna, ed il nostro, vuole essere questo: finché non esisteranno sistemi operativi in grado di autoverificarsi e di segnalare la perdita di integrità, ogni altro strumento, per quanto sofisticato, sarà solo un costoso palliativo dalla durata limitata.

Riferimenti:

  • La presentazione di Joanna Rutkowska.
  • Un documento sulla fattibilità dei duplicatori di RAM via FireWire
  • Altro documento di presentazione di un software dimostrativo per duplicare la memoria via FireWire.

Oggi

Nel racconto ho volutamente esagerato i vincoli posti sull’operato dell’investigatore, per rendergli inevitabile la figuraccia. Inoltre gli ho fatto compiere un errore madornale, ossia operare sul sistema principale, invece che quello di riserva, inattivo. Ma il suo fato di personaggio virtuale era già segnato, quindi anche operando sul sistema di riserva per primo non sarebbe cambiato nulla sul suo destino finale.

Ma veniamo a noi. Joanna Rutkowska, nel frattempo, non è rimasta certo con le mani in mano. Abbiamo malware virtualizzanti in grado di infilarsi dietro l’hypervisor di un sistema di virtualizzazione, ossia capaci di operare una virtualizzazione annidata, mandando all’aria l’assioma che un sistema impiegante la virtualizzazione è sicuro rispetto all’attacco di un malware. Abbiamo malware che riescono, sotto certe condizioni, naturalmente, ad evadere da una macchina virtuale ed attaccare l’hypervisor, demolendo un altro assioma della virtualizzazione.

Insomma, sono tempi duri per chi pensava di mettersi al sicuro usando un sistema di virtualizzazione. Come sempre, non si può contare su strumenti automagici e soluzioni semplicistiche. I malware, espressione (perversa) della creatività e fantasia umane, sono sempre pronti a raccogliere nuove sfide, demolendo miti e soprattutto fedi mal riposte.

Poi, naturalmente, ci sono gli integralisti, come il signore della nota azienda IT americana che ha attaccato e, secondo lui, demolito il lavoro del team di Joanna tramite un articolo su un noto portale IT. Peccato che il signore in questione abbia dimostrato che nella fretta di confutare (o forse per voler avere ragione a tutti i costi) ha letto male e compreso peggio il lavoro presentato al noto Black Hat di quest’anno, riguardante una trilogia per sovvertire il funzionamento di Xen, il sistema di virtualizzazione basato su Linux. Ora, considerando che l’hypervisor di Xen è molto piccolo e compatto, il codice è sottoposto ad una serie impressionante di test e di controlli allo scopo di eliminare, ragionevolmente, ogni possibile bug di sicurezza, gli altri produttori di sistemi di virtualizzazione non hanno di che stare allegri. Nel senso, non pensino di gioire della dimostrazione che Xen non è invulnerabile: il loro hypervisor si basa su codice proprietario chiuso, e quindi senza il possibile contributo di questi geniali ricercatori per scovare falle e buchi.

Molto probabilmente alcuni degli attacchi portati con successo a Xen sono altrettanto efficaci anche con altri prodotti, naturalmente con qualche modifica.

I dettagli della trilogia su Xen, sull’articolo del signore e la relativa risposta di Joanna, si possono trovare leggendo il blog di Joanna Rutkowska, presente da tempo nel mio blogroll e nel mio lettore di feed.

Tags: , ,

Repliche estive: “Un malware veramente cattivo #2: trovami, se ci riesci…” (20 dicembre 2006)

Sep 9

Pubblicato da Mario Pascucci in Information security | 2 commenti

Siamo quasi al termine delle repliche estive. Ancora un altro articolo e abbiamo terminato. Qui esaminavo una classificazione dei malware proposta dalla ricercatrice di sicurezza Joanna Rutkowska. Ci rileggiamo alla fine per le oziose considerazioni di rito.

Un malware veramente cattivo #2: trovami, se ci riesci…

Nel precedente articolo abbiamo mostrato (con l’aiuto di Joanna Rutkowska) come risolvere il problema di comunicare con l’esterno senza essere scoperti.

Qui vedremo le opzioni a disposizione dei malware per occultarsi invece all’interno del computer colpito.

Ogni malware, come sappiamo, è un programma, una porzione di codice che deve essere eseguita per rendere attivo il malware stesso. Una volta attivato e compiute le operazioni necessarie a stabilirsi, rimane da risolvere il problema di evitare di essere scoperto troppo facilmente. Un malware che si fa scoprire ha vita breve, mentre lo scopo è quello di agire senza insospettire né il normale utente, né l’amministratore di rete più smaliziato.

In realtà questo problema ha due aspetti: sfuggire sia all’occhio umano, sia agli strumenti automatici di rilevamento (antivirus, rootkit checker, ecc.). Joanna propone una classificazione ragionata dividendo i malware in quattro classi, in funzione del modo in cui si insediano e di come questo li renda difficili da rilevare.

Tipo 0

L’insediamento avviene con un normale programma, che usa le normali funzioni del sistema operativo per essere avviato per esempio come servizio di sistema. In questo caso il malware compare fra i processi in esecuzione, ed ha una porzione di memoria dedicata come tutti gli altri. La sua rilevazione è piuttosto semplice, in quanto con le normali funzioni di controllo del kernel se ne può controllare lo stato di esecuzione, le risorse impegnate, ecc.

Ad esempio un classico botnet agent come Gaobot è un malware di tipo 0. Il fatto che alcuni malware, come Gromozon, adottino delle strategie molto sofisticate per non essere rimossi, non cambia il fatto che rimangono malware di tipo 0, usando sempre e solo API documentate del sistema operativo per agire.

Tipo I

I malware di questo tipo non si presentano come processi separati, ma si agganciano al codice di altri processi sia del kernel che di servizi di sistema fondamentali. Una volta attivati non si notano processi aggiuntivi, ma un servizio di sistema, una porzione del kernel, un driver o una applicazione fondamentale per il funzionamento del sistema divengono portatori del malware, che si esegue nello stesso processo.

Per far questo viene modificata una parte dell’immagine in memoria del processo preso di mira dal malware, con una vera e propria operazione di patching, che aggiunge il proprio codice a quello in esecuzione.

In questo caso è molto più difficile trovare il malware, dato che non ha usato normali API per insediarsi, ma ha modificato il codice di una parte del sistema operativo o di una delle sue applicazioni.

Tipo II

Questo tipo di malware usa una strategia ancora più sofisticata. Il kernel contiene alcune strutture dati che sono in realtà puntatori a funzioni, di dimensione variabile e compilate con i giusti valori al momento dell’avvio del sistema operativo. Ad esempio i driver NDIS sono elencati in una struttura dati di questo tipo. I malware di questo tipo non toccano niente nel codice del kernel o delle applicazioni principali, ma si agganciano ad una di queste strutture dati, modificando un puntatore e inserendosi al suo posto o in aggiunta a quelli già presenti.

Il vantaggio di questo tipo di tecnica è che tali strutture sono modificabili per definizione e non possono essere bloccate, né protette dalle modifiche.

Tipo III

E’ il tipo più temibile: non tocca nulla all’interno del sistema operativo colpito, non genera nuovi processi, non modifica né porzioni di codice né strutture dati, è completamente esterno e fuori dalla visibilità. Al momento l’unica tecnica conosciuta è quella della virtualizzazione, applicata ad esempio nella pillola blu, che abbiamo già conosciuto.

Richiede che l’architettura del computer colpito sia conforme alle specifiche per macchine virtuali sicure, come la tecnologia Pacifica di AMD™ e quella VT-d di Intel™, e quindi è legata ad uno specifico tipo di hardware, ma l’efficacia è devastante.

La ciliegina sulla torta

I malware di tipo 0 e I hanno bisogno di operazioni aggiuntive per non rivelare troppo facilmente la loro presenza. Alcuni agganciano porzioni specifiche del kernel e nascondono le informazioni necessarie a scoprirli: per esempio filtrando l’elenco dei processi in esecuzione o l’elenco dei driver caricati. Il discusso sistema anticopia della nota multinazionale usa un filtro sul filesystem per nascondere i propri file.

Un rootkit sperimentale denominato Shadow Walker usa un sofisticato metodo per capire se un altro processo sta leggendo la zona di memoria in cui risiede il suo codice, tipicamente un antivirus che spazzola la memoria per capire se ci sono segni di malware, e mostra una differente zona di menoria all’antivirus, rendendone impossibile la rilevazione. Ma ha bisogno di modificare la parte di kernel che gestisce la memoria, e questo permette di scoprirne le tracce.

I malware di tipo II pongono un problema del tutto nuovo: non modificando in alcun modo nessuna parte del codice del kernel o delle applicazioni, ma solo strutture di dati che per definizione sono modificabili, diventano del tutto invisibili ai normali meccanismi di rilevamento.

I malware di tipo III, pur limitati ad una specifica architettura hardware, sono del tutto fuori dalla portata di qualsiasi metodo di rilevamento che sia interno alla macchina compromessa.

Sappiamo tutti la difficoltà di rimozione per alcuni tipi di malware, vedi Gromozon, come pure la fatica nel rilevarne la presenza, come il noto rootkit del sistema anticopia. Vedremo in un prossimo articolo le difficoltà che pongono queste nuove categorie di malware, sia per la rilevazione da parte di strumenti automatici che da parte di una persona che sappia dove guardare.

Oggi

Joanna Rutkowska è andata molto più avanti, ed in direzioni impensate. Ora è possibile annidare gli hypervisor, ossia un malware può virtualizzare un sistema già virtualizzato: ecco il NBP (Nested Blue Pill, pillola blu annidata). E’ stato dimostrato che la virtualizzazione, ritenuta dai più anche un modo per rendere più sicuro un sistema operativo, dato che l’hypervisor è in teoria isolato dall’interferenza delle macchine virtuali, non risolve per nulla il problema. Prendendo di mira Xen, il sistema di virtualizzazione usato in Linux, di cui è disponibile il sorgente, è stato dimostrato come sovvertirlo e riuscire da una macchina virtuale a modificare la memoria dell’hypervisor, demolendo di fatto l’assunto base della sicurezza della virtualizzazione.

E’ stato anche dimostrato come aggirare la protezione aggiuntiva offerta dall’architettura VT-d di Intel, grazie ad un bug nel bios di alcuni modelli di schede madri.

Ora, il semplice fatto che sia stato dimostrato che si può fare, dimostra che la virtualizzazione e tutto meno che un sistema di sicurezza. Ma il mondo IT, sordo a queste dimostrazioni, ritenute teoriche ed irrealizzabili in pratica, sta andando esattamente in questa direzione, con l’idea di mettere un semplice hypervisor dentro il sistema operativo allo scopo di proteggere il nucleo principale di esso.

Tutto questo nella Xen 0wning Trilogy di Joanna Rutkowska che vi invito a leggere.

Ma, naturalmente, nessuno userà mai questo per creare malware. Noooooo. Mai. E’ impraticabile.

D’altra parte lo stesso si diceva riguardo l’IP spoofing ed il TCP sequence number prediction. Poi nel Natale del 1994 Kevin Mitnick riuscì a penetrare nel computer di Tsutomu Shimomura usando proprio questo tipo di attacco.

Tags: , ,

Repliche estive: Un malware veramente cattivo #1: comunicare senza comunicare (9 dicembre 2006)

Aug 25

Pubblicato da Mario Pascucci in Information security | 1 commento

La ricercatrice Joanna Rutkowska ne sa veramente una più del diavolo. Naturalmente il suo blog è fra i miei preferiti. Lo aggiorna raramente, ma ogni suo scritto vale ogni singolo bit impiegato. Questo articolo, scritto quasi due anni fa, prendeva spunto dalla presentazione di un suo progetto, realizzato e funzionante, di cui avevo parlato già in una differente occasione.

Joanna nel frattempo ha prodotto molte altre cose, tutte estremamente interessanti, nel campo della sicurezza e dei malware. Uno dei suoi punti di vista che condivido completamente è che l’uso della virtualizzazione come strumento di sicurezza è una falsa soluzione. Ma questa è un’altra storia. Buona lettura.

Un malware veramente cattivo #1: comunicare senza comunicare

Ogni malware ha necessità di comunicare, vuoi per avvertire casa di essere arrivato, vuoi per fare il suo sporco lavoro. Per questo motivo, in mancanza di alternative, si può sempre agire dall’esterno del computer sospetto di essere compromesso: lavorando di sniffer è di solito possibile vedere il traffico anomalo generato dal malware per comunicare con l’esterno.

Ma… immaginate un metodo di comunicazione che non sia rilevabile con un normale sniffer: niente trucchi elettronici o elettrici, la comunicazione c’è, ma non si vede.

Presentiamo i nostri attori:

  • A: il computer compromesso con dentro un malware di quelli cattivi.
  • B: il computer di chi ha spedito il malware ed ora sta aspettando i suoi messaggi.
  • C: il computer del detective che deve scoprire cosa comunica il malware.
  • X: un computer qualsiasi su Internet.

A comunica in protocollo TCP con X. B si trova in qualche punto fra A e X, e riesce a vedere il traffico di rete fra i due. C si trova anche lui fra A e X, ma anche fra A e B, quindi se A manda un qualsiasi pacchetto IP a B, C lo intercetta immediatamente e può rilevare il traffico anomalo.

Alla fine fra A e B non circola un solo pacchetto, solo fra A e X, ma B ha ricevuto tutti i dati inviati da A.

Come può essere accaduto?

Usando un Passive Covert Channel della nostra incredibile Joanna Rutkowska.

Nell’intestazione di ogni pacchetto TCP ci sono dati per il funzionamento del protocollo, sotto forma di bit. Ognuno di essi ha un significato ben preciso, e non può avere valori arbitrari. Inoltre non si possono usare trucchi come accodare dei byte in più ad ogni pacchetto, perché sarebbero immediatamente rilevati.

Un solo blocco di bit può avere in teoria un qualsiasi valore ed essere valido: il campo dell’ISN (Initial Sequence Number).

La comunicazione avviene in questo modo:

  1. A apre la comunicazione con X. Il malware annidato al suo interno intercetta i pacchetti TCP di tipo SYN in uscita e sostituisce l’ISN originale con quello generato da lui.
  2. X riceve i pacchetti e risponde normalmente.
  3. B, che legge in modo passivo il traffico fra A e X, estrae i dati inviati da A in tutti gli ISN dei pacchetti TCP SYN, li riassembla, e legge la comunicazione.
  4. C non vede nulla di strano, solo A che comunica con X, e basta.

I limiti sono che B non può inviare dati al malware e che il malware può inviare dati al ritmo di soli tre byte per ogni pacchetto TCP SYN inviato dal computer compromesso. L’integrità della comunicazione è assicurata dal meccanismo di funzionamento del protocollo TCP stesso: se dovesse andare perso un qualsiasi pacchetto, il computer compromesso lo ritrasmetterebbe automaticamente perché richiesto dal protocollo stesso. Dato che B si trova fra A e X, se X riceve un pacchetto, lo riceve anche B. Quindi anche l’integrità è assicurata.

Per evitare di essere scoperta troppo facilmente, la comunicazione usa anche una cifratura derivata dal DES, che garantisce anche una relativa casualità nei valori di ISN forgiati. In questo modo si evita di insospettire per l’inevitabile regolarità dovuta alla presenza di dati sensati in un posto dove non dovrebbero essercene.

In conclusione: abbiamo la possibilità di creare un canale sicuro e coperto con il computer compromesso, senza scambiare direttamente neanche un singolo pacchetto.

La stessa tecnica si può applicare sfruttando altri elementi di un qualsiasi altro protocollo, ad esempio, citando Joanna, i cookie http, oppure i pacchetti TCP di tipo SYN/ACK, utili se ad essere compromesso è un server.

Oggi

C’è poco altro da aggiungere. Joanna nella presentazione ha mostrato anche come accorgersi che quello che dovrebbe essere casuale non lo è, chiudendo il cerchio, come dovrebbe fare ogni hacker degno di questo appellativo.

Per il resto, gli attuali malware a grande diffusione sono tutt’altro che sofisticati, preferendo colpire la massa con poco sforzo piuttosto che spendere energie per colpire pochi ma buoni. Tanto, come ho più volte affermato, a chi crea virus interessa sfruttare le risorse del computer colpito, creando botnet, e niente altro. Malware più sofisticati sono l’eccezione, e si preferisce utilizzare la legge dell’ottanta/venti: il venti per cento dello sforzo necessario a creare un malware realmente pericoloso è sufficiente a creare un malware che colpisca l’ottanta per cento dei computer del pianeta. Perché pagare di più?

Tags: , ,

Repliche estive: “Hasta la vista” (20 ottobre 2006)

Jul 9

Pubblicato da Mario Pascucci in Computer Forensics, Information security | 3 commenti

Nel periodo estivo le televisioni sono ripartite come di consueto con le repliche. E se lo fanno loro, lo faccio anch’io. Per qualche settimana pubblicherò delle repliche di articoli apparsi sul defunto sito di ISMProfessional.

Questa settimana ripropongo un articolo che parlava di come rendere totalmente inefficaci tutte le misure di sicurezza che venivano sbandierate come la soluzione definitiva al problema malware che affligge tutte le versioni di Windows. Buona lettura.

Prosegui la lettura »

Tags: , ,