Basic Pentesting (Try Hack Me)
I am currently in the process of completing these boxes on Try Hack Me again in an effort to document my experience, reinforce my knowledge of the topics, and improve my ability to concisely communicate the pentest lifecycle.
Scenario
Title: Basic Pentesting
Description: This is a machine that allows you to practice web app hacking and privilege escalation.
Free/Subscriber: Free
Enumeration
From the version information for the SSH and HTTP services, the target is an Ubuntu Linux OS.
There are six open ports:
- 22 (SSH)
- 80 (HTTP)
- 139/445 (Samba/SMB)
- 8009 (Apache Jserver)
- 8080 (HTTP)
The NetBIOS ports, 139 and 445, usually go hand in hand to serve SMB or Samba services.
SMB
Beginning with SMB, let’s try to list the shares hosted on the server as an unauthenticated user.
Looks like there is one available share, Anonymous, that we may be able to access. The IPC$ share is usually not accessible unauthenticated. Let’s see if we can connect to the share and list the files.
We accessed the share unauthenticated which has one file, staff.txt. Within the image, the file contents are an all-staff announcement to not dump items in the share. There isn’t much useful information in the message but thinking about this a bit, there are two key pieces of information leaked from the file.
- jan
- kay
These are potentially two username that we can use to our advantage to brute force into other services hosted on the target or to protected endpoints of the web applications.
HTTP (80)
Browsing to the web application on port 80, we’re presented with the landing page indicating that the website is undergoing maintenance.
Maybe there’s some information hidden in the page source.
Looks like there might be a dev section hidden behind an endpoint that is not publicly accessible. Let’s use Gobuster to search for it.
Woot! We found the dev section as /development. It’s a directory index listing with two text files, dev.txt and j.txt.
The dev.txt file contains,
2018-04-23: I've been messing with that struts stuff, and it's pretty cool! I think it might be neat
to host that on this server too. Haven't made any real web apps yet, but I have tried that example
you get to show off how it works (and it's the REST version of the example!). Oh, and right now I'm
using version 2.5.12, because other versions were giving me trouble. -K
2018-04-22: SMB has been configured. -K
2018-04-21: I got Apache set up. Will put in our content later. -J
The j.txt file contains,
For J:
I've been auditing the contents of /etc/shadow to make sure we don't have any weak credentials,
and I was able to crack your hash really easily. You know our password policy, so please follow
it? Change that password ASAP.
-K
The above two text files provide varying pieces of information.
- Struts might be referring to Apache Struts which may be the application on port 8080.
- Jan appears to have a weak password according to Kay so we could potentially use that to our advantage to brute force the SSH service
Initial Foothold
SSH Brute Force
Let’s use Hydra to brute force Jan’s password. It’s been a while since I covered the format of the Hydra command so I’ll summarize it briefly.
hydra -l jan -P /usr/share/wordlists/rockyou.txt 10.10.103.246 ssh
-l jan: Use the username jan for the brute force authentication against SSH-P rockyou.txt: use the following list of passwords to test10.10.103.246: target IP addressssh: service to brute force against, ssh requires no additional parameters
Success! We have our initial foothold into the target system.
Privilege Escalation
Jan contained no useful files within her home directory that could be utilized for privilege escalation. Searching for other user directories in /home, there is the home directory for the user kay that we encountered earlier from the all-staff email.
Kay has a pass.bak file but is only readable as Kay. The .ssh directory is accessible to us however.
For directories, the x bit in the permission scheme means change into, so it’s accessible by anybody in this case.
Checking the directory, kay has a private key generated for himself. We may be able to use this SSH key to perform some horizontal privilege escalation and log into the system as Kay.
This failed as the key is password protected but no matter! We can copy it over to our attacker workstation, convert it to a file that John the Ripper can use to brute force using ssh2john, and crack the passcode with the rockyou.txt wordlist.
With access to the passcode for Kay’s private key, let’s re-run the SSH command to log into the system as Kay.
Checking out the pass.bak file, it looks like it’s the password for Kay’s user. Listing out the sudo privileges for Kay, he has full administrative privileges to the system. Running sudo su, we have obtained a root shell!
Looks like there’s a flag in /root indicating that we have completed this challenge so we can be done. Success!
Reflection
Alternate Initial Foothold
Reading through the final flag, it looks like there is an additional vector for obtaining our initial foothold as well as performing privilege escalation.
My hunch is that this has to do with the Apache Struts comment found in the /development index along with the web application on port 8080. We did not enumerate those fully so let’s explore those a bit.
This is a typical Apache Tomcat deployment with the Manager App which I have encountered before to deploy malicious WAR payloads to obtain a reverse shell through as an Administrative user.
I tried to brute force my way through the application to the Administrative panel but that was not possible through either the default credentials or Jan/Kay’s username.
After a bit of time unsure on how to approach this and using the default Metasploit options for the module that can exploit this Apache Struts version, nothing was working. Taking a step back, I thought about the note a bit more and identified key pieces of information about the “Showcase Example”.
Looking at this example of abusing the Apache Struts example, we have an idea of the URL structure for the showcase example and an endpoint that we can access. Let’s see if we can access this.
Fantastic! We finally found the URL to access the Apache Struts example. Let’s update the Metasploit options to reflect this.
The following image is the original set of Metasploit options for this module.
I updated the Metasploit options to reflect the new URL and the target information.
Running the module,
we obtained a shell as the tomcat9 user!
Alternate Privilege Escalation
We could use the original technique through Kay’s .ssh folder that we used for privesc but let’s try to find the alternate method.
As one of the privesc techniques, let’s list out the SUID binaries.
One of the binaries stands out, vim.basic, which we can use to abuse our privileges. Since the SUID bit is enabled on this binary, we can run the file impersonating as the user that owns the binary which is root in this case.
This means, we can view Kay’s pass.bak file and switch into Kay’s user account. With those two techniques, we have found both methods to obtain our initial foothold as well as both methods to escalate our privileges.
With every aspect of this room covered, we have fully completed it!