Running a bit behind the schedule once again due to work stuff, but this time we’re focusing on pivoting, so while I’m still waiting for my Unraid server to finish the array rebuild it’s time to dive right in.
Day 9 - Pivoting
Deploy the attached VM, and wait a few minutes. What ports are open?
After staring up the target host and Kali hosted by THM we will be first doing a quick little nmap scan to figure out the open port(s). Alternatively you could cheat a little, look at the next question and figure out the answer to this one. Work smarter, not harder.
What framework is the web application developed with?
Since we know we’re working a web application we can load up the target host IP in Firefox and see the Laravel version on the site, but if that wasn’t the case we could open Developer tools with F12 and check the Network tab to see the HTTP Set-Cookie header. It reveals that we’re dealing with Laravel framework (laravel_session=)
What CVE is the application vulnerable to?
Knowing that we’re working with Laravel version 8.26.1 we can look up possible CVE’s online, or we can use Metasploit with the multi/php/ignition_laravel_debug_rce module to check whether the target is vulnerable. This check will return us the info that the target appears to be vulnerable, so we can proceed with it.
As for the actual CVE number we don’t get that, but a little searching with your favorite search engine will do the trick.
What command can be used to upgrade the last opened session to a Meterpreter session?
Next we need to set the rhosts and lhost values correctly in order to execute the exploit, and once that goes through we don’t get a shell, but we can run commands to verify that we’re in. For example whoami will return www-data, which generally is the web server itself.
Lets drop the current session/connection to the background with the background command, and use the sessions -u -1 (1 being the session number) to upgrade the shell. Now listing the sessions we can see a new connection established, and connecting to it we can start taking a deeper look at the target system.
What file indicates a session has been opened within a Docker container?
We can check the root of the filesystem and find the ./dockerenv file, which gives us a reason to believe that we’re actually inside a Docker container.
This is also where the pivoting part comes in. Since we’re dealing with a Docker container we can’t just directly jump around like we’d want to, and instead we have to proxy our traffic through the Meterpreter session. First we’ll background the session, and then add routes for Docker internal addresses 172.17.0.1/32 and 172.28.101.51/32 (latter is the actual target host IP, it will likely be different for you).
To make use of these new routes we need to use the auxiliary/server/socks_proxy module to handle the proxy connection.
What file often contains useful credentials for web applications?
Many web applications use the .env environment variable file to store all sorts of secrets, and since we’re dealing with a web app we can cat the /var/www/.env file to find all sorts of useful things that might help us move forward. Especially useful one might be the database, which seems to be using the default credentials…
What database table contains useful credentials?
Given that we have found out that the server is both running a postgres database and more importantly running it with default credentials we can use the auxiliary/scanner/postgres/postgres_schemadump module to get access to the database, and then use auxiliary/admin/postgres/postgres_sql to dump the schema of the database.
What is Santa’s password?
To get the password from the users column we’ll use the command run postgres://postgres:postgres@$MACHINE_IP/postgres sql='select * from users'. This will print us the list of the database contents, and in this case we’re interested in the username and the password, which is available in cleartext.
What ports are open on the host machine?
Utilizing the SOCKS proxy we have up and running we can run an nmap scan to see if there’s something else interesting running on the host, and indeed we get a list of ports. Note that THM may not like space in the answer, took me a little while to actually get this answer accepted due to that.
What is the root flag?
So, SSH is up and running, and we have username and password… Maybe we can combine these? Lets try to use the auxiliary/scanner/ssh/ssh_login module to establish SSH connection to the server, and using the credentials from before we manage to get a connection open, and after entering the session it looks like nothing is working, but we once again don’t have a full terminal access, so but listing the contents will print out the directory structure for us to navigate with, and soon enough we will be able to find the root.txt with the flag we’ve been after.
And that’s Day 9 done. The difficulty in these tasks is definitely starting to ramp up, and how Docker networks are handled is a rather complex subject anyway so the YouTube walkthrough may come in handy. But the most important thing is to manage to get through it, and at least I learn the best by doing even if I happen to need some handholding. A nice room overall, tomorrow we’ll tackle web app memory hacking!