Domanda:
La sicurezza fisica è meno importante con i dischi su un server crittografati?
user93353
2015-12-29 11:05:39 UTC
view on stackexchange narkive permalink

Se potessi ottenere l'accesso fisico a un server, potresti cambiare la password root / admin anche se non conosci la password corrente.

Tuttavia con i dischi crittografati, non penso che questo sia possibile (o lo è?).

Quindi, questo significa che proteggere fisicamente il tuo server è diventato meno importante - è ancora necessario per altri motivi - ma questo motivo non è più lì?

Perché dovrebbe essere impossibile cambiare la password se il disco è crittografato? Il disco non è in modalità di sola lettura, il sistema può salvare i registri, ecc. Quindi un utente malintenzionato può modificare qualsiasi file (inclusa l'archiviazione della password) se ha accesso al server.
Capisco che le informazioni siano - probabilmente - la risorsa più preziosa per te, ed è probabile che siano preziose anche per la tua concorrenza. Ma se sei il bersaglio di un "hacktivist", criminale o gruppo terroristico che ti vuole semplicemente fuori dal gioco, lasciare un piccolo esplosivo nella stanza dei server sembra piuttosto efficace. Anche se non andiamo a quell'estremo pulire il disco, rubarli (magari sostituendoli) o installare hardware o software dannosi (come hanno sottolineato le risposte attuali) può fare molti danni.
@A.L - come individuare l'archivio delle password se il disco è crittografato.
@user93353 il server è in esecuzione, quindi le partizioni sono montate, sono leggibili e scrivibili.
Caso aperto, hotplug nella scheda PCI, dump della memoria, ricerca nella memoria dell'immagine per la password. https://www.blackhat.com/presentations/bh-dc-07/Rutkowska/Presentation/bh-dc-07-Rutkowska-up.pdf
@pjc50: Sono consapevole che è fattibile in condizioni ideali. Tuttavia, quando ho provato a collegare qualcosa sul mio PC, sono seguite scintille e fumo, quindi non sono sicuro di quanto sia facile farlo.
@MartinArgerami Caso aperto, inserimento a freddo nella scheda PCI, avvio, dump della memoria, attesa che l'utente incapace di accedere, dump della memoria, dump della memoria diff per la password, rimuovi la scheda PCI poiché, sai, l'hardware non è economico e abbiamo altro da hackerare . O, sai, keylogger USB. Nessun cacciavite richiesto.
@CandiedOrange: Stavo specificatamente rispondendo al commento di pjc50 su "hotplug". Se si tratta di rubare la password, puoi anche installare una webcam che riprende la tastiera; non è nemmeno necessario aprire il caso. O ancora più semplice, puoi [distruggere l'operatore con una chiave inglese da $ 5] (https://xkcd.com/538/).
Personalmente penso che sarebbe più facile entrare in una stazione server con pochi scagnozzi e una pistola carica piuttosto che imparare le tecniche richieste per violare la sicurezza virtuale. La differenza fondamentale sarebbe la quantità di prove lasciate indietro.
@pharap non conosci il potere del lato aggressivo passivo.
Nove risposte:
#1
+71
Adam Caudill
2015-12-29 12:33:25 UTC
view on stackexchange narkive permalink

L'accesso fisico, in molte, probabilmente nella maggior parte delle situazioni, comporta una perdita totale di sicurezza, per una serie di motivi (tutto questo presuppone dischi crittografati):

  • Furto: un utente malintenzionato potrebbe rubare il server o dischi, per attaccare al loro ritmo. Ciò consente a un utente malintenzionato di prendersi il suo tempo e non hai idea se abbia effettivamente ottenuto l'accesso ai dati.
  • Modifica fisica: se posso accedere a un server, potrei aggiungere hardware, potrebbe essere qualsiasi cosa dalla registrazione tramite USB o tastiera all'aggiunta di un'interfaccia wireless per consentire l'accesso remoto.
  • Cold Boot Attack: esistono attacchi che possono essere utilizzati per estrarre le chiavi di crittografia, consentendo la decrittografia dei dischi .
  • ecc.

Ce ne sono altri ovviamente, ma questo è solo un esempio di ciò che può accadere se un utente malintenzionato ha accesso fisico. Ci sono possibili attacchi che sono ancora alquanto teorici, come l'applicazione di immagini UEFI con backdoor e simili.

Forse la parte peggiore di un attacco fisico è che potresti non sapere nemmeno cosa è stato fatto esattamente, quindi c'è un vero problema nel poter fidarsi dell'hardware in seguito.

La parte relativa al non sapere cosa è stato fatto non è realmente specifica per gli attacchi fisici.
C'è tuttavia una probabilità dello 0% che tu possa rintracciarli e rilevare comportamenti imprevisti sulla rete o sul dispositivo immagino.
In tema di modifica fisica: con l'accesso fisico arriva l'accesso al bus PCIe, e questo dà la possibilità di sfruttare l'accesso DMA. Non penso che abbia nemmeno bisogno del sistema operativo per caricare correttamente un driver per esso, ma non importa poiché un utente malintenzionato può falsificare l'identità della carta. Un impianto PCIe può rompere efficacemente il sistema completamente aperto in un modo difficile da rintracciare.
Una volta ho avuto un'esperienza in cui tutti i firewall, router e dispositivi HSM in un sito sono stati rubati. Come puoi immaginare, non c'era solo un onere finanziario per sostituire i dispositivi che costano da $ 30.000 a $ 120.000 ciascuno, ma il fatto che i colpevoli avessero accesso alle chiavi di crittografia significava che tutti i dati dovevano essere nuovamente crittografati. Quindi la sicurezza fisica è meno importante? Diavolo, no!
JTAG, SMM, IPMI, ...
#2
+32
candied_orange
2015-12-29 11:13:31 UTC
view on stackexchange narkive permalink

L'accesso fisico è un accesso totale. Tipo. Dammi l'accesso fisico a un server con un disco crittografato e la prima cosa che farei è collegare un key logger alla tastiera per occuparmi di quella fastidiosa crittografia.

Presentati alla mia porta con un crittografato disco rigido e lo formatterò e vi caricherò i film.

La crittografia viene più comunemente sconfitta non violandola ma aggirandola. Ti protegge solo così come lo usi. Hai accesso perché hai qualcosa che ti dà accesso. Che si tratti di password, RFID, impronte digitali, qualunque cosa. Dammi l'accesso fisico mentre lo stai ancora utilizzando e scoprirò come ottenerlo.

Che tipo di keylogger installerai senza prima decriptare il disco?
presumibilmente un keylogger hardware
La cosa che richiede la password è software o firmware? In tal caso, potrebbe essere sostituito con un clone che registra la password da qualche parte. In caso contrario, è il keylogger hardware.
@EloyRoldánParedes Perché è necessario accedere al disco per installare qualcosa? Dato l'accesso fisico, puoi essere in grado di leggere e modificare qualsiasi cosa nella sua memoria mentre è ancora in esecuzione, in modo da poter leggere tutto ciò di cui hai bisogno o ottenere l'accesso root al sistema operativo e ai driver ed eseguire il keylogger in questo modo.
"Lo formatterò e ci caricherò i film". +1
#3
+11
André Borie
2015-12-29 18:37:40 UTC
view on stackexchange narkive permalink

La crittografia del disco può essere sconfitta sostituendo la macchina con una dannosa che sembra e si comporta esattamente allo stesso modo, ma il suo unico scopo è indurre l'utente legittimo a digitare la password FDE. Nel caso di un utente locale può essere semplice come un keylogger USB, nel caso di un utente remoto (inserendo la chiave tramite SSH) è necessario estrarre le chiavi private SSH (che si trovano nella parte non crittografata della memoria poiché La chiave FDE non è ancora disponibile), quindi avvia il tuo SSHd con quella chiave e attendi che l'utente ritorni.

#4
+10
John Deters
2015-12-29 12:27:28 UTC
view on stackexchange narkive permalink

Cold Boot Attack è stato utilizzato sui laptop per bloccare la crittografia del disco e funzionerebbe sicuramente sui server. Ci sono stati anche attacchi alla RAM utilizzando DMA tramite Thunderbolt, PCI Express e altre tecnologie bus. E il malware ha accesso ai dati non crittografati; un aggressore fisico potrebbe avere più difficoltà a installarlo tramite hardware locale.

Ricorda, per funzionare, il server deve essere avviato, il che significa che le chiavi del disco si trovano da qualche parte nella macchina.

"il che significa che le chiavi del disco si trovano da qualche parte nella macchina.". Qualsiasi buon controllo della password non è solo un semplice confronto di stringhe.
@mathreadler Cosa? Stiamo parlando di chiavi di decrittazione, non di password.
Sì chiave, password. Potayto, potahto.
@mathreadler, nella crittografia moderna le chiavi di crittografia non vengono utilizzate come password e le password non vengono utilizzate come chiavi di crittografia. Le password vengono talvolta utilizzate per derivare le chiavi di crittografia in modo algoritmico, ma è altrettanto possibile che vengano convalidate solo come un passaggio del recupero della chiave di crittografia. Cold Boot sconfigge la crittografia del disco ripristinando direttamente la chiave di crittografia del disco. La password dell'utente viene utilizzata all'interno del sistema operativo per derivare una chiave utilizzata per accedere alla chiave utilizzata per decrittografare i file crittografati dall'utente; non è correlato alla crittografia del disco.
Sì, so che la password utente per il sistema operativo di solito non è la stessa della chiave per la crittografia del disco. Non è ancora necessario riporre la chiave sulla macchina. Può essere memorizzato su un dispositivo rimovibile o non memorizzato affatto ma solo convalidato. Inoltre vedo cosa stai cercando di fare e non funziona molto bene.
#5
+8
Silverfox
2015-12-30 00:14:15 UTC
view on stackexchange narkive permalink

In caso di accesso fisico, stai aggirando molti dispositivi di sicurezza come firewall e dispositivi ips ids ai margini della rete, quindi sei avanti di parecchi passi. Quando ottieni l'accesso remoto al server devi ancora occuparti della crittografia, quindi è la stessa per entrambi i casi. C'è una citazione a riguardo che dice: "Non devono bypassare il tuo firewall se possono bypassare il tuo receptionist."

#6
+3
Theraot
2015-12-30 04:36:43 UTC
view on stackexchange narkive permalink

Va ​​notato che la sicurezza non riguarda solo la privacy e la riservatezza, ma include anche disponibilità e integrità (e tracciabilità, ecc.).

Come tale, con l'accesso fisico, anche se non possono accedere ai tuoi dati: un utente malintenzionato può causare molti danni.

Presumo che integrità e disponibilità siano le tue "altre ragioni". Tuttavia, se la domanda è qualsiasi cosa o meno la sicurezza fisica è meno importante, la risposta è che anche se rimuovi la riservatezza dalle tue preoccupazioni, la sicurezza fisica è ancora fondamentale.


Considera questa risposta come un complemento agli altri qui, non è necessario ripetere i loro punti.

#7
  0
Ajay
2015-12-29 11:27:12 UTC
view on stackexchange narkive permalink

Se potessi avere accesso fisico a un server, potresti cambiare la password root / admin anche se non conosci la password corrente.

Quale sistema operativo non te lo chiederà per la password corrente quando si desidera modificare? O intendi cambiare la password di un altro utente (che è un amministratore)?

Tuttavia con i dischi crittografati, non credo che questo sia possibile (o lo è?).

Con la mia esperienza su Windows, cartella EFS / il file non sarà accessibile se un altro amministratore modifica la password con forza. Avrai bisogno di un certificato EFS per lo stesso se perdi la password o si verifica una modifica forzata della password (o se l'account stesso viene eliminato).

Quindi, questo significa che la protezione fisica del tuo server è diminuita importante - è ancora necessario per altri motivi - ma questo motivo non è più presente?

IMO, sono necessari entrambi.

Per Linux, Unix e Windows, se si dispone dell'accesso fisico alla macchina si cambia il root / admin. Avvia un'immagine diversa e la cambi. Google per questo.
Con EFS non è possibile. E, anche con un volume / cartella non EFS, come è possibile accedere e modificare la password?
Questa è esattamente la mia domanda, giusto? In precedenza i dischi non erano crittografati - si poteva cambiare la password se si aveva accesso fisico - quindi proteggere fisicamente la macchina era molto importante. Ora con i dischi crittografati, quel motivo per proteggere fisicamente le macchine non esiste più.
Bene, ignora la crittografia del disco. Le password vengono archiviate crittografate (ad es. AES 256). Come puoi accedere o modificare? Anche con il vecchio file di password "semplice" in Unix, il sistema operativo utilizzava il salting per difendersi da attacchi bruti / dizionari. Le password vengono archiviate utilizzando hash unidirezionali come forse saprai. Il sistema operativo manterrebbe le informazioni di autenticazione / integrità sul file della password da qualche parte (MAC / HMAC), quindi una modifica di un singolo byte interromperà il MAC.
Bene, capisco il tuo punto. Cosa succede se `etc / passwd` viene rubato, modificato e rimesso a posto? Bene, allora la sicurezza fisica IMO è d'obbligo!
`etc / passwd` è stato rubato ... Qui pensavo che l'accesso fisico significasse trovarsi nella stessa stanza del server. Posso rubare il tuo "etc / passwd" dall'altra parte del mondo. Perché stai equiparando l'accesso ai file con l'accesso fisico?
In un disco non crittografato, la password può essere modificata (sebbene non recuperata) se si dispone dell'accesso fisico alla macchina. Questo perché puoi eseguire l'avvio da un'immagine diversa e sovrascriverla sul disco. http://www.liberiangeek.net/2013/03/unlock-the-root-account-reset-the-root-password-change-username-in-ubuntu-13-04-raring-ringtail/
@CandiedOrange: Con una buona sicurezza di rete e impostazioni di autorizzazione è difficile rubare etc / passwd. Se ho la tua unità SATA, devo solo collegarla a un connettore SATA sul MIO OS sul MIO PC per montarla per rubare ecc / passwd - questo è ciò che l'accesso fisico sconfigge - tutto il software che protegge ecc / passwd da quei software ( compreso il sistema operativo) non verrà eseguito. L'unica cosa che potrebbe salvarti è la crittografia. Ma senza alcun software in grado di eseguire e limitare i tentativi di hacking delle password, l'unico costo per me è il tempo.
Ho cambiato molte password di amministratore di Windows 7 Pro in circa cinque minuti con un trucco che richiede l'accesso fisico. Certo, Windows 7 (anche pro) non è un sistema operativo server, ma le password sono archiviate con un hash unidirezionale. Il trucco che si può usare non richiede la conoscenza o l'inserimento di alcuna password corrente sul sistema: si limita a sovrascrivere la password dell'amministratore con una nuova. Sebbene non identici, processi simili possono essere utilizzati per altri sistemi operativi se l'unità non è crittografata. Come indicano CandiedOrange e Andre Borie, alcuni tipi di accesso fisico possono portare al completo accesso a un sistema di destinazione.
"Sovrascrivi la password" - Dove? Vedi qualche file o hash calcolato?
http://www.howtogeek.com/96630/how-to-reset-your-forgotten-windows-password-the-easy-way/ Le funzionalità di accessibilità possono essere sostituite con cmd.exe che può quindi essere utilizzato per emettere il comando, "net user adminusername newpassword", sovrascrivendo così la password per l'utente in questione. ** Supponendo che tu abbia accesso fisico **.
Quindi, ancora una volta, stai dimenticando EFS. Se il disco non è crittografato e hai accesso fisico, ruba semplicemente il disco rigido!
... mentre se * è * crittografato, è necessario entrare in analisi forense della memoria. Che è una classe di attacchi molto reale, in particolare se i tuoi aggressori sono ben finanziati (all'ultimo richiamo, le schede PCI per estrarre immagini di memoria dal vivo costavano circa $ 8k circa).
@Ajay Stavo cercando di rispondere alla tua domanda qui citata: "E, anche con un volume / cartella non EFS, come puoi accedere e modificare la password?" Sei stato tu a specificare un sistema non EFS.
@slebetman / etc / passwd è * leggibile in tutto il mondo *. Deve esserlo, perché contiene cose utili come le mappature tra ID utente numerici e significativi / a misura d'uomo. Ottenere una copia è banale se si dispone dell'accesso al login. Questo è il motivo per cui i sistemi moderni utilizzano "password shadow", dove le * password con hash * sono memorizzate in un file diverso, accessibile solo a root (/ etc / shadow su Linux).
#8
  0
guest
2017-02-28 12:37:54 UTC
view on stackexchange narkive permalink

Risposta breve: no, è ancora molto importante

La maggior parte delle persone ha pubblicato risposte che includono ingegneria sociale o attacchi che sono necessariamente interattivi (come keylogger o varianti di l'attacco della domestica malvagia). Questi possono essere annullati utilizzando tecniche di attestazione remota sicure (in genere che coinvolgono Intel TXT o SGX). Poiché la maggior parte di questi sono interattivi e molti avversari non possono permettersi di aspettare fino a quando qualcuno accede al server, fornirò alcuni esempi che possono essere utilizzati per compromettere un server crittografato in qualsiasi momento, oltre a mitigazioni. Tieni presente che questo sarà incentrato su Linux, ma i punti hardware sono indipendenti dal sistema operativo.

Recupero diretto della memoria utilizzando attacchi di avvio a freddo

Il metodo che tutti conoscono , un attacco di avvio a freddo, può ripristinare le chiavi di crittografia sulla maggior parte dell'hardware con moderata affidabilità con due metodi. Il primo prevede il raffreddamento della memoria utilizzando uno spray congelante, quindi estrarlo fisicamente e inserirlo in una nuova scheda madre per leggere il contenuto. Il secondo prevede il mantenimento della memoria, facoltativamente il raffreddamento per migliorare l'affidabilità e il riavvio del sistema in un sistema operativo dannoso e leggero, bootloader o, in almeno un caso noto, BIOS personalizzato, che legge e scarica la memoria su un non -medio volatile.

L'attacco di avvio a freddo funziona perché la moderna memoria del computer ad alta capacità, chiamata DRAM, che memorizza i dati in condensatori che devono essere aggiornati ad alta velocità quando immagazzinano una carica, oppure " perderò la carica. In genere vengono aggiornati ogni 64 ms per affidabilità, ma anche senza alimentazione molti conservano i dati per un breve periodo.

Esistono tre tipi principali di memoria comunemente utilizzati nei server oggi: DDR2, DDR3 e DDR4. DDR2 a volte può conservare i dati per 30 secondi o più senza alimentazione. DDR3 e DDR4 perderanno potenza in pochi secondi, rendendo molto più difficile il montaggio di attacchi di avvio a freddo. Inoltre, le memorie DDR3 e DDR4 mescoleranno i loro contenuti per ridurre le interferenze elettriche, ma l'algoritmo che utilizza è un LFSR, che non è crittograficamente sicuro ed è banale da violare.

Mitigare il primo metodo è semplice quanto assicurandosi che i DIMM non possano essere rimossi. Questo può essere fatto utilizzando correttamente la resina epossidica antimanomissione. Se usato correttamente, qualsiasi tentativo di rimuoverlo distruggerà la memoria nel processo. Ciò potrebbe non essere possibile se stai utilizzando un server che non possiedi fisicamente. Per mitigare il secondo metodo è necessario che il BIOS cancelli la memoria prima dell'avvio. La disabilitazione dell'avvio rapido a volte può causare la cancellazione della memoria della memoria come parte del POST. La memoria ECC spesso richiede anche di essere inizializzata dal BIOS prima dell'uso. Tuttavia, almeno una volta, un attacco di avvio a freddo di questo tipo ha comportato una versione personalizzata di avvio a freddo. BootGuard, una funzionalità di molti nuovi sistemi Intel, impedirà l'installazione di BIOS personalizzati, ma un avversario particolarmente avanzato sarà comunque in grado di aggirarlo.

Esiste ancora un metodo finale per sconfiggere l'avvio a freddo attacco, che funziona contro entrambi i tipi di attacchi di avvio a freddo, e cioè per non consentire mai alla chiave di crittografia di entrare in contatto con la memoria. La patch del kernel TRESOR per Linux fa proprio questo, inserendo le chiavi nei registri di debug x86. Ciò non rende il tuo computer immune da tutti gli attacchi che implicano l'accesso fisico, ma impedisce solo agli attacchi di avvio a freddo di leggere le tue chiavi di crittografia. I dati dal tuo disco che rimangono nei buffer del filesystem, ad esempio, saranno ancora recuperabili.

Lettura e scrittura in memoria utilizzando attacchi DMA

Qualsiasi dispositivo collegato al PCH (PCI, PCIe, LPC) ha il potenziale per leggere e scrivere direttamente in memoria tramite DMA, o Direct Memory Access, attacchi, chiamati anche evil bus mastering (un dispositivo che è bus master è consentito per inviare richieste DMA, tra le altre cose). DMA è una tecnica che consente ai dispositivi di leggere e scrivere in modo asincrono in memoria, senza dover coinvolgere la CPU, per prestazioni migliorate. Sfortunatamente, se un tale dispositivo viene dirottato o inserito in modo dannoso, può leggere e scrivere su tutta la memoria e la CPU non può fare nulla al riguardo. La CPU può dire se il dispositivo ha funzionalità DMA, ma se è abilitato, la CPU ripone la sua fiducia nel dispositivo, confidando che non lo tradisca.

Ci sono tre tipi di attacchi DMA di cui sono a conoscenza. Il primo è l'hotplugging PCI / PCIe, che implica l'inserimento di un dispositivo dannoso in uno slot sulla scheda madre e la possibilità che il sistema operativo lo configuri automaticamente. Questo è banale da mitigare, disabilitando l'hotplugging. Ciò potrebbe richiedere una modifica alla configurazione del kernel. Il secondo tipo di attacco consiste nel dirottare un dispositivo affidabile esistente che è il bus master e utilizzarlo per leggere o scrivere in memoria. Questo può essere fatto sfruttando il firmware in esecuzione sul dispositivo o dirottando l'hardware attraverso interfacce di debug esposte, eseguendo il reflash del firmware e innescando un ripristino a freddo della CPU del dispositivo, ecc. Il tipo finale, che è molto meno noto, è un attacco tramite LPC. L'LPC è l'equivalente dell'arcaico bus ISA sull'hardware moderno. Gestisce vecchie periferiche a bassa velocità. Tuttavia, può anche essere reso bus master affermando l'interrupt LDRQ #. Non tutte le schede madri lo rivelano e, sebbene sia puramente aneddotico, uno sviluppatore Intel che ho incontrato ha detto di non aver mai visto un laptop che mostrasse LDRQ #. Potrebbe essere diverso per i server. Sfortunatamente, la scheda tecnica di Intel PCH specifica che il bit master del bus dell'LPC è di sola lettura, forzato. Se il tuo sistema supporta LDRQ #, la mitigazione degli attacchi DMA basati su LPC deve essere eseguita in altri modi.

Esistono due modi per mitigare gli attacchi DMA. Il primo sfrutta il fatto che, mentre DMA funziona indipendentemente dalla CPU, l'attivazione del DMA richiede comunque che la CPU gli dia il permesso abilitando il bit master del bus. Un driver, che è solo un software, può rifiutare un dispositivo che richiede questa autorizzazione. Se il dispositivo non riceve l'autorizzazione, non può avviare DMA. Ad esempio, non utilizzando il driver Firewire, o utilizzando il driver Firewire più moderno che ha DMA disabilitato per impostazione predefinita, il dispositivo PCI Firewire avrà DMA disabilitato (il bit master del bus sarà disattivato). Questa tecnica ha i suoi svantaggi, perché alcuni dispositivi richiedono il DMA per funzionare. Schede di interfaccia di rete, schede grafiche, ecc. Richiedono DMA, altrimenti sarebbero così lente da essere inutilizzabili. Anche se non dovresti preoccuparti che ne venga collegato uno nuovo e dannoso, un exploit contro la scheda o un attacco contro l'hardware (controllandolo utilizzando interfacce di debug, ad esempio) possono utilizzare questo privilegio contro l'host.

L'altra mitigazione consiste nell'utilizzare una funzionalità nella maggior parte delle CPU moderne, IOMMU (la funzionalità è denominata VT-d sui processori Intel). L'IOMMU è in grado di filtrare in modo efficiente tutti gli accessi DMA, senza disattivarlo completamente. Questo si chiama DMAR, o DMA Remapping. La specifica ACPI specifica un blob di dati chiamato tabella DMAR che è archiviato nel BIOS che l'IOMMU utilizzerà per isolare i singoli dispositivi compatibili con DMA, reindirizzando qualsiasi accesso diretto alla memoria a un'area di memoria specifica e sicura. Su molti sistemi Linux, devi abilitarlo avviando con il parametro intel_iommu = on (per Intel), o amd_iommu = force (per AMD). Queste opzioni non sono abilitate per impostazione predefinita perché molti BIOS hanno una tabella DMAR rotta, che impedisce l'avvio del sistema o causa problemi. Controlla se il tuo sistema utilizza IOMMU per isolare i dispositivi se dmesg | grep -e IOMMU -e DMAR mostra la Intel (R) Virtualization Technology for Directed I / O (ovviamente specifica di Intel) nell'output e si fa riferimento a più dispositivi.

Hijack della CPU stessa utilizzando JTAG

JTAG è un gruppo di standard che specificano interfacce e protocolli per il debug dell'hardware. Uno standard, denominato IEEE 1149.1, consente di mettere una CPU in una modalità di debug di basso livello semplicemente collegando una sonda JTAG a un'intestazione sulla scheda madre. I sistemi Intel utilizzano un'intestazione proprietaria modificata, chiamata ITP-XDP. Se qualcuno vuole attaccare un server crittografato con JTAG, deve connettere la sonda all'intestazione XDP. Anche se l'intestazione non è chiaramente visibile, le tracce saranno ancora lì e saranno ancora attive e praticabili. Non appena la sonda è collegata, tutti i core della CPU si arrestano e l'aggressore sarà in grado di leggere il contenuto di tutti i registri, leggere tutta la memoria, scrivere su qualsiasi registro, scrivere su qualsiasi memoria, eseguire il il puntatore dell'istruzione, riattiva e mette in pausa la CPU e molto altro. In breve, JTAG consente a un utente malintenzionato di assumere il controllo completo della CPU, controllandola come un burattino, e non può fare nulla al riguardo.

Non c'è modo di mitigare un attacco JTAG nel software. Essenzialmente tutte le schede madri hanno intestazioni XDP. Un possibile modo per mitigarlo, se si ha accesso fisico al server e si è autorizzati a modificarlo in modo permanente (ad esempio colo, hosting a casa, ecc.), È possibile utilizzare una resina epossidica forte e metterla sull'intestazione XDP. Questa tecnica può essere ulteriormente migliorata mettendo una spessa lastra di metallo sopra la resina epossidica, evitando che le punte fini rompano i fori nella resina epossidica. Mi è stato detto che non c'è da preoccuparsi che un utente malintenzionato possa perforare il fondo, perché ci sono così tanti strati di tracce in una scheda madre moderna che potrebbero distruggere il sistema. Non so se ciò provocherebbe l'arresto del sistema o impedirebbe il funzionamento di JTAG, quindi potrebbe essere meglio mettere una resina epossidica e una lamiera su entrambi i lati.

Esotico, attacchi estremamente difficili o teorici

Esiste il noto problema degli attacchi di canale laterale attraverso l'analisi della potenza e l'analisi termica. Ciò può essere possibile quando il programma che esegue la crittografia / decrittografia non utilizza operazioni a tempo costante in cui sono critiche, con conseguenti ritardi rilevabili o grandi assorbimenti di corrente che si verificano in momenti diversi a seconda del valore della chiave. È improbabile che i moderni driver crittografici abbiano questo problema e l'accelerazione hardware come AES-NI rende questo ancora meno problematico. Le mitigazioni includono l'uso di cifrari che supportano l'accelerazione hardware, come AES su hardware appropriato, usando cifrari che hanno piccole S-box e possono essere ottimizzati usando il bit slicing, come Serpent, o usando la separazione rosso / nero per un EMSEC corretto (cerca NATO SDIP-27 per le specifiche. Di solito è sufficiente acquistare un computer approvato).

Gli analizzatori del bus logico possono essere collegati direttamente a qualsiasi traccia o filo elettrico esposto, senza la necessità di interrompere il circuito. Questo è possibile con la DRAM, ma man mano che le velocità aumentano, diventa sempre più difficile. PCIe utilizza tecniche per migliorare la velocità che si traducono in fenomeni elettrici molto strani che agli analizzatori logici non piacciono affatto (una corsia PCIe non ha una netta separazione tra hi e lo, poiché i dati sanguinano in linee adiacenti e i segnali elettrici echeggiano avanti e indietro). Potrebbe essere possibile, ma sarebbe difficile da fare. Se il tuo hub principale PCI supporta AER, segnalazione degli errori, puoi configurare il tuo sistema per disabilitare immediatamente il bus master da qualsiasi dispositivo che segnala errori correggibili, piuttosto che continuare, come è l'impostazione predefinita. Questa tecnica rapida potrebbe essere in grado di rilevare un tentativo di inserire un analizzatore di bus logico in un dispositivo PCIe. Poiché questo è un attacco così teorico ed esotico che molto bene potrebbe non essere comunque possibile, e la mitigazione non è testata (semplicemente un'idea nata durante una conversazione che ho avuto con un ricercatore), sto solo spiegando il concetto, non il passaggi per farlo. È probabile che non dovresti comunque preoccuparti di leggere i dati PCIe, poiché è improbabile che abbia la chiave, ma lo includo per completezza.

Infine, e il più irrealisticamente, un attaccante estremamente avanzato potrebbe innescare bug nella CPU sfruttando tempistiche e stranezze di alimentazione. Questi attacchi (chiamati attacchi glitching) sono comunemente usati per sfruttare semplici microcontrollori come gli economici Atmel 8051, ma sono molti ordini di grandezza meno ben testati dei processori Intel. Il glitch può comportare l'impostazione dell'orologio o degli orologi su valori non validi o instabili, l'eliminazione delle tensioni dalle specifiche, la violazione delle specifiche di temporizzazione, ecc. In casi particolarmente avanzati, il glitch può coinvolgere una tecnica chiamata laser fault injection, in cui il processore è accuratamente sciolto o bruciato) e un laser controllato con precisione viene utilizzato per suscitare attività elettrica in aree specifiche, inducendo guasti. L'obiettivo finale del glitch è quello di causare un errore che modifica lo stato interno del dispositivo in uno stato più favorevole agli aggressori, come quello in cui il bus master può essere abilitato o le restrizioni IOMMU possono essere violate. Esempi del mondo reale con microcontrollori 8051 spesso tentano di disabilitare i bit di blocco di sicurezza, come il bit di lettura del firmware. Hanno quasi sempre successo su dispositivi così semplici.

Mitigare tutto, almeno in teoria

Infine, esiste una mitigazione commerciale che protegge da tutto tranne l'attacco JTAG, ovvero PrivateCore vCage. È una soluzione di virtualizzazione che crittografa tutta la memoria e inserisce il kernel nella cache della CPU. Gli attacchi DMA sono fondamentalmente prevenuti e il TCB (Trusted Computing Base) è ridotto interamente alla CPU stessa, il che significa che, indipendentemente da ciò che viene dirottato, solo la CPU deve essere considerata attendibile. In teoria, anche gli attacchi JTAG potrebbero essere sconfitti se il sistema eseguisse tutto il codice non attendibile in un'enclave SGX. Ciò funzionerebbe perché la modalità probe, la modalità CPU in cui JTAG inserisce il sistema, non può essere utilizzata nel contesto di un'enclave SGX. Sfortunatamente, questa implementazione è closed source e il servizio è molto costoso, quindi è più interessante dal punto di vista accademico.

#9
-6
Darien
2015-12-30 07:50:24 UTC
view on stackexchange narkive permalink

Ho un disco "crack" basato su UNIX che può sconfiggere la maggior parte dei sistemi di accesso standard basati su Windows, server e desktop. E non è un segreto della Difesa Nazionale, sono abbastanza disponibili in tutto il mondo. Quindi, se mi dai il tuo server e un USB o CDROM aperto, probabilmente sarò in meno di 15 minuti, a volte sotto 5. Quindi sì, mantieni la tua sicurezza fisica tanto stretta quanto quella virtuale. Altrimenti verrai colpito, prima o poi l'unica domanda sarà "quanto è stata grande la violazione?"

funziona anche su un disco crittografato?
Ci scusiamo per il voto negativo Darien, ma non voglio lasciare una risposta errata che sembra corretta. L'OP menziona esplicitamente la crittografia del disco.
E ci sono dischi che possono violare i sistemi di accesso Linux / Unix. Ma come il tuo, non funzionerà su sistemi crittografati.
Quei dischi vivi non eseguono attacchi DMA.Nella migliore delle ipotesi puoi estrarre hiberfil.sys + pagefile.sys o copiare in modo raw la partizione di swap.OP ha un'unità crittografata, molto probabilmente con un file di chiavi gpg e una richiesta di password all'avvio.Ha solo pochi file in / boot e altrove che sono in chiaro.In questo caso, un utente malintenzionato deve sovvertire il binario che fornisce la sfida di scrivere anche la password su file / remotehost.
@user93353 Crack sha512 password con hash che ora sono standard?Hai bisogno di una grande GPU rig o ci vorrà troppo tempo.OP non sta comunque parlando di un sistema di accesso, sta (probabilmente) parlando di un cryptodisk LUKS, che può mantenere tutto tranne alcuni file in forte crittografia.OP non può eseguire nuovamente il login remoto a questo sistema, poiché ormai un utente malintenzionato moderatamente esperto può aver eseguito il backdoor dei suoi binari in chiaro.


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