Vulnhub Pluck Walkthrough

Life has been crazy as of late and I haven’t had as much time to sit and play around with vulnhub boxes like I would like. With Easter weekend just passing I finally got a chance to sit down and play with some new boxes. Here’s my walkthrough for the Pluck box.

1. Fire up Sparta and run the usual scans against the target. There are a few open ports, but as always I focus in on the web application which Nikto informs me has an LFI vuln.

2. I navigate to and confirm the LFI vulnerability. I also make my way to the admin.php page to see if there may be a SQLi vulnerability, and after sticking a single quote in the email field it looks like we might be in business.

3. I run SQLMap against the target and the parameter I believe to be vulnerable, but frustratingly SQLMap states there are no vulnerable parameters…

4. Looking at the /etc/passwd file in the LFI, I notice a backup user who’s got a comment stating that the users purpose is to backup the server and shows me where the backup script is.

5. Browsing to the /usr/local/scripts/ file gives me some great information about how the backups occur, where they’re stored and how they’re transferred.

6. Taking a shot in the dark I try to log in via TFTP and retrieve the tar file to see what I can work with.

7. Once I retrieved the folder and looked through it’s contents, I see that the Paul user has several keys within his /home folder. I try to use them to connect via SSH and managed to find some luck with id_key4

** Side Note: ** After browsing through the code on the admin.php page, I see that the reason it appeared to show a SQLi vuln is because it was programmed to be a red herring…sneaky.

8. I successfully log in and am prompted with a Pdmenu screen (which will forever be the most annoying way to interact with a computer). In any event I use the “Edit File” functionality to create a php reverse shell (link) and save it in Paul’s home directory. I then use the previous LFI command to access the file and initiate a reverse shell by navigating to

9. Once I have my callback shell, I perform a wget to get an enumeration script from my web server to see where the possibility exists for privesc.

10. There are no obvious routes for privilege escalation via cron or other services running with unnecessary privileges. I see that the bob user is running under a number of groups and also see that he has a .sudo_as_admin_successful file in his /home directory that leads me to believe he has sudoer privileges. I try to see if there are any ways I can use his privileges but find nothing.

11. I turn my attention to the Kernel and Server version. I see that the server is running Ubuntu 16.10, which looks to be vulnerable to the infamous Dirty Cow vulnerability. I download, compile and run the script and have successful rooted the box.

** Note  that I had several errors when compiling the code. This appears to be normal. In addition, this exploit made the box extremely unstable and it crashed on me several times before I could confirm that it had worked.

12. Last step was to capture the flag.