My observations while working this target:
· Enumeration: Life-like
· Vulnerabilities: Life-like
· Exploitation: Life-like/CTF-like
· Difficulty: Easy/Medium
· Community Notes: Life-like/CTF-like
The recommended tools for this lab were:
The following vulnerabilities were found:
· Remote Code Execution
· Local Privilege Escalation
Using my trusty Nmap scanner, I performed a scan for service version detection, OS detection, script scanning, and traceroute.
Next, I tried Nikto and dirb, but kept getting disconnected from the target. I had thought that there was a lot of traffic or that a reboot was taking place. However, this behavior persisted during each scan. So, I decided to launch a web browser and take a look at the site.
The site noted that there was DoS protection and that false positives may occur. That explained why the automated tools were disconnecting. So, I had to start manually enumerating the target web server.
I also took note of the email address as I was thinking that this could have been important.
Reviewing the findings from Nmap, I knew that robots.txt and the /writeup/ directory were present.
Next, I reviewed the ypuffy, blue, and writeup hyperlinks. I did not find useful information on the ypuffy or the blue web pages. However, I did find it interesting that the writeup site was incomplete.
After exhausting my manual search for finding additional web pages, I visited https://www.cmsmadesimple.org to find out more about the content generator. Reviewing the site, I found that there was an admin page that should be included within the webserver of the target. So, I returned and further enumerated until I found the admin login page.
CMS Made Simple Exploit:
Launching searchsploit, I searched to determine if a vulnerability and/or exploit would be listed for CMS. It turned out that there were many entries returned within searchsploit.
I reviewed several scripts and ultimately settled on the SQL Injection RCE, by Daniel Scanu, based on the details found for CVE-2019–9053.
I ran the script multiple times and found the output to be rather odd. Reviewing a post on HTB, it was noted that the TIME variable may need to be adjusted in order to receive valid output.
So, I increase the variable by one until the email output matched what I found from the email address on the target’s default website.
After I started receiving the same output, after multiple attempts, I moved to my cracking rig to use HashCat. Since the password hash was 32 characters, as well as mention of the hash type within the Python script, I knew that the hash was MD5.
So, I created several files with variations of MD5+Salt+Pass and tried them against several MD5 hashes within HashCat. However, I did not have much luck. I then reviewed the Python script and discovered that it could use a wordlist to crack the password.
After modifying the script flags, I launched the script and let it crack against the default rockyou.txt wordlist on my attacker system. This took roughly an hour +/- to crack the password.
Edit: after cracking the hash with the Python program, I returned to HashCat determined to crack the hash. I reexamined the output and realized that I was using an incorrect hash separator character as well as in the incorrect order. Once corrected, the file containing the following hash format:
Next, I used the MD5 20 (MD5+Salt+Pass); which was the opposite for the formatted hash from above. I overlooked MD5 10 (MD5+Pass+Salt); which also worked.
HashCat cracked the hash within less than a second.
With the newly obtained credentials, I launched SSH to see if I could connect to the target.
After connecting to the target, I issued the commands of whoami && id to determine privileges.
I then listed the contents of the /home directory and then the /home/jkr directory; where I found and viewed the contents of the user.txt file.
I started performing typical enumeration, but seemed to not be coming up with anything. I ran LinEnum.sh and lse.sh and found a couple of interesting items.
Using a tip that was provided, I decided to upload pspy from GitHub. The tool permitted unprivileged users to ‘snoop’ on processes :
With the tool uploaded to the home directory, I launched it and observed the results.
Since I was on a HTB free server, I started noticing interesting traffic when others were logging into the target via SSH. The part that caught my eye was the script that posted the motd.d or message of the day.
Next, I decided to research each one of the commands to determine what was occurring during the login process. In addition, I reviewed each one of the directories that was within the PATH statement as well.
Unlike the other directories, /usr/local/bin and /usr/local/sbin both had write access and no read access for the group of staff. Reviewing the output from the id command from above, I knew that the jkr user was a member of staff. Meaning, I could create a file/script in either directory.
To aid me in this process, I reviewed IppSec’s video review of the HTB system Lazy. The interesting portion of the video was between 17:30 and 22:50 of the following link:
Armed with that information, I needed to replicate that technique with the login process. So, I created the following script and gave it execute privileges. I then moved the script to the /usr/local/sbin directory.
Next, I logged out of the target and then SSH’d back into the target. I immediately reviewed the /tmp directory for the file of testing.out; which had the contents of the root flag.
Note: I probably would have been better served by obtaining a reverse shell with Netcat instead of going directly after the flag.
Edit: I decided it would be best to go back and create a reverse shell using Python.
To cleanup my tracks, so other were not able to read the contents of the testing.out file, I used the following process and then logged out and back into the target.
You can't perform that action at this time. You signed in with another tab or window. You signed out in another tab or…
This article is made available for educational purposes only!!! In addition, this article provides general information on cyber security topics used for “Ethical Hacking”.
Persons accessing this information assume full responsibility for the use and agree to not use this content for any illegal purpose. Furthermore, the author is not liable for any direct or indirect damages or expense incurred which may result from the use of the information covered within this article.
Information within this article is “as is”, without warranty of any sort.