Skynet Walkthrough - TryHackMe [EN][ES]

Write-up of the room Skynet - TryHackMe. Difficulty: Easy 🟢

Skynet Walkthrough [EN]

[Task 1] Deploy and compromise the vulnerable machine!

Deploy the machine and wait 5 minutes:

My initial Nmap scan:

Search in the source code, robots, so on. Fuzzing the web directories I found a secret path:

After exploring the samba shares, with the anonymous credentials, I found a possible user “milesdyson” and possible passwords in the “log1.txt” file:

After trying the possible credentials in the SSH and in the “milesdyson” samba share, we found that the credentials work in the secret path of the webpage:

In the SquirrelMail we found the password for the “milesdyson” samba share:

In the “important.txt” file, we found a new secret directory in the web. After that, we fuzzed again the web with the tool GoBuster:

I found a secret path called “administrator” and if we go there, we can see a CMS called CuppaCMS. So the next step was to search and check exploits of that CMS.

After checking the exploit, we have to load the shell using the Remote File Inclusion vulnerability. For that, we need to modify the well-known php-reverse-shell, activate the local netcat and share the shell with the python server. Finally, we need to exploit the vulnerability and get a shell.

Exploit:

With the initial shell there are other ways to escalate privileges but in my case, I tried to change to the “milesdyson” user with the password used before in the SquirrelMail and it worked. Also I used this blog to get a fulltty shell.

After enumerating the system, I found a kernel vulnerability which allows us to escalate privileges with a compiled executable (link).

---

Skynet Walkthrough [ES]

[Task 1] Deploy and compromise the vulnerable machine!

Desplegamos la máquina y esperamos alrededor de 5 minutos para que se configure.

Realizamos un escaneo inicial de la máquina con Nmap:

Buscamos en el código fuente, en el robots.txt, etcétera. Fuzzeamos los directorios de la web y encontramos una ruta secreta:

Exploramos el puerto samba y los shares que contiene. Intentamos acceder sin credenciales y podemos acceder a un recurso llamado “anonymous”. En este momento, ya tendríamos un usuario potencial como es “milesdyson” y unos ficheros con información, en el que el “log1.txt” puede que sean posibles contraseñas.

Tras haber probado las distintas posibles credenciales en el puerto SSH o en el recurso compartido “milesdyson”, tratamos de loguearnos en la ruta de “SquirrelMail” que habíamos encontrado con GoBuster:

Las credenciales nos han dejado loguearnos, y encontramos en la bandeja de entrada un correo con la contraseña para el usuario “milesdyson” con el que poder acceder al recurso compartido de samba.

Tras leer la información del recurso, encontramos un fichero “important.txt” en el que nos indica una ruta secreta de la web. Después de eso, y como normalmente hacemos, fuzzeamos, otra vez, los directorios con GoBuster.

Tras el fuzzeo nos encontramos con la ruta “administrator”, la cual es un login page de CuppaCMS. Tras enumerar y buscar posibles formas, encontré un exploit haciendo uso de searchsploit para este CMS. Esta vulnerabilidad se trata de un LFI (Local File Inclusion) y de un RFI (Remote File Inclusion), que nos permite ver tanto recursos locales como hacer que la web acceda a un recurso remoto. Podemos observar como se ha comprobado que el exploit funcionaba en la segunda imagen.

Después de haber probado que el exploit funcionaba, y sabiendo que también es un RFI, nos preparamos para subir nuestra shell. Para ello, modificamos la shell de php-reverse-shell, activamos nuestro netcat local y compartimos la shell haciendo uso del servidor de Python. Tras eso, únicamente deberíamos explotar la vulnerabilidad para obtener la shell.

En este momento, ya tendríamos una shell con el usuario “www-data”. Primeramente, pasé la shell a una fulltty haciendo uso de un blog. Después, se me ocurrió hacer uso de las credenciales que habíamos obtenido para intentar escalar al usuario “milesdyson” y en este caso funcionó. Siempre tenemos que tener este factor en cuenta dado que muchas veces, como en este caso, puede funcionar.

Tras enumerar el sistema desde ese usuario, me encontré con que existía una vulnerabilidad del kernel que nos permitía escalar privilegios con un simple binario (link) obteniendo root del sistema. En la guía oficial, por otra parte, la forma de escalar los privilegios lo realiza aprovechandose de un script, que hace uso de “tar”, que se ejecuta en el crontab con privilegios de root.