Luks + Sleep: ¿Seguridad de la pantalla de inicio de sesión?

Question

Luks + Sleep: ¿Seguridad de la pantalla de inicio de sesión?

#1 de forest (2 votos)
#2 de safesploit (1 votos)

3

Situación: Un Linux de escritorio (por ejemplo, Debian, escritorio de Xfce, inicio de sesión de Lightdm) con particiones encriptadas con LUKS (en la medida de lo posible, por ejemplo, los archivos Efi no están encriptados, por supuesto). La computadora está en modo de suspensión (no hibernación, es decir, Luks en desbloqueado y clave en la memoria RAM).

Ahora un ladrón roba la computadora y quiere encontrar una manera de entrar.

Cualquier cosa que involucre apagarlo no ayudará, por supuesto, debido al cifrado del disco.
Instalar keyloggers de hardware, reemplazar Bootloader / Efi con algo maliciours, y cosas similares no ayudarán porque el propietario sabe que es robado y no se puede confiar en él.
ataques elaborados que por ejemplo. leer las claves directamente desde la RAM a través de algunos medios está fuera de las capacidades de los ladrones y / o el riesgo que el propietario asume para poder usar el modo de suspensión en lugar del apagado.
Eso deja el riesgo de que la pantalla de inicio de sesión (de LightDM) se pueda omitir de alguna manera, dado el escritorio que se está ejecutando detrás.

Mi pregunta es, ¿qué cosas debo hacer para prevenir esto?

Los siguientes puntos ya los conozco:

Terminales de conmutación (CtrlAltFn).
- Si la GUI se inicia con startx, esto permite obtener un TTY donde el usuario ya ha iniciado sesión. Sin embargo, no existe tal TTY cuando se utiliza LightDM.
- También hay una pantalla GUI que solo muestra "Esta sesión está bloqueada, cambiará para iniciar sesión en unos segundos" (o un mensaje similar). Sin embargo, no parece que haya una manera fácil de salir de eso.
X Server tiene una opción de configuración DontZap que permite matar a X con el acceso directo CtrlAltBackspace. Esto podría ayudar en la pantalla "bloqueada" o incluso en Lightm, sin embargo, está desactivada de forma predeterminada, por lo que no hay problema.
Hay otro atajo con X CtrlAlt * (estrella) (config AllowClosedownGrabs) que mata a todos los procesos que tienen un "bloqueo" (sea cual sea el bloqueo, esto significa). Esto también está deshabilitado por defecto.
Kernel SysRQ shortcut F para OOM killer. Se puede deshabilitar, y tal vez las dos GUIs estén entre los procesos protegidos (lo intenté unas 50 veces y no logré matar a LightDM, pero no estoy seguro de la razón exacta).

¿Qué otros riesgos podrían existir en 2018?

linux luks desktop

pregunta DoeDoe 15.08.2018 - 12:45

fuente

2 respuestas

Lea otras preguntas en las etiquetas linux luks desktop

¿Cómo arreglar la variante 3a y la variante 4 de Spectre? ¿Es posible acercarse para completar el anonimato del tráfico de bittorrent?

score 2 · Answer 1

Suponiendo que todas las funciones de SysRq relevantes están desactivadas cuando la pantalla de bloqueo está activo ( SAK , enviando SIGTERM o SIGKILL a todos los procesos, activando al asesino de OOM como lo mencionó, etc.), y asumiendo que Los vectores de ataque avanzados como los ataques DMA, los ataques de arranque en frío y la explotación de la red están fuera de alcance, por lo que no hay forma de pasar por alto la pantalla de bloqueo sin explotar un error en el código que actualmente se desconoce (son no demasiado infrecuente , sin embargo). En resumen:

La omisión puede ser posible utilizando otras funciones de SysRq que no hayas mencionado.
La omisión puede ser posible mediante la explotación de un error desconocido en el software de bloqueo.
Infoleaks puede ser posible conectando un monitor grande, activando un cambio de tamaño. ^*
Un proceso local podría (intencionalmente o no) interferir con el bloqueo.

Hay otros programas de bloqueo más seguros por ahí. Un ejemplo es vlock que funciona al abrir un nuevo TTY que controla y deshabilitando el cambio de TTY. También deshabilita SysRq mientras está activo. Se debe tener en cuenta que, si se ejecuta desde un terminal, se cerrará si el terminal se bloquea por algún motivo (este es un error que es fácil de solucionar). La razón por la que vlock es particularmente seguro es porque no depende de la seguridad de su servidor X, que en sí mismo no tiene un concepto fundamental de pantallas de bloqueo. En su lugar, está diseñado para utilizar el aislamiento TTY, que es algo que fue diseñado teniendo en cuenta la seguridad. Otra alternativa podría ser xsecurelock , una pantalla de bloqueo gráfico simple creada por Google que enfatiza la seguridad contra bloqueos. Sin embargo, como la mayoría del software de bloqueo de pantalla, no deshabilita ninguna función de SysRq por sí mismo, por lo que debe hacerlo usted mismo si está habilitado.

_{* Si se conecta un monitor grande a la computadora bloqueada, la ventana raíz puede cambiar su tamaño automáticamente. Si la pantalla de bloqueo no detecta esto y se maximiza de nuevo, puede ser posible ver más allá del bloqueo. Esto no es un problema con el software de bloqueo basado en terminal virtual como vlock, ya que el servidor X está en otro TTY.}

score 1 · Answer 2

Mientras está bloqueado, las capacidades de red aún están activas. Por lo tanto, el dispositivo es susceptible de tener vulnerabilidades explotadas. Los vectores de ataque de red incluyen un adaptador de red USB, Ethernet y Wi-Fi. Aunque, Wi-Fi requerirá mirar las sondas que se envían y crear un AP con el mismo SSID y seguridad de red (frase de contraseña si está asegurada).

Otra idea es extraer las claves de cifrado de la RAM . Sin embargo, creo que la mayoría de las ideas discutidas en ese documento están más allá de las capacidades de la mayoría de las personas.

Eludir la pantalla de bloqueo es algo limitado. Las distribuciones basadas en Linux a menudo utilizan una variedad de diferentes interfaces gráficas de usuario. Si bien esto no desacredita esta idea, simplemente vale la pena menos que encontrar un desvío de pantalla de bloqueo de Android o iOS.