Inicio de sesión de OpenSSH en una cuenta del sistema

Question

Inicio de sesión de OpenSSH en una cuenta del sistema

#1 de Gilles (2 votos)

1

Mientras realizaba una prueba de lápiz de rutina para un cliente, me topé con una caja que tenía OpenSSH 7.2p1 en ejecución.

A través de una búsqueda en Google descubrí esta vulnerabilidad con la versión de OpenSSH anterior

Fui a investigar más a fondo. Pude entender algunos de los detalles de la vulnerabilidad y la vulnerabilidad. Sin embargo, necesito ayuda para entender algunas cosas más.

Tengo una comprensión básica de cómo funciona exactamente SSH. Este es un recurso que está muy en sintonía con el entendiendo que tengo.

Ahora investigando el problema más a fondo, por lo que entiendo es que en el servidor X11Forwarding yes se requiere en el archivo de configuración sshd. Debido a que tengo acceso SSH a la caja, verifiqué que se cumplió esta condición.

Lo siguiente que entiendo es que se necesita una cuenta con el shell configurado en /bin/false o una cuenta de usuario con comandos forzados para poder demostrar la explotación en sí.

Además, además, el usuario anterior ya debe estar autenticado. (¿Es correcto este entendimiento?)

Así que entré en el cuadro e intenté ver si existe algún usuario que cumpla con las condiciones anteriores.

Hice un cat /etc/passwd | grep /bin/false y apareció una lista de usuarios que tenían su shell configurado en / bin / false. Uno de estos usuarios fue el usuario llamado mongodb , que tenía su directorio de inicio configurado en /home/mongodb y también estaba protegido por una contraseña como lo indica el x en el archivo passwd .

Leí sobre la instalación de mongodb y llegué a saber que se instala con su propio usuario.

Ahora hay algunas cosas que necesito ayuda para comprender:

¿Cuál es el uso de este usuario mongodb ? Miré a fondo / inicio y no pude encontrar un directorio de inicio para este usuario a pesar de que se mencionó en el archivo de contraseña.
¿Cómo y cuándo se autentica este usuario?
¿Hay alguna forma de que cuando este usuario se autentique con el sistema, se pueda aprovechar para explotar el error de inyección del comando xauth autenticado OpenSSH?

Perdone mi menor comprensión de los usuarios de Linux o SSH y avíseme si hay recursos que me ayuden a comprender mejor estos conceptos básicos.

authentication exploit linux openssh mongodb

pregunta qre0ct 22.09.2016 - 13:46

fuente

1 respuesta

Lea otras preguntas en las etiquetas authentication exploit linux openssh mongodb

¿Qué tan bien protegidos deberían estar los datos de facturación y facturación del cliente? ¿Cuáles son las configuraciones de seguridad posibles de un iPhone iOS para la máxima seguridad posible?

score 2 · Accepted Answer

Los sistemas Unix generalmente tienen muchas cuentas de usuario para fines del sistema, que se utilizan para un servicio del sistema en particular, por ejemplo. para ejecutar un demonio en particular. Los procesos que proporcionan ese servicio se ejecutan como ese usuario, los archivos de datos manipulados por el servicio son propiedad de ese usuario y los archivos de configuración son legibles por ese usuario (pero normalmente no se pueden escribir: root, es decir, el administrador del sistema, posee los archivos de configuración). ). Esta cuenta mongodb es un caso típico de bog: sería el propietario de los archivos de la base de datos MongoDB.

Los directorios de inicio no son realmente útiles para la mayoría de los usuarios del sistema. Para los usuarios humanos, determinan dónde buscan las aplicaciones los archivos de configuración, pero eso no es una preocupación para los usuarios del sistema que solo ejecutan un programa específico que no lee los archivos de configuración por usuario. El directorio principal también es donde el servidor SSH busca las claves autorizadas del usuario, es decir, las credenciales adicionales que otorgan acceso a la cuenta, pero la mayoría de los usuarios del sistema no deben iniciar sesión y, por lo tanto, no tendrán claves SSH. A veces, el directorio principal es un directorio del sistema (por ejemplo, bajo /var ), a veces es / , a veces es un directorio inexistente, no importa.

Los usuarios del sistema pueden o no tener una shell válida como su shell de inicio de sesión. Tener una shell válida como /bin/sh permite cosas como su mongodb pero en muchos casos esto no es necesario y el shell de inicio de sesión está configurado como un programa que no hace nada , como /bin/false , /bin/true o /usr/sbin/nologin . Esto sirve como una capa adicional de defensa si alguna otra parte de la configuración es errónea y permite al usuario iniciar sesión.

La mayoría de las formas de acceder a una cuenta de usuario ejecuta el shell de inicio de sesión del usuario, incluido SSH (pero también su , cron, etc.). Normalmente, con el shell configurado en /bin/false , incluso si lograste iniciar sesión a través de SSH, no podrías ejecutar nada. El error que encontraste, CVE-2016-3115 , se debe a que OpenSSH ejecuta la inyección de la cookie X11 (llamando a xauth ) antes de que ejecute el shell de inicio de sesión del usuario.

Pero para explotar este error, primero deberá pasar la primera capa de defensa e iniciar sesión en la cuenta mongodb . Esto no debería ser posible: la cuenta no tiene claves públicas autorizadas ya que su directorio de inicio no existe, y no debería tener una contraseña. Tener x en la columna de contraseña de /etc/passwd no indica que la cuenta tenga una contraseña; Es probablemente el caso de todas las cuentas. Esto significa que el hash de la contraseña, si existe, está en /etc/shadow .