Another day, another challenge.
In this post, we’re going to solve the Hemisphere boot2root from Vulnhub.
Let’s get started.
When we start the Hemisphere – Gemini machine we see the following screen:
OK, we’re prompted with a login screen.
For most boot2root’s we need to find user and root.txt on the box.
Next, on our attacker machine (I’m using parrot security), I am going to type the command netdiscover.
Netdiscover will ping your network with active IPs. From there you can figure out which IP is being used for the virtual machine.
After finding the IP address, let’s open a terminal and type nmap -sV <IP address from netdiscover>. In my case, it’s going to be nmap -sV 192.168.1.132. Doing this we have the following output:
We have 5 ports open.
FTP
SSH
HTTP
And ports 139 and 445.
What do the above two ports belong to?
Well these two ports are for Samba SMB. SMB allows computers to talk with each other. Most times when SMB is enabled, it’s SMB 1.0 which is extremely insecure. So how do we exploit it?
Well, there’s an application enum4linux which will enumerate all of the SMB shares. To do this we’ll use the command enum4linux -a <IP address from netdiscover>. In my case it will be enum4linux -a <192.168.1.132>
Doing this we have:
As you can see we have A LOT of output from enumerating the different shares from SMB.
Looking through the input we see there’s a username: William. We need to save this as we’ll use it later.
Now reviewing the nmap scan again – we see that port 80 or HTTP is open.
Next step, is to enumerate/brute force to see if we can find hidden directories.
Let’s use our two favorite applications – dirb and gobuster.
We have an assortment of files/directories to review.
robots.txt – a helpful file that tells web crawlers to exclude directories to be crawled/exposed on the internet.
Going to the robots.txt file we see:
There are three directories. Let’s see if we can find any goodies!
Going to the secret folder we see:
Hmm… there’s nothing there.
Let’s try admin.
Nothing there either.
Let’s try the last folder – lol
Nothing there.
So the robots.txt was a red herring. It’s a way to knock us off our game as there’s nothing there.
Going back to dirb/gobuster we see there are two folders to review.
Let’s try assets and see what we get.
Going to the assets folder we see:
Hmm – nothing really there. It’s styling for our website.
Let’s try the second folder – images.
Going to this folder we see:
Nothing of importance. This directory is a space for all of the pictures for our site.
Speaking of our site. Let’s go to the index.html file
Going to this page, we see:
Looking through the page we don’t see anything of value.
So now – we’ve enumerated all of the hidden folders and really haven’t found anything. We know we have a user of William, but how do we log in?
We need to enumerate/brute force the directories again.
How do we do this? Change our wordlist.
Going back to gobuster – we’re going to use the dirbuster directory-list-2.3-medium.txt which has more directories to check.
Entering the updated command we see there’s a new folder – portal. Let’s go to that page and see what we get.
Entering this into the URL we see:
Another page. It’s written in Spanish. We see there are three links at the top. Let’s click on the second (Sobre Nosotros) and see what we get.
Nothing to render/view.
But there is something interesting. In the address bar we have a view parameter. Which is pointing to the about-us.html page. Whenever we see a parameter field we should try to do a Local File Inclusion (LFI).
LFI is a vulnerability where you can access the files in the underlying filesystem. Let’s try to access the /etc/passwd file.
In Linux, the /etc/passwd file holds all the users. Let’s try it.
Let’s break this down.
We have five ../. What is this? Well we’re using this (../) to navigate one folder up. Meaning we want to access the parent directory of our current directory. Finally, when we’re at the topmost area of the file system. We’re telling the application to go to /etc/passwd.
Doing this the webpage displays the /etc/passwd file which reveals all of the users!
When you look in the file we see that there is a user named William. That let’s us know our enumeration from the enum4linux command worked correctly.
Now we have the user William, and we can do LFI on this application. What’s our next step.
Well we know that port 22 or SSH is open. We also know there’s a public and private key for all the users to log into the server.
We have a user of William. So we know he’s a valid user. How do we find William’s public and private key?
These keys will be in his home folder.
In Linux, every user has a home folder which allows the user to save files that can only be accessed by them.
With the public and private keys for SSH, we know it’s stored in a hidden directory titled – .ssh and saved in the id_rsa file.
id_rsa is the private key file
id_rsa.pub is the public key file
We don’t want to access the public key file as it’s accessible to EVERYONE. Hence the name.
We want the private key (id_rsa).
Let’s see if we can access this folder through LFI.
Success! We’re able to access the private key. We’re going to need this to log into the SSH server.
First we need to save this key.
To do this, right-click on the file and highlight the text, copy the text.
Open your favorite word browser, and save the contents as id_rsa (the name is important!). Also make sure you know where you saved this file!
After saving the file – let’s do a ls (listing) in the terminal
We see our id_rsa file.
Now let’s try to log in the ssh server.
Enter the command ssh -i id_rsa william@<IP address from netdiscover>. In my case the command will be ssh -i id_rsa william@192.168.1.132.
Uh-oh. We can’t log in as the permissions are too permissive or too open.
Press Control-C to get out of the prompt, we’re going to change the permissions of the id_rsa file.
To do this we’re going to enter the command chmod 600 id_rsa.
After entering this command, do a listing (ls) to view the permissions.
For the id_rsa file we see there is rw in the 2nd and 3rd position. These positions belong to the owner. In this case the owner would be parrot (column 4 in the above screenshot).
Now let’s try to log in again.
Success! We’re in the SSH server.
Now let’s do a listing to see what we see
We have the user.txt file. Let’s open it.
Enter the command cat user.txt
We have the user flag. Now to find the root.txt.
How are we going to do this?
Well there’s a few things we can do.
Since this is a Linux system, let’s enter the command sudo -l
This command will see if a user can elevate (or escalate) their privileges without being the root user.
Entering the command we see this program doesn’t exist.
OK, so we can’t use that.
Remember how we had to change the permissions to gain access to the server?
Well I wonder if we can check files that are overly permissive and use one of those files to elevate our privileges.
What command would we use?
The command we enter is find / -perm -u=s -type f 2>/dev/null
Let’s break this down
We’re using the find command
the / specifies we want to start at the top of the file system
-perm u=s specifies we want to find users that have the sticky bit on.
What is the sticky bit? Sticky bit in Linux specifies we can run an application as the owner of the file.
We want to access the root.txt, so we know that the superuser root is probably the only user who can access this file.
-type f = specifies we want files
2>/dev/null specifies that any errors go to the /dev/null file.
Entering this command we see:
Most of these files are always there but we have a file that shouldn’t be there /etc/passwd.
Why shouldn’t this file in this list? Well the /etc/passwd file holds all the users in the operating system.
This file is overly permissive. We see we have read, write, and execute.
So what do we do? Add another root user.
How do we do this?
First we need to create a password. We’re going to use the openssl command to create a suitable password for the /etc/passwd file. I’m going to select a password of password. See the screenshot below.
Next, we’re going to add our new user in the /etc/passwd file. How are we going to do this?
We’re going to use the echo command.
Let’s break this line down.
echo is a command in Linux. We’re going to echo what is in quotation marks.
We’re going to create a user of test
Next, we enter the password we created with openssl
Next, we have the numbers of 0 for userid and groupid. 0 represent root.
Next, we have the name of root
Next, we specify the home folder for root which is /root
Next, we have the shell for this user which is the bourne again shell (/bin/bash)
Finally, we’re appending this input to the /etc/passwd
Pressing Enter we are prompt back to the command line
Using the command su (switch user)
and enter our new user of test and password of password
We see that the login was successful.
Entering the whoami command we see that our user is now root. Which means our privilege escalation worked!
Now that we’re root let’s navigate to the /root folder and do a listing
Cool, we see the root.txt file.
Opening this file we see:
Success! We found the root flag!
*****If you’ve read to the end – I wanted to add that I am now on @buymeacoffee! If you like the above content and want more of it. Please support: https://www.buymeacoffee.com/thefluffy007
You must be logged in to post a comment.