Nell'era dei cryptolocker, è possibile impedire a Windows di modificare la partizione Linux?

A meno che la virtualizzazione impedisca fisicamente al sistema di opreating di vedere il dispositivo come tale (ad esempio che il "disco" sia realmente un VHDX o simile), la risposta è "sì, ovviamente". Non c'è nulla di speciale e non puoi fare nulla per evitare che ciò accada, una volta che il malware ha acquisito i privilegi di amministratore.

Non saprei a memoria come aprire il dispositivo sotto Windows (qualcosa come \device\harddisk1 o così?), ma ho sicuramente sovrascritto il dispositivo raw sotto Linux più di una volta. Qualcosa come cat /dev/random > /dev/sda ha funzionato "bene", come ... per sempre , assumendo che tu abbia effettuato l'accesso come root . Questa è la cancellazione sicura da parte del povero in mancanza di qualcosa di meglio.

L'installazione di un boot loader (che è la parte 1 del ransomware) non è altro che fare proprio questo, solo con dati non casuali. Sovrascrivi il boot loader con un tuo binario che mostra il testo "pay me, sucker".
Si noti che questo bootloader (né la parte encrypt / decrypt, se esiste una parte di decrypt) deve essere in grado di accedere alla partizione o al filesystem in modo significativo.

Crittografare (o ingarbugliato, l'utente non può davvero dire una differenza) è la seconda parte, e questo è altrettanto facile. Se è possibile scrivere un boot loader, è possibile scrivere settori. Quindi, invece dei file, criptare settori sul dispositivo raw. A chi importa della struttura logica all'interno di quei settori quando puoi renderli inutilizzabili in entrambi i casi? Tipo di partizione diverso, diverso filesystem? Non ti potrebbe importare di meno. Qualcuno che vuole usarli deve sapere, non è necessario saperlo.
Questo è qualcosa che il malware può fare in pochi secondi, non c'è nemmeno bisogno di essere segretamente o super-intelligente. Non è necessario mantenere un profilo basso per evitare il rilevamento. Nel momento in cui l'utente nota anche la luce che lampeggia furiosamente sul computer e si chiede cosa può succedere, il malware avrà già sovrascritto centinaia di megabyte (dozzine di gigabyte) di dati. Se il writer di malware possiede solo una minima quantità di intelligenza, questo è sufficiente per sovrascrivere i metadati del filesystem su ogni partizione inclusi i metadati di backup nei rispettivi offset noti e un paio di centinaia di megabyte di file effettivo contenuti.
Certamente, con solo i metadati sovrascritti, è in linea di principio ancora possibile recuperare il contenuto dei file non ancora sovrascritti, ma questa è una cosa eccessivamente costosa da fare, e ben oltre le capacità dell'utente medio (e potrebbe essere impossibile per piccoli file su alcuni file system.

Non è nemmeno necessario crittografare correttamente, puoi anche sovrascrivere i settori con i dati inutili. L'utente non può dire una differenza, si rende conto solo dopo aver pagato se è così stupido da pagare un criminale nella speranza che il criminale si difenda dalla sua parola .

Quindi ... sì, tecnicamente questo non è assolutamente un problema (per la maggior parte dei computer di proprietà della maggior parte delle persone).

Versione breve: Probabilmente no , supponendo che il virus sia in grado di montare la partizione da sola.

Versione lunga : in un determinato computer in cui sono presenti partizioni separate, Windows e Linux non sono realmente "consapevoli" del fatto che l'altra partizione contiene un sistema operativo diverso. Loro potrebbero capirlo, ma se lo desideri puoi montare la partizione come qualsiasi altra e modificare il file system.

Se riesci a farlo da solo, non devi impedire a un virus di farlo, supponendo che sia in grado di verificare la presenza di partizioni non montate da montare. La tua unica vera scommessa è sperare che non possa farlo o mettere i tuoi SO su dischi separati, che dovresti rimuovere quando apri Windows.

Con un po 'di fortuna il nuovo sistema di Windows 10 impedirebbe un simile attacco ma non ne è sicuro.

Sì.

I pezzi tecnici necessari per farlo sono disponibili oggi (e lo sono stati, da qualche anno a questa parte). Infatti grub (uno dei più popolari boot loader su Linux) viene fornito con il supporto per molti file system in un piccolo pezzo di codice. Per qualcuno capace di scrivere cryptolockers (usandolo come termine generico) senza copia-incolla, non è un affare troppo grande.

Se non l'hanno già fatto, sarà fatto (entrando nel regno delle previsioni, scusa) non appena qualcuno pensa che sia utile. FWIW, gli autori di malware devono mantenere il loro codice il più compatto possibile (sia in termini di dimensioni che di comportamento) per eludere il rilevamento, quindi questo potrebbe essere un fattore possibile contro di esso.

Gli scenari in cui diversi sistemi operativi coesistevano nello stesso computer sono la virtualizzazione e il multi-boot.

Nel caso della virtualizzazione di tipo 1 (non esiste una macchina host, ovvero virtualizzazione bare metal), i sistemi sono isolati gli uni dagli altri attraverso il sistema di virtualizzazione.

Nel caso della virtualizzazione di tipo-2 (una macchina host e macchine guest virtualizzate), una macchina guest non può accedere direttamente ai file nella macchina host. D'altra parte, la macchina host può crittografare l'intero file system della macchina guest. In ogni caso, poiché il file system della macchina ospite è un file stesso nella macchina host, non è un caso diverso dal malware cryptolocker attuale.

Infine, per lo schema multi-boot. Un malware è in grado di montare altre partizioni di sistema nello stesso modo in cui l'utente esegue e crittografa i file (o anche l'intera partizione senza montare!). Ma la protezione per questo scenario è molto più difficile da raggiungere.

Ogni sistema operativo gestisce le autorizzazioni concesse da solo, ovvero se l'utente avvia un sistema Linux e monta una partizione Windows, le autorizzazioni dal sistema Windows non vengono conservate e viceversa.

Se la restrizione è stata implementata a livello di sistema operativo, potrebbe essere aggirata o rimossa da un utente o da un processo con privilegi sufficienti. Pertanto dovrebbe essere controllato da qualche elemento fuori dal controllo del sistema operativo.

AFAIK, UEFI non offre protezioni per lo scenario che descrivi, ma ha conoscenza delle partizioni disponibili e funziona come livello di astrazione per comunicare con l'hardware. Quindi penso che le autorizzazioni potrebbero essere implementate lì, ma forse richiede modifiche all'architettura.

Detto questo, i sistemi multi-boot IMO sono qualcosa che ha un numero limitato di utenti finali e non qualcosa che la maggior parte dei computer ha (la maggior parte degli utenti finali e ambienti aziendali). Un malware con le funzionalità che hai menzionato sembra troppo complesso per un target così piccolo.

L'unica protezione possibile è la regola meno privilegiata. Se il ranswomware può ottenere un privilegio di amministratore (o privilegiare la scrittura sulla partizione del disco raw) su una macchina, sarà in grado di fare qualsiasi cosa su qualsiasi disco. Non ha nemmeno bisogno di capire quale file system si trova lì né montare la partizione, ma semplicemente crittografare tutto a livello di settore. AFAIK, non è raro che cryptolocker provi ad accedere a partizioni raw dist, ma dato che non è molto difficile da fare - tranne per la domanda privilegiata - potrebbe essere aggiunto se qualche malvagio crede che ne valga la pena.