Now this was a fun change from the last one, and marks box #6 in my OSCP Prep. I had done this box some months ago and it was fun to play with again and re-remember how to do it.
Here’s the nmap scan:
Browsing, we get a blog, and it mentions a php bash shell that arrexel developed on this very server! That has to be promising!
Kicking off a dirsearch, we indeed find some interesting directories.
And now we have a shell.
We quickly see that we can run commands as the user ‘scriptmanager’ with no password, and we can browse around. www-user is enough to get us into arrexel’s directory and find the user flag.
But how to get the pesky root flag? Well, let’s see what the scriptmanager user can do.
Of particular interest is this scripts folder in the root of the server. Looking inside the directory we find a test.py and a test.txt. Don’t forget to look in the directory as scriptmanager otherwise you won’t be able to see anything.
All the test.py script does it write to test.txt. But as you can see above, it must be doing it with root permissions as test.txt is only writable by root. It’s trivial to modify the python script to get the contents of root.txt and write them out for us.
Now just wait for the script to be run (cron job) and poof, you’ve got your root flag!
This was a fun box. I look forward to moving on to more! Video to follow shortly!
As the name would suggest, I learned about a vulnerability called ShellShocker doing this one. First things first, kick off an auto-recon and let’s take a look at the full nmap scan.
Only port 80 and an SSH server running on a non-standard port. Let’s get after port 80.
Browsing to the page we don’t see anything exciting in the source, no robots, nothing there. So let’s see what else we can find with dirsearch. If you don’t have dirsearch, definitely get it. It’s a threaded version of dirb, dirbuster, gobuster, and it runs great.
Looking at this output, we have a couple directories. Maybe the cgi-bin has some scripts, so let’s run dirsearch again with some other extensions like .sh.
We found a .sh script inside of the cgi-bin on this server. Read more about this vulnerability here: https://en.wikipedia.org/wiki/Shellshock_%28software_bug%29 , but then let’s get msfconsole up and running. Once you type ‘search shellshock’, you’ll want to use apache_mod_cgi_bash_env_exec , as that’s what we’re doing here.
Make sure to adjust your settings. Set your LHOST to your own IP address, and change the TARGETURI to the /cgi-bin/user.sh script we located. Additionally, set the RHOSTS to the ip address of the shocker VM in HackTheBox. Then try an exploit!
If all goes according to plan, we get a nice meterpreter session, like below:
Once here, drop into a shell with the ‘shell’ command, and poke around to find that user flag. Additionally, drop a sudo -l to see what our permissions are.
A few things from that picture above. You see how we don’t have a prompt? That doesn’t affect us on this box, but it will on future vms. Also, we see in shelly’s home directory the user flag, which is easy to submit at this point. Finally, we see that shell can run /usr/bin/perl with no password. Browse out to GTFOBins, at https://gtfobins.github.io/gtfobins/perl/ , and look at the sudo section.
And that makes short work of Shocker! As always, I’ll record a video walkthrough of this as well. Please consider subscribing to me on YouTube, and thanks for catching this walkthrough!
Back to the hacking I go. Between the Masters program and three children all being home-schooled, it’s been a challenge for sure, but I’m back at it and happy to be doing it! This is a fun challenge to do as I work through the Linux boxes over at HackTheBox.
First, we run Autorecon, and we find a few ports, 21, 22, and 80, all open. We also see what’s supposedly a minecraft server on a high port. Looking at the versioning for ports 21 and 22 we don’t see much. There is a File Copy exploit for vsFTPd 1.3.5, but it doesn’t suit us here as there’s nothing on the FTP server. So on to port 80!
Once AutoRecon finished with Gobuster, I popped open those results, and looked for anything out of place. There’s a few pages to look at here.
Of particular curiosity is the /phpmyadmin and the /plugins. Browsing to the plugins directory you’ll find some downloadable Java repository files, or .JAR files. Let’s get into those.
Extracting “BlockyCore.jar” leads you to find the file “BlockyCore.class”, in /com/myfirstplugin folder. Looking up how to open a .CLASS file led me to install jd-gui, and open the file with that. In doing so, you’ll find some awesome credentials to a SQL server database!
However, trying to ssh into this machine with root / 8YsqfCTnvxAUeduzjNSXe22 doesn’t work. There must be more. Thinking about accessing SQL servers, there’s a web interface with phpmyadmin. Let’s check that out!
Sure enough, we can login with those credentials to phpmyadmin.
So looking around here, we see a wordpress database, with a hash of a password. We also see a username, notch, both in the wp_users table.
Maybe notch is a good username for the machine? Sure enough, using the same password we logged into phpmyadmin with and the user ‘notch’ gets us shell access!
First thing I always do is try running ‘sudo -l’, and in this case, we get some great news!
Just run a quick ‘sudo su’ and you are now root!
Thanks to everyone for checking out my blog. Please also check out my video walkthroughs, and remember, users like to re-use passwords!
This box got me going for a little bit, until I remembered my basics and focused. Beep is a good box for demonstrating the most common vulnerability of all – users. With that said, let’s get to it! The initial AutoRecon scan shows a lot of open ports.
As you can see, we have a lot to work with here. SSH, SMTP, HTTP (on Port 80, 443, and 10000), a POP3 Server, an IMAP Server, and numerous others (HylaFax anyone?).
With there not being a lot of common ports here, probably the best place to start is by looking at the HTTP ports. Port 80 has nothing, and quickly redirects over to Port 443. Port 10000 has a Webmin portal up, which may be accessible.
The best thing here is to slow down, get all of your services down, and RESEARCH! Look up vulnerabilties on each port related to the services, and if possible, the versions of the software (if you can find them). This is the only good way to stop you from going down rabbit holes.
Eventually, on the HTTPS server on port 443, you’ll see the Elastix login. Looking up vulnerabilities for this takes you to https://www.exploit-db.com/exploits/37637, which describes the ability to perform some local file inclusion. If you read through the comments, you can find the Proof of Concept here:
Trying this out by pasting it in our browser window works! You’ll be able to pull up a configuration file for the Asterisk Management Portal. Right-clicking and selecting View-Source will probably make it look a little better for you, like this:
Scrolling through here we can see a bunch of passwords, including some that are re-used. That is the key to this lesson – password re-use. Maybe one of these is re-used for other logins. We have some passwords, let’s use the LFI vulnerability to get our users list.
Modifying the LFI to browse to the /etc/passwd file works, and we can see the standard root user has logon, as well as the user on the bottom, fanis.
Trying both of these user names against our passwords from our configuration file over SSH quickly gains us access. I’ve included a screenshot of an error I’ve received trying to SSH in here as well as the fix, for future reference. This is because of the age of this box, but it still could be applicable in future pentesting.
Once here, it’s a trivial matter again to browse to the two flags. No extra privilege escalation needed!
Lame is the first box from HackTheBox in my OSCP Preparation series, and I wanted to get off to a good foot with my methodology. Once we added the ip address to our /etc/hosts file as lame.htb, we kick off an AutoRecon scan and let it run. Opening the full nmap scan, we
As you can see, we have a few ports open, and nmap did a pretty good job here of giving us version information. After adding all of this to my notes, I began by looking up various exploits I could find for the different ports and services that were running. Ports 139 and 445, running SMB, looked the most juicy here, and in any penetration test, are the first I would typically go after.
For my OSCP Preparations using HackTheBox, I’ll be following an awesome list made by TJ Null and the Mayor, Joe Helle. The list is curated here for your enjoyment. I did make a few changes – I sorted it out into Linux and Windows, and sorted from easiest to most difficult.
The purpose of doing this is to build up muscle memory in methodology, as well as get some great notes for taking the OSCP with.
For each box, I will write a walkthrough, and I will make a Youtube video of it as well. If it is during my stream time, I will livestream the work on it.
Thanks for coming along on the journey! I’m looking forward to this and crushing the OSCP before Christmas!
This is the 2nd box of TJ Null’s OSCP Preparation list, and the first one I’m publishing my writeup for. I recorded the video for YouTube earlier this evening, and I’ll get that posted as soon as my awesome new branding, courtesy of Nathan Cavitt at Mad Standards, comes in!
Once this box is launched, run your standard autorecon scan against it, and wait while it finishes. I tend to add the IP address of the box to my /etc/hosts so I can track the folders easier. As you can see by the screenshot below, port 22 (SSH) and port 80 (HTTP) are open, and the subsequent scans are kicking off.
With CTF-like one-off boxes to hack, chances of port 22 having anything are pretty slim to none here. SSH is not a very oft-hacked protocol, and bruteforcing isn’t normally the goal here. Let’s take a look at port 80’s nmap-http scan.
When autorecon kicks off the subsequent scans, it runs with the appropriate scripts for the port. Great! Here you can see there is a comment on the index of the page that refers you to the nibbleblog directory. Let’s do some enumeration with gobuster on the nibbleblog directory and see what we can find.
Seems pretty standard so far. A login page exists at admin.php, and pulling up the README, you can see that we are running nibbleblog version 4.0.3. A quick jaunt to Exploit-DB (https://www.exploit-db.com/exploits/38489) will show there is an exploit, but you need to know the username and password for it! Time to do some more looking around.
If you try brute-forcing the password with hydra, you will quickly get an error of blacklist protection, causing you to have to reboot the VM. Luckily, taking a look at config.xml and just trying some simple ones shows that we have a lazy admin here!
At this point you can run metasploit and you will get a shell, enabling you to grab the user flag. However, when I went that route, I had issues with privilege escalation that I did not have when I ran this exploit manually, and as I’m prepping for the OSCP, that’s the path we will take here. Let’s keep at it! Login to the website with the above credentials, and let’s keep at it!
The exploit, reading Exploit-DB and the CVE (https://nvd.nist.gov/vuln/detail/CVE-2015-6967) says it utilizes an unrestricted file upload vulnerability in the My Image plugin to upload an executable file and access it at “content/private/plugins/my_image/image.php” so that’s exactly what we will do. I grabbed a PHP reverse shell courtesy of pentestmonkey (https://raw.githubusercontent.com/pentestmonkey/php-reverse-shell/master/php-reverse-shell.php), updated it with my IP address and port, and renamed it to image.php, finally uploading it via the Plugins page. All that’s left to do is browse to the page and get the reverse shell!
From here it’s trivial to browse to /home/nibbler and read user.txt. But what is our path to root from this point? The first, and easiest thing to do is check permissions by running sudo -l. As you can see, there’s something of interest here!
Well, you know we have to check that out! Going to the folder though all we see is a zip file. Unzipping it, we get the monitor.sh discussed. At this point, there’s a few things we can do. You could edit monitor.sh to run netcat back to another listener you set up, or you can go about it the quick way, like this:
As you can see, we echo’d “bash -i” and overwrote monitor.sh with the command to give us an interactive bash shell. We then ran it using sudo, which ran it with no password as ROOT. Once done, we have a root shell! From here it’s trivial to go to /root/root.txt and get the flag for your submission!
I hope you’ve enjoyed the second machine in the TJ Null OSCP Prep list! Stay tuned for more!