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.
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:
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):
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>
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:
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:
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>
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:
Contents of “/wp”
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:
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:
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”:
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:
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:
ssh firstname.lastname@example.org -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:
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:
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:
Result of the “sudo -l” command
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
Privilege escalation to user c0ldd
Now, as the user c0ldd, we can read the flag that is in its home directory:
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:
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:
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:
Privilege escalation procedure
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
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
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.