Nibbles
Nmap Scanning
$ nmap -A -T4 -p- 10.10.10.75 -Pn
We have 2 ports open: port 22 and port 80.
Enumeration
Using searchsploit, I check to see if there are any vulnerabilities for apache 2.4.18 (don't be too specific with the version number or you might miss some results.)
$ searchsploit apache 2.4
I find an exploit, but it's local (requires us to already have some sort of foothold in the machine). I was looking for a remote exploit.
Let's open up the website the web server is running.
We come across a blank page with the text Hello World! From here, let's view the page source.
Let's navigate into the highlighted directory.
I land on the above page. Further clicking around and viewing page source reveals nothing interesting. At the bottom right of the web-page however, there is a Powered by Nibbleblog text. This hints to me that Nibbleblog might be some sort of CMS (Content Management System). Let me google some more to find out.
I was right. Let's use searchsploit to find any existing vulnerabilities for Nibbleblog.
Initial Foothold
With Metasploit
The 2nd one looks more promising to us due to the higher potential of getting RCE. Since it's a ruby file (.rb), we can find it in Metasploit. Let's load up metasploit and find more info regarding it. Let's also note we don't know the version of Nibbleblog we have running.
The exploit can only work if we have credentials. So we need to enumerate further and find out if the website has a login page, or something similar. I am going to run dirbuster to look for hidden files and directories.
Already we start getting results.
The admin.php file looks interesting. Let's navigate to that.
Nibbleblog does not have default credentials. So we can try brute-forcing the login page with a list of common usernames and passwords. To save time, the credentials are admin:nibbles (I cheated). Let's enter them.
Go ahead and click around to just get a feel of the application and what we can do on it. We are also trying to find the version of nibbleblog we are on. When we click on Settings and scroll all the way to the bottom, we find our version information.
Therefore the exploit we found earlier can work. Make sure to set all the options required then run it.
The reason this exploit is working is because if we click on the Plugins tab on the left-hand side and select Configure under My Image, we can upload a php file masquerading as an image file.
There is no form of blacklisting or whitelisting taking place.
Back to our meterpreter shell. We are not root, so we might have to perform some form of privesc.
Let's retrieve the user flag.
Before we search for any privesc methods, go ahead and type:
$ history
or
$ cat .bash_histroy
This can show us prevous commands a user of the system typed in (including passwords).
However, they yield nothing.
Without Metasploit
In our dirbuster results, there was also a README page. When we navigate to it, we find that we are on version 4.0.3.
We can now google for existing vulnerabilities against this version of nibbleblog. We find a promising shell upload vulnerability.
Several important pieces of information are mentioned in the page.
It’s a code execution vulnerability.
The vulnerability is in the “My image” plugin that allows the upload of PHP files. So it would allow us to upload a PHP reverse shell.
It’s an authenticated vulnerability which means that we need admin credentials before we exploit this vulnerability.
Alright, so the next steps would be:
Navigate to the admin login page and figure out the admin credentials
Navigate to the My Image plugin page and upload a PHP reverse shell
As mentioned in the Proof of Concept, the admin page can be found here.
Now we need admin credentials. When I’m presented with an enter credentials page, the first thing I try is common credentials (admin/admin, admin/nibbles, nibbles/nibbles, nibbles/admin). If that doesn’t work out, I look for default credentials online that are specific to the technology. Last, I use a password cracker if all else fails.
In this case, the common credentials admin/nibbles worked! Step #1 is complete!
Next, we need to navigate to the My Image plugin. Click on Plugins > My image > Configure.
Head over to pentestmonkey and get the code for a PHP reverse shell. Change the IP address and port used by your attack machine. Then save it in a file called image.php and upload it on the site.
Start a listener on the specified port.
$ nc -nvlp 1234
In the browser, navigate to the image we just uploaded to run the reverse shell script.
Success! We get back a shell.
Let’s first upgrade to a better shell. Python is not installed but python 3 is.
$ python3 -c 'import pty; pty.spawn("/bin/bash")'
This gives us a partially interactive bash shell. To get a fully interactive shell, background the session (CTRL+ Z) and run the following in your terminal which tells your terminal to pass keyboard shortcuts to the shell.
stty raw -echo
Once that is done, run the command “fg” to bring netcat back to the foreground.
Grab the user flag.
Privilege Escalation
Let's go ahead and check which commands the user nibbler can run as root.
So we can run /home/nibbler/personal/stuff/monitor.sh as root. However, when we open up the nibbler directory, there is no /personal folder. Only a /personal.zip file.
Rather than unzipping it, I will create the necessary folders and file.
The bash -i command is for us to run an interactive shell when we execute the file (make sure to make it executable as shown in the screenshot above). Now let's run the file as root using the sudo command.
And success! We are now root. Let's go ahead and retrieve the root flag.
Lessons Learnt
To gain an initial foothold on the target machine we had to perform two things: (1) guess the credentials of the administrator, and (2) exploit a vulnerability in the installed Nibbleblog version. The application was using weak authentication credentials, and so we were able to guess the admistrator credentials. The application was also using the vulnerable “My image” plugin which allowed us to run a reverse shell back to our attack machine. This shows the importance of enforcing the use of strong authentication credentials and patching your software. In this case, I’m not sure if a patch was even made available. The application also reached its end of life, so the recommendation would be to use other software to host your blog, or at the very least remove the “My image” plugin so that an attacker cannot exploit this specific vulnerability.
To escalate to root privileges, I used a security configuration that was clearly no longer needed by the user since the script is no longer there. This allowed me to run arbitrary commands with root privileges. The system admin should have conformed to the principle of least privilege and not given a regular user the ability to run a script with root privileges.
Last updated
Was this helpful?