Today I will be showing how I managed to hack into an old LotusCMS box. Usually I won’t bother writing about stuff like this, but I figured that it would make an interesting blog post given my discoveries, and it might be helpful to someone (Legally, of course) in the future.
Contents
Legal Disclaimer
In case it isn’t obvious, the stuff that I’m showing in this post is considered illegal in most sane jurisdictions. What I’m showing is for educational purposes ONLY, and should NOT be attempted on any machines or networks that aren’t yours. There’s also the possibility of data loss should you follow anything in this post, so make sure to have backups of anything important, and only perform anything in an isolated and controlled environment. If you’re dumb enough to try any of this stuff on your critical systems and you lose data, or you decide to try it on a machine that isn’t yours and now you’re in federal prison, then don’t come crying to me saying that I told you to do something illegal. I warned you.
If you want to hack Linux machines legally, then check out VulnHub or Hack The Box for more machines like the one I’m demonstrating in this post.
Now that we’ve got the legal stuff out of the way, time for the actual post.
Backstory: Why This Post Even Exists
The backstory isn’t exactly relevant to the hacking itself, so feel free to skip this if you don’t care.
Recently, in my pen-testing class, I got assigned a group project, which usually I hate. This is because there’s generally a massive knowledge gap between me and the other group members, so this results in a huge imbalance of work. Regardless, our professor had assigned us a Linux machine that we were supposed to hack into. Our professor only told us that it was some sort of server, gave us a VM image, and no other details.
Long story short, while waiting for my group members to figure out what to do with it, I got bored over my Spring break and hacked into the VM myself. This happened well before they did anything with the VM, so now I’m writing this post as a tutorial for them, and educational/entertainment content for you. This post will show how I got to that point.
First Observation: Metasploitable 2?
When I first booted up the VM, I noticed that the boot screen looked awfully familiar:
It reminded me of Metasploitable 2, a purposely vulnerable Ubuntu machine we’ve been using in class that’s basically designed to demonstrate different exploits using Metasploit. As I later found out, while it wasn’t directly based off of Metasploitable 2, it used a similarly old version of Ubuntu.
First Steps: Scanning The Target
The very first thing I did was get the IP address and run an aggressive nmap scan on it:
Even though there wasn’t much running, it was running an ancient version of Apache, PHP, and SSH, with an equally ancient Linux kernel. Regardless, I still got excited because I knew it was going to get interesting.
About Apache
Since we now know it’s running a web server, let’s see what it’s hosting:
Oh look, a blog! While I did later find out that there were a few hints on it, the first thing that caught my attention was that Login button, so let’s click it and see what happens:
We’ve got ourselves a login screen that reveals a critical detail: The server is running LotusCMS, which I quickly found out was a notoriously vulnerable blogging platform.
Let’s see what else is running on this server by running nikto:
I made multiple observations, including multiple pages that ran phpinfo(), and much more interestingly, phpMyAdmin, which I initially assumed was responsible for managing the database for LotusCMS. Let’s navigate to /phpmyadmin and see what surprises we get:
Wow! That is an absolutely ancient version of phpMyAdmin. Since I got excited about the LotusCMS exploit, I didn’t spend much time with phpMyAdmin.
Getting a Foothold: Exploiting LotusCMS
Exploiting LotusCMS proved to be a bit more difficult than I initially thought, but regardless, it was still very easy. Since I had it right at my fingertips, I searched Metasploit for LotusCMS, and found the Holy Grail:
With an excellent rank and a disclosure date from forever ago, it seemed like the perfect exploit, so I went ahead and configured it:
And I tried to exploit it:
Which after a few attempts, failed. Unfortunately, even after a bit of trial and error, it didn’t work.
Plan B: DuckDuckGo To The Rescue
After my fail with Metasploit, I decided to give a quick search for LotusCMS on DuckDuckGo, and even after just simply typing “lotuscms” revealed this on GitHub:
Yeah it’s definitely not a great sign for security when you’re searching up a product online and the very first thing that comes up, even before the official SourceForge repository, is a exploit on GitHub for it. Regardless, I knew that this was probably my ticket, so I used Metasploit to create a reverse listener:
I then downloaded the script and configured it:
And after a few seconds:
Success! We’ve got ourselves a shell. You might notice that the path for the web server is /home/www/kioptrix3.com, which tells us that this VM was originally from kioptrix.com, a now defunct website owned by some gambling website in a language that I can’t speak. You can still view the original kioptrix.com website on the Wayback Machine. Regardless, I figured that our professor grabbed a vulnerable VM from somewhere for us to hack rather than making their own, and I’m not sure if/how many changes my professor made to it, but it’s still interesting to know the backstory.
Doing a Bit of Exploring
Now that we have access to a shell, let’s do a bit of exploration:
There’s kind of a lot going on here, mainly because I don’t feel like taking a bunch of screenshots, but as you can probably see, I find a file named salt.dat in data/config (Relative to /home/www/kioptrix3.com), and in data/users, I find a file named admin.dat, that contains some information on the admin user. We can save these for later as we can use this to crack the admin password.
We can also check the password files to see what access we have to them:
Unsurprisingly, they didn’t make /etc/shadow world-readable, nor are password hashes are stored in /etc/passwd, so let’s explore some potential privilege escalation methods.
The Fun Part: Exploring Privilege Escalation
Since this VM is running Linux kernel 2.6.24, there are plenty of potential privilege escalation vulnerability, including the notorious DirtyCOW exploit, allowing unprivileged users to write to read-only files like /etc/passwd. Even though I got excited again and used this method the first time, I found something that was much easier and didn’t require kernel-level exploits.
First, lets explore /home:
There isn’t much of interest in dreg, however, even though loneferret‘s bash history is empty, there are a couple of interesting files: CompanyPolicy.README, and checksec.sh. Let’s see what CompanyPolicy.README contains:
Boom, full sudo privileges to run ht, which is a hex editor. There are a few ways of exploiting this, but we’ll get to that later. For now, let’s change our focus to trying to get into loneferret.
Brute Forcing Our User’s SSH Login
As you might have recalled earlier, SSH was open on the VM, so let’s try using nmap’s ssh-bruteforce script, adding the users we found to a list, and using good old rockyou.txt as a password list:
After a bit of waiting, we’ve got ourselves a hit for loneferret:
Let’s try SSHing into loneferret, and see what happens:
Unfortunately, the SSH client included with Kali doesn’t like the ancient OpenSSH server included with our VM, and even after messing around, it still refused to connect. But don’t worry, I have a workaround.
First, install Docker with their convenience script (Or another method described in their documentation):
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.shNext, create a Ubuntu 14.04 container, since we can install an SSH client old enough to connect:
sudo docker run --rm -it ubuntu:14.04 bashAfter it pulls the image and creates the container, your prompt should change to something like this:
root@<random string>:/#From there, run the following command in the container to install openssh-client:
apt update && apt install -y openssh-clientAfter that, you can now use ssh loneferret@ip-address to connect to the VM:
Exploiting Sudo Permissions
Now that we’re logged in as loneferret, let’s see what sudo permissions we have by running sudo -l:
It appears that we only have access to ht, and have been explicitly denied access to su. So let’s open up /etc/sudoers to change that.
Before I continue, now is a good time to take a snapshot, because if you break sudo, then you’re basically screwed (Unless if you want to boot another OS and fix it), so please, take some sort of snapshot or backup before continuing.
After opening /etc/sudoers in ht, you’ll get a crazy looking screen like this:
This is because ht is designed to be a hex editor, and not a text editor. You can still view text files normally by switching modes, but you can’t edit them. Regardless, I’ll show you how to safely(ish) edit /etc/sudoers in ht in its hex view.
First, press F4 on your keyboard to switch to edit mode. You’ll probably notice that your arrow keys move around the cursor.
Next, press Tab on your keyboard. You will see the cursor switch over to the plaintext part.
Next, navigate to the part in the file where it starts with loneferret ALL=NOPASSWD:
Since there’s a lot going on with no line breaks, it might be difficult to find at first. My cursor in this screenshot is white and indicates where you need to be in the file.
Next, and this is an extremely important step to pay attention to, otherwise you’ll need to revert back to that aforementioned backup/snapshot, type over /usr/local/bin/ht with /bin/bash. Since there’s no way to delete characters, and ht only lets you replace characters, replace the extra ones with a space, right up until the red ??:
The text that you overwrote will appear in red. It should look something like my screenshot. If you think you messed up, press F10 to quit without saving, and open it up again.
To verify that you edited the file correctly, especially since sudo can be very picky about syntax, press F6 on your keyboard to bring up the mode selection:
Use your arrow keys to move to text, and press enter. The lines we edited will appear towards the bottom and are a bit hard to spot at first glance (Especially given the poor background/text colors), but they should look like this:
Press F6 again to bring back the mode screen, then select hex. If it looks right, press F2 to save, and then Press F10 to exit.
Next, run sudo -l to verify that your sudoers file syntax is correct:
If you get a prompt asking for your password and/or you get a syntax error, then it’s time to use that snapshot you took. If it looks like the above screenshot, then congrats! You’ve successfully edited /etc/sudoers using a hex editor without breaking it!
Now that we can run bash with full root permissions, let’s try that:
Success! Now we can navigate to /root and retrieve our congratulations message:
Congratulations! You can now say that you’ve hacked a Linux system by simply exploiting a web server (Using the term “simply” loosely).
But Wait! There’s More
Since you now have the entire VM in the palm of your hands, we can do a bit of exploring.
Maintaining Persistent Access
Any good hacker will want to have persistent access to the machine they just hacked, because what would happen if that security hole was closed? We can simply accomplish this by creating a new user, and in case you didn’t already discover, the admin group gets full sudo permissions:
Next, log out of root and loneferret, and try SSHing using your new user:
Success! Now you’ve got your own user.
Important Note
For whatever reason that I haven’t bothered to figure out, it seems like the VM will wipe out any newly created users after you shut it down. I’m not sure if this is a bug or what, but I decided to just simply give loneferret full sudo permissions.
Now that we can access all tools that require root, we can now safely edit /etc/sudoers with visudo, so open visudo. If you’re not root, then make sure to use sudo at the beginning:
EDITOR=/bin/nano visudoNext, where we gave loneferret access to /bin/bash, comment out that line, and add the following line to give loneferret full sudo permissions:
Your file should look like mine. Since we’re using visudo to safely edit /etc/sudoers, you don’t have to worry about bad syntax breaking sudo since visudo verifies it. To verify that loneferret now has full sudo permissions, switch to loneferret with su loneferret (If you’re not already loneferret), and run sudo -l:
What About LotusCMS?
Even though we’re in the VM itself now, we can’t forget to hack the thing it’s actually hosting: LotusCMS. After exploring LotusCMS’s files, I managed to track down the function that generates the admin password, located in /home/www/kioptrix3.com/core/lib/User.php:
So what it does is it takes the passwords, adds the salt to the end of it, and hashes it with SHA1:
sha1(password.salt)Thankfully Hashcat has a mode for this, so let’s first add add our password with its salt to a file, and try cracking it with rockyou.txt using best64.rule for our rules:
That was… extremely fast, even on my crappy lab VM. Regardless, now that we know that the username is admin and the password is Mast3r, let’s try logging in:
That’s… not supposed to happen. It appears someone bought the domain lotuscms.org, and after doing a bit of debugging with inspect element, they’re making update.lotuscms.org and news.lotuscms.org redirect to some sketchy ad domains that are being blocked by my DNS servers.
Thankfully, you can fix this by SSHing into the LotusCMS VM again, and adding the following lines to /etc/hosts (You need root permissions to edit it):
0.0.0.0 update.lotuscms.org
0.0.0.0 news.lotuscms.orgNow you just need to restart your browser (Or open a private session), and let’s try logging in again. It’ll take a little bit since it’ll try contacting those domains and eventually time out:
Success! Despite a few warnings from us blocking those domains, it works! We can now navigate the dashboard without worrying about getting redirected to some sketchy domains. Some pages like settings may take a bit to load because it’ll try contacting those domains again, but regardless, it all works.
Gallerific
When we were exploring the root of LotusCMS earlier, you might have noticed a folder named gallery. As it turns out, it’s yet another service that this server is hosting. Unfortunately, there doesn’t seem to be any Metasploit modules for it, but regardless, let’s check it out:
That doesn’t look right. Since it appears that kioptrix3.com is hardcoded in multiple places, it’s trying to connect to that domain, which doesn’t exist, but you can fix that by adding kioptrix3.com to your clients /etc/hosts file, replacing the IP address with the actual IP address of the LotusCMS box:
10.1.1.20 kioptrix3.comThat’s a little better now:
There’s no apparent login button, but we can figure out where the login page is by simply exploring the gallery folder:
Let’s navigate to http://kioptrix3.com/gallery/gadmin in our browser and see what happens:
The good news is that we’ve got ourselves a login page. The bad news is that the credentials for LotusCMS don’t work on it, so let’s try getting them.
Getting The Login
If you check gconfig.php in gallery, there’s hardcoded database credentials for a MySQL server:
Looks like it’s using the default root user and a password straight out of rockyou.txt, so let’s log in to phpMyAdmin using those credentials:
You can also use the mysql command, but what’s the fun of that when you have phpMyAdmin? Anyway, let’s explore the gallery database:
We’ve got ourselves a user table, so let’s check it out:
Sweet! The login is stored in plaintext, so we don’t need to worry about cracking it. Let’s try logging in with those credentials:
We’ve successfully logged in! Not only do we have full root access to our VM, but now we have full access to all of the services running on it.
phpMyAdmin?
As I was exploring the VM, I happened to notice something in /etc/phpmyadmin:
There was a file named htpasswd.setup containing a user named admin with no password, so I tried logging in with it:
Which turns out to be yet another valid login. Despite this, there didn’t appear to be anything interesting. Regardless, it still opens up another attack vector that I’m not going to go over, mainly because of a lack of time, and frankly this post is long enough as it is.
Conclusion
So that’s how I managed to hack into an old LotusCMS box, which was actually a lot of fun, and I plan on doing more of this in the future. I’m not sure if I’ll blog about similar stuff like this in the future, but I might, especially given my infrequency of posts (This was posted over a year after my last post, after all). This was also written on short notice, and even though it’s very long, clocking in at just shy of 3k words, I’m still very happy with the result of it. I promise I will try blogging more frequently, but I can’t guarantee anything.
In case you’re wondering, no, unfortunately I was not able to crack the root password, which doesn’t matter much anyway since we have full root access to the VM, and can easily change it.