Domanda:
Come impedire a una società di hosting di accedere alle chiavi di crittografia di una VM?
Benjamin
2019-08-26 14:03:22 UTC
view on stackexchange narkive permalink

Voglio prevenire il potenziale furto della mia applicazione web (codice sorgente + database) da parte della mia società di hosting locale, di cui non mi fido completamente per qualche motivo (ma non ho altra scelta che usare come danno, di gran lunga , la migliore latenza qui).

Ho intenzione di crittografare una partizione con cryptsetup e memorizzare la directory web + i file di database lì.

L'unico problema è che dovrò sbloccare la partizione ad ogni riavvio (anche quelli non controllati), prima di poter avviare i server di database web &; ma immagino di essere pronto a conviverci per ora.

Tuttavia, per quanto posso leggere in tutto il Web, le chiavi di crittografia sono archiviate così come sono in memoria, e può essere letto con accesso fisico alla macchina, anche da una macchina dedicata utilizzando attacchi di avvio a freddo. Su una VM, immagino che questo sia ancora più semplice, poiché l'hypervisor può acquisire un'istantanea dell'intero stato del server (memoria + RAM).

Per quanto ne so, dovrebbe essere abbastanza facile da eseguire un dump della memoria e individuare la chiave di crittografia in qualsiasi momento.

Esiste un modo per impedirlo?

So che il controllo dell'hypervisor fornisce un enorme vantaggio per chi tenta di rubare dati, e come tale non sto cercando una soluzione perfetta qui; ma sto piuttosto cercando di rendere il più difficile possibile l'accesso ai dati, in modo che non sia economicamente sostenibile spendere tempo con le risorse di & per ottenerli.

Non sono molto ottimista qui, poiché le chiavi di crittografia devono essere archiviate in qualche forma in memoria per la decrittografia, ma spero di essermi perso qualcosa.


Modifica - chiarimento

Dal mio commento di seguito:

Sono sicuro che gli hypervisor della società di hosting non vengono modificati in alcun modo per eseguire operazioni dannose; la loro attività è l'hosting, non il furto di oggetti e l'azienda è relativamente affidabile. Quello che sto cercando di proteggere è qualcuno che corrompe un dipendente per vendergli un'istantanea dei dati. Finché la chiave di crittografia non può essere recuperata da nessuna istantanea che può eseguire l'hypervisor di serie, considero la soluzione abbastanza buona per il mio caso d'uso.

Se la crittografia omomorfica diventerà possibile, sono sicuro che qualche società di hosting offrirà un hosting VM sicuro.
La crittografia omomorfica di @user non è una formula magica per "calcolare le cose su supporti non affidabili".
... perché preoccuparsi delle chiavi di crittografia, quando il codice / database verrà decrittografato durante l'esecuzione?Cioè, basta eseguire l'istantanea direttamente del codice decrittografato.
@Clockwork-Muse Se stai parlando del codice eseguibile (opcode) che risiede in memoria, pagine di memoria del server database e cache del disco, allora sì, almeno una parte del codice sorgente + database sarà in memoria durante lo snapshot.Tuttavia, considero il codice sorgente e il database preziosi solo nel loro insieme, non come un puzzle da 1.000.000 di pezzi su cui si impiegherebbero mesi a cercare di dare un senso.Finché il lavoro per recuperare qualcosa di utile dall'istantanea non è banale, sono felice.
Basta affittare un piccolo appartamento vicino alla posizione del datacenter (poiché è noto per dare bassa latenza alla tua area di destinazione) e ottenere un abbonamento Internet appropriato e ospitarlo tu stesso?
Hai provato a chiedere all'azienda quali misure adottano per impedire a un singolo dipendente malintenzionato di fare qualcosa di simile?
cancellato una risposta applicabile, dimostrato di funzionare - perché questa domanda è in qualche modo ipotetica e basata su nient'altro che paranoia della sicurezza ... probabilmente non cerca nemmeno una soluzione.
@MartinZeitler Se solo potessi capire il tuo commento, forse potrei rispondere.
Otto risposte:
#1
+109
Lie Ryan
2019-08-26 14:29:11 UTC
view on stackexchange narkive permalink

Non puoi, chiaro e semplice. Se non ti fidi della società di hosting, non ospiti con loro. Questa è la legge n. 3 della 10 legge immutabile della sicurezza:

Legge n. 3: se un malintenzionato ha accesso fisico illimitato al tuo computer, non è più il tuo computer .

L'hypervisor ha sempre una posizione privilegiata sulla tua macchina virtualizzata, non puoi proteggerti da hypervisor canaglia.

Un modo che puoi fare per trarre vantaggio dalla loro posizione di rete ma mantenere al sicuro il tuo codice significa fare un hosting di colocation. In un hosting in colocation, porti la tua macchina che metti nel data center di qualcun altro.

La stessa colocation di base dovrebbe scoraggiare la maggior parte degli attaccanti opportunisti, ma un attaccante mirato / determinato potrebbe comunque connettersi alla tua macchina. Se questo è un problema per te, dovresti mettere la tua macchina in un involucro del server a prova di manomissione / a prova di manomissione, in modo che l'unica porta sbloccata verso il mondo esterno sia il cavo di alimentazione e il cavo di rete, e tu crittografi tutto il traffico di rete in corso dentro / fuori dalla macchina. In questo modo puoi inserire la tua macchina nella sua rete e trarre vantaggio dalla bassa latenza della rete e non saranno in grado di rubare dati dal tuo server a meno che non rompano lo chassis del server.

Se la protezione dei dati molto importante, vorresti anche fare un controllo regolare che il caso non sia stato manomesso. Se si dispone di un budget infinito, potrebbe anche essere possibile progettare chassis a prova di manomissione che hanno vari sensori che possono attivare un allarme e avviare l'arresto (scartando tutte le chiavi sensibili / crittografiche) se rilevano che lo chassis è stato manomesso, ma ovviamente questi diventano costosi molto rapidamente.

... e il passo successivo, ovviamente, è creare la tua struttura di hosting, completa di tutto ciò che è fisico (serrature, porte, ...), elettronico (sistemi di allarme, telecamere di sorveglianza, ...) e umano (guardie, receptionist, ...) sono necessari elementi di sicurezza per garantire un adeguato livello di sicurezza.Certo, diventa costoso molto velocemente, ma ehi, qual è il prezzo per una buona notte di sonno comunque?
Ho un budget limitato, quindi sto cercando una soluzione "abbastanza buona" che renda non economicamente fattibile tentare di decrittografare i dati.Che dire di [TRESOR] (https://www.cs1.tf.fau.de/research/system-security-and-software-protection-group/tresor-trevisor-armored/?q=content%2Freadme), che sembramantenere la chiave di crittografia nei registri della CPU e non nella RAM?
@Benjamin: TRESOR presume che l'hypervisor sia affidabile.Un hypervisor inaffidabile può fingere in modo che il tuo programma pensi che stia eseguendo codice sulla CPU, ma scopre che le tue istruzioni sono effettivamente in esecuzione su una CPU emulata il cui comportamento e registri di debug sono completamente controllati dall'aggressore.
@LieRyan Potrei conviverci.Sono sicuro che i loro hypervisor non vengono modificati in alcun modo per fare questo genere di cose, poiché la loro attività non è rubare cose e l'azienda è * relativamente * affidabile.Quello che sto cercando di proteggere è qualcuno che corrompe un dipendente per vendergli un'istantanea dei dati.Finché la chiave di crittografia non può essere recuperata da nessuna istantanea che può eseguire l'hypervisor di serie, per me va bene.
@Benjamin: la macchina host è privilegiata sulla macchina guest.È abbastanza semplice per l'hypervisor in esecuzione sulla macchina host leggere i registri di debug della vcpu guest.Questo non è nemmeno difficile poiché molti hypervisor supportano l'API di debug guest che include la lettura dei registri di debug tra le altre cose.Anche in hardware reale, l'attaccante può allegare un debugger JTAG per leggere i registri di debug.Questo tipo di attacchi si colloca ben al di fuori del modello di minaccia di TRESOR, ma sarà rilevante per il tuo.
Quello.Se fossi quel dipendente della società di hosting canaglia ... beh, non accetterei la tangente, ma se i cattivi avessero un membro della mia famiglia in ostaggio, * potrei * ottenere un deposito di registro.E potrebbe farlo in un modo completamente non rilevabile, supponendo che l'hypervisor in questione supporti la migrazione in tempo reale o gli snapshot (dell'intero sistema / live).Scarica lo stato dell'hardware (emulato), copia i dati su un supporto personale e torna ad analizzarli in un secondo momento.E non sono un pentester o uno specialista di RE, solo un ingegnere di sistema con un po 'di esperienza nell'amministratore di sistema e in C.
@LieRyan Bene, alcune schede in realtà hanno un'opzione per disabilitare fisicamente JTAG bruciando cose all'interno del chip, ma tu mantieni il tuo punto di vista poiché rende le cose molto più complicate.
A rigor di termini, è possibile utilizzare l'attestazione remota ed eseguire tutti i calcoli sensibili in un'enclave SGX (e SGX disabilitato JTAG), ma sarebbe difficile da realizzare, necessitando di una riscrittura completa dell'hypervisor.Almeno sposterebbe la fiducia dal tuo host VM all'hardware Intel.L'unica soluzione completa di cui sono a conoscenza è vCage, che è commerciale e piuttosto costosa.L'unico problema è che non disabilita JTAG, per quanto ne so.
@LieRyan TRESOR non funziona correttamente con un hypervisor.Ho lavorato a una patch per far sì che KVM supportasse TRESOR senza un enorme calo delle prestazioni, e non è banale.Ma hai ragione sul fatto che non protegge comunque da un host dannoso.Protegge solo dalla RAM da _read_ (ad esempio un attacco di avvio a freddo).
@val È il chipset che lo supporta, ma di solito è necessario il chip Intel in modalità di produzione per impostare quei fusibili OTP.Tuttavia, praticamente _tutte_ le CPU Intel non consentono JTAG senza una password specifica per numero di serie che può essere ottenuta solo firmando un NDA con Intel.Ma un NDA non è una barriera di sicurezza!
@Benjamin: [Ecco Jeff Atwood] (https://blog.codinghorror.com/the-cloud-is-just-someone-elses-computer/) sui prezzi dei colori che sta pagando._Qualcuno_ ha ancora il potenziale per l'accesso fisico al tuo computer, ma dovrebbe armeggiare con il tuo hardware per ottenere un dump della memoria.
Ci sono chassis con un interruttore aperto che nota quando il pannello laterale è stato aperto.È utile per rilevare quando qualcuno potrebbe aver rubato la RAM da un desktop in un laboratorio informatico o qualcosa del genere (se accede al firmware senza che la CPU sia accesa), ma probabilmente anche per questo se il software può essere avvisato.
@aCVn c'è un passaggio intermedio: assumere una guardia che si trova accanto alla macchina fisica collocata nel loro datacenter ^^
#2
+19
Graham
2019-08-27 04:35:42 UTC
view on stackexchange narkive permalink

in modo che non sia economicamente sostenibile spendere tempo con le risorse di & per ottenerle.

Odio dirlo a te, ma semplicemente non sei così importante . Nessuno conosce te o la tua app web. Quindi non è già economicamente sostenibile.

Considera il rapporto costi-benefici. Per la società di hosting, se ciò accade una volta , i clienti potrebbero emorragia. Quindi avranno registri appropriati. Qualsiasi dipendente sorpreso a farlo non solo verrà licenziato, ma anche arrestato. Quindi la tangente dovrebbe essere seria . Parliamo di milioni, perché deve risarcire il dipendente per essere stato imprigionato e non essere più in grado di lavorare una volta rilasciato. E se questa è la tangente, la tua azienda deve valere almeno 10 volte tanto. Ciò valorizza la tua azienda nell'ordine di decine di milioni e più probabilmente centinaia di milioni.

Onestamente, vale la pena per la tua azienda? Tutto quello che hai detto finora dice che non lo è. E se lo è, non hai motivo di non eseguire i tuoi server.

-1 per _Mi odio dirtelo, ma semplicemente non sei così importante_.Le persone che presumono che siano le persone che finiscono per essere fregate di più.Anche se l'OP non è così importante, l'OP potrebbe avere accesso a qualcosa che lo è (forse lavorava presso un importante ISP e un malintenzionato sta cercando ex dipendenti che potrebbero avere vecchie credenziali salvate).
Sì e no.Certo, potresti non essere importante tu stesso, ma potresti essere solo un trampolino di lancio in un [watering hole attack] (https://en.wikipedia.org/wiki/Watering_hole_attack)
Hai perfettamente ragione, l'azienda è piuttosto piccola e il progetto non è così importante.Tuttavia, il database contiene un discreto numero di clienti dell'intera isola e l'app ha impiegato molte migliaia di ore di lavoro per scrivere.Inoltre, non mi fiderei che l'azienda stia effettivamente conservando i registri delle azioni dei propri dipendenti o che il dipendente in questione stia rischiando qualcosa (per non parlare della prigione) se entrasse nel nostro server.Pertanto non sarei sorpreso se qualcuno vendesse effettivamente un'istantanea per un paio ** migliaia **, non milioni.Questo è ciò da cui sto cercando di proteggermi.
@Benjamin Quindi è necessario verificare che la società * stia * conservando quei registri ed è necessario verificare che il meccanismo di controllo esista per visualizzare tutte le azioni amministrative sulle VM.Soprattutto se ti trovi in un paese con leggi sulla privacy (GDPR è quello ovvio; fai affari con clienti europei?), La sicurezza dei tuoi clienti dipende dalla sicurezza della tua società di hosting.E se hai davvero un'opinione così bassa della tua società di hosting, non dovresti usarli, indipendentemente dalla loro latenza.
@forest Questo è un ipotetico stretching what-if.L'OP cerca sicurezza nel suo progetto attuale.Certo, lui stesso ci ha messo molto impegno, ma questo non significa che sia un giocatore significativo in quel settore, né che i suoi concorrenti si preoccupino abbastanza da fare di tutto per sabotarlo.Il ransomware sarebbe una possibilità, ma poi come piccola startup non avrà i soldi per ripagare molto (altrimenti non userebbe questa società di hosting).E se il problema è la sicurezza dei dati riservati dei clienti, semplicemente non dovrebbe ospitare tali dati su un server non attendibile.
@Gaius Come?Non si tratta di sicurezza dell'utente, ma di sicurezza dell'hosting del server.
@graham il presupposto che non sarai attaccato se non sei importante non è sicuro
@Gaius L'attacco alla pozza d'acqua non è rilevante per la sua situazione.E anche se sono d'accordo sul fatto che non è sicuro presumere di non essere attaccati, la sicurezza è * sempre * una funzione del costo e della probabilità.Come ingegnere dove "sicurezza" nei miei progetti ha significato "la gente muore", ne sono più consapevole della maggior parte degli altri!:) L'OP deve decidere cosa è "abbastanza sicuro" data la probabilità di * questo specifico vettore di attacco * e, a meno che non ci siano altri fattori, la probabilità appare incredibilmente bassa.Ovviamente se la sua azienda diventa grande, deve rivalutare, ma probabilmente può anche permettersi un hosting migliore.
#3
+11
interfect
2019-08-26 23:45:31 UTC
view on stackexchange narkive permalink

In teoria, dovresti essere in grado di utilizzare le funzionalità hardware affidabili delle moderne CPU per eseguire la crittografia del disco, o anche l'intera VM, all'interno di una parte della CPU a prova di manomissione, con tutti i dati su disco e in memoria crittografati con chiavi accessibili solo all'interno di quell'enclave affidabile a prova di manomissione.

Sebbene l'esposizione del sistema di elaborazione affidabile SGX di Intel alle VM non sembra essere possibile sugli hypervisor di serie, AMD ha una funzione chiamata Secure Encrypted Virtualization, o SEV, che suona esattamente come stai cercando: puoi configurare la tua VM in modo tale che sia protetta dall'hypervisor con chiavi note solo a AMD o qualcuno che è disposto e in grado di smontare la CPU host.

Sfortunatamente, è improbabile che la particolare società di hosting che devi utilizzare fornisca host che supportano AMD SEV o renda la funzionalità disponibile ai propri clienti.

Interessante, grazie.Tuttavia, non c'è alcuna possibilità che questa società di hosting lo utilizzi.
Comunque, per quanto riguarda la faccenda di SEV, leggendola velocemente, non sembra dimostrabile che l'host la stia davvero usando.Cosa fermerebbe un server dannoso che esegue la VM su un sistema emulato che finge di utilizzare SEV ma falsifica semplicemente le istruzioni appropriate?
@Vality se il tuo provider di hosting ti dà accesso alla macchina di hosting e sei tu a configurare il server con SEV, questo _potrebbe_ funzionare.
@Vality Come descritto in https://github.com/AMDESE/sev-tool#guest-owner, sembra che tu crittografi (la parte sensibile) della tua VM con una chiave condivisa tra te e l'hardware affidabile nella CPU, quindi ili dati possono essere utilizzati solo in un guest che esegue l'immagine specificata.La verifica dell'immagine viene eseguita in qualche modo come l'avvio sicuro, penso, tranne che invece del TPM che verifica le misurazioni sul processo di avvio dell'host, tu stesso verifichi e approvi i parametri di misurazione sul processo di avvio della VM.
@Vality È possibile verificarlo proprio come è possibile verificare che un TPM sia reale e non emulato (per un TPM, tramite la sua chiave di verifica dell'autenticità).Non sono sicuro di come lo faccia SEV, o anche se AMD supporta l'attestazione remota oltre al semplice controllo del firmware, ma potrebbe.
#4
+4
Gaius
2019-08-26 23:50:17 UTC
view on stackexchange narkive permalink

Microsoft ha una possibile soluzione per questo chiamato VM schermate, queste sono specificamente destinate al vettore di attacco che un attore malintenzionato ha accesso amministrativo all'hypervisor. Un esempio di ciò sarebbero le macchine distribuite nel cloud o in un colo.

Lo svantaggio è che dovrai mantenere un Guardian Server sotto il tuo controllo fisico. Potrebbe essere eccessivo per le tue esigenze.

Ancora più eccessivo è IBM Secure Service Container.Funziona su una macchina LinuxONE (il costo parte da circa 100k, se ricordo bene) ...
Purtroppo non ho assolutamente alcun controllo sulla scelta dell'hypervisor!
#5
+4
jpa
2019-08-26 23:54:00 UTC
view on stackexchange narkive permalink

Non mi fido completamente per qualche motivo

In che modo mi fido di loro? Credi che possano essere incompetenti o pensi che possano essere dannosi?

Se semplicemente incompetenti, probabilmente otterrai una ragionevole protezione dal crittografia che hai descritto. È ovviamente possibile che il loro computer host venga compromesso e l'attaccante trovi un modo per afferrare le chiavi di crittografia correnti dalla RAM, ma nei tipici compromessi dell'host web gli aggressori non andranno così lontano. Troveranno semplicemente un posto facile per scaricare il malware o per acquisire le password.

Ma se sono attivamente dannosi, non puoi proteggere i dati sulla VM. Nella migliore delle ipotesi, potresti configurarlo come un server proxy, che potrebbe darti i vantaggi della latenza senza esporre il tuo database e il codice sorgente.

Come chiarito nella domanda, stavo pensando a un dipendente malintenzionato che sarebbe stato corrotto per ottenere un'istantanea e consegnarla a qualcuno in cambio di denaro.Per quanto riguarda il server proxy, ho pensato anche a questa idea;questo può essere un ragionevole fallback se tutto il resto fallisce.Ovviamente non tutto può essere memorizzato nella cache dal proxy, specialmente in un'applicazione web, ma se fornisce l'80% o il 90% delle prestazioni percepite, questo può essere abbastanza buono.Ciò richiederebbe una revisione approfondita dell'applicazione, tuttavia, poiché finora non è stata costruita pensando al caching.
#6
+4
R.. GitHub STOP HELPING ICE
2019-08-27 03:55:07 UTC
view on stackexchange narkive permalink

La risposta di Lie Ryan è quella giusta, ma oltre alla colocation, che ha ancora una superficie di attacco fisico presso la sede dell'host, un'ulteriore possibilità è utilizzare il provider di hosting solo per ottenere un indirizzo IP pubblico e collegarlo a un server locale tramite un collegamento a banda larga di classe aziendale o domestico decente.

Se vuoi essere davvero stravagante, puoi persino adottare un approccio misto in cui le chiavi private per i certificati non lasciano mai le tue il server locale e il server sul sito di hosting ha accesso solo per generare le chiavi di sessione. Cloudflare offre qualcosa di simile; Tuttavia, non sono sicuro di come funzioni. Penso che sia persino possibile (non con le loro, ma se si rotola da soli, facendo un uso fantasioso di primitive crittografiche) avere i dati sul sito di hosting, ma crittografati con chiavi simmetriche che non sono mai sul sito di hosting e consegnando il connessione al sito di hosting in modo tale che solo il cliente, ma non il sito di hosting, possa decriptare i dati.

È descritto su https://www.cloudflare.com/learning/ssl/keyless-ssl/
#7
+1
Jas Panesar
2019-08-28 19:18:49 UTC
view on stackexchange narkive permalink

Il cloud in definitiva è il computer di qualcun altro e le regole di qualcun altro. Se stai cercando la sicurezza dell'accesso fisico, il percorso migliore potrebbe essere ospitare il tuo server fisico o ottenere un server fisico dedicato. Con tutti gli strumenti disponibili per orchestrare tutto questo oggi e il fatto probabile che vorrai ospitare progetti per molto tempo, non è una cattiva idea ..

#8
  0
Dennis Jaheruddin
2019-08-27 19:44:05 UTC
view on stackexchange narkive permalink

La tua domanda sembra cambiare ritmo alcune volte, ma se la tua preoccupazione principale è qualcuno che clona il tuo lavoro, la seguente dovrebbe essere una semplice protezione:

Assicurati che non ci sia nulla di interessante da rubare

Invece di lasciare che il codice sorgente di tutto risieda sulle loro macchine, lavora sul codice in un ambiente diverso e distribuisci solo i binari.

Ciò dovrebbe impedire a chiunque di copiare il tuo lavoro poiché non può aggiornare il binari, se sei veramente paranoico potresti persino inserire una bomba a orologeria nella logica per assicurarti che le cose smettano di funzionare anche se copiano la versione corrente.

Tieni presente che anche se una quantità considerevole del tuo codice deve risiedere nel server, diventa già finanziariamente poco attraente se si è in grado di impedire a chiunque di utilizzare una o due parti fondamentali. Ovviamente possono essere decodificati, ma è probabile che sia proibitivo.


Questa soluzione ovviamente non offre protezione contro la fuga di dati, ma in base alla tua domanda sembra che prevenire la concorrenza sia più una preoccupazione che i dati diventino pubblici.

Il codice è scritto in PHP, quindi codice sorgente == codice di produzione.Al momento non c'è modo di spedire solo gli opcode compilati (che dipendono dalla macchina), e anche se ci fosse, decompilare gli opcode probabilmente ti porterebbe qualcosa di molto vicino al codice sorgente in questo linguaggio.Gli offuscatori del codice PHP di solito non sono nemmeno lontanamente dalla qualità della produzione e rovinano ogni possibilità di eseguire il debug di qualsiasi problema sul server stesso.E infine, non voglio nemmeno che il database venga rubato!
In tal caso capisco che non funzionerà per te, ma lascerò questa risposta qui in quanto potrebbe aiutare i futuri visitatori con la stessa domanda in un contesto diverso.


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