Reconocimiento
Comprobamos la disponibilidad de la máquina objetivo:
|
|
|
|
ttl->63 Linux por proximidad.
Lanzamos nmap para ver los servicios expuestos:
|
|
|
|
Extraemos los puertos del archivo mediante expresiones regulares:
|
|
|
|
Lanzamos los scripts de reconocimiento y versión de nmap para recopilar más información de los servicios expuestos:
|
|
|
|
Añadimos el dominio a nuestro archivo “/etc/hosts”.
Obteniendo acceso a la máquina víctima
Principalmente actuamos como si fueramos un usuario normal y vemos como funciona la aplicación, creamos nuestro usuario y guardamos algunas contraseñas; en paralelo dejamos trabajando gobuster para listar directorios:
|
|
Tras un poco obtenemos:
|
|
Con unas contraseñas almacenadas y un usuario creado intentamos acceder:
Obtenemos un error y vemos que Werkzeug está por detrás como WSGI.Echando un vistazo más detenidamente al error:
Parece ser que hay un parametro que gestiona el fichero que hay que leer para descargar el csv asociado, lo que significa que podemos hacer lo siguiente para poder ver contenido de ficheros del sistema como “/etc/passwd” para ver posibles usuarios potenciales e intentar iniciar sesión en la aplicación.
|
|
Nos descargamos el csv y podemos ver el contenido del archivo. Las líneas más relevantes son:
|
|
Tres potenciales usuarios.
Una vez ganado LFI podemos generar el PIN para acceder a la consola “debug” del servicio web. Hay múltiples recursos en la web; yo en concreto me he basado en el siguiente: enlace.
Una vez en la consola de desarrollo podemos ejecutar comandos en la máquina objetivo, por lo que entablamos una reverse shell.
Escalada de privilegios
SQLalchemy: usuario Corum
Ya dentro del equipo podemos echar un vistazo a los archivos de una forma más eficiente. Hay un archivo de configuración en json con credenciales para la BBDD. Creamos el siguiente script y usamos esta información:
|
|
¿Cómo podemos saber las columnas y el nombre de la tabla? Echando un vistazo a los archivos del servicio, en “passwords.py”:
Y obtenemos:
Chrome Remote Debug Port: Usuario Edward
Una vez conectados a través de ssh, echando un vistazo a los archivos del sistema, veo que chrome está instalado (ls -la /opt
) lo que no suele ser común en estas máquinas.
Si observamos los procesos:
Para poder acceder desde nuestro equipo hacemos “port forwarding”" vía ssh y accediendo a Chrome:
Inspeccionando la página:
Sudoedit: root
Ya desde Edwards como dev_admin podemos ejecutar:
Como versión de sudo tenemos la 1.9.9, por lo que podemos usar la siguiente vulnerabilidad para escribir algún fichero extra:
Vemos los ficheros que podemos editar ya sea como usuario o grupo:
|
|
|
|
|
|
|
|
Buscando si se ejecuta algún proceso que implique alguno de estos archivos:
|
|
Nos devuelve que se está ejecutando “pytest”. Recordando un fichero anterior de actualización:
De alguna forma root debe ejecutar source /app/venv/bin/activate
para poder ejecutar el test, por lo que aprovechando esto:
|
|
Damos permisos SUID:
Y con esto finalizamos la máquina y obtenemos permisos de administrador.