Domanda:
In che modo il software dannoso crittografa i file delle vittime così rapidamente?
Ulkoma
2015-07-05 12:19:52 UTC
view on stackexchange narkive permalink

Crittografare un file per me è come gestire una stringa molto lunga, inserendolo nella funzione di hashing o crittografia per ottenere un'altra lunga stringa crittografata (o un hash nel caso dell'hashing).

Questo processo richiede una buona quantità di tempo. Lo so perché utilizzo HashTab per verificare l'integrità dei file che scarico da Internet.

In che modo ransomware come CTB-Locker o Crypt0l0cker possono crittografare i file delle vittime istantaneamente?

Recentemente un mio amico è stato vittima di uno di questi ransomware e NON ha potuto aprire i suoi file / foto da Ubuntu sulla sua macchina con doppio sistema operativo anche quando l'infezione è avvenuta con MSWindows. Ciò suggerisce che la crittografia non viene eseguita al volo quando si apre un file.

Non è necessario crittografare tutto un file, quanto basta per impedire all'applicazione di aprirlo. Poiché molti file sono già codificati in binario, per l'utente finale, il file è effettivamente inutilizzabile.
Potrebbe valere la pena menzionare la crittografia completa del disco (il mio datore di lavoro ci fa usare Symantec PGP) che può crittografare il tuo disco mentre lo usi, usando (presumo) l'inganno del driver. Detto questo, questa è la crittografia a livello di unità, non a livello di file.
Per molti scopi potrebbe anche essere sufficiente crittografare i metadati del file system. Quindi la tabella FAT o i metadati NTFS in Windows. Se rimescolo, sarebbe abbastanza difficile per la maggior parte degli utenti recuperare i propri file, anche se il contenuto del file è completamente intatto.
Otto risposte:
Mike Ounsworth
2015-07-05 22:16:49 UTC
view on stackexchange narkive permalink

Ero a una conferenza OWASP in cui l'oratore ha decompilato e analizzato un eseguibile ransomware (per Windows) di fronte a noi. Esistono molti tipi di ransomware là fuori, quindi non posso parlare con il ransomware in generale, ma posso certamente parlare di quello che ho visto. L'idea generale è che l'eseguibile del ransomware contenga la chiave pubblica di crittografia necessaria per crittografare i file utilizzando un algoritmo asimmetrico, ad esempio RSA. La corrispondente chiave privata / di decrittografia rimane con gli hacker in modo che nessuna quantità di reverse engineering dell'eseguibile possa darti la chiave di decrittazione.

Per crittografare effettivamente un file, fa qualcosa di simile a:

  1. Salta i primi 512 byte del file in modo che l'intestazione del file rimanga intatta.

  2. Crittografa i successivi 1 MB utilizzando la chiave di crittografia incorporata .

  3. Se il file è più lungo di questo, lascia il resto in chiaro.

Il punto non è nascondere completamente o proteggere i dati, è sufficiente per renderli non analizzabili.

Per quanto riguarda il tempo, eseguire 1 MB di RSA è ancora lento e ci vorranno ancora diverse ore per eseguire la scansione del disco rigido.

Sospetto che questo esemplare che ho visto fosse solo una pigra imitazione del ransomware RSA-AES completo di cui Steffen Ullrich ha parlato nella sua risposta, che è quella che dovresti essere davvero preoccupato.

Poiché RSA è così lento, di solito viene scelta una chiave casuale, crittografata con RSA, quindi questa chiave casuale viene utilizzata per eseguire un cifrario a flusso, spesso qualcosa come AES / DES, che è molti ordini di grandezza più veloce.
"Salta i primi 512 byte del file in modo che l'intestazione del file rimanga intatta, ad esempio Windows può ancora dire che si tratta di un pdf, mp3, ecc." - Nota che Windows controlla solo l'estensione, non il contenuto.
@user2064000 sul serio? Windows è ancora così stupido? Sono stato puro Linux dal 2006, avrei supposto che Windows avesse superato quel problema ormai. Impara qualcosa ogni giorno ...
@MikeOunsworth Per quanto ne so, il kernel Linux non si preoccupa nemmeno delle intestazioni dei file.
@nanny Dalla pagina `man` per il comando` file` ([link] (http://linux.die.net/man/1/file)): "Il concetto di" magia "è stato applicato per estensione a file di dati. Qualsiasi file con un identificatore invariante con un piccolo offset fisso nel file di solito può essere descritto in questo modo. " - suona come un'intestazione di file per me!
@nanny: Questo perché il kernel Linux non si preoccupa affatto dei tipi di file. Per quanto riguarda il kernel, sono tutti solo "file". Ci sono alcune eccezioni (ad esempio lo shebang e altre cose eseguibili), ma per il resto, i byte sono byte. Ora, la tua * GUI * può visualizzare i tipi di file, ma questo è a un livello di astrazione molto più alto.
... e ovviamente non è il * kernel * che si preoccupa di shebang e quant'altro, ma la shell. Proprio come non è Windows che si preoccupa del bitrate dei tuoi mp3, ma Windows Explorer.
Questo è un po 'fuori tema ma c'è un sacco di software su Linux che guarda le estensioni dei file e non le intestazioni dei file.
@jon In realtà, il kernel Linux controlla i primi byte per trovare l'interprete, vedere https://coderwall.com/p/pdg77q/how-the-shebang-is-processed-by-the-linux-kernel
@Jon: In realtà, [il kernel Unix * non * interpreta gli shebangs] (https://en.wikipedia.org/wiki/Shebang_%28Unix%29#History).
Sono corretto - e abbastanza confuso sul motivo per cui hanno ritenuto preferibile farlo nel kernel. Grazie per il riferimento!
@Jon Questa è una caratteristica che consente ai file di testo di essere effettivamente eseguibili, anche al di fuori della shell. Vedere [execve (2)] (http://man7.org/linux/man-pages/man2/execve.2.html).
Hai un link alla presentazione OWASP? O il nome del presentatore?
@ColBeseder Non credo che il discorso sia stato registrato, ma ecco un link all'abstract del discorso e alla biografia del relatore (fare clic su "vedi tutto" per espandere): http://www.meetup.com/OWASP-Ottawa/events/219842720/ ? a = uc1_vm & read = 1 & _af = evento & _af_eid = 219842720
Gerald Davis
2015-07-05 19:06:53 UTC
view on stackexchange narkive permalink

La prima crittografia simmetrica è piuttosto veloce. AES in alcune modalità è facilmente 200 MB / s. La tua affermazione che l'hashing è lento è una falsa pista. L'hashing è incredibilmente veloce. È così veloce sui processori moderni che indebolisce l'effettiva sicurezza degli hash delle password. Ciò ha portato allo sviluppo di funzioni di derivazione di chiavi multi-round per "rallentare" l'hashing.

La velocità "lenta" che stai vedendo è principalmente l'effetto del tuo disco rigido lento. In memoria l'hashing è qualcosa nell'ordine da 500 MB / sa 2 GB / s +.

Tuttavia il malware non ha bisogno di essere "istantaneo". Il sistema dell'utente viene infettato silenziosamente. Le copie dei file possono essere crittografate senza avvisare l'utente e quindi una volta pronti gli originali cancellati e l'utente avvisato "istantaneamente". L'intero processo, dall'infezione a quel punto, potrebbe aver richiesto una notevole quantità di tempo nonostante sembrasse avvenire istantaneamente.

Per inciso, è anche meglio che l'avviso avvenga qualche tempo dopo l'infezione, in modo che la vittima non possa facilmente capire dove / come è stata infettata.
C'è un po 'di confusione anche qui, dove l'OP sta fondendo la crittografia con l'hashing. Anche se condividono una teoria matematica simile, l'hashing NON È una crittografia e le due hanno scopi molto diversi. Per questo motivo, molti algoritmi di hashing sono lenti PER PROGETTAZIONE (per rallentare gli attacchi di forza bruta), mentre gli algoritmi di crittografia tendono ad essere semplificati il ​​più possibile senza compromettere la sicurezza.
Non c'era confusione. Ho incluso solo le prestazioni di hashing perché l'OP riportava le prestazioni di hashing e riteneva che fosse lento e quindi la crittografia dovrebbe essere ancora più lenta. La realtà è che sia la crittografia simmetrica che gli algoritmi di hashing sono molto veloci. Su messaggi lunghi, AES256 è da 2 a 13 cicli per byte (a seconda della modalità) e SHA-512 è 8 cicli per byte. La maggior parte del "ritardo" durante l'hashing o la crittografia è dal tempo necessario per leggere i dati dal disco. La crittografia effettiva è incredibilmente veloce. I KDF vengono utilizzati per rallentare l'hashing delle password perché le operazioni di hashing sono molto veloci.
Non volevo dire confusione da parte tua - penso che la tua risposta sia eccellente. :-) Volevo dire confusione dalla persona che ha posto la domanda. Sembra che potrebbero essere confusi, se stanno usando le prestazioni di hashing come metrica delle prestazioni di crittografia.
Gli algoritmi di hash @loneboat utilizzati per controllare l'integrità dei file mirano ad essere il più veloci possibile senza sacrificare la sicurezza. È solo che gli hash delle password sono deliberatamente lenti, ma non c'è motivo di menzionarli qui. Gli hash e la crittografia simmetrica hanno prestazioni simili ed entrambi sono generalmente associati a I / O. Poiché l'hashing deve solo leggere il file, ma la crittografia deve leggere e scrivere dati, la crittografia dovrebbe essere circa il doppio più costosa in questo contesto.
Un mio amico è stato colpito da uno di questi attacchi. * Non * è stato istantaneo. Se ne accorse abbastanza presto da spegnerlo dopo che aveva crittografato solo circa la metà della sua vasta libreria di musica / video. OP aveva ragione sul fatto che * ci vogliono * diverse ore per fare la magia. È il silenzio che gli permette di portare a termine il suo sporco compito.
Steffen Ullrich
2015-07-05 14:57:04 UTC
view on stackexchange narkive permalink

L'hashing (come SHA-1 ecc.) e la crittografia simmetrica (come AES) sono relativamente economici, la crittografia asimmetrica (come RSA) è molto più costosa. Ecco perché di solito non si utilizza RSA per crittografare un file di grandi dimensioni, ma invece si utilizza la crittografia simmetrica con una chiave casuale e si crittografa solo questa chiave breve con RSA.

Lo so perché uso HashTab per verifica l'integrità dei file che scarico da Internet.

Mi sembra un metodo molto scientifico. A meno che tu non abbia un processore vecchio e lento la velocità di hashing (e quindi di verifica dei dati) è per lo più più veloce di quanto puoi leggere i dati dal disco (nel caso questo non sia ovvio: ovviamente devi ancora leggere i dati per hash , ma passerà più tempo ad aspettare i dati dal disco che a calcolare l'hash).

In che modo ransomware come CTB-Locker o Crypt0l0cker possono crittografare i file delle vittime all'istante?

I sistemi operativi moderni supportano i file system crittografati e con i processori odierni (che spesso includono l'accelerazione hardware per AES) non noterai molta differenza di velocità se utilizzi o meno un file system crittografato, perché il collo di bottiglia è non la crittografia ma la velocità del disco (nei benchmark vedrai un calo delle prestazioni ma questi non riflettono l'utilizzo nel mondo reale per la maggior parte delle persone). Quindi non c'è motivo per cui il ransomware non possa crittografare i dati velocemente. Ovviamente potrebbero farlo sembrare più veloce collegandosi al sistema in modo che i file che si desidera aprire vengano crittografati prima e il resto in background.

E la chiave simmetrica utilizzata per crittografare i file viene quindi eliminata? Ciò significa che è possibile recuperare la chiave simmetrica dalla memoria durante la crittografia, o non è così?
@Michael: sì, dovresti essere in grado di recuperare la chiave simmetrica dalla memoria durante la crittografia, anche se probabilmente ci sono modi per renderlo non troppo facile. E ovviamente potresti usare una chiave diversa per ogni file per rendere più difficile il recupero dei dati.
economico come in veloce? costoso come in lento? quindi i file sono effettivamente crittografati simmetricamente, ma la chiave è crittografata con RSA. Quanto velocemente? non mi suona bene. Anche su un buon PC ho bisogno di 30 secondi per calcolare l'MD5 per un file.
I dati vengono letti dal disco per essere alimentati alla funzione, giusto? come può essere inferiore il tempo totale? oppure ti riferivi al tempo effettivo necessario per elaborare la stringa / file in memoria dalla funzione di hashing / crittografia.
@Ulkoma: economico / costoso come nelle risorse, ad es. Memoria, potenza di elaborazione ecc. Questo si traduce in economico essere veloce. E non ho mai affermato che il tempo totale sia inferiore (di cosa?). Ovviamente è necessario leggere i dati dal disco per inserirli nella funzione, ma la parte principale è la lettura non il calcolo. E per quanto riguarda "Ho bisogno di 30 secondi per calcolare l'MD5 per un file". - quanto è grande il tuo file, quanto è lento il tuo disco, quanto è veloce il tuo processore ....? Se hai bisogno di 30 secondi per eseguire l'hashing di un file con una dimensione di 1 byte, probabilmente questo è il tempo necessario ai tuoi sistemi per caricare il tuo programma.
Ho fatto un test su una vecchia macchina P4 con Debian Linux. Ci sono voluti 0,23 secondi per eseguire un hash MD5 di un file da 15 MB.
@mti2935: sì, e in base a `openssl speed` posso fare circa 500 MByte / s SHA-1 su un processore mobile Intel I5 (i5-4200U). In questo modo supera la velocità del mio disco.
Loren Pechtel
2015-07-06 03:19:38 UTC
view on stackexchange narkive permalink

L'errore che stai facendo è pensare che sia istantaneo. Piuttosto il malware sta lì crittografando in background e decrittografando tutto ciò che l'utente richiede. È silenzioso durante questa fase, richiede il riscatto solo dopo che tutto è stato crittografato.

Freedo
2015-07-05 12:44:42 UTC
view on stackexchange narkive permalink

Secondo wikipedia:

Quando viene eseguito per la prima volta, il payload si installa nella cartella del profilo utente e aggiunge una chiave al registro che lo fa eseguire all'avvio. Quindi tenta di contattare uno dei numerosi server di comando e controllo designati; una volta connesso, il server genera una coppia di chiavi RSA a 2048 bit e invia la chiave pubblica al computer infetto.

Non è lento come pensi, se il tuo computer è veloce e non lo è Non facendo un uso intenso della CPU al momento dell'infezione potresti perdere gigabyte di dati in meno di 15 minuti. I PC moderni possono calcolare l'hash ed eseguire operazioni di crittografia più velocemente di quanto possano funzionare i dischi del disco rigido / SSD. Quindi direi che il limite moderno sulla velocità per la velocità di hash / crittografia si basa più sul disco stesso. Posso generare un hash SHA-512 per un file da 2,5 GB in 2 minuti.

E anche il malware può solo aspettare che crittografa tutto ciò che vuole prima di visualizzare un messaggio all'utente.

Se questo è il caso, perché utilizziamo funzioni di hashing lento per confrontare i file e verificare l'integrità? Perché non usare solo RSA? Sono abbastanza sicuro che l'output sia unico per ogni chiave univoca.
L'RSA non viene in genere utilizzato per crittografare i dati direttamente (può crittografare dati arbitrariamente grandi?). Viene utilizzato per crittografare la chiave della crittografia simmetrica.
Corey
2015-07-06 15:45:27 UTC
view on stackexchange narkive permalink

Il processo di base è leggere il contenuto del file e riscriverlo su disco utilizzando una qualche forma di crittografia asimmetrica per assicurarsi di dover pagare per riavere i dati. Alcuni crittograferanno solo piccole sezioni dei dati per migliorare la velocità, altri riscriveranno l'intero disco rigido se possono. Come notano alcune delle altre risposte, alcuni malware crittografano semplicemente una parte del tuo file sul posto per accelerare il processo, poiché per molti formati di file anche un leggero cambiamento nel file rende l'intero file inutilizzabile.

In che modo i ransomware come CTB-Locker o Crypt0l0cker possono crittografare i file delle vittime all'istante?

Non possono. Invece quello che fanno è nascondere la loro attività facendo in modo che i file sembrino a posto fino al completamento del processo. Intercettando le chiamate al file system è possibile modificare la visualizzazione dell'utente di ciò che è effettivamente presente sul disco, facendo sembrare che tutto sia ancora OK fino al termine, poi quando si toglie le intercettazioni l'utente può vedere il vero stato del drive . Il pericolo nel fare ciò è che devi avere entrambe le parti della tua coppia di chiavi asimmetriche per decrittografare i file al volo quando l'utente ne apre uno, il che in linea di principio significa che qualcosa potrebbe trovare la chiave privata che desideri vendere l'utente in un secondo momento.

Altri malware come CryptoWall (con cui di recente ho avuto più esperienza di quanto voglio ricordare) non si preoccupano di nascondersi, ma si limitano a criptare tutto il più rapidamente possibile ... e questo è praticamente limitato dalla velocità IO dell'unità a cui si sta crittografando.

Guardando alcuni benchmark per AES, che è l'algoritmo di crittografia che CryptoWall pretende di utilizzare, una modesta CPU moderna può crittografare i dati a velocità ben superiori a 100 MB / sec, il che significa che è probabile che l'operazione sia vincolata a IO su qualcosa di diverso da un SSD. Aggiungi più thread in esecuzione su core CPU separati destinati a cartelle e / o unità diverse e il processo può essere completato abbastanza rapidamente.

Recentemente ho dovuto ripulire un file server che era stato elaborato da CryptoWall in esecuzione su uno dei PC degli utenti. Quando gli utenti hanno notato che qualcosa non andava, il malware era in esecuzione da circa 1,75 ore. Abbiamo rimosso la cosa dalla rete appena prima delle 2 ore e durante la pulizia ho trovato circa 230 GB di file crittografati. Si tratta di una crittografia media di ~ 30 MB / sec, che è certamente fattibile nell'ambiente. Ci sono voluti circa 3 volte quel tempo per ripristinare i file dal backup precedente. Anche se ho alcune idee su come velocizzarlo la prossima volta, la maggior parte dei clienti ha i propri backup su NAS a basso costo o ( rabbrividisce ) unità USB.

Purtroppo siamo improbabili per vedere una fine a queste cose in qualunque momento presto. Una soluzione di backup competente e adeguatamente configurata è il tuo migliore amico quando una di queste cose colpisce. Non fa male avere un programmatore a portata di mano per eseguire lo script del ripristino.

Boluc Papuccuoglu
2015-07-05 18:03:54 UTC
view on stackexchange narkive permalink

Da una prospettiva di ingegneria sociale, l'autore del malware avrebbe potuto scrivere un programma che sostituisse il contenuto dei dati con bit casuali. La vittima non avrebbe modo di verificare se i contenuti sono stati crittografati o semplicemente cestinati. Se decidono di pagare il riscatto e la "chiave" non funziona, non c'è molto che potrebbero fare, i ragazzi dopotutto sono criminali.

Questo è esattamente quello che sospetto
Se lo facessero, danneggerebbero il proprio modello di business. Se un numero sufficiente di persone dichiarasse di non aver ricevuto indietro i propri soldi, altri non pagherebbero. Per ottenere la maggior parte di questo losco affare, le vittime si fidano maggiormente di recuperare i propri dati e queste informazioni devono diffondersi in modo che anche gli altri paghino. E in effetti sono sufficienti i rapporti per riavere i suoi dati.
Il collo di bottiglia è l'I / O del disco e la scrittura di bit casuali dimezza il tempo perché non richiede la lettura dal disco. Probabilmente non è molto significativo per un malware.
La mia sensazione è che ESISTONO alcuni autori di crypto ransomware che elaborano un modello di business sostenibile, come Evgeniy Bogachev. Ma sembra inevitabile che ce ne saranno altri che riusciranno a guadagnare rapidamente senza doversi occupare di chiavi di crittografia simmetriche, database di chiavi, ecc.
@SteffenUllrich: È risaputo che i dirottatori taglieranno la gola a tua moglie o tuo figlio nel momento in cui li paghi (non ne hanno più bisogno e potrebbero identificare i dirottatori). Tuttavia, quasi tutti pagheranno.
@Damon: Dubito che questo sia ben noto e dubito addirittura che sia vero. Direi che la maggior parte delle vittime di rapine in realtà continuano a vivere.
Ángel
2015-07-06 16:33:24 UTC
view on stackexchange narkive permalink

Alcuni riscatti come TorrentLocker crittografano solo il primo MB (più aggiungono un finale). Questo è sufficiente per impedire che la maggior parte dei formati venga riconosciuta, ma allo stesso tempo rende molto più veloce la crittografia di un gran numero di file (ricorda anche che solo alcuni tipi di file sono crittografati, come documenti, foto ...).

Questo è stato segnalato da Nixu nel blog SANS e anche su ( white paper ESET), sebbene abbiano riportato 2 MB.

E, come ha detto Loren , il ransomware mostra solo il grande banner che chiede il riscatto dopo che tutto è stato crittografato (non va bene che ti rendi conto quando sono stati "trattenuti" solo pochi file), anche se alcuni ransomware posizionano mentre eseguono un file di richiesta di ransomware su ogni cartella / per ogni file crittografato.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...