Ready - Walkthrough
Última actualización
Última actualización
Técnicas aboradas:
Explotación Redis-CLI
Abuso grupo disk (debugfs)
Fuerza bruta id_rsa key
Fuerza bruta archivo ZIP
Escaneo de puertos sobre la máquina con nmap.
Escaneo de los servicios de los puertos abiertos con nmap.
Echamos un vistazo al servicio web HTTP publicado por el puerto 80. Nada interesante, el simple index.html por defecto de Apache.
Echamos un vistazo al servicio web HTTP publicado por el puerto 8080. Es muy probable que este servicio web este configurado con Redis, para que de alguna forma sea posible interactuar en el almacenamiento o recuperación de datos.
Realizamos fuzzing en busca de directorios y archivos ocultos en los dos servicios webs mencionados anteriormente. No encontramos nada interesante en ninguno de los servicios webs publicados.
Nos centraremos por el servicio Redis publicado por el puerto 6379.
Existe el comando info para listar información acerca del servicio (el output del comando es mas largo, he acordado la salida de información).
Configuramos el directorio por defecto de un servicio web Apache. En este punto desconocemos si Redis hace uso del servicio web Apache publicado por el puerto 80 o 8080, pero es mas probable que haga uso del publicado por el 8080.
Cambiamos el nombre del archivo de la base de datos de Redis.
Por defecto, Redis almacena los datos en un archivo llamado "dump.rdb". Sin embargo, con este comando, estamos cambiando el nombre del archivo de la base de datos a "redis.php". Esto significa que Redis guardará los datos en un archivo llamado "redis.php" en lugar de "dump.rdb".
Establecemos la shell interactiva como valor dentro de la variable redis.
Guardamos la configuración y en este caso Redis, escribirá los datos en el archivo de base de datos redis.php.
Accedemos vía navegador al servicio web publicado por el puerto 8080 y probamos de realizar un RCE y tenemos ejecución de comandos.
Vamos a proceder a enviarnos una reverse shell por el puerto 4444. Abrimos el puerto con netcat.
Ejecutamos el RCE donde nos enviaremos la reverse shell.
Recibimos la reverse shell.
Realizamos el tratamiento de la tty.
Durante la enumeración de grupos del usuario ben, encontramos que pertenece al grupo disk. Este grupo es muy peligroso porque hay maneras de acceder a todos los datos de una máquina a través de el.
Buscamos donde esta montada la raíz del sistema "/".
Entramos con debugfs dentro del sistema de archivos donde se monta la raíz para modificar el propio sistema de archivos.
Leemos la clave privada ssh del usuario root.
Nos traemos la clave privada a nuestra máquina y sacamos el hash con ssh2john.
Con john procedemos a romper el hash y sacar la contraseña de la passphrase de la id_rsa del usuario root.
Accedemos al usuario root de la máquina víctima vía ssh con la id_rsa.
Obtenemos la flag del usuario ben.
Nos damos cuenta que la root flag esta comprimida en un archivo zip, procederemos a traerlo a nuestra máquina.
Procedemos a descomprimir el fichero zip pero nos damos cuenta que esta protegido con contraseña.
Con la herramienta zip2john sacamos el hash de la contraseña que protege el fichero comprimido y lo volcamos en un fichero llamado ziphash.
Con john rompemos el hash y sacamos su contraseña.
Descomprimimos ahora si el fichero comprimido zip introduciendo la contraseña.
Tenemos la root flag.
es un motor de base de datos en memoria, basado en el almacenamiento en tablas de hashes pero que opcionalmente puede ser usada como una base de datos durable o persistente.
En su documentación pública pude encontrar un de comandos interesantes, en este caso probamos de acceder al servicio sin proporcionar credenciales. Es posible acceder, esto quiere decir que se ha configurado permitiendo el acceso sin necesidad de proporcionar credenciales.
Buscando información, encontramos un articulo en con información de como crear una shell interactiva y proceder con un RCE sobre un servicio Redis.
En encontramos esta entrada muy interesante donde se explica el proceso de elevación de privilegios desde el grupo disk.
