Immersion – OFFICIAL Write-Up (English)

Immersion – OFFICIAL Write-Up (English)

Today we are going to solve my second vulnerable machine created, this machine is called Immersion, in it, thanks to the recognition we can identify a possible LFI and, with it, get the password of a user of the system, where once inside we must abuse the sudoers repeatedly until we reach the root user.

Ip of the machine in my case: 10.10.1.64

I am going to skip the previous configuration, if you download the machine and use it locally, it is recommended that you see how to configure it in VirtualBox as I showed in the Write-up of the ColdBox: Easy.

This Write-Up was written in English for TryHackMe. 

Recognition

The first thing, as always, is to launch a furious, this time I will launch “rec0ldd” is a utility that I created (I put “rec0ldd” for recognition and coldd, I know a great name, no doubt), where basically this utility receives a parameter (the ip of the machine to solve), once obtained this parameter, it will run furious and will scan the 65535 ports, it will show it to us on the screen, it will throw a file called “furiousScan” where it shows us the default output of furious and not the customized one that I add to the utility and, finally, with xclip, it will copy automatically the open ports separated by commas to the clipboard, so that we can execute with them a nmap later or another deeper recognition without need to copy them of manual form, soon I will upload the code by github so that you can use it, in the meantime:

escaneo con rec0ldd

Result of recoldd execution against immersion machine

Also, to show the functionality of the utility a little more, this would be the file it returns (the default output of furious):

resultado de furious

Contents of the “furiousScan” file generated by the rec0ldd utility.

Well, to what we are going, the machine has two open ports, the 80 (HTTP) and 3042 (Unknown), already with these ports in the clipboard, let’s run a deeper scan with nmap, for this:

nmap -sC -sV -T3 -p80,3042 <ip> -oN <output_name>

escaneo de nmap

Scan result with nmap

We can see that, indeed on port 80 runs an HTTP service, in this case an apache and, that port 3042 runs an SSH, at this point, we are going to check the HTTP service:

pagina de inicio

Web server home page.

At first glance it is just a page with a link to my Twitter, in the source code there is not much information either, just more code that customizes the main page:

codigo fuente pagina de inicio

Home page source code

At this point, what can be done, let’s fuzz with gobuster to identify resources that may be hidden, for this:

gobuster dir -u http://<ip>/ -w <wordlist>

clear ya funciona

Result of fuzzing with gobuster

As we can see, we have detected several directories, the css and js directories are a bit irrelevant in this case, since we will focus our attention on the “login”, “secure” and “wp” directories, we will review them one by one, starting with wp:

contenido de wp

Contents of “/wp”

contenido de secure

Contents of “/secure”

So far so normal, they are two normal pages, one of them that hopefully will get to be a WordPress someday and another that is the default page of apache only with some modifications in the titles, the really interesting thing here is the following directory:

pagina de login

Contents of “/login”

As we can see, it is a simple login form, we can not register or anything, we must simply put some credentials, but, if we look at the source code we will see the following:

cometario codigo fuente

Login page source code

We see that the form sends the information to account.php, this is always interesting because we can intuit that being a php, it is executing actions of which we can take advantage, nested to this, there is a comment that “c0ldd” left to “Carls” and gives us clues on how to get his credentials

I explain it, I left this comment with the intention that the user that was solving the machine could intuit that vulnerability should take advantage, in the comment it is indicated to “carls” that it must find its password reading the file carls.txt located in /var, in addition that it is mentioned that it must “detect a security flaw in the web” therefore, which web vulnerability allows mainly to read files of the system, that is, a Local File Inclusion, but for this we need to indicate through a variable, the name of the file in question, this variable is usually “filename”, “page”, among others, so in the comment it is said “i left clues on the “page””, alluding to this variable, but where could this be tested? well, in the same code you can see that the data is sent to account.php, so, either by filling and sending data through the form or accessing that resource directly, the user should get there and with all the information previously given and thinking a little, he should test a LFI through the account.php file.

So, based on this, let’s go into account.php and there we change the variable in the url to “page” and, for example, look for the resource indicated in the comment, “/var/carls.txt”:

resultado de prueba de lfi

LFI Result

When doing it, we see that we manage to read this file, you will see equally that I went to the father directory many times, that happens because if we try directly “?page=/var/carls. txt”, it will not show us anything, this because maybe in the file there is a small and minimal sanitization of the data and it is only looking for the requested information in the directory that was indicated in the code, but equally, pulling up in the structure of directories we manage to arrive at the root (/) and once there, to request the resource that we wanted, in this case, the file “carls.txt”.

Now, we see that we have some credentials, the username “carls” and a password encoded in base64, to decode it is very simple, it can be with an online tool or from the operating system itself having base64 installed with the command:

echo “Y2FybG9z” | base64 -d

However you do it, you will see that it gives us what seems to be the password of the user carls, in fact, to check if the user “carls” exists in the system and so we can try to log into it, we can consult the file /etc/passwd in the same way that we consult the file “carls.txt” thanks to the LFI:

fichero passwd

Result of file /etc/passwd

Effectively “carls” is a system user, so now we have his credentials and we are ready to log in, for this we must remember that we had an SSH running on port 3042, so to log in just run:

Explotation

ssh [email protected] -p3042

Remember that the -p is used when the port where the SSH runs is not the default (22), once we put the password, we will see that we access without problem to the system:

primer acceso al sistema

First access to the system as user “carls”.

At this point, let’s try to read the user flag, which is not in /home/carls, so we can guess that it is in /home/c0ldd (the one that left the note), but we do not have permissions to access its directory:

directorio de c0ldd

You do not have the permissions to access the home directory of the user c0ldd

Now, we intuit that we must escalate privileges, either to c0ldd or failing that to root, right now I want you to remember the comment we saw on the web server, specifically the last part:

“log in and finish your work by preparing my bash”.

There the user c0ldd gives one more clue, “preparing my bash” can we use the bash to escalate privileges, at this point we can try to search for resources by SUID permission let’s do the most basic of privilege escalation in Linux systems, do a sudo -l to see what we assigned in the sudoers that we can run as another user:

sudoers del usuario carls

Result of the “sudo -l” command

Privilege escalation

This is curious and that is why I wanted to configure it like this, normally in this type of machines it is usually set that the user with which we are trying to escalate privileges, can run a system resource as root through the abuse of sudoers, in this case it is not so, but we can run the bash binary but as the user c0ldd, therefore when we run it we will get a shell like this, we must always keep in mind that the “sudo” command is not always used to obtain privileges, in fact it is a command to execute commands as other users, but its frequent use to execute commands with elevated permissions can confuse its purpose, then, based on this, in order to carry out this escalation of privileges, we must execute the following command:

sudo -u c0ldd /bin/bash

acceso como c0ldd

Privilege escalation to user c0ldd

Now, as the user c0ldd, we can read the flag that is in its home directory:

lectura user txt

Reading user.txt

Now, if we list what is inside the directory, we will see that there is a Python script that belongs to the root user that literally tells us not to run it:

directorio home de c0ldd

Reading the script in Python

It is something obvious that we should not run it, the script is simple, an infinite loop that will print us by pantal “I told you”, although of course, that is not there by chance, remember that at this point we must again escalate privileges, but this time to the root user, therefore, let’s try the most basic of privilege escalation in Linux again, a “sudo -l”, when doing so we will see the following:

sudoers de c0ldd

Resources that can run the user “c0ldd” on the system as root

We can see that we are allowed in the system to run as root and without password the python3 binary and in turn the Python script that we saw, although if we run it as is, what we will achieve is to run the infinite loop as root (nothing useful), therefore, we will do something curious, if you look at the permissions, we can not write to the file, but we can delete it, so the idea is as follows, we delete the file “DoNotRun. py”, we create another one called “DoNotRun.py”, inside this one we will introduce code in python3 that will return us a shell and, finally, we will execute as root this script so that the code of the shell is executed with elevated permissions and we obtain a shell as root, then, we delete, we create a new one and inside the new one we add the shell:

escalacion de privilegios con python

Privilege escalation procedure

rm DoNotRun.py

echo ‘import pty; pty.spawn(“/bin/bash”)’ >DoNotRun.py

Once all this is done, all that remains is to execute this script with sudo:

sudo /usr/bin/python3 /home/c0ldd/DoNotRun.py

acceso como root

Shell as root obtained

And we are root, it is important that you execute it as I put it, it does not serve to execute it indicating a relative route to the script in Python, since if you do it will not take it as what is indicated in the sudoers and it will ask for the password of the user “c0ldd” to be able to execute (password that we do not have).

Now it only remains to read the flag root.txt

lectura de root txt

Reading root.txt

 

And we would have completed the machine.

This was only one of the ways to solve this machine, I left some more in both intrusion and privilege escalation that you can look for to solve it in a different way.

As usual, I will not give my opinion about the difficulty of the machine, I prefer to see the Wrute-ups that you will do and see how you rate it, you can send them to me by twitter, without further ado, thank you very much and I hope you can learn something new.

Sobre el Autor

C0ldd

Founder of Coldd Security

2 Comentarios

  1. Avatar

    I loved this Vulnhub machine, your blog is interesting, it helps me improve my Spanish and to touch more Penteting concepts, thank you very much 🙂

    Responder
    • C0ldd

      We are here to help, thanks 🙂

      Responder

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Información adicional sobre protección de datos:
Responsable: Martin Frias.
Finalidad: Moderar los comentarios de este sitio web.
Cesión: NO se cederán a nadie, salvo obligación legal.
Derechos: Acceso, rectificación, cancelación y borrado de tus datos.
Legitimación: Tu consentido expreso.

Sponsor By

Coldd Security

REDES SOCIALES

Newsletter

Estadísticas

  • 55.938
  • 43

TheHackerSnow

0

Share This