Autorización local sin contraseña en Ubuntu

Hoy hablaremos sobre cómo encontramos la autorización local sin una contraseña en Ubuntu, que, al parecer, nunca se cerrará. Cómo sucedió todo, lea debajo del corte.

Una hermosa tarde de verano, el autor del artículo cerró la tapa de una computadora portátil que funcionaba desde Ubuntu 16.04 Desktop a Unity y se fue a su casa. La noche fue tan hermosa que decidí tomarme un par de días libres, le envié un SMS a mi jefe y él me dejó ir.

Al final resultó que, no todos mis colegas tuvieron la misma noche maravillosa. La computadora portátil de C4n se descompuso, por lo que me pidió que le prestara la mía, pero con su disco duro. Por supuesto que lo permití.

Con esto, comenzó nuestra fascinante investigación.

Que paso

A la mañana siguiente, c4n desarmó mi computadora portátil e insertó mi disco duro allí. Abrió la tapa y vio, en lugar de comenzar a cargar su sistema operativo, la ventana de inicio de sesión en mi sistema. Se podía hacer clic, y c4n comenzó a ingresar contraseñas aleatorias, sin embargo, todo fue en vano. Frustrado, presionó el botón de encendido, y luego ocurrió un milagro .

En lugar de reiniciar la computadora, inicié sesión con éxito en mi sistema y también se mostraron los últimos programas y documentos que abrí. Vale la pena señalar que los documentos no solo se mostraron, ¡funcionaron por sí mismos! Puede desplazarse por los documentos y pasar por las pestañas del navegador. c4n inmediatamente me tomó una captura de pantalla.


De hecho, la captura de pantalla fue diferente. Al salir del trabajo, no dejo abierto KeePass y el sitio web de la empresa.

¡Ante la autorización local sin contraseña!

Cuando salí de vacaciones, me preguntaba cuál es la culpa de este fenómeno, si siempre se reproduce y siempre se reproduce igual, si se reproduce en todos los sistemas.

Razones

Al final resultó que, la falla de este fenómeno fue que cuando se cerró la tapa, mi computadora portátil no entró en hibernación, sino que se fue a dormir (es decir, dejó la alimentación en la RAM), y después de abrir la tapa, el sistema operativo cargado y los últimos archivos permanecieron en la RAM, con con el que trabajé El sistema operativo no sabe que el disco duro se ha eliminado de la computadora y continúa funcionando hasta que necesite acceder al disco duro.

Por qué es posible aprobar una autorización sigue siendo un misterio para nosotros. Pecamos en el trabajo de los módulos PAM (Módulos de autenticación conectables), que, muy probablemente, no están en RAM, y Ubuntu 16.04 procesa incorrectamente su ausencia, pero luego nos dimos cuenta de que el problema es otra cosa.

¿Se reproduce siempre y siempre es lo mismo?

Nuestros experimentos comenzaron con Ubuntu 16.04. Las acciones fueron las siguientes:

1. Enviamos la computadora al modo de suspensión.
2. Sacamos el disco duro.
3. Despertamos la computadora del modo de suspensión.

Además, como resultó, puede haber varias opciones para el comportamiento del sistema:

1. La computadora muestra la ventana de inicio de sesión, ingrese una contraseña aleatoria => vemos ventanas de usuario frente al resbalón (todas las ventanas están funcionando).
2. La computadora muestra la ventana de inicio de sesión, ingrese una contraseña aleatoria => el sistema dice que la contraseña es incorrecta => presione el botón de encendido una vez => vemos las ventanas de usuario antes del deslizamiento (todas las ventanas están funcionando).
3. La computadora muestra una pantalla negra (el cursor pasa sobre ella), presiona teclas aleatorias y Enter => vemos ventanas de usuario frente a la hoja (todas las ventanas están funcionando).
4. La computadora muestra una pantalla negra (el cursor pasa sobre ella), presiona teclas aleatorias y Enter => no pasa nada => presiona el botón de encendido una vez => vemos las ventanas del usuario antes del deslizamiento (todas las ventanas están funcionando).

Lo más probable es que los elementos 3-4 sean similares a los elementos 1-2, solo por alguna razón, el gráfico no dibuja una ventana de inicio de sesión.

El experimento se llevó a cabo muchas veces, y todas las veces fue posible acceder a las ventanas del usuario, es decir. La reproducibilidad es del 100%. Esto es muy bueno para un error tan extraño. Es cierto que vale la pena señalar que solo hay ventanas activas disponibles, no pudimos cambiar a ventanas minimizadas. Además, algunas ventanas desaparecieron después de un tiempo y, a veces, se observó el efecto de registro, pero uno de los cuatro métodos de entrada permitió regresar.

PoC

Grabamos un video corto que demuestra todo el proceso de ataque.

¿Juega en todos los sistemas?

La condición para la prueba fue la presencia de todas las últimas actualizaciones en el sistema. ¿Por qué necesitamos un error que se ha cerrado durante mucho tiempo?

Para empezar, se decidió comprobar si el error se reproduce en PC normales (no en computadoras portátiles) con Ubuntu 16.04 con Unity. Había una teoría de que la visualización de la ventana podría estar conectada de alguna manera a una tarjeta de video. Por lo tanto, la verificación se realizó desde una PC con tarjetas gráficas integradas y discretas, en todos los casos el resultado fue el mismo: cumple el error perfectamente.

El siguiente fue Ubuntu 16.04 con GNOME. Y aquí estábamos decepcionados: no resolví el error. A veces, al salir de un deslizamiento, el sistema mostraba las últimas ventanas durante medio segundo (es bastante posible grabar un video), los investigadores informaron esto en 2011 , y hasta ahora no se ha cerrado.

Además, llevamos a Arch con Wayland y Xorg: decepción, no funciona. Debian 9 con GNOME y nuevamente decepción. Tampoco funcionó en el nuevo Ubuntu 18.04, como era de esperar, porque para entonces ya comenzábamos a sospechar que el problema estaba en Unity. Por lo tanto, decidimos tomar Ubuntu 14.04 para las últimas pruebas y también ver qué sucede con Ubuntu 18.04 si cambia el administrador de ventanas de GNOME a Unity. En Ubuntu 14.04, todo funcionó bien (aunque las ventanas tuvieron una vida útil mucho más corta que el 16/04). En Ubuntu 18.04 con Unity, después de salir del deslizamiento, el sistema se bloquea inmediatamente y no se pueden realizar más experimentos.

Conclusión: decidimos que las versiones de Ubuntu con Unity instalado de forma nativa son vulnerables, es decir version

• 10.10
• 11.04
• 11.10
• 12.04
• 12.10
• 13/04
• 13.10
• 14.04 (probado por nosotros)
• 14.10
• 15/04
• 15.10
• 04.16 (probado por nosotros)
• 16.10 (probado por nosotros)
• 04.17 (probado por nosotros)

Lista bastante impresionante, ¿no? Hemos probado lejos de todo. Si alguien tiene la oportunidad de verificar otras versiones que no hemos probado, con gusto lo agregaremos a la publicación.

¿Por qué pensamos que esto es malo?

La vulnerabilidad solo permite el acceso local a los datos, y no a todos, sino solo a aquellos que están abiertos en aplicaciones e implementados. Sin embargo, esto sigue siendo bastante crítico, porque:

1. Los datos utilizados pueden no guardarse en el disco (por ejemplo, un documento editable).
2. Los datos pueden estar en un directorio de inicio cifrado (por ejemplo, un archivo con contraseñas).
3. Los datos pueden estar en una unidad flash cifrada.
4. Los datos pueden requerir autorización adicional (como en nuestro PoC con KeePass).

Además de esto, en Unity, cualquiera puede enviar una computadora a un recibo, simplemente desde la pantalla de inicio de sesión (sin autorización). Es decir Es una situación bastante real que una persona bloquee la pantalla y salga a almorzar, en este momento el atacante envía la computadora a un resbalón, saca el disco duro y mira lo que hizo la persona antes de ir a almorzar. Después de que queda reiniciar la computadora que ya tiene el disco, y la persona no adivinará que sus datos podrían verse comprometidos.

Los escépticos dirán que se puede lograr fácilmente un resultado similar realizando un ataque de arranque en frío, y los resultados serán aún mejores, pero ¿con qué frecuencia alguno de ustedes lleva un termo con un par de litros de nitrógeno líquido?

Decidimos que el problema es crítico y debe escribirse en Ubuntu.

Mientras escribimos en Ubuntu

Para obtener un error, tuvimos que registrarnos en launchpad.net , luego crear una descripción del error y agregar un video de PoC. Obtuvimos 406 puntos de calificación y una insignia de hoguera (lo que sea que eso signifique). Comenzaron a esperar. Comenzamos el error el 2018-06-18.

Después de una larga correspondencia, el camarada Marc Deslauriers terminó nuestro debate con un mensaje que se reducía a: "No arreglaremos nada. Es lo mismo que tener acceso físico ".



Los intentos de convencer no tuvieron éxito. Fuimos enviados a ignorar por completo durante una semana. Después de lo cual nos dieron permiso para publicar este estudio:



UPD: 9 de julio de 2018, a las 16 en punto, decidimos hacer público el error (gracias amarao ). En la discusión sobre launchpad, el error fue confirmado para Mate 18.04, y no solo para Unity. La comunidad también insiste en que el error existe y no debe ignorarse.