Utilizzo di MD5 per gli ID malware: rischi di collisione?

8

È noto dal 2004 che l'hash MD5 è vulnerabile agli attacchi di collisione ( aggiornamento - non "preimage" - il mio errore ....). Tuttavia sembra ancora che le persone lo stiano usando per identificare il malware. Per esempio. rapporti sul nuovo documento di malware Flame che risale a diversi anni per scoprire le stesse firme md5 nei dati md5 archiviati.

Quanti anni ha Flame? - Alienvault Labs

Un utente malintenzionato potrebbe presumibilmente assicurarsi che tutti i suoi file corrispondano all'hash md5 di altri file che rendono pubblici e che sembrano innocui, quindi fare affidamento su md5 sembra pericoloso.

Non vedo riferimenti a sha256 o anche a sha1, che non hanno visto attacchi di collisione (pubblici). Qual è lo stato del passaggio a hash migliori per i database dei virus?

Aggiornamento : la mia preoccupazione era che se il virus db non conservava anche le copie complete di tutti i file in questione (ad esempio perché alcuni erano veramente grandi o simili), e / o se la gente che cerca il db non ha controllato l'intero contenuto dei nuovi file che stanno cercando con i file archiviati, quindi un nuovo file da un virus malevolo, che corrisponde a un vecchio file "innocuo" potrebbe essere erroneamente considerato non pericoloso basato su una corrispondenza MD5. Ma si spera che i file completi vengano conservati e controllati dai ricercatori antivirus, altrimenti sarebbero vulnerabili a questo attacco.

Quindi quali tipi di attacchi contro id di malware potrebbero sfruttare la facilità di produrre collisioni con md5 e quali misure sono effettivamente adottate in specifici database hash e software AV per contrastarli?

    
posta nealmcb 30.05.2012 - 15:48
fonte

3 risposte

6

Prima di tutto - hai ragione che sarebbe meglio usare SHA1, SHA256, SHA2 o qualche altra funzione di hash moderna.

Tuttavia, non penso che il rischio sia molto alto. Per spiegare perché devo dare un po 'di informazioni sugli attacchi alle funzioni di hash. Ci sono due tipi di attacchi di cui preoccuparsi:

  • Attacchi di collisione. Un utente malintenzionato trova due file M (dannosi), S (sicuri) con lo stesso hash. Qui l'attaccante può scegliere M e S liberamente.

  • Secondo attacco pre-immagine. L'autore dell'attacco riceve un file C (Comune) e deve trovare un secondo file M che ha lo stesso hash del file C . Si noti che l'utente malintenzionato non può scegliere C ; è dato a lui. L'unico grado di libertà dell'attaccante è nella scelta di M .

I secondi attacchi pre-immagine sono molto più dannosi, perché lasciano che l'attaccante faccia cose che non potrebbe fare con un attacco di collisione. La cosa da sapere su MD5 è che è noto per essere vulnerabile agli attacchi di collisione. Tuttavia, non sono noti secondi attacchi pre-immagine contro MD5.

Con questo contesto, ora posso rispondere alla tua domanda. Sebbene MD5 sia vulnerabile agli attacchi di collisione, non esiste un modo chiaro in cui un utente malintenzionato potrebbe usarlo per causare problemi. Certo, un utente malintenzionato potrebbe trovare un file M dannoso e un file S innocuo con lo stesso hash. L'utente malintenzionato potrebbe quindi iniziare a diffondere il malware M , in modo che l'hash MD5 di M entri nella lista nera di qualcuno e questo potrebbe indurre alcune persone a concludere falsamente che S è dannoso. Ma allora cosa? S sarà un mucchio di byte dall'aspetto casuale. Non c'è motivo per cui qualcuno abbia già S memorizzato nei loro sistemi, quindi il fatto che l'attaccante possa attivare falsi allarmi su S è sostanzialmente innocuo.

Un secondo attacco pre-immagine su MD5 sarebbe molto più problematico. Permetterebbe all'utente malintenzionato di scegliere un file benigno C che è archiviato sul disco fisso di tutti: forse un file che è fondamentale per il funzionamento di Windows Firewall, ad esempio. Quindi (se l'hacker conosceva un modo per eseguire un secondo attacco pre-immagine su MD5) l'autore dell'attacco potrebbe essere in grado di costruire un file M malevolo che ha lo stesso hash di C , e inizia a diffondere M in giro. Quando le società di anti-virus aggiungono l'hash MD5 di M a una lista nera, ciò potrebbe causare problemi: potrebbe causare errori nel software anti-virus che C è dannoso, e quel falso allarme potrebbe finire per disabilitare Windows Firewall su un gruppo di sistemi o qualcosa del genere. Sarebbe male, se fosse possibile. Tuttavia, per quanto ne sappiamo oggi, uno scenario così brutto non è possibile, perché nessuno conosce in alcun modo il successo di un secondo attacco pre-immagine su MD5.

In conclusione: mentre sarebbe meglio usare una funzione di hash più moderna invece di MD5, non penso che ci sia molto potenziale per i cattivi di sfruttare l'attuale pratica dell'utilizzo di MD5. Il rischio sembra terribilmente basso.

    
risposta data 04.06.2012 - 05:22
fonte
9

Un'analisi rapida:

Minaccia : qualcuno crea un file pulito che corrisponde all'hash MD5 del file dannoso.

Risultato : il file pulito è identificato come dannoso, ma è semplicemente una collisione. Un altro file che combacia esiste ancora e sarà sempre identificato come lo stesso.

Suppongo che, se questo accadrà, potrebbero esserci dei discorsi su come procedere. Le mie ipotesi sul perché non abbiamo:

  • Questo non sta autenticando il malware, ma lo identifica. L'inserimento di corrispondenze false positive ha un valore limitato. I veri positivi si troveranno ancora.
  • È attualmente universale. È possibile identificare il malware con una sola operazione dell'algoritmo di hashing. Se cambiamo, dovrai avviare l'hashing di ogni file con più algoritmi a meno che qualcuno non conservi un repository e possa pubblicare nuovi hash di algoritmi per ogni cosa.

Una falsa corrispondenza ha un valore molto limitato in quanto non puoi fare molto di più che cercare di convincere qualcuno che sta guardando un pezzo di software dannoso che potrebbe essere un diverso software dannoso ... o solo un mucchio di bit. Solo i ricercatori che cercano di apprendere su quel particolare malware potrebbero preoccuparsi e dovrebbero rendersi conto di cosa sta succedendo.

Aggiornamento

Sono a conoscenza del fatto che i database dei virus non includono checksum "puliti". Se c'è una voce MD5 corrispondente, è per qualcosa che non vuoi sul tuo sistema a meno che tu non stia cercando di ricercarlo. Poiché una sezione di un eseguibile può essere accantonata per essere riempita con qualsiasi vecchia assurdità, è possibile creare un file malware che ha la stessa somma MD5 di un altro file innocuo (un "attacco di collisione"). Mentre non sappiamo come fare un pratico "attacco pre-attacco", la natura progettuale degli eseguibili rende ragionevolmente probabile che un attaccante focalizzato possa creare un attacco di collisione come descritto sulla pagina MD5 di Wikipedia . Vale a dire, la struttura eseguibile consente una grande flessibilità nel riempimento inserendo qualsiasi dato di scelta che viene ignorato durante l'esecuzione. Inoltre, è possibile caricare un file altrimenti non eseguibile da un launcher che consente la modifica di uno qualsiasi dei dati iniziali o finali del file. Ciò prevede l'uso di lanciatori generici e collisioni hash eccezionalmente semplici poiché il primo e l'ultimo byte possono essere qualsiasi cosa.

Poiché i database non contengono file puliti, non si otterrà un falso negativo. Potresti ottenere un falso positivo se qualcuno ha progettato un pezzo di malware con questo in mente. Se tu fossi responsabile della creazione del primo database di malware oggi, dovresti utilizzare un algoritmo di hash diverso. Per ragioni storiche e un impatto relativamente basso di un attacco di collisione di successo, MD5 continua a marciare, anche se ora non è ideale.

    
risposta data 30.05.2012 - 16:35
fonte
2

Non sono d'accordo con le conclusioni che l'autore di quell'articolo ha scritto.

We have found a version of the main component (mssecmgr.ocx) that seems to be compiled at the end of 2008. It can indicate that Flame has been around at least for 4 years.

In realtà tutto ciò indica che il componente principale di un malware molto grande ha 4 anni. Questo non significa che ci siano altri componenti principali in uso. Come è Flame sfrutta un difetto che è stato risolto credo nel 2010.

Aggiornamento: dopo le prime due settimane di guardare la fiamma. È stato scoperto che la fiamma aveva in realtà diversi anni. È stato in grado di rimanere nascosto perché sfrutta un difetto in Servizi terminal e un attacco MD5 Collision contro un certificato Microsoft.

Il resto delle conclusioni dell'autore sono d'accordo. Non c'è dubbio che Flame è nuovo nel senso che è il carico di malware di madre, sfrutta un sacco di cose, per molti attacchi sofisticati.

An attacker could presumably ensure that all their files matched the md5 hash of other files which they make public and which seem innocuous, so relying on md5 seems dangerous.

Flame non ha tentato di farlo. La tua preoccupazione non è diretta verso la cosa giusta

Update: the concern I had was that if the virus db didn't also retain full copies of all the files in question (eg because some were really big or whatever), and/or if folks searching the db didn't check the full contents of the new files they're looking up with the archived files, then a new file from a malicious virus, which matched an old "innocuous" file might be mistakenly dismissed as not dangerous just based on an md5 match. But hopefully the full files are retained and checked by anti-virus researchers, or else they would be vulnerable to this attack.

Tutto quello che ho da dire su questo aggiornamento è che sei preoccupato per la cosa sbagliata. Questi siti Web di database dei virus conservano una copia del file. Le società di sicurezza utilizzano anche solo l'hash MD5 di un file per determinare se un file è dannoso.

Le possibilità che un file reale che corrisponda all'hash MD5 di un file dannoso siano davvero VERAMENTE piccoli. Quindi, anche se un file dannoso corrisponde a un file reale, viene utilizzato solo l'hash MD5 per identificare la minaccia .

La maggior parte delle infezioni maligne ben conosciute negli ultimi 10 anni ha utilizzato lo stesso exploit, oltre agli exploit scoperti tra "date di scoperta", oltre a lavorare in modi molto simili.

Tutti pensavano che Stuxnet fosse un trojan veramente avanzato scritto in un linguaggio "personalizzato". Vieni a scoprire che è stato scritto in C e condiviso gli stessi componenti, come ogni altro dei suoi fratelli.

    
risposta data 30.05.2012 - 18:11
fonte

Leggi altre domande sui tag