Symfonos 1 + Symfonos 2 Walkthrough
Última actualización
Última actualización
En este laboratorio el objetivo principal es realizar un pivoting entre una máquina de salto que contiene una interfaz de red con direccionamiento similar a nuestra máquina Kali y otra interfaz de red con direccionamiento de una red la cuál no tenemos acceso desde la red de la máquina Kali. El mapa topológico sería el siguiente:
Las IPs pueden variar debido a que son asignadas por DHCP. Las que se muestran en la imagen son orientativas para entender el objetivo de este laboratorio.
Todas las máquinas del laboratorio están virtualizadas bajo VMware.
Lo primero que haremos para iniciar la fase de reconocimiento, es escanear la red vía paquetes ARP. Con esto conseguiremos identificar tanto la IP como MAC de todas las máquinas de nuestra red. Hay que recordar que la máquina atacante tiene una IP de la red 192.168.1.X/24.
En un primer escaneo veo que la única IP de la que sospecho y desconozco, es la siguiente 192.168.1.52. Por mi intuición diría que esta pertenece a la máquina symfonos1.
Los 3 primeros bloques de una MAC siempre corresponden al OUI del fabricante, por eso filtraremos lo encontrado para ver a que vendedor pertenece.
Vemos que coincide con la MAC encontrada y nos aseguramos de que esta es la máquina symfonos1 virtualizada.
El primer paso que haremos es realizar un contacto vía ping con la máquina. Como se observa el TTL tiene como valor 64 por lo que ya se intuye que es una máquina Linux.
Mediante un ping con la opción -R listamos todos los saltos a nivel enrutamiento del paquete vemos que tenemos contacto directo y no pasamos por ningún intermediario.
Realizamos un primer escaneo con nmap y detectamos los siguientes puertos abiertos.
Lanzamos un escaneo más agresivo con los scripts de nmap a los puertos ya encontrados.
Este es el resultado del escaneo con mucha más información detallada de cada servicio.
Así a primeras vemos el puerto SSH (22) abierto, servicio postfix (25), servicio HTTP (80) y servicio SMB (139 y 445). El servicio web está corriendo bajo un Apache 2.4.25. Vía SMB nos reporta que el hostname de la máquina es symfonos y la versión del sistema operativo Debian 4.5.16.
A nivel web, con la herramienta whatweb vamos a lanzar un escaneo de las tecnologías utilizadas. No encontraremos mucha información relevante.
En esta fase de explotación investigaremos como explotar los diferentes servicios para conseguir acceso a la máquina víctima. Vamos a echar un vistazo por navegador sobre la página web de la máquina víctima. Esto es lo que nos encontramos.
Si inspeccionamos el código fuente de la página web no veremos mucha más información que lo ya visto.
Nos enfocaremos en el puerto 445 - SMB para ver si encontramos algo de información útil. Con smbmap nos conectaremos a la máquina víctima para enumerar que recursos a nivel de red está compartiendo. Vemos los siguientes.
Vemos dos recursos muy interesantes, uno de ellos es helios el cual a nivel de permisos no tenemos acceso, pero nos da un indicio de que puede haber un usuario a nivel de máquina llamado helios y otro recurso llamado anonymous que a nivel de permisos tenemos solo Read Only.
De forma recursiva vamos a listar todo lo que contenga el recurso compartido anonymous. Vemos que hay un archivo de texto plano llamado attention.txt.
Nos descargamos el archivo para inspeccionarlo.
Una vez descargado le cambiamos el nombre por comodidad. Listando el contenido, se nos muestra un mensaje donde se pide que los usuarios dejen de utilizar las contraseñas siguientes. Esto nos puede dar un pequeño indicio de que una de estas contraseñas puede ser utilizada para algo. Vemos que el archivo ha sido escrito por alguien llamado zeus, quizás es un usuario valido de la máquina.
Lo que haremos a modo de documentación es crearnos un archivo llamado passwords.txt apuntando estas tres contraseñas por si acaso en un futuro las podemos probar para autenticar algo.
Realizaremos un ataque de fuerza bruta al servicio SSH con el listado de posibles contraseñas hacía el usuario zeus. No hay éxito y no sabemos ni si quiera si zeus es un usuario válido.
Volviendo al servicio Samba – 445 habíamos encontrado un recurso de red llamado helios el cual en el campo comentario tenía lo siguiente: Helios personal share.
Vamos a probar de acceder al recurso compartido con usuario helios y como contraseña probaremos las guardadas en el archivo passwords.txt.
Con la contraseña epidioko no tuvimos suerte, pero si con qwerty. Ya sabemos que el usuario helios es válido y tenemos su contraseña.
Encontramos dos ficheros llamados research.txt y todo.txt. Nos los descargamos para echarles un vistazo.
Realizamos los cambios de nombre a los ficheros por comodidad. En el archivo todo.txt vemos que hay una especie de llamada a lo que parece ser un directorio el cual quizás podamos llegar vía web.
Accedemos a lo que parece ser un directorio web. Vemos la siguiente información al acceder vía web. La página esta creada por WordPress y un usuario admin realizo un post. Cuando el resultado vía web lo vemos en este tipo de formato suele venir precedido la web es Virtual Hosting. Si inspeccionamos el código fuente podemos sacar mucha más información al respecto.
Si echamos un vistazo al código fuente de la página web veremos que hace llamadas a un dominio symfonos.local.
Agregaremos el dominio en nuestro archivo hosts apuntando hacía la IP de la máquina víctima.
Ahora si cargamos la web de nuevo apuntando al dominio symfonos.local, veremos una representación mucho mejor.
Con whatweb podemos listar las tecnologías utilizadas por parte de la web. Vemos versión de Apache, WordPress, JQuery, etc.
Vamos a inspeccionar el código fuente de la página para tratar de sacar información sobre posibles plugins, etc. Vemos un plugin de WordPress llamado mail-masta. Este plugin está lleno de vulnerabilidades a explotar como por ejemplo una LFI.
Si recordamos y tiramos de memoria, cuando hemos realizado el escaneo de servicios hemos visto que había un postfix por el puerto 25.
Haciendo una búsqueda de exploits asociados a mail-masta encontramos dos LFI y un SQLi. Nos centraremos en el primero de la lista.
Lo descargamos e inspeccionamos el exploit. Vemos una PoC para explotar el LFI de dicha vulnerabilidad.
Vamos a probar de realizar nosotros mismos esta PoC desde el navegador.
Vemos como hemos podido sacar el contenido del fichero /etc/passwd. Viendo el código fuente de la página lo veremos mucho más cómodo.
Para automatizar todo el proceso de explotación, crearemos un script que vía curl pueda hacer las llamadas por consola y explotar la vulnerabilidad mas cómodamente. Le pasaremos como parámetro el fichero que queremos mostrar y nos lo devolverá.
Vamos a realizar una PoC con nuestro script automatizado sobre el exploit LFI encontrado.
Y aquí vemos el resultado. Hemos conseguido leer el archivo /etc/passwd de la máquina víctima.
Vamos a filtrar en el fichero /etc/passwd todas aquellas líneas que acaben en sh para ver usuarios potenciales de sistema porque así buscamos por la shell bash. La máquina como vemos solo tiene usuarios de sistema root y helios.
Como habíamos visto anteriormente, el servicio de correo este activo por lo que quizás podemos listar los logs de correo del usuario helios que sabemos que existe en el sistema. Tenemos éxito.
Visto que tenemos acceso a los logs de correo del usuario helios podemos tratar de realizar un Log Poisoning de los logs. Para ello mediante telnet podemos conectamos al puerto 25 de correo de la máquina víctima y quizás con el comando FROM podemos enviar un correo falso a un usuario que conozcamos como por ejemplo helios e inyectar código PHP para que lo interprete y realizar un RCE.
Vemos que tenemos acceso y ahora toca la parte más crítica, validar que sin autenticación podemos realizar lo comentado anteriormente.
Vemos que sin autenticación de un usuario válido, podemos realizar la primera fase. Ahora vamos a probar si podemos realizar el input de datos.
La idea es introducir una webshell PHP simple donde podamos realizar un RCE vía el parámetro cmd.
Si volvemos a consultar los logs de correo /var/mail/helios, vemos que se ha enviado el mail, pero no se ha ejecutado nada.
Esto es normal porque lo que hemos realizado es un Log Poisoning y ahora vamos a poder tramitar una petición GET con curl realizando RCE a través del parámetro cmd.
Vemos que con la concatenación del parámetro cmd a través del Log Poisoning que hemos realizado, podemos ejecutar comandos a nivel de sistema. En este caso hemos realizado un whoami y nos muestra el usuario helios.
Listamos los grupos a los que pertenece el usuario helios con el comando id.
Resumiendo, hemos realizado un LFI a RCE mediante un Log Poisoning.
Para enviarnos una reverse shell primero de todo vamos a comprobar si NetCat está instalado en la máquina víctima.
Esta instalado. Recordad que el símbolo + introducido entre which y nc, es para substituir los espacios.
Ahora vamos a ponernos en escucha en nuestra máquina por el puerto 443 donde recibiremos la reverse shell.
Y ahora realizaremos la petición para ejecutar el envío de la bash con NetCat.
Verificamos que nos ha llegado la reverse shell correctamente.
Tenemos acceso. Ahora es necesario una vez ganado el acceso, realizar un correcto tratamiento de la tty.
Para el tratamiento de la tty, lanzamos el comando script /dev/null -c bash y CTRL+Z.
Lanzamos el comando stty raw -echo; fg.
Lanzamos reset xterm seguidamente y ya vemos algo mucho más acorde.
Veremos que al exportar un nuevo valor para la variable TERM se nos descuadra un poco el prompt. Esto se debe a la proporción de tamaño de la tty, debemos ajustarla a nuestro tamaño.
Para ajustar bien el tamaño de la tty, nos vamos a una nueva ventana de consola y ejecutamos el comando stty size. Con esto veremos que tamaño tienen las ttys de nuestra máquina y podremos ajustar este tamaño a la reverse shell, así evitaremos el problema de encuadre.
Ajustamos el tamaño de la tty de la reverse shell.
Ahora ya en este punto tenemos acceso a la máquina symfonos1 que si recordamos hace de intermediaría entre dos redes. Si lanzamos el comando ip a visualizaremos las dos interfaces de red.
Ahora como ya tenemos acceso a esta máquina intermedia y por lo tanto tenemos acceso a la segunda red, vamos a utilizar dicha máquina como “puente”. Vamos a empezar con el descubrimiento de hosts de la segunda red. Para ello crearemos un pequeño script en nuestra máquina Kali que mediante ICMP realice un host Discovery.
Recordad darle permisos de ejecución al script con chmod. Comprobamos que la máquina víctima tiene wget.
Nos abrimos el puerto 80 de nuestra máquina Kali, para poder transferir el script. Importante abril el servidor HTTP desde el directorio que se encuentra el fichero a copiar.
Vía wget nos traemos el fichero a la máquina víctima.
En este punto el script, debería tener permisos de ejecución ya que se lo hemos dado anteriormente, y si no es así se lo damos.
Ejecutamos el script y vemos que hosts nos descubre dentro de la segunda red.
Vemos dos IPs interesantes, por supuesto la dirección 10.10.0.129 pertenece a la segunda interfaz de la máquina symfonos1, pero la dirección 10.10.0.128 desconocemos a quien puede pertenecer. A priori podemos intuir que se trata de la máquina víctima de la segunda red.
Ya visto esto, para ganar persistencia en la máquina symfonos1 vamos a intentar realizar la escalada de privilegios. Revisamos de nuevo a que grupos pertenece el usuario helios.
En cuanto a grupos no hay nada interesante.
Desde la raíz vamos a realizar una búsqueda de privilegios SUID. Hay un fichero en que salta mucho a la vista por estar ubicado en un directorio poco común como es opt.
Tras listar el contenido del fichero nos encontramos con caracteres no legibles por lo que se puede entender que es posible que sea un archivo compilado o codificado, por lo que verificaremos que tipo de fichero es.
Estamos en lo cierto, parece ser un fichero compilado para Linux. Si lo ejecutamos para ver exactamente que realiza, vemos que hace una especie de petición que seguramente será vía curl.
Con el comando strings podremos imprimir por pantalla las cadenas de caracteres imprimibles.
Como podemos ver curl se está ejecutando de forma relativa por lo que no se contempla la ruta absoluta del comando durante la ejecución. Viendo esto podemos llegar a intentar realizar un PathHijacking para hacer la escalada de privilegios.
Esto se puede hacer porque al ejecutar el script statuscheck de forma privilegiada, si engañamos al path haciéndole creer que esta ejecutando un curl pero realmente estará ejecutando un script llamado curl que modificara el SUID de la bash, podremos realizar la escalada de privilegios.
Primero de todo en nuestra máquina local nos crearemos un fichero llamado curl.
Importante que el fichero sea un script. Como queremos darle SUID a la bash tendremos que introducir dentro del script el comando para realizar esta acción.
Lo transferimos a la máquina víctima montándonos un servidor HTTP en nuestra máquina Kali para que mediante wget nos lo podamos descargar, acción similar a lo realizado anteriormente para poder subir el script hostDiscovery a la máquina víctima. Recordad darle permisos de ejecución al script.
Si ejecutamos el script statuscheck veremos que no modificamos el SUID en la bash. Esto se debe a que el curl que se ejecuta por detrás, no está atacando a nuestro script curl. Para que realice la modificación, tenemos que modificar el PATH del usuario helios para que apunte a nuestro directorio tmp donde se encuentra nuestro script curl.
Modificaremos el PATH del usuario helios de la siguiente forma. Con esto estaremos añadiendo al PATH que consulte siempre primero, el directorio actual-
Muy importante modificar nuestro script curl y quitarle la extensión (error en los pasos anteriores) .sh porque si no, no lo ejecutará.
Ejecutamos de nuevo el script statuscheck y comprobamos si se ha realizado el secuestro de la bash.
Tenemos la bash con privilegios SUID. Ahora podemos realizar la escalada de privilegios.
Tenemos el usuario root.
Ahora ya comenzaremos con la fase de reconocimiento de la máquina con dirección IP 10.10.0.128 de la segunda red. Para ello tenemos dos opciones, o subirnos un portable de nmap o crear un script para el escaneo de puertos. Vamos a crear el script y lo haremos en nuestra máquina local para luego transferirlo a la máquina víctima symfonos1. Nos situamos en el directorio tmp para trabajar desde allí en la máquina víctima.
Script para hacer el reconocimiento de puertos.
Creamos de nuevo un servidor HTTP temporal en nuestra máquina Kali.
Desde la máquina víctima realizamos la descarga del script vía wget.
Le damos permisos de ejecución al script.
Lanzamos el script. Vemos los siguientes puertos abiertos que nos muestra en los primeros segundos tras su ejecución.
Vemos que el script es útil pero lo que nos interesa en este punto es poder lanzar nmap y sus scripts de reconocimiento desde nuestra máquina atacante hacía la máquina symfonos2. Para ello debemos jugar con chisel con una conexión tipo SOCKS.
Nos lo traemos a nuestro directorio de exploits y seguidamente le cambiaremos el nombre para que sea mas cómodo.
Lo descomprimimos y le damos permisos de ejecución.
Le reduciremos el peso al ejecutable chisel para poder transferirlo mucho mejor.
Nos compartimos de nuevo un servidor HTTP en el directorio donde se encuentra chisel para transferir-lo a la máquina symfonos1.
Y lo transferimos a la máquina symfonos1.
Por si acaso le damos de nuevo permisos de ejecución.
Ahora en nuestra máquina como atacante ejecutaremos chisel en forma de servidor, de modo que en la máquina symfonos1 lo ejecutaremos en forma de cliente.
Lo que haremos sera tunelizar todo el tráfico de ciertos puertos a traves de un proxy SOCKS. En este caso utilizaremos un reverse proxy.
En el lado cliente hacemos un remote port forwarding vía SOCKS hacía la IP de nuestra máquina Kali.
Y vemos como del lado de nuestra máquina atacante que actúa como servidor se nos ha creado una interfaz virtual que escucha por el puerto 1080.
Y en nuestro fichero /etc/proxychains vamos a configurar una nueva conexión tipo SOCKS5.
Ahora para realizar el escaneo con nmap aprovechándonos de este túnel tipo SOCKS5 que nos hemos montado con chisel, tenemos que establecer en cualquier comando el comando proxychains por delante de todo. Ejemplo:
Si queremos escanear el puerto 80 de la máquina symfonos2, hacemos lo siguiente. Es importante establecer un escaneo por -sT (TCP connect) para que no nos de problemas el escaneo por el túnel SOCKS5
Dejaremos configurado vía FoxyProxy una nueva entrada SOCKS5 por la IP 127.0.0.1 y puerto 1080, podemos llegar a ver el contenido web HTTP de la máquina symfonos2 aprovechando al túnel.
Realizamos un escaneo para todos los puertos abiertos, tenemos primero que redirigir el flujo del stderr al stdout y quitar con grep los diferentes errores que nos muestra nmap debido al túnel.
El escaneo se demora mucho debido a que no estamos realizando un SYN scan (-sS). Pero escanearemos solo los 500 puertos más comunes.
Jugamos con la exportación de los puertos y nuestra herramienta extractPorts.
Ahora lanzaremos los scripts de reconocimiento para todos los servicios de la máquina symfonos2.
Ya tenemos el archivo targeted con toda la información de cada servicio.
Listamos los recursos compartidos en red de la máquina symfonos2. Vemos un recurso anonymous con acceso de lectura. Accedemos al directorio.
Vemos un directorio backups. Accedemos al directorio.
Vemos un archivo de texto plano llamado log.txt. Nos descargamos el fichero. Lo descargamos y lo renombramos para una mayor comodidad.
Si le echamos un vistazo al contenido del archivo lo primero que vemos es que esta cateando el contenido del archivo shadow y el resultado (stdout) lo está redirigiendo a una copia.
Inspeccionando el archivo más a fondo también encontramos que a nivel de recursos de red el recurso anonymous se mapea con una carpeta home llamada aeolus.
Echando un vistazo a otros servicios habíamos visto que FTP estaba abierto y la versión era ProFTPD 1.3.5, una versión bastante antigua la cual es posible que contenga varías vulnerabilidades.
Encontramos las siguientes vulnerabilidades. Cabe destacar que la única que funciona es la última listada.
Si vemos de que trata la vulnerabilidad podemos observar que a través de una conexión vía FTP, con los comandos CPTO y CPFR podemos copiar archivos de la máquina origen a nuestra máquina como destino.
Así que nos conectaremos vía FTP a la máquina symfonos2 y comprobaremos si tenemos capacidad de poder ejecutar estos dos comandos.
Con estos comandos lo que vamos a tratar de copiar es el archivo shadow.bak hacía el home del usuario aeolus porque al estar mapeado con el recurso de red anonymous nos lo podremos traer a nuestra máquina.
Si volvemos a listar el recurso compartido deberíamos ver el archivo .bak.
Nos descargamos el fichero .bak.
Lo movemos de directorio y le cambiamos el nombre para una mayor comodidad.
Con john craqueamos las contraseñas y conseguimos sacar la del usuario aeolus.
Como hemos visto anteriormente, en la máquina symfonos2 tenía el puerto SSH abierto así que probaremos de acceder con estas credenciales. Tenemos acceso.
Vamos con la escalada de privilegios de esta última máquina. Echamos un vistazo a los grupos el cual pertenece, pero no encontramos nada interesante.
Tampoco tenemos éxito con el comando sudo -l.
Echamos un vistazo a los puertos internos abiertos y encontramos un puerto 8080 muy interesante el cual no habíamos descubierto durante la fase de reconocimiento.
Este puerto no lo descubrimos porque muchas veces el firewall de Linux (iptables) puede denegar el acceso desde fuera a ciertos puertos.
Lo que tenemos que hacer ahora es tratar de traernos el puerto 8080 de symfonos2 hacía nuestro puerto 8080 realizando un local port forwarding vía SSH.
Comprobamos que nuestro puerto local 8080 está ocupado por SSH.
Accedemos vía web para ver de qué se trata y vemos lo siguiente. Estamos ante LibreNMS, un sistema de monitorización.
Probamos de acceder reutilizando las credenciales de aeolus. Tenemos acceso.
Buscamos vulnerabilidades asociadas a LibreNMS. Encontramos una interesante.
Inspeccionamos el script más a fondo para ver qué es lo que explota. Si nos fijamos lo que se intenta realizar es mediante la url addhost y un campo llamado community, inyectar un payload para generar una reverse shell. Veremos más en detalle el proceso cuando realicemos una investigación más a fondo al programa.
Vemos que addhost se encuentra en las siguientes opciones.
Y dentro del formulario de añadir un device, un campo llamado community como el que se encontraba en la petición del exploit. Ya podemos intuir que inyectando cierto código a través de este campo es posible entablarse una reverse shell.
Vamos a copiar el payload utilizado en el exploit para realizar la explotación manualmente controlada por nosotros.
La idea es tramitar el alta del device manualmente para poder realizar la explotación. Introduciremos los mismos valores que el exploit para los otros campos del formulario.
Antes de todo nos vamos a poner en escucha por el puerto 4343 para recibir la reverse shell.
Configuramos el device que vamos a añadir con los siguientes parámetros y el payload. La reverse shell la enviaremos a la propia máquina symfonos2 por el puerto 4343 previamente puesto en escucha.
Nos mostrará una alerta conforme el device se ha añadido correctamente.
Ahora nos iremos al listado de dispositivos que existen para buscar el nuestro. La ruta es la siguiente.
Lo vemos ahí creado. Entramos dentro del device creado.
En este punto nos dirigimos a las opciones del device para mediante la opción capture empezar la explotación.
Como último paso debemos lanzar el proceso de captura mediante SNMP. Este proceso lo que hará es comunicarse contra el fichero ajax_output.php y devolvernos una shell.
Y ya tenemos la reverse shell. Hemos superado la fase de explotación. Somos usuario cronus.
Si listamos los permisos a nivel sudo que tiene este usuario vemos que puede ejecutar comandos mysql con privilegios.
Encontramos el siguiente comando que si tenemos poder de ejecutar mysql como sudo crearemos una shell con privilegios.
Ejecutamos el comando y hemos ganado acceso como root.
Tenemos la flag final. Laboratorio completado.
Primero de todo nos descargamos chisel en github y nos descargamos el release de linux_amd64.
Ante este tipo de casos, nos iremos a gtfobins para ver si hay alguna escalada de privilegios con mysql.
