Dina 1.0.1 Walkthrough (VulnHub) by gr0mb1e
Dina 1.0.1 Walkthrough
Original Author : gr0mb1e (https://gr0mb1e.wordpress.com/author/gr0mb1e/ )
A couple weeks back, dear ol’ VulnHub delivered unto us a buh-hut load of VMs after a bit of a dry spell. As someone who’s still cutting their teeth with pen testing, I was pretty anxious to fire up a bulk of those and get to work. Like many others, I’ve begun to document my steps for my own sake of retaining what I learn — and fail at — and also in preparation for when I eventually attempt the OSCP. I hope what I learn helps someone else learn along the way.
One of the first machines I chose was Dina, created by Touhid Shaikh and targeted towards beginners. This is his first boot2root entry and my first write-up; an appropriate pairing, I think. So, without further ado…
A little brief on the machine itself:
Target IP: 10.0.2.121
Attacking IP: 10.0.2.115
First thing’s first: I’ve gotta see what’s under the hood..
nmap -T4 -A -v 10.0.2.121
nmap’s output is pretty weak, revealing only a web server running on port 80 and some directories in robots.txt I’ll want to check out.
PORT STATE SERVICE VERSION
80/tcp open http Apache httpd 2.2.22 ((Ubuntu))
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
| http-robots.txt: 5 disallowed entries
|_/ange1 /angel1 /nothing /tmp /uploads
|_http-server-header: Apache/2.2.22 (Ubuntu)
|_http-title: Dina
Poking around the main page and its source reveals nothing of real interest.
Time to see what’s up with those directories in robots.txt. Of course, the only one with something in it will be /nothing.
Checking the page source, I’m conveniently given a list of possible passwords in the form of a comment.
I throw these into a list (passes.txt) and keep on truckin’. A quick run of dirb with its default list pretty quickly finds a new directory, /secure. Yeah, we’ll…we see about that. ?
It’s home to a backup file of some sort, it seems. After downloading the zip, I discover it’s password protected. Time for a closer look.
root@box:~/boot2roots/Dina# strings backup.zip backup-cred.mp3 ‘Kn@M+Y K]*/ backup-cred.mp3
Music to my ears? Could be interesting. Now to get it.
Using zip2john, I extract the password hash from the zip and then ask john to help crack it using the list of passwords given to me before.
zip2john backup.zip > brown.hash john brown.hash –wordlist passes.txt
Ah. Sweet, sweet freedom. Now to see what’s up with that mp3…
root@box:~/boot2roots/Dina# 7z e backup.zip
Wait a sec, that’s no mp3…
root@box:~/boot2roots/Dina# file backup-cred.mp3 backup-cred.mp3: ASCII text
Let me pull some more strings to see what I can find.
root@box:~/boot2roots/Dina# strings backup-cred.mp3
I am not toooo smart in computer …….dat the resoan i always choose easy password…with creds backup file….
uname: touhid
password: ******
url : /SecreTSMSgatwayLogin
Welp. We all start somewhere, right? So I’ve got a username, an idea of where to find the password and a new directory to peep.
Visiting /SecreTSMSgatwayLogin lands me a login page for playSMS.
It’s around this time I began dickin’ around the search engines, trying to find out whatever I could about playSMS and any vulnerabilities it may have. I happened across a few exploits on ExploitDB authored by none other than our main man himself, Touhid! The gift that keeps on giving, I tell ya. These are all RCE exploits and require user access, which brings me…
♫One step forward and two steps back♫
Going down the list of passwords from before I log in as touhid, using diana as the password.
Now to leverage one of those exploits. I chose the exploit I found most interesting, which takes advantage of a vulnerability in the Phonebook’s import function. The gist of it is that an attacker can drop a payload in a CSV file with a given format and then execute code by modifying the user agent string during upload.
I doctor up a CSV using LibreOffice with the appropriate fields and payload, per the exploit instructions and prepare to import it into Phonebook.
Next, with the help of Burp, I intercept the request and modify the user agent to execute whatever commands I feed to it. To make sure this is actually the case, I run “cat /etc/passwd” and check the output before attempting to get a reverse shell.
Good enough for me. Let me go ahead and open up my listener…
root@box:~/boot2roots/Dina# nc -lvp 8008 listening on [any] 8008 …
Now to drop that load. I repeat the steps above, only this time modifying the user agent to spawn a reverse shell via php.
A brief pump of the arm and some chanced enumeration later, I discover that the current user (www-data) can run perl as sudo.
I’ve already been given the location of the flag in the VM’s description, so I can go ahead and sudo chop that sucker:
sudo perl ‘exec “cat /root/flag.txt”;’
Now I’ve got the angel by its wings!
And there you have it. Overall, I had fun with this machine and feel that it’s a good first entry from Touhid that combines a decent variety of techniques for those starting out to have their goat. I would’ve liked to have had a bit more of a challenge when getting the initial foothold, but that ain’t no thang. Looking forward to seeing what’s next! Feel free to hit me up with any questions, suggestions or comments.
Chapeau à toi frère
Du courage
$ sudo perl ‘exec “cat /root/flag.txt”;’
Can’t open perl script “‘exec”: No such file or directory
/bin/sh: 10: ’: not found
same as
$ /usr/bin/perl ‘exec “cat /root/flag.txt”;’
Can’t open perl script “‘exec”: No such file or directory
/bin/sh: 9: ’: not found
Please help
try this mate…
sudo perl -e 'exec("cat /root/flag.txt")'