Luks + Sleep: sicurezza della schermata di accesso?

Question

Luks + Sleep: sicurezza della schermata di accesso?

#1 da (2 voti)
#2 da (1 voti)

3

Situazione: un desktop Linux (es. Debian, desktop Xfce, accesso Lightdm) con partizioni crittografate con LUKS (per quanto possibile, ad esempio, i file Efi non sono crittografati, naturalmente).
Il computer è in modalità di sospensione (non in modalità ibernazione, ad esempio Luk in sbloccato e digitazione RAM).

Ora un ladro ruba il computer e vuole trovare un modo.

Tutto ciò che comporta la sua disattivazione ovviamente non aiuta a causa della crittografia del disco.
Installare keylogger hardware, sostituendo Bootloader / Efi con qualcosa di malizioso, e cose simili non saranno d'aiuto perché il proprietario sa che è stato rubato e non può essere considerato attendibile.
Attacchi elaborati che ad es. leggere le chiavi direttamente dalla RAM attraverso alcuni mezzi sono al di fuori delle capacità dei ladri e / o un rischio che il proprietario prende per essere in grado di utilizzare il sonno anziché lo spegnimento.
Ciò comporta il rischio che la schermata di accesso (di LightDM) possa essere ignorata in qualche modo, dato il Desktop già in esecuzione dietro di esso.

La mia domanda è: quali cose devo fare per essere consapevole di ciò?

Seguendo i punti che già conosco:

Commutazione dei terminali (CtrlAltFn).
- La GUI viene avviata con startx, questo permette di ottenere un TTY dove l'utente ha già effettuato l'accesso. Tuttavia non esiste tale TTY quando si utilizza LightDM.
- C'è anche una schermata della GUI che mostra solo "Questa sessione è bloccata, passerà all'accesso in pochi secondi" (o un messaggio simile). Tuttavia non sembra che ci sia un modo semplice per uscire da quello.
X Server ha un'opzione di configurazione DontZap che permette di uccidere X con la scorciatoia CtrlAltBackspace. Questo potrebbe essere d'aiuto nella schermata "bloccata" o anche in Lightm, tuttavia è disabilitato di default, quindi nessun problema.
C'è un'altra scorciatoia X CtrlAlt * (stella) (config AllowClosedownGrabs) che uccide tutti i processess che contengono un "lock" (qualunque lock questo significhi). Anche questo è disabilitato per impostazione predefinita.
Kernel SysRQ abbreviazione F per OOM killer. Può essere disabilitato, e forse le due GUI sono tra i processi protetti contro di esso (ho provato circa 50 volte e non sono riuscito a uccidere LightDM, ma non sono sicuro della ragione esatta).

Quali altri rischi potrebbero esserci nel 2018?

linux desktop luks

posta DoeDoe 15.08.2018 - 12:45

fonte

2 risposte

Leggi altre domande sui tag linux desktop luks

Divulgazione di informazioni per identificatori Che tipo di hashing viene generalmente utilizzato nei moduli di accesso?

score 2 · Answer 1

Supponendo che tutte le funzioni SysRq rilevanti siano disabilitate quando la schermata di blocco è attivo ( SAK , inviando SIGTERM o SIGKILL a tutti i processi, attivando l'OOM killer come hai detto, ecc.) e assumendo i vettori di attacco avanzati come gli attacchi DMA, gli attacchi a freddo e lo sfruttamento della rete sono fuori portata, quindi non c'è modo di aggirare il lockscreen per non sfruttare un bug nel codice attualmente sconosciuto (sono non troppo raro , però). In breve:

L'esclusione potrebbe essere possibile utilizzando altre funzionalità di SysRq che non hai menzionato.
Il bypass potrebbe essere possibile sfruttando un bug sconosciuto nel software di blocco.
È possibile eseguire l'Infoleak collegando un monitor di grandi dimensioni, attivando un ridimensionamento. ^*
Un processo locale potrebbe (intenzionalmente o meno) interferire con il blocco.

Ci sono altri programmi di blocco più sicuri là fuori. Un esempio è vlock che funziona aprendo un nuovo TTY che controlla e disabilitazione della commutazione TTY. Disabilita anche SysRq mentre è attivo. Va notato però che, se viene eseguito da un terminale, uscirà se il terminale si blocca per qualsiasi motivo (questo è un bug che è facile da risolvere). Il motivo per cui vlock è particolarmente sicuro è che non si basa sulla sicurezza del tuo server X, che a sua volta non ha fondamentalmente alcun concetto di lock screen. Invece, è progettato per utilizzare l'isolamento TTY che è qualcosa progettato pensando alla sicurezza. Un'altra alternativa potrebbe essere xsecurelock , una semplice schermata di blocco grafica creata da Google che enfatizza la sicurezza contro i crash. Tuttavia, come la maggior parte dei software di blocco dello schermo, non disattiva le funzionalità SysRq da solo, quindi devi farlo tu stesso se è abilitato.

_{* Se un monitor di grandi dimensioni è collegato al computer bloccato, la finestra di root potrebbe ridimensionarsi automaticamente. Se la schermata di blocco non rileva questo e si ingrandisce di nuovo, potrebbe essere possibile vedere oltre il blocco. Questo non è un problema con il software di blocco virtuale basato su terminale come vlock, poiché il server X si trova in un altro TTY.}

score 1 · Answer 2

Durante il blocco, le funzionalità di rete sono ancora attive. Pertanto, il dispositivo è suscettibile di sfruttare vulnerabilità. I vettori di attacco di rete includono adattatore di rete USB, Ethernet e Wi-Fi. Sebbene, il Wi-Fi richiederà la visualizzazione dei probe inviati e la creazione di un AP con lo stesso SSID e la stessa sicurezza di rete (passphrase se protetta).

Un'altra idea è estrarre le chiavi di crittografia dalla RAM . Tuttavia, ritengo che la maggior parte delle idee discusse in quel documento siano al di là delle capacità della maggior parte delle persone.

Bypassare la schermata di blocco è un po 'limitato. Le distribuzioni basate su Linux utilizzano spesso una varietà di interfacce utente grafiche diverse. Anche se questo non discredito questa idea, è semplicemente la pena di meno di trovare un bypass della schermata di blocco Android o iOS.