Red - Vulnhub Machine

Holaa!, en esta ocasión os tengo otra máquina Vulnhub, como siempre hay que agradecer a hadrian3689 por proveer estos alimentos del día de hoy.

Descripción de la maquina.

Sistema Operativo	Linux 🐧
Dificultad	Fácil
Lanzamiento	27/10/2021
Creador	hadrian3689

Esta máquina tiene una premisa algo peculiar, ya que un malechor a penetrado el servidor y tomo el control de este.

Pero calma pueblo!!, que hemos llegado nosotros, para volver a tomar el control del servidor y exterminar al malechor.

Enumeración

Escaneo de puertos y ya.

Adelantándome para observar la web del puerto 80, se mira fea y sin estilos.

Así que miré el código fuente de la web. Me percaté que hace alusión a un dominio, así que lo declaré en /etc/hosts.

Y pues mucho mejor

Y bueno, como buen malechor educado y juguetón, el mismo nos indica que ha escondido un supuesto backdoor 🤨, así que confiaremos en el, "Nunca lo hagas". Vamos a buscar el dichoso backdoor con algunas listas de seclists. Intenté con dos lista:

• seclist/Discovery/Web-Content/CommonBackdoors-PHP.fuzz.txt

• seclist/Web-Shells/backdoor_list.txt

Ajaaa, ya tenemos algunos archivos sospechosos, intuyo que este archivo debe de recibir algún parámetro para ejecutar algún comando o algo así. Ya que hablamos de un backdoor.

Así que con otra lista de parámetros comunes que he encontrado en Github, voy a aplicar un fuzz en los dos archivos. Aunque ya os adelanto que NetworkFIleManagerPHP.php es el bueno.

key es el parámetro sospechoso, así que me dirigí a la página esperando ejecutar comandos directamente.

Pero claramente no obtuve una respuesta, así que pensé en algún LFI, algo raro para mis gustos para creer que es un backdoor.

LFI

Pero funcionó, sabiendo esto busqué algo que me diera entrada a un RCE (LFI to RCE) pero sin éxito. Así que me dio por husmear el presunto backdoor que estaba haciendo uso, por el mismo LFI.

Pero al ser un archivo .php este sería automáticamente interpretado por la web, es decir, que no me lo iba a mostrar ya que este seria interpretado, así que por medio de un wrapper lo codifique a base64 de tal manera que pudiera obtenerlo.

Así que lo descargué con curl para el análisis minucioso de este backdoor.

curl 'http://redrocks.win/NetworkFileManagerPHP.php?key=php://filter/convert.base64-encode/resource=NetworkFileManagerPHP.php' | base64 -d > NetworkFileManagerPHP.php

<?php
   $file = $_GET['key'];
   if(isset($file))
   {
       include("$file");
   }
   else
   {
       include("NetworkFileManagerPHP.php");
   }
   /* VGhhdCBwYXNzd29yZCBhbG9uZSB3b24ndCBoZWxwIHlvdSEgSGFzaGNhdCBzYXlzIHJ1bGVzIGFyZSBydWxlcw== */
?>

Y bueno todo parece normal hasta que ves comentada la tremenda cadena en base64 comentada, decodificamooos y...

That password alone won't help you! Hashcat says rules are rules

Y bueno, en lo absoluto no le entendí y por el momento lo dejaré, así que pase a descargar otros archivos de wordpress como el de su configuración.

curl 'http://redrocks.win/NetworkFileManagerPHP.php?key=php://filter/convert.base64-encode/resource=wp-config.php' | base64 -d > wp-config.php

Tenemos una contraseña, pero para reutilizarla en algún otro servicio como ssh no funcionó. Aquí es donde tuve que recordar lo tenemos y que me pudiera servir. Así que retomando el comentario de mi amigo, el Red.

That password alone won't help you! Hashcat says rules are rules

Hasta que...hashcat reglas son reglas? reglas...

Ajaa, minuciosamente analicé la técnica...

Y llegué a una conclusión 😑...

Aun que me hubiera encantado haber realizado esta pequeña investigación, pero mis dedos teclearon otra cosa y di primero con un WriteUP. Aquí es donde me di cuenta de que existía algo como Rule-based attack con HashCat.

Así que no olvides tomar agua y prestar atención a las pistas proporcionadas, que estamos en un CTF :/

Dicho esto sabemos que tenemos que usar dicha técnica, así que ahí la tiene. Esta técnica lo que hace es generar un diccionario de contraseñas a partir de una sola, por lo tanto usaremos la única contraseña que tenemos.

hashcat --force pass-db.txt -r /usr/share/hashcat/rules/best64.rule --stdout > new_pass

Ahora nos falta obtener los usuarios, aunque ya tenemos a john del archivo wp-config.php, podemos tener todos los usuarios del sistema con el LFI.

curl 'http://redrocks.win/NetworkFileManagerPHP.php?key=/etc/passwd' | grep sh | awk '{print $1}' FS=':' > users.txt

Después realizamos fuerza bruta contra el servicio SSH con hydra.

Brute force SSH

Y valla, estamos dentro, analizando los posibles casos para la escalada de privilegios, me enteré de ciertas cosas que no son de mi agrado y algo fastidiosas, cosas que son responsables de Red, ya que se tomó el tiempo de aplicar ciertas "Defensas" que solo son para fastidiar, ya que estando dentro podemos encontrar lo siguiente.

• Nos cierran la sesión de john y cambian la contraseña.

• herramienta cat, modificada.

• Imprimen mensajes en la terminal.

Y ya, no hay más, son solo dos, pero suficientes para que aplique su objetivo.

Cuando *Red* cambie la contraseña de *john* solo realice nuevamente el brute force.

Escalada de privilegios

Continuando con la escalada de privilegios busqué ciertas cosas.

• Permisos en directorios /.

• Archivos del usuario.

• Privilegios de sudo (Este es el bueno).

Ya que observando los permisos que tenía con sudo, miré esto.

Y para estos casos podemos abusar de este permiso, con la ayuda de GTFObins.

Seguro? 🤨

Valla, ahora para evitar que nos quita la conexión, me enviaré una shell reversa desde el directorio /dev/shm que aquí mismo cree un archivo .sh con el usuario ippsec.

De tal manera que me hice de una shell donde el Red ya no pueda sacarme 🙂. Continuando con la escalada, busque en:

• Archivos del usuario.

• Privilegios de sudo.

• Permisos en archivos.

• Servicios web 🙂.

Dentro de la única aplicación web que es el directorio de wordpress está la carpeta .git no era el propietario, pero sí pertenezco al grupo ippsec, algo raro.

Y por supuesto que había algo raro ahí.

El archivo rev es un binario; al ejecutarlo pasa esto.

mmmm, veamos el otro archivo.

Interesante, ¿no crees? Anteriormente, les comentaba que el llamado Red está todo el tiempo spawneado mensajes en la terminal y este mensaje que imprime el binario rev ya lo había visto. Eso me hace pensar que hay una tarea cron ejecutando este binario.

Aunque este punto lo pude comprobar, observando los procesos con pspy.

Hasta que en algún momento mire el usuario con uid=0 compilo el archivo supersecretfileuc.c y ejecuto como rev.

¿Y qué podemos hacer ante esto? No tenemos permisos directamente al archivo en c, pero tenemos permisos por medio del grupo de la carpeta .git, lo que me otorga el control de la carpeta, es decir, puedo eliminar el archivo, remplazarlo con un código algo malicioso y que root lo compile y lo ejecute.

Así que obtuve el código de c para una shell reversa.

Guardé la shell y la alojé en mi máquina atacante, mediante un servicio web de python3.

Descargue la shell reversa, denle permisos de ejecución en la máquina víctima y lo mueve a la carpeta .git con el mismo nombre del anterior script, así root compilar y ejecutar el archivo sin preguntar.

No olvide ponerse en escucha para recibir su shell, hasta que en algún momento llega 🙂.

Podemos ver la flag y los scripts que "defendían" el server.

Gracias a mis maniobras defensivas y a mi maestra del kinder, logré reprimirlas para así poderlas mostrar.

Déjeme presentarle a los soldados caídos (scripts).

Por el momento es todo, espero que siga aprendiendo como nunca. Hasta luego!!

---

Referencias

• ( Red: 1 ) ( Vulnhub ) preparación OSCP

• saltacybersecurity write-up

• @juden098 write-up