Domanda:
Esiste un file system che non supporta la crittografia?
Thomas Roy
2017-05-15 00:06:37 UTC
view on stackexchange narkive permalink

Preferirei che nessuno, nemmeno io, potesse crittografare i miei file. Non ne ho bisogno e non lo voglio.

C'è un modo per disabilitare permanentemente qualsiasi tipo di crittografia a livello di sistema operativo?

In caso contrario, è un possibile miglioramento che un futuro file system potrebbe incorporare? O è fondamentalmente impossibile prevenire?

Perché preferiresti questo?
È davvero * "Come faccio a prevenire il ransomware?" *
Anche se una cosa del genere fosse possibile, cosa che non è, non proteggerebbe i tuoi file dal ransomware.Gli hacker ransomware eliminerebbero invece irrimediabilmente i tuoi file e poi _segnerebbero_ che sono stati crittografati e potrebbero essere recuperati se pagassi il riscatto.Alcune persone disperate pagherebbero, semplicemente non riavrebbero effettivamente indietro i loro file.
Sembra un caso di un problema XY (https://meta.stackexchange.com/a/66378).Comunque sia: il blocco della crittografia non fermerà il ransomware in primo luogo e non è davvero possibile bloccare tutta la crittografia * comunque * su un dispositivo informatico generico.
Potresti non averne alcun uso personale, ma il tuo sistema operativo e molti programmi che esegui lo fanno.
Dovrebbe essere un filesystem che non supporta i contenuti.
Stai effettivamente chiedendo se puoi acquistare un diario che ti impedisce di scrivere voci in francese.Un file system, proprio come un diario, contiene esattamente ciò che scrivi al suo interno.
Suppongo che se l'obiettivo è rendere inefficace il ransomware in base alla scelta del filesystem, ne vuoi uno che non supporti _deletion_ (né sovrascrittura), non importa se supporta la crittografia.
Grazie a tutti.Per qualche ragione stavo pensando alla crittografia come un meccanismo della partizione / FS / OS / driver.Ora mi rendo conto che il ransomware crittografa semplicemente i byte del file e li scrive su disco.Questo è più semplice di quello che immaginavo.
usa btrfs + snapper
Gli snapshot di sola lettura di btrfs sono un approccio a de-fang ransomware.Una volta creata l'istantanea, solo l'utente root del sistema può eliminare l'istantanea o renderla scrivibile per crittografarne il contenuto.Il sovraccarico di istantanee frequenti è piuttosto ridotto.zfs ha strutture simili.
I file system strutturati in log sono un altro approccio.L'idea di base è che una volta che i dati sono stati scritti, non è possibile sovrascriverli entro un intervallo di tempo definito, quindi è possibile riportare il filesystem a com'era in qualsiasi momento nella finestra, non solo per un'istantanea.Un processo separato recupera lo spazio che rappresenta i dati più datati della finestra.Il problema più grande con tali filesystem è che la sovrascrittura ripetuta dello stesso file riempirà il filesystem e il ripristino da questa situazione può essere un problema serio.Ma forse man mano che i dischi diventano sempre più grandi, questa idea sarà finalmente quella il cui momento è arrivato?
@nigel222 Man mano che i dischi diventano più grandi, le persone penseranno che avere i loro film in Ultra-Ultra-Ultra-Ultra HD sia un'idea ancora migliore: P E se permetti in qualsiasi modo di eliminare i log, questo sarebbe ciò che il ransomware userebbe ...
Nove risposte:
Peter
2017-05-15 00:11:48 UTC
view on stackexchange narkive permalink

No, è impossibile, a meno che non modifichi la definizione di un file.

Un file è un dato arbitrario. I dati arbitrari possono essere dati crittografati.

Anche se consentiamo solo i dati strutturati, i dati strutturati possono - se non assumiamo vincoli di spazio - essere utilizzati in modo improprio per memorizzare tutti i dati arbitrari * (citazione necessaria). Il che ci porta al punto di partenza.


Puoi avere un successo parziale, se introduciamo restrizioni. Un esempio potrebbe essere che se non vuoi che i file vengano crittografati dopo averli scritti, puoi usare un sistema scrivi una volta (o anche solo scrivi). Oppure, se vuoi combattere gli attacchi ransomware, potresti avere un filesystem che conserva le copie originali dei file modificati per un certo periodo di tempo.


* Ad esempio un formato di testo restrittivo che consente solo le parole "Fizz" e "Buzz" possono rappresentare tutti i dati binari sostituendo 0 con "Fizz" e 1 con "Buzz".

scusate gente, questo è diventato sciocco
Che ne dici di un filesystem che comprende molte estensioni di formato plausibili e convalida i dati salvati rispetto al formato, rifiutandosi di scrivere il file se non viene estratto?PER ESEMPIO.Se apri un ".jpeg" in un editor esadecimale e modifichi alcuni byte _ (nel tentativo di creare kewl glitch art) _, quando salvi il sistema operativo ti dà un errore ** "il file non può essere salvato;i dati non possono essere convalidati rispetto alle specifiche JPEG / JFIF "**.Ovviamente, questo tipo di filesystem metterebbe un enorme fardello sugli sviluppatori di app di utilizzare solo i formati supportati e di richiedere l'aggiunta dei loro formati al sistema operativo ... ma in teoria potrebbe funzionare.
@SlippD.Thompson Non solo avresti bisogno di una tale convalida specifica del tipo di file, ma dovresti anche verificare che ogni .jpeg sia un'immagine reale, piuttosto che un mucchio di pixel che possono essere interpretati come dati crittografati.Devi anche assicurarti che le immagini non contengano alcun contenuto stenografico.
@CortAmmon Certo, se vuoi avere un filesystem completamente anti-crittografia / dati oscurati.Stavo girando di più per un filesystem anti-crittografia-contenuto esistente-sul posto.
@Peter So che questo non è un commento utile, ma la tua affermazione è geniale.Credo anche che i dati strutturati con lunghezza arbitraria possano essere utilizzati per memorizzare ogni file.
@Slipp Ciò potrebbe offrire una certa protezione contro i cambiamenti casuali.Gli attacchi ransomware sono modifiche deliberate e mirate.La conoscenza di tale verifica rende facile, se non banale, bypassare.Tieni presente che il numero di tipi di file che il ransomware di successo deve influenzare è piccolo (presumo che docx e jp (e) g da soli siano sufficienti per ottenere il 95% dei "clienti" privati).
@Peter Ebbene sì, ogni miglioramento in materia di sicurezza e protezione finirà per essere interrotto - non esiste un sistema perfetto.La sicurezza della verifica del formato dei file sarebbe contro gli attacchi che si basano su _un file come dati arbitrari_— attacchi senza la conoscenza di questo processo di verifica.E ovviamente non tutti i dati possono essere verificati e quindi se un attacco fosse progettato per, ad esempio, cifrare tutto il testo leggibile dall'uomo in un ".doc", funzionerebbe comunque.
@SlippD.Thompson Quindi voglio crittografare il tuo jpeg.Lo leggo, lo eseguo attraverso un algoritmo di crittografia e converto l'output in ottale o esadecimale.Quindi lo salvo come file txt.È perfettamente valido che un file txt contenga i caratteri "01234567".Il mio codice quindi cancella il file originale e pone la richiesta casuale.La verifica del formato del file non fa esattamente nulla.
@Murphy Questo esempio include l'eliminazione del file originale, quindi tutte le scommesse sono disattivate.Un magico filesystem a prova di crittografia non serve a nulla se la tua strategia è l'eliminazione definitiva dei file.Va notato che il ripristino dei dati del filesystem è molto più semplice sui file eliminati definitivamente _ (la modifica dei file può essere un'operazione atomica o non atomica, ma la copia del contenuto in nuovi file è sempre atomica sulla maggior parte dei filesystem) _ e il recupero dei backup dei file eliminati è molto più semplicerispetto ai file che sono stati modificati: da allora, i file modificati possono sostituire le versioni legittime di cui è stato eseguito il backup.
Se fai in modo che il file system comprenda improvvisamente la semantica dei tipi di file e esegua la convalida, ora hai più problemi: 1. Una convalida rigorosa potrebbe impedire la scrittura di file parziali.2. Hai notevolmente aumentato la tua superficie di attacco: ora c'è la possibilità che un file malformato colpisca i bug nel codice di analisi del formato del file system.
@SlippD.Thompson Existing ransomeware esegue regolarmente una copia crittografata e quindi elimina il vecchio file in modo irrecuperabile.Se i file non possono essere danneggiati (ad esempio rendendo le immagini tutte nere, i file di testo tutti zeri ecc.) Dopo aver eliminato i vecchi file, creare semplicemente un singolo file di testo di grandi dimensioni grande quanto lo spazio non allocato nel file system che è una stringa casualecaratteri di testo.Niente più recupero di file per te a meno che tu non abbia un sistema di backup separato.se in effetti hai un sistema di backup separato, non hai bisogno del tuo filesystem onnisciente massicciamente complesso.
l0b0
2017-05-15 16:58:54 UTC
view on stackexchange narkive permalink

File system di sola lettura non possono per definizione essere scritti (almeno non digitalmente. Quello che fai con una perforatrice e un magnete al neodimio sono affari tuoi). Esempi:

  • Live CD, da cui è possibile avviare un sistema operativo che avrà lo stesso aspetto a ogni avvio.
  • Dispositivi WORM (Write Once Read Many), utilizzati ad esempio da istituzioni finanziarie che devono registrare transazioni per molti anni senza alcun mezzo per modificarle o eliminarle digitalmente.
  • Partizioni scrivibili montate in sola lettura. Questo può ovviamente essere aggirato da un programma con accesso root.

Il controllo delle versioni dei file system sarebbe più pratico, ma non sono comuni . Tali sistemi potrebbero facilmente includere opzioni per scrivere in modo trasparente ciascuna versione di un file (o la sua differenza rispetto alla versione precedente) su un dispositivo WORM o su un archivio protetto in altro modo.

Entrambi risolvono il problema sottostante: non perdere dati originali in caso di crittografia da parte di software dannoso.

Sarebbe più accurato dire che i file system di controllo delle versioni non sono * attualmente * comuni.VMS aveva un tale file system, ed era relativamente comune prima che i PC diventassero onnipresenti.
Buona risposta.Questa è la più vicina a una risposta praticamente utilizzabile.Mi piacerebbe avere un blocco fisico sul mio disco dati che impedisca qualsiasi scrittura.
Potresti riuscire a trovare una chiavetta USB con un interruttore di protezione dalla scrittura hardware http://www.fencepost.net/2010/03/usb-flash-drives-with-hardware-write-protection/
Ciò che manca a questa risposta è che i dispositivi di sola lettura "artificiali" possono essere montati o modificati fisicamente (tramite un interruttore) per abilitare le scritture.CD e DVD diventano poco pratici se si desidera scrivere continuamente modifiche.Il controllo delle versioni dei file system non può garantire che una versione precedente sarà disponibile e "intatta".
Anche un supporto di sola lettura come un CD-ROM non è immune da un attacco contro una vittima ingenua: l'attaccante potrebbe utilizzare un modulo del kernel che fa apparire _apparire_ che un particolare disco è crittografato o altrimenti alterato, invogliando la vittima a pagaredenaro per "decrittografare" i file, anche se i file non sono stati affatto alterati, e sarebbero stati facilmente recuperati su un computer diverso, non infetto.
@Johnny un semplice riavvio spazzerebbe via qualsiasi attacco e ripristinerebbe il sistema a quello che era per quanto riguarda i CD live.A meno che non usi generosamente il termine ingenuo :)
"Mi piacerebbe avere un blocco fisico sulla mia unità dati che impedisca qualsiasi scrittura."Oh, quelli esistono già.Il pulsante di accensione.
@Shane Per un'unità di sistema, i due sarebbero quasi equivalenti, sì.Ma Thomas stava parlando specificamente della sua unità dati :)
@ThomasRoy Bene, ci sono alcuni modi per ottenere effetti simili.Ad esempio, Windows Embedded ha un'opzione che consente le scritture, ma in realtà non le scrive sul disco: quando riavvii il computer, torni al punto di partenza.Se esegui il tuo computer virtualizzato, puoi montare il tuo sistema utente su unità che utilizzano istantanee, registri, impedire la scrittura tutto insieme ... ci sono molte opzioni.Ovviamente non funziona ancora molto bene per i giochi, ma per il resto non è così difficile da configurare e mantenere.
NTFS (e btrfs e HFS +) hanno un supporto per il controllo delle versioni;ma non proteggono dai programmi con privilegi di amministratore.
Alexander O'Mara
2017-05-15 00:11:17 UTC
view on stackexchange narkive permalink

Carichi di file system non hanno il supporto per la crittografia a livello di file system nativo. I file crittografati tramite software possono essere archiviati su qualsiasi file system, proprio come qualsiasi altro file. Il file system non è in grado di distinguere tra dati casuali e dati crittografati.

Esiste un modo per disabilitare in modo permanente qualsiasi tipo di crittografia a livello di sistema operativo?

Non finché il codice può eseguire e scrivere file su disco.

O è fondamentalmente impossibile prevenirlo?

Senza sacrificare le funzionalità di base, sì.


Hai contrassegnato la tua domanda come ransomware. Quello che potresti cercare sono informazioni sul sandboxing delle applicazioni o sul rilevamento del ransomware basato su euristica.

dark_st3alth
2017-05-15 00:22:18 UTC
view on stackexchange narkive permalink

Sembra che ci sia un malinteso tra crittografia e file system.

I due sono indipendenti, uno può eseguire la crittografia senza avere un file system e uno può avere un file system senza eseguire la crittografia.

Ad esempio, i tradizionali file system FAT16 / FAT32 non "supportano" la crittografia nativa come fa NTFS con il suo sottocomponente EFS. Ciò non significa, tuttavia, che non si possano modificare dati già salvati, né scrivere dati nel file system crittografato.

È del tutto possibile avere un File system "solo scrittura" o unità "sola lettura", ma ciò non impedisce comunque a qualcuno di copiare i dati, crittografarli e quindi conservarli altrove. Puoi sicuramente impedire la cancellazione e il sovrascrittura dei dati già presenti sul disco (i file in Windows possono essere bloccati da un processo attivo).

Out of Band
2017-05-15 00:26:05 UTC
view on stackexchange narkive permalink

Un file system è fondamentalmente un fornitore di servizi per il sistema operativo (ad esempio, fornisce un modo per archiviare e recuperare in modo permanente i dati sui supporti di archiviazione sottostanti) e il sistema operativo offre questo servizio a qualsiasi programma in esecuzione sul computer.

Non è nella descrizione del lavoro di base di un file system occuparsi della crittografia e, sebbene ci siano alcuni file system che offrono la crittografia nativa, di solito sono altri livelli che se ne occupano.

Al ransomware non interessa nulla di tutto ciò, però. Anche se hai un file system che non esegue la crittografia nativa e anche se hai rimosso qualsiasi software aggiuntivo che fornisce un livello di crittografia (come Truecrypt, Veracrypt ecc.), Il codice ransomware stesso utilizzerà l'interfaccia fornita dal sistema operativo per accedere ai file sul filesystem e crittografarli. Non c'è niente che ti proteggerà in modo affidabile da questo tranne il diligente backup dei tuoi dati, in modo che tu possa ripristinarlo se necessario.

Avvertenza: anche i ransomware particolarmente pericolosi cercheranno di crittografare il backup.
Sì, dovrai implementare uno schema di backup generazionale e non mantenere tutte le generazioni sullo stesso supporto di backup.Inoltre, sarebbe utile eseguire alcuni semplici controlli statistici durante il backup dei dati;se sembra completamente casuale (il che significa che è crittografato), è necessario interrompere immediatamente il backup e ripristinare invece il sistema a uno stato sicuro noto.
@Pascal i tuoi controlli potrebbero dover cercare specificamente le intestazioni di file compressi di grandi dimensioni poiché questi avranno una grande percentuale di dati apparentemente casuali.Ma ovviamente il ransomware potrebbe scrivere intestazioni nei file crittografati.E la casualità è difficile da misurare nel migliore dei casi.
La casualità è abbastanza facile da misurare: invia i dati attraverso una libreria di compressione dei dati e se non si comprime affatto, questo è un buon segno di casualità.Un altro sarebbe una distribuzione uniforme di tutti i valori di byte.Un'altra euristica che potrebbe causare un avviso sarebbe una diminuzione dei file identificati come file di testo rispetto a un istogramma precedente.Per quanto riguarda i file compressi: potresti semplicemente decomprimerli e controllarne il contenuto, proprio come gli scanner antivirus.Ma hai ragione che se hai a che fare con dati che consistono principalmente in dati compressi, dovresti stare attento.
The Spooniest
2017-05-15 18:43:52 UTC
view on stackexchange narkive permalink

Idealmente, i dati crittografati dovrebbero essere indistinguibili da dati casuali . Non si tratta di "nascondere" se i dati crittografati sono presenti o meno (questa è la steganografia; ne parleremo più avanti) ma si tratta di garantire che un utente malintenzionato non possa trovare schemi nei dati che potrebbero, a loro volta, essere utilizzati per capire la chiave per decrittografarlo.

Ciò causa problemi al sistema desiderato, perché i dati casuali potrebbero, in teoria, contenere qualsiasi sequenza di bit . Non è necessariamente probabile che una stringa casuale di bit risulti essere, ad esempio, un JPEG casuale, ma è successo. Combina questo con la steganografia, in cui i dati sono nascosti all'interno di altri dati (spesso utilizzati per nascondere dati crittografati all'interno di altri dati non crittografati), e la situazione sembra più cupa per il tuo scenario.

Per questo motivo, ci non è realmente un modo per stabilire se un dato dato è criptato o meno, o contiene un altro dato che potrebbe essere criptato . La cosa più vicina a un filesystem che non può assolutamente contenere dati crittografati è uno che non può contenere alcun dato e ci sono pochissimi usi per un filesystem come quello.

_Non è probabile [...] che una stringa casuale di bit risulti essere [...] un JPEG casuale, [ma è successo] (http://riii.me/5knk0) ._ Per un ** definizione molto ** ampia di "casuale", sì.Il processo effettivo è stato un po 'più complicato ed è stato "spinto" verso un file JPEG valido.C'è ancora una possibilità molto, molto, _molto_ scarsissima che qualsiasi sequenza casuale di bit sia un JPEG valido (dove dipende da ciò che definisci una 'possibilità molto, molto, _molto_ scarsa' essere) ma estraendo bit casuali dal nulla senzaquesto "aiuto" extra non avrebbe portato a JPEG _quello_ veloce.
+1 una cosa da aggiungere è che anche i file compressi sembrano dati casuali, proprio come i file crittografati (specialmente se il lettore non conosce l'algoritmo di compressione).
Karl Bielefeldt
2017-05-16 07:41:47 UTC
view on stackexchange narkive permalink

Come altri hanno detto, non è possibile impedire la crittografia a livello di filesystem, ma l'alternativa più vicina che non ho già visto menzionata è Controllo di accesso obbligatorio.

Fondamentalmente, puoi impostare autorizzazioni extra in modo che le tue applicazioni che hanno accesso a Internet abbiano un accesso estremamente limitato al tuo disco. Il tuo browser web, ad esempio, potrebbe essere configurato per essere in grado di scrivere solo nelle sue impostazioni, nella cache e in una directory di download. Qualsiasi tentativo da parte di quel processo di scrivere al di fuori di quelle cartelle verrebbe negato dal sistema operativo.

Quindi cosa succede se una vulnerabilità viene sfruttata è invece che l'intero disco viene crittografato, solo la directory dei download può essere crittografata. Ovviamente non è sicuro al 100% (niente lo è), ma è un altro livello che gli aggressori di solito non si aspettano.

Lo svantaggio è che è difficile da configurare e scomodo da mantenere, e dopo un po 'sembra inutile gli attacchi di alto profilo lasciano gli occhi del pubblico.

Thomas Carlisle
2017-05-15 03:55:13 UTC
view on stackexchange narkive permalink

Immagino che il tuo ragionamento sia dovuto alla preoccupazione di essere vulnerabile al ransomware. Se non è così, anche la mia risposta diventa "perché"? Tutti i file system che supportano la crittografia offrono le opzioni per non utilizzarla. In questo modo non hai l'overhead che rallenta gli accessi ai tuoi file e non devi preoccuparti del danneggiamento del disco che rende illeggibile l'intero file system.

Non credo che nessuna delle varietà di ransomware sfrutti le capacità di crittografia dei file system. Fanno da soli, quindi disabilitare la crittografia a livello di file system non aiuterà.

Per impedire al ransomware di crittografare i file, dovresti rendere il tuo file system di sola lettura o giocherellare con le autorizzazioni. Potresti toglierti la possibilità di scrivere / modificare / cancellare i tuoi file di dati e in particolare concederti quei diritti solo quando vuoi aggiornare un file. Non molto fattibile. Recentemente ho fatto una piccola prova di concetto con un tipo di app lockbox, che rimuoverebbe tutte le autorizzazioni di modifica a una cartella rendendola di sola lettura per te, gli amministratori, ecc. Quindi, quando vuoi abilitare la tua capacità di modificare i file, sblocchi la cartella.

Non sono andato molto oltre perché ancora non vedo che sia fattibile dal punto di vista dell'utente.

La migliore protezione dal ransomware continua ad essere quella di eseguire frequenti backup dei file. Windows 7/10 ha la funzionalità "versioni precedenti" che è piacevole perché mantiene una cronologia dei file mentre cambiano. Quindi se i tuoi file vengono crittografati, cancellati, ecc. Una settimana fa, ma non l'hai notato fino ad oggi, troverai comunque le versioni non danneggiate.

Potresti configurare Windows 7/10 per attivare l'UAC quando i tuoi file di dati vengono modificati se metti quei file nella cartella "Programmi".

rackandboneman
2017-05-17 11:55:32 UTC
view on stackexchange narkive permalink

Se la preoccupazione è di impedire che i file vengano resi inaccessibili, un filesystem con versione (come aveva VMS), impostato in modo che l'eliminazione delle vecchie versioni non sia banalmente possibile, è probabilmente la soluzione migliore.

questo non è coperto dalla risposta accettata?sembra più un commento poiché non affronta la parte della crittografia ma punta alla tangente


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...