CTF especial Geekshubs
Este artículo describirá la solución de un CTF que se realizó como trabajo final en Geekshubs, en el bootcamp de seguridad de final de 2020. A continuación el escenario y una de las soluciones, con la que conseguí dar.
0. Objetivo:
Como trabajo final del bootcamp de ciberseguridad en Geekshubs se propone un escenario con varias máquinas vulnerables. El objetivo es aplicar las herramientas y conocimientos adquiridos durante el curso, comprometiendo las diferentes máquinas y haciéndose con sus flags.
Se presentan los siguientes recursos para realizar el trabajo final: una red 10.244.0.0/24, donde se encuentran varias máquinas; y una conexión VPN a la red 10.240.0.0/24, la cual tiene acceso a la red 10.244.0.0/24.
1. Gathering – Recopilación de información:
1.1. Escaneo de sistemas en la red:
Tras acceder a una máquina kali-linux a través de un software de virtualización y conectarse a la VPN, se procede a realizar un escaneo de la red 10.244.0.0/24.
1. Herramienta nmap
Se utiliza la herramienta Nmap con la opción -sP (“skip port scan”) para realizar un escaneo rápido de los sistemas que se encuentran en la red.
2. Resultados de escaneo con nmap en la red 10.244.0.0/24
Nmap detecta un total de cinco máquinas. Las máquinas en las direcciones 10.244.0.115 y 10.244.0.122 son propias de Kubernetes y el ambiente virtual, y, por lo tanto, no se las tendrá en cuenta. Hay que recalcar la posibilidad de que la red puede estar segmentada y que existan máquinas adicionales que no aparecen en el scan.
1.2. Escaneo de puertos abiertos y servicios en los sistemas:
Seguidamente se ejecuta un escaneo de puertos de las máquinas en 10.244.0.6, 10.244.0.15 y 10.244.0.71. Para ello, se usará Nmap con las siguientes opciones: nmap -p- (“port” hace un scan en todos los puertos) -A (-A activa la detección de sistema operativo, la versión de los protocolos en puertos…) [IP].
3. Ejemplo de la instrucción Nmap sobre la máquina en 10.244.0.6
4. Resultados sobre la máquina en 10.244.0.6
5. Resultados sobre la máquina en 10.244.0.15
6. Resultados sobre la máquina en 10.244.0.71
2. Exploiting – Accediendo a los sistemas:
2.1. Sistema en 10.244.0.6:
El sistema en la dirección 10.244.0.6 tiene el puerto 80 (HTTP) abierto. Sobre este puerto se ejecuta un servidor Apache versión 2.4.38 sobre la cual existe una estructura Wordpress 5.5.3. Se puede acceder al Wordpress a través de un browser con la dirección IP seguido del puerto.
7. Wordpress sobre Apache en 10.244.0.6
En la web se observa que existe un usuario llamado admin, además de un enlace Log in (marcados con rectángulos rojos en la imagen 7). Tras ello, al enlace “Log in” confirma la presencia de una pantalla de Log in (imagen 8), convirtiéndose en el vector inicial de ataque.
8. Pantalla de Log In de Wordpress en 10.244.0.6
Se usará la herramienta Burp Suite para intentar crackear el sistema por fuerza bruta, obteniendo credenciales válidas. Para ello, primero, se captura la petición de Log in con el módulo Proxy->Intercept de Burp.
9. Intercepción petición de Log In
Esta petición se envía al módulo intruder, en el cual se procede al ataque por fuerza bruta con el usuario admin (obtenido anteriormente) y la lista de contraseñas del archivo “rockyou.txt”.
10. Intruder Attack
Se obtiene así la contraseña del usuario admin: “admin:secret”. Con estas credenciales se puede acceder a la plataforma de Wordpress, consiguiendo la primera flag. Esta se encuentra en la pestaña de users, dentro del campo de email.
11. Flag en el campo de usuarios dentro de Wordpress
Luego, se observa que la plataforma dispone de un plug-in llamado “Ajax Load More”, el cual se encuentra desactualizado en la versión 2.80. Una búsqueda rápida en internet descubre que la versión del plug-in es vulnerable y que cuenta con un módulo en metasploit para explotarlo.
En metasploit se utilizará el módulo: wp_ajax_load_more_file_upload. En este se configuran los parámetros de dirección IP, usuario y contraseña. El payload se configura como un meterpreter/bind_tcp, no como un reverse_tcp, ya que la máquina Kali si puede conectarse a la dirección 10.244.0.6, pero no a la inversa.
12. Parámetros del exploit wp_ajax_load_more_file_upload
Una vez ejecutado el exploit y navegando por el sistema de archivos se halla la segunda flag.
13. Segunda flag
2.2. Sistema en 10.244.0.15:
El sistema en 10.244.0.15 tiene el puerto 22 (FTP) abierto. Sobre este se ejecuta el servicio VSFTPD con versión 2.0.8, además, permite anonymous log in. Al acceder con el comando: ftp -p 10.244.0.15 y con usuario anonymous y contraseña en blanco, se accedió al servidor FPT. Se puede acceder a todo el sistema, menos al directorio root. En el directorio /var/ftp/ se encuentra la tercera bandera.
14. Descarga de la tercera flag del servidor FTP
15. Tercera flag
Se procede a conseguir una shell en el sistema, con el objetivo, luego, de escalar privilegios y acceder al directorio root. Para ello, se hace uso de un exploit de VSFTPD que se encuentra en metasploit. El exploit “vsftpd_234_backdoor” hace uso de una puerta trasera en VSFTPD, abriendo una puerta trasera en el puerto 6200.
16. Exploit vsftpd 234 backdoor
Se observa que el usuario ftp está dentro del grupo de administradores y que simplemente con la instrucción sudo su se consigue el root del sistema. Al acceder a la carpeta root se encuentra la cuarta flag.
17. Cuarta flag y cadena de texto
Además del código hash de la flag, se puede observar una cadena de texto que parece cifrada en BASE64. Al descifrarla se obtiene lo siguiente: “#root:passw0rd”. No se encuentra nada de valor al investigar el sistema y archivos como /Etc/passwd.
El siguiente paso lógico es conseguir un meterpreter en la máquina, ya que la shell del exploit de VSFTPD es demasiado básica. En este punto, existe el problema de que el sistema es read-only y se necesita permiso de escritura para subir un payload y conseguir un meterpreter.
No obstante, se observa que existe un directorio en el sistema: /var/log/ con un archivo llamado “vsftpd.log” que sí cambia. Al usar la instrucción touch se crea un archivo en el directorio, confirmando así que es el único directorio del sistema que permite escritura, lugar donde se subirá el payload.
Se crea un payload con la herramienta de msfvenom en formato .elf (Linux). El meterpreter será de tipo bind por lo comentado anteriormente en el payload del sistema wordpress.
18. Creación de un payload con msfvenom
Una vez con el payload creado, este se sube a la máquina FTP en el directorio /VAR/LOG/. Luego, se le da permisos de ejecución con chmod 744 y se ejecuta, abriendo así el puerto 4444 a la espera de una conexión.
19. Carga del payload y ejecución
Luego, se utiliza el módulo de metasploit multi/handler para conectarse a la máquina FTP, consiguiendo un meterpreter.
20. Consecución de un meterpreter en la máquina ftp
En este punto conviene averiguar si existe alguna otra máquina conectada a la máquina ftp, para ello se hace uso del script de meterpreter run arp-scanner.
21. Error en la ejecución de run arp-scanner
Debido a que el script no funciona, se envía la sesión al background y se pivotará usando route add. Se añade la red de 10.244.0.0/24, utilizando como gateway el número de sesión de meterpreter. Metasploit usará esta ruta de red cada vez que se lance un módulo contra una IP dentro de la red 10.244.0.0/24. Más adelante, se utiliza otro módulo de metasploit llamado socks4a para poder utilizar la ruta de red que proporciona el meterpreter fuera de metasploit. Por último, se añade al archivo proxychains.conf (se encuentra en el directorio /etc/) la ruta que proporciona el server de socks4a.
No obstante, al lanzar Nmap con proxychains para averiguar si existen otras máquinas en la red, no se obtiene nada nuevo.
22. Nmap contra todos los puertos de la red a través de proxychains
23. Resultados del nmap con proxychains
Debido a esto, se usa un escáner interno de metasploit llamado portscan/tcp. Se configura este escáner para analizar toda la red, desde el puerto 1 al 65535.
24. Configuración del escáner portscan/tcp
25. Primeros resultados del scan
Se descubre una máquina en 10.244.0.55 con el puerto 22 (SSH) abierto, pero al intentar conectarse a ella a través de proxychains y SSH, rechaza todas las conexiones. El escáner continúa durante varias horas, descubriendo una máquina en la IP 10.244.0.58 con el puerto 22222 abierto.
26. Máquina descubierta en el 10.244.0.58
Tras una búsqueda en internet se descubre que el puerto 22222 se suele utilizar para conexiones SSH, ofuscando su puerto típico, el 22. Se vuelve a usar proxychains para hacer una conexión SSH con esta nueva máquina. Se usan el usuario y contraseña descubiertos en la flag dentro de la carpeta root de la máquina FTP.
Se consigue conexión con la máquina, encontrando la quinta flag.
27. Conexión con la nueva máquina y 5 flag.
2.3. Sistema en 10.244.0.71:
El sistema en 10.244.0.71 tiene el puerto 80 (HTTP) abierto. Sobre este se ejecuta un servidor nginx versión 1.19.0. Al acceder al servicio a través de un browser vemos que se trata de una página tipo, sin ningún enlace interior ni pista en su código.
28. Servidor nginx sobre 10.244.0.71:80
Se usa la herramienta dirbuster para descubrir directorios y archivos en el servidor, pero al usar los wordlists del propio dirbuster, no se consigue nada más que la página de inicio “index.html”. En consecuencia, se usa un wordlist de mayor extensión:
https://gist.github.com/jhaddix/f64c97d0863a78454e44c2f7119c2a6a
Dirbuster consigue encontrar un directorio con el nuevo wordlist. Al acceder a este se observa que el directorio existe, pero no podemos acceder a él.
29. Mensaje del servidor al intentar acceder a whynot/eureka
Al obtener el mensaje “403 Forbidden” del servidor, se utiliza el directory traversal attack para conseguir la sexta y última flag.
30. Sexta flag.