Cengbox 1 – Vulnhub

Lets start by gathering our nmaps. I always do a basic nmap, and then a detailed nmap, based off the ports returned by the basic nmap scan.

As we can see from the nmap scan, we know we are dealing with an Ubuntu Linux system. Ssh is running on port 22 and the web server is on port 80. Since we don’t have any creds to go off of, we will start with the web server.

I started by checking for /robots.txt, /.svn, and /.DS_STORE extensions but found nothing. I then checked the source code and also found nothing. None of the links seem to work. I ran a nikto scan and again found nothing. That eliminates quite a bit. I then ran a feroxbuster scan and found some interesting extensions: vendor, masteradmin, uploads, and a login at /masteradmin/login.php. A quick Wappalyzer check confirms the website is running php so I added all that to my notes.

If we try to navigate to the /uploads we get redirected to a 403 Forbidden page. /vendor turned out to be nothing. If we navigate to the login page, we get:

I tried some basic user:password combos like admin:admin, admin:root, root:root, etc etc but I came up with nothing. I didn’t have any default creds to try so I tried running some basic sql injection on both the username and password fields. I found that if I put “admin” in the username field and put “‘ OR 1=1 — -” in the password field, this would allow me to bypass the authentication and log directly in to the system, and that brings us to an upload page:

I created a test.txt file to try to upload but that failed. I also tried a test.php file, but that failed as well. I then tried a test.ceng file and that succeeded. The error message was a bit hard to read due to the styling of the page itself:

So we know that whatever we upload needs to have the .ceng extension on it. I then created a php-reverse-shell and named it revshell.ceng. I configured it to reach back on port 9090 and setup a pwncat listener to match. That uploaded successfully as well. We know that there is an /uploads directory; I suspect it was uploaded there. In the URL, I navigated to 10.0.3.22/uploads/revshell.ceng and that activated the shell and we got a reverse connection! Great, now we have our initial foothold on the machine.

With that done, I moved over my enumeration script and ran it, but you could manually enumerate all this as well. We are currently the www-data user and do not have sudo privileges. We cannot look in the home directory of the user, who we found to be ‘cengover’ from the /etc/passwd file. That file is not writable, and no other users except root exist. /etc/shadow is not writable and cannot be viewed. The web root was located as /var/www/html, and I always work out of /var/tmp, so that’s where any scripts or binaries I upload will go. There was nothing in the /var/mail’s and no cronjobs were running as www-data. There were no binaries with SUID or GUID bits set that were exploitable, no suspicious mounts, and no NFS shares. My script ran a check for common privesc software and found:

There must be some creds stored else where in the system. I did find that mysql was running on the localhost (127.0.0.1) and tried to connect to it but failed with default creds. I then tried to hydra it but that failed as well. We know that the web login page is vulnerable to sql injection because we used it to bypass the authentication. Maybe we can use sqlmap to help us enumerate the databases stored on the system. I spun up Burpsuite and captured a simple login request of admin:test, and then saved it to a file called request.txt. I then supplied that with the -r flag to sqlmap, with the –dbs flag to enumerate databases. Sqlmap found a time based injection and enumerated the databases to be: information_schema, cengbox, mysql, performance_schema and sys.

Obviously the cengbox database is probably the one we need so I then asked sqlmap to enumerate the tables in that database, which there was only 1, and we get:

Nice, some new creds, which I added to my notes. Back in the reverse shell, I tried to login to mysql using these creds, but that failed. Could it be that the cengover user is using this password as his login password? I tried to ssh in using this cred and success! I should note that I also tried so hydra the ssh login for cengover as soon as I found that user, but that failed.

Now that we are in as the cengover user, I restarted the enumeration. I found a file in the /opt directory called md5check.py that was updating a file that only root could see, so that wasn’t helpful. I checked the permissions of this file and found that md5check.py is owned by root but that the users group is assigned. And cengover is a member of the users group. Further the users group has read and write permissions to this file. Interesting. I then uploaded pspy64 to the system and ran it to check for processes, and I found that there was a root cronjob that was calling md5check every minute.

If root is calling a cronjob, that in turn is calling the md5check.py file, and we as cengover can write to that file, we could implant some malicious code to have that file create a suid bit set copy of /bin/bash in the /var/tmp directory. Since this is being done as the root user, the suid bash file will be created as the root user as well. And, since it has the suid bit set, we as a non root user can run it, using the -p flag, and we should get a bash shell that has the permissions of the owner of /bash, which in this case will be root. Effectively giving us a root shell!

To do that, I edited the md5check.py file with nano and implanted a line to import the os module. Then at the bottom of the code, I implanted another line to create the suid bit set copy of /bin/bash:

os.system(‘cp /bin/bash /var/tmp/bash; chmod u+s /var/tmp/bash’)

I saved the changes and then used the watch command to see if the new bash file would be created:

watch ls -la /var/tmp

And sure enough, the file was created! I then ran ./bash -p and instantly got a shell as the root user!! All that was left to do was grab the flags located at /root/flag.txt, and /home/cengover/user.txt.