privilege escalation Archives

boot2root, hacking, web application security

@Vulnhub – Solving #Cofveve

July 7, 2023July 14, 2023 thefluffy007

Another day, another challenge.

In this post we’re going to solve the Cofveve virtual machine.

Let’s get started

After downloading the virtual machine and starting it we see the following:

Using the netdiscover command we can find the IP that the virtual machine is using

Going back to our attacking machine (I’m using the parrot virtual machine).

Doing an nmap scan with the command – nmap -sV <IP address from netdiscover command>, we see the following

There are three ports that are open – ssh, and two http ports.

When http ports are opened the next step is to try to do a recursive brute force attacks to find hidden directories.

We’re going to use two programs – dirb and gobuster.

Doing the dirb of port 80, we get:

Using gobuster we see:

We see that both of the programs did not return anything.

Let’s try to the following programs with the 31337 port, let’s start

We see five files – a robots.txt, and four hidden files (start with .)

The robots.txt gives information about sites that should not be crawled by the internet. This is useful as it will give us files or directories (folders) to review to get more information.

Going to the robots.txt we see:

Hmm, there are three directories that are disallowed. Let’s try to go to them.

Let’s start with taxes. When navigating there we see:

We found the first flag!

Going to the second directory .bashrc we see

Hmm, it’s a file, let’s save it.

Going to the last directory of .profile we see

Another file to save.

Going back to either dirb or gobuster results we have one more directory, .ssh.

This is strange. The .ssh which is hidden should not be exposed on the internet. This folder has information about how to login into the system. Such information is a private key (which only the user should know) public key (which everyone knows), as well as other things.

Going to this folder we see:

We see three items, which look like additional files.

Let’s see if we can navigate to these files.

Navigating to the first item, id_rsa we see:

Another file, so let’s save it.

Let’s try the second file – authorized_keys. Going there we see:

Another file, let’s save it.

Finally, let’s go to the third item – id_rsa.pub

Now that we saved everything let’s go back to our virtual machine and open the files.

First, let’s open the id_rsa.pub file. This file is the public key that is part of a pair. The other pair is the private key. As the name suggests only the user should know their private key and not expose it to anyone else. The public key can be exposed to everyone.

Opening the file we see:

We see a ssh-rsa. RSA is a cryptographic algorithm. Looking at the end of the file we see a valid user – simon@covfefe. We need to save this user as we will need it later.

Opening the id_rsa file we see:

This file is the private key to log into the SSH server as Simon! This is bad, as I said before this file should NOT be exposed as Simon private key should only be known by him only.

Opening the authorized_keys file it has the same content as the id_pub

How can we use this information?

We know a user (simon@covfefe) and a private key.

Well we can log into the ssh server.

Let’s start.

We can use the command ssh -i id_rsa simon@covfefe

Let’s break this down.

We’re logging into the SSH server, specifying a file id_rsa (Simon’s private key) and the user of Simon

We get the following output:

Uh oh – we received an error:

The private key is too open. We need to change the make it less accessible. To do this we’re going to change the permissions from 644 to 600. What this will do is give access to the owner in this case parrot (which is us).

To do this we will use the command chmod 600 id_rsa

Trying to log in again we have the following:

We need a passphrase… which we don’t have. How do we get this?

Doing a good ol’ Google search of cracking passphrase for id_rsa we see the following link

We see there’s a command ssh2john which can be used to crack the passphrase. Let’s do it!

First, we located where the ssh2john command lives in the file system. Next, we’re going to create a hash using ssh2john. We’re going to use this for the next step.

Next, we’re going to send our hash to john which will be used to crack it. We’re going to use the wordlist rockyou.txt which is a common wordlist used to crack passwords. Doing so, we found our passphrase – starwars.

Running our SSH command again, we enter the passphrase of starwars and we’re in the system!

Doing a long listing and showing all of the files (ls -la) we see the files we found before when brute forcing the directories. Let’s look at the .bash_history. This file is good to review as it will let you know commands that were executed on the machine.

Opening this file we see a read_message and then exit. What is read_message? Is this a program?

Executing the read_message we get a prompt. Let’s enter the name Simon. We received a message stating this is is a private messaging system and the source code is in the root directory.

Navigating to the root directory and doing a long listing with all the files (ls -la) we see there’s a read_message.c file, and flag.txt!

Opening the flag.txt file we see a permission denied :-(. Looking at the long listing again this file (flag.txt) can only be accessed the owner, which in this case is root (column 4). I am the user Simon, so I can’t view the file.

Opening the read_message.c file, we see source code, and… the second flag!

And it’s giving us a hint – we need to review the source code.

Looking at the source code we have a buffer (buf) that is holding 20 characters and is executing another file program which is pointing to /usr/local/sbin/message. Whenever we see buf we need to think of buffer overflows.

Buffer overflows are a vulnerability where you overflow the input to access other parts of the computer system. In this case, since we have a holding space of 20 characters – we’re going to overload the buffer with characters OVER 20 characters. Also we’re going to try to change the shell to /bin/sh <— bourne shell. We’re going to change the shell to escalate the user. Changing from Simon to root. We need to be root to open the flag.txt file.

Let’s try it.

Running the commands id and whoami we see we’re root!

Now let’s open the flag.txt and see what’s in the file.

We solved the challenge!

boot2root, hacking, web application security

@Vulnhub – Solving Hemisphere – Gemini #boot2root

June 30, 2023June 30, 2023 thefluffy007

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

boot2root, hacking, web application security

@TryHackMe – Basic Pentesting Room

June 23, 2023April 9, 2023 thefluffy007

Another day, another challenge.

Today’s blog post – I will give a walk-through on a boot-to-root room called, “Basic Pentesting Room”. This boot to root is perfect to get practice in preparation for the OSCP.

Let’s get started.

Logging into TryHackMe with your credentials and heading into the room we see the following:

OK, we have tasks to complete and we will learn the following skills – brute forcing, hash cracking, service enumeration, and Linux enumeration.

The first question is:

Clicking the deploy button at the top we get the following:

Second question is:

OK, we need to find the services exposed. What can we do?

One solution is to use nmap -sV (TCP scan) <IP address>

In this case it would be nmap -sV 10.0.0.204. Doing this we see the following screenshot:

Success! We now have the services.

Let’s use dirb to find the hidden directories. See the following screenshot:

Our hidden directory is development.

Reviewing our enumeration we see that ports 139 and 445 are open. These ports are used for SMB (Server Message Blocks) which are HIGHLY vulnerable. Let’s run the command enum4linux and see what we find.

We found two users: kay and jan

Question #5!

First, entering kay, I received an error. Let’s try entering jan. Success!

Let’s fire up Hydra which is password cracking tool with the password list of rockyou (this password list is used a lot in Kali and even in the OSCP… hint, hint!)

The service we use to access the server is SSH.

kay

Since we have a new user (kay) and we have a ssh folder that lists the public key we can try to get the password.

From question #10 we have the user (kay) and a public key how can we go about cracking the key?

Doing a quick Google search, I was presented with the following link.

Scrolling down we see the following:

Let’s see if we can recreate this to find the passphrase. Using the ssh2john we created the hash.

Next we’ll use John The Ripper with the famous rockyou wordlist to see if we can crack the passphrase.We were successful! The passphrase is beeswax. Let’s try to ssh with kay’s private key and see if we can get in.

Entering the passphrase we see that we were able to successfully log into the kay account! Just to be sure I issued the command of whoami (don’t mind the fat fingering!)

Next, we run the list command to see what we’re working with. We see a pass.bak file, let’s see if this lists the password. Opening the file we see the password. Score!

Let’s run sudo -l, which will show us what commands kay can run as root. We’re prompted with the password and we entered the password that we just acquired. We’re presented with all of the commands that kay can run, and we see that kay can execute all commands as root. Great, this will be helpful for us.

There’s another file that is important in the directory – bash_history. Bash_history is useful because it shows all the commands the user executed before logging off. Let’s open the file.

After opening the file we see a lot of commands. There is one that is very useful – sudo su. If working correctly, running this command we will change from the kay user to root. In other words we would do privilege escalation – where we start as a non-admin user and through improper configuration change to a root user. Let’s try the command and see if it works.

Running the sudo su command, and typing whoami, we see that we’re now root! We do another directory listing which shows the files from before, so no change. Let’s see if we can get into the root directory.

Changing to the root directory we see that there is a flag.txt file. Opening this file we presented with the verbiage above. We solved the challenge!

boot2root, hacking, OSCP, web application security

OSCP Series: Kioptrix Level 3

March 10, 2019March 3, 2021 thefluffy007

Another day, another challenge.

In today’s blog post we’re going to solve level 3 of the Kioptrix series.

For the level 2 walk through, click HERE.

Let’s begin.

Starting the VM, we’re presented with the following login screen.

Kioptrix_Level3_Login

Going back to the login screen the disclaimer states that we need to modify the /etc/hosts to include our IP address that our kioptrix3 vm is running.

Kioptrix_Level3_cat_etc_hosts

Let’s see which services are running on the virtual machine Kioptrix_Level3_nmap

Hmm… we have two services open – ssh and http. Let’s go to the web application and do a manual crawl of the site.

Navigating to kioptrix3.com we see the following:

Kioptrix_Level3_webpage1

Clicking the Login button we’re presented with a login screen. At the bottom we notice the page is using LotusCMS. Let’s keep this in mind, just in case we it to exploit the application. Kioptrix_Level3_webpage2_login

Let’s run nikto to see if we can find more vulnerabilities in the web application.

Kioptrix_Level3_nikto

Kioptrix_Level3_nikto2

We see that the application found a phpmyadmin folder. Let’s go to the folder and see what we can find.

Kioptrix_Level3_webpage2_phpMyAdmin

Going to the php page, we realize we don’t have login credentials, so at this point we can’t log into the phpmyadmin page. We know the application is using LotusCMS let’s see if there’s a LotusCMS module that we can use in Metasploit.

Kioptrix_Level3_msfconsole

Kioptrix_Level3_msfconsole2

After opening and searching Metasploit for LotusCMS we see there’s a perfect remote code execution we can use.

Kioptrix_Level3_msfconsole_lotus_exploit

After selecting the exploit let’s review the options to see what we need to add to the module to make the exploit work. We need a remote host (RHOST), remote port (RPORT) and the URI. Let’s add the information below.

Kioptrix_Level3_msfconsole_lotus_meterpreter

After entering the information, and typing run, we notice that we’re presented with a meterpreter shell! Let’s go to the home directory and see how many users are on the box.

Kioptrix_Level3_msfconsole_lotus_meterpreter_2

We have three users, dreg, loneferret, and www (web). Let’s see what’s in the dreg folder.

Kioptrix_Level3_msfconsole_lotus_meterpreter_dreg

Searching the dreg folder we don’t see much. We see a bash_logout, bashrc, and profile scripts. Let’s move on to loneferret.

Kioptrix_Level3_msfconsole_lotus_meterpreter_loneferret

Hmm… Loneferret has a lot of information. We see there’s a file titled, “.sudo_as_admin_successful”, a company police readme, and a checksec script. Let’s review the company policy readme.

Kioptrix_Level3_msfconsole_lotus_meterpreter_loneferret_company_readme

Well… it seem if we want to edit, create, or view files we need to use the command sudo ht. Let’s keep this in our toolbox because I am sure we will use it later. Remember we found a phpmyadmin page, let’s see if we can find a config file with login credentials.

kioptrix_config_file

Doing a search on the kioptrix3 folder, we see there are three config files. Let’s review the last file, gconfig.php.

Kioptrix_Level3_msfconsole_lotus_meterpreter_loneferret_gconfig

Opening the gconfig.php file we notice there are login credentials for the phpmyadmin page! Let’s keep this in our toolbox because we might have to use it later.

At this point, we have php login credentials, but that’s not enough to gain root privileges. Let’s see if we can review the web application again for more clues.

We notice there’s a gallery section of the application. Maybe we can be lucky and the application is susceptible to sql injection.

Kioptrix_Level3_gallery

Adding an apostrophe to the end of the number there’s no change in the application. We notice at the bottom of the page there’s a sorting option. Let’s see if changing the sorting option will invoke a SQL injection. Kioptrix_Level3_gallery_photo_id_before_sql_injection_2

Changing the sorting option to Photo Id, and adding the apostrophe to the end of the number, we get the following… Kioptrix_Level3_gallery_photo_id_sql_injection_2

Success! The application is susceptible to SQL injection. Let’s fire up sqlmap and see what goodies we can find.

Kioptrix_Level3_sqlmap

Kioptrix_Level3_sqlmap2

Executing a preliminary SQLMap run we see that SQLMap verified our manual testing results that the application is susceptible to SQL injection. SQLMap also found the technologies the application is using. Let’s do a more extensive probe. Firing SQLMap again we use the dump all to see what data we can find.

Kioptrix_Level3_sqlmap3

Kioptrix_Level3_sqlmap4

We found the dev accounts database, and notice that we have two users dreg, and loneferret, along with their passwords. Remember these are the same users we found when we used Metasploit with the LotusCMS remote code execution.

Now that we have login credentials, and we know that loneferret has more promising information than dreg, let’s connect to loneferret’s account through ssh.

Kioptrix_Level3_ssh

Connecting to loneferret’s account, we try to access the root folder, but receive a permission denied (we’re not root… yet). We also try to execute the sudo ht command that was listed in the company readme file, and we get the error, “error opening terminal: xterm-256color”.

Doing a quick google search we find that we need to use the following command “export TERM=xterm”. Doing this and running the sudo ht command again we’re presented with the following screenshot. Let’s see if we can view and modify the /etc/sudoers file and see if we can escalate our privileges from loneferret to root.

Kioptrix_Level3_ht1

Kioptrix_Level3_ht_adding_sh

Opening the /etc/sudoers file we notice that the loneferret has a user privilege escalation where a password is not required. Right now it’s for the commands: su, and sh. Let’s add our ht command to the list. After adding the command, saving, and exiting we’re presented back to the command prompt.

Kioptrix_Level3_root

Executing the command sudo /bin/sh, and running a whoami we see that we’ve been escalated to root! Running the ls command we see that we’re presented with the same information we had in our meterpreter shell. Changing our directory to /root we notice there’s a Congrats.txt file. Kioptrix_Level3_root2 Kioptrix_Level3_root3

Opening the Congrats.txt file we have found the flag and completed the challenge!

boot2root, hacking, OSCP, web application security

OSCP Series: Kioptrix Level 2

February 13, 2019March 3, 2021 thefluffy007

Another day, another challenge.

In today’s post we’re going to solve Kioptrix Level 2.

Let’s get started.

After booting the machine, we see the following:

Kioptrix_Level2

This screen is very similar to level 1 click HERE if you missed that.

Let’s begin.

First, let’s enumerate using nmap, with the command nmap -sV <IP_ADDRESS>. In my case it will be nmap -sV 192.168.0.14

Below is the screenshot I have:

Kioptrix_nmap_Level2

We have a number of ports open. Let’s look at port 80 (http) and see what we can find.

Going to http://<IP_ADDRESS> (substitute IP_ADDRESS with your IP address)

We see the following screen:

Kioptrix_webpage_Level2

A login screen… let’s see if we can do an authentication bypass by doing a SQL injection.

Kioptrix_webpage_login_Level2

Entering the username of admin and password of ‘ OR ‘1’=’1′–

Success! We were able to complete an authentication bypass. Now we’re presented with a web console to ping a machine. So let’s ping. Kioptrix_webpage_console_Level2

Entering our IP address and pressing the submit button we see that the web page pings our machine.

Kioptrix_webpage_ping_Level2

Kioptrix_webpage_ping_results_Level2

Let’s see if we can complete one or more commands in succession. This vulnerability is called command injection, as the attacker can enter arbitrary commands to read and write to the server.

Kioptrix_webpage_command_injection_Level2

Kioptrix_webpage_command_injection_results_Level2

We see this application is vulnerable to command injection as we were able to ping our machine and list the contents on the server.

Let’s see if we can use the command injection vulnerability to get a remote shell.

Going to Google and typing in “remote shell commands” the following screenshot is from the first result.

Kioptrix_remote_shell_command_Level2

As you can see this web page lists different ways to gain a remote shell a server. Let’s use the first command, and see this will be successful for us.

First we need to get our IP address.

Entering the command in a terminal ifconfig we will get our IP address, which is what we need for our remote shell.

The below screenshot is mine:

Kioptrix_webpage_ipconfig_Level2

The next two steps need to be completed at the same time.

Going back to the web console, we’re going to enter the above remote shell command, changing our IP address, to the IP address from our ifconfig command. As well as change our port to the port listed in our netcat command (note the port can be anything, I just picked 4444 as it’s easier for me. It could be 1234, 2222, etc.)

Kioptrix_remote_shell_command_webpage_Level2

Now we need to start a listener, the below screenshot is used with netcat

Kioptrix_remote_shell_Level2

After pressing the submit button from the web console, we have the following screenshot – our remote shell worked! we see that we’re connected (192.168.0.14 is the Kioptrix machine and 192.168.0.12 is my machine). You’ll notice that when we list the directory it matches the above screenshot from the command injection inside the web console.

Continuing on let’s see the server version we’re running. See screenshot below. Kioptrix_webpage_uname_Level2

Opening a new terminal, let’s go to searchsploit and see how many exploits we can find for this version. Kioptrix_webpage_searchsploit_1_Level2

There are A LOT of exploits, as I was pretty lax on the search results. Let’s use exploit 9545.c as it lists the version number and it also use CentOS (which we saw during the enumeration phase) exploit.

Let’s copy the exploit to the current directory – see screenshot below.

Kioptrix_copy_exploit_Level2

Since we’re working with a web server, we need to move our exploit to the Apache folder and start Apache. See screenshots below.

Now let’s try to download our exploit. The first time doesn’t work as one we didn’t specify the file, and we get a permission denied – screenshot below.

Kioptrix_download_file_failure_Level2

Let’s try to change the directory to the /tmp folder and see if we can download our exploit. Kioptrix_download_file_success_Level2

We were successful! Our exploit was downloaded.

Let’s compile our exploit, and give it the name of exploit. See screenshot below.

Running the exploit and entering the whoami command we’re now root. W00t! Kioptrix_whoami_root_Level2

Let’s see if we’re truly root – let’s read the /etc/shadow by entering the following command cat /etc/shadow Kioptrix_etc_shadow_Level2

We’re able to view the /etc/shadow file, which means we’re truly root.