CPTS #03: Shells and Payloads
Hint:
Host 1: Choose the right payload.
Host 2: Remember how you accessed the blog.
Host 3: It’s too easy when using Metasploit.
Host 1
– Accessing the IP of host 1 on port 8080, we reach the Tomcat page. Next, we attempt to access the Tomcat Manager App. At this point, we don’t have the credentials to log in to the Tomcat manager page.
– Looking at our Foothold machine, we found a file named access-creds.txt. It is likely that this file contains login credentials for various applications.
– Proceed to log in and look for a place where we can upload a shell. The Tomcat Manager previously had a vulnerability related to file uploads.
– After identifying the vulnerable file upload location, we attempt to upload a shell. This application only accepts files with the .war extension. Therefore, we will use msfvenom to generate a reverse shell with a .war extension.
– Proceed to upload the shell file.
– At this point, we see that after deploying the WAR file, Tomcat has automatically extracted and deployed it as an application directory displayed as /shell02.
– Set up an nc handler and access the path of the file we just uploaded.
– And we have obtained a shell on host1.
Host 2
– On host2, we access blog.inlanefreight.local, which requires login credentials stored on our jump machine. After logging in, we find a post mentioning that this blog has an RCE vulnerability, referenced in Exploit-DB with ID 50064.
– After accessing the blog post link, we see that this is an exploit code that we can import into Metasploit for exploitation.
– Download the exploit code and save the file with the .rb extension (this is the extension used for Metasploit modules). After moving the file to the appropriate directory (/usr/share/metasploit-framework/modules/exploits/…/…/), access msfconsole and run reload_all to reload the exploit modules. Then, configure the basic target information.
– The next step is to choose a payload for this exploit module.
– After running the exploit, it was unsuccessful. I’m thinking about what might have gone wrong.
– I suddenly realized that I was accessing the blog using a virtual host, so we need to set the vhost parameter for the exploit module. After setting it and running the exploit—boom! We have obtained a shell on host02.
Host 3
– According to the hint for host3, this machine has a vulnerability related to ‘blue’ and was quite well-known in 2017. From this, we can immediately think of EternalBlue, a famous vulnerability associated with the WannaCry malware.
– Since my internet is quite slow, making VPN and remote access to the Foothold machine sluggish, I decided to use Metasploit’s exploit module to speed up the process.
– Bonus: If you want to exploit it manually without using Metasploit, host3 also has port 80 open, and we can upload files freely without any restrictions.
