VulnNet: Endgame
https://tryhackme.com/room/vulnnetendgame
Last updated
Was this helpful?
https://tryhackme.com/room/vulnnetendgame
Last updated
Was this helpful?
By Jacvbtaylor
For this challenge, the goal is to find the administrator's password of the CMS along with the user and root flag.
Starting with a scan using https://github.com/jacvbtaylor/nmapscript, I can see the following services running:
22/tcp open ssh
80/tcp open http
Knowing there is a webserver running, I pulled up the webpage using the IP address provided and was prompted with the following HTML text:
Our services are accessible only through the vulnnet.thm domain!
I decided to try adding this to my host file to see how this would possibly change the webpage and was served a new webpage
Viewing the page source first, I found some directories insides the vulnnet webfolder such as /js/.
I figured this was a good time to start searching for folders that are not indexed or may be hidden so I cracked open dirb and gobuster:
dirb http://vulnnet.thm
gobuster dir -u http://vulnnet.thm -w /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt
I noticed some basic names coming back positive but found these to be indexed with
The images folder had no index but held nothing noticeably useful. Below are the folders that I found using multiple tools and wordlists, all leading to a dead end.
I was unable to locate anything within the vulnnet domain that would direct me to a CMS, so my next thought was to search for possible subdomains. Something commonly done when trying to be more discreet and/or secure with your webpage is move important information in front of the domain. EX: if you are hosting a wordpress site, the wp-config file is commonly sought after because of it's critical information inside. Moving that file from var/www/html to /var/www would keep the site functioning but would not grant public access to the wp-config.php file. The same concept can be used for a test or develop site making it only accessible using the www subdomain or similarly, another folder created for those files. I tried a few various of tools and options within them to find subdomains with no real luck and a lot of crashing my kali machine using up too much ram. Here are a couple of examples of what did not work for me:
gobuster dns -d vulnnet.thm -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt
wfuzz -c -v -w /usr/share/dirbuster/wordlists/directory-list-2.3-medium.txt --sc 200,202,204,301,302,307,403 -u http://vulnnet.thm -H "Host:FUZZ.vulnnet.thm"
After bumping up my VM's ram and CPU, I looked toward other options. This was my first time using the ffuf tool. Initially, too much information was being spat out with a status 200 but they all had the same word count of 9. You can see from the image above that those results all have different word integers. So in order to get the appropriate results, the command had to have the -fw 9 option on the end
ffuf -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt -u http://vulnnet.thm -H "Host: FUZZ.vulnnet.thm" -fw 9
The ffuf scan gathered those 4 domains fairly quickly, but I let it continue to run while I scoped out these subdomains, in the event it may capture more.
In order for me to be able to visit these additions, I need to add them to my /hosts/ file
I visited each of these subdomains and was able to find more areas to explore, but to broaden this further, I initiated a dirb attack on the domains. I saw in the source code for blog.vulnnet a clue to the CMS being used when I saw Mediumish Theme. This is a Wordpress theme, so PHP may be my main focus here, or at least incorporated into the attack.
Dirb was able to pull some new information for me- some highlights being a fileadmin directory and a login page. The fileadmin directory shows a folder called user_upload. I may be able to use this if I find a way to upload to this directory.
The login form for typo3 initiates on index.php, but reacts differently than any other login page I've used.
I intercepted my post request using burp to see how the request looked so I could create a payload with hydra to attempt a bruteforce
hydra -L /usr/share/wordlists/usernames.txt -P /usr/share/wordlists/rockyou.txt admin1.vulnnet.thm http-post-form "/typo3/?loginProvider=1433416747:login_status=login&userident=^PASS^=&interface=backend&username=^USER^&p_field=&commandLI=:Your login attempt did not succeed Make sure to spell your username and password correctly, including upper/lowercase characters." -vV -t 60 -F
All of my attempts to bruteforce the login ended with the username 3d and a different password each time. I was getting false positives. I realized this wasn't going to work. Either my syntax wasn't appropriate for the request or there was some line of defense set up against bruteforcing, so I had to turn toward other means.
I retreated to the blog subdomain. I noticed some of the files on the blog page used html but the posts used php extensions. This felt important to investigate since the API was also using php:
All of the post().php files seemed to have the same script implemented in them which can be seen on line 305
When I call that file in the browser I am presented with this:
I began messing with the parameters in the URL and was getting new results, but I wasn't sure how to truly exploit this yet
The fastest way to kickstart this URL exploitation was to use a tool called SQLmap.
sqlmap -u http://api.vulnnet.thm/vn_internals/api/v2/fetch/?blog=1
This is good news! I ran the command again, but this time with the -dbs option at the end and was informed about 3 databases:
[*] blog
[*] information_schema
[*] vn_admin
Using SQLmap again, I dumped the tables and columns
sqlmap -u http://api.vulnnet.thm/vn_internals/api/v2/fetch/?blog=1 -dbs --tables --columns
Focusing first on the blog database, we discover a users table with 3 columns: id, username, and password.
sqlmap -u http://api.vulnnet.thm/vn_internals/api/v2/fetch/?blog=1 --dump -T users -D blog
Dumping the users table gave us 651 usernames and passwords. I sorted this into a file that I could maybe use for later:
cat /root/.local/share/sqlmap/output/api.vulnnet.thm/dump/blog/users.csv | sed -e 's/,/ /g' | awk '{print$3,$2}' > bloguserpass
I got rid of the id number and moved the usernames to the left of the password. I can easily separate the 2 columns now if I need to make a list for bruteforcing.
After exploring the vn_admin database, I found a user from the be_users table and password/username columns. Hopefully this is the user for the typo login!
I put the user and hash into a file and started john the ripper to try and crack this hash. This was my first time encountering argon, so I was putting a lot of faith into john. While that ran, I grabbed the passwords from the blog database so I could try and crack the password with that as well if I was unable to get in with hydra
cat bloguserpass | awk '{print$2}' > passwords
hydra -l chris_w -P THM/VulnnetEG/passwords admin1.vulnnet.thm http-post-form "/typo3/?loginProvider=1433416747:login_status=login&userident=^PASS^&username=^USER^:Your login attempt did not succeed Make sure to spell your username and password correctly, including upper/lowercase characters." -vV -t 60 -F
Another false positive. I was hoping this smaller password list would help us get in, but back to john:
Using that username and password, I was granted access to the typo dashboard. Remembering that user_upload folder I found earlier, I figured now would be a good chance to utilize that to gain access to the server.
I figured this was going to work with no issue, but found that php wasn't allowed into these directories. This rule would either be set in an .htaccess file or some configuration control may be available inside this dashboard.
After looking through some tabs in the admin tools and the settings, I came across
"Configure Installation-Wide Options
Global Configuration
Modify settings written to LocalConfiguration.php."
It looks like I was write about the rule being the .htaccess file. I don't think anyone will be upset if I delete this rule. Now I just need to upload and visit my new webshell.
There's a good chance this is where our user flag is placed, but we don't have permission to open it. I noticed this file is in system's home directory, and I saw system has bash from viewing the /etc/passwd file. This is probably my next move, becoming the system user.
My next idea is to gain shell access, and possibly escalate my user from there. Since I already uploaded one php file, I can go through the same step to upload a reverse shell and start netcat to listen in on the call home and I am in:
From the reverse shell, I should be able to accomplish a bit more than I could with the web shell. My user, www-data, doesn't belong to any special groups and probably has no sudo privileges, so I want to see if I can find more information about the system user.
cd /home/system && ls -a
There are a few files I now see that I may be able to check out, assuming I have access to them.
After some snooping around in this folder, my initial thought was to copy this browser information to a public folder, but my user did not have permission
cp -r /home/system/.mozilla/firefox/8mk7ix79.default-release /var/www/admin1/fileadmin/user_upload
"cp: cannot open '/home/system/.mozilla/firefox/8mk7ix79.default-release/saved-telemetry-pings/49e0d2f0-9780-4e75-b40e-ae927de3bdcf' for reading: Permission denied"
I was having issues zipping the information as well.
This is when I realized I need to find a directory my user could tamper with, not just navigate through and read inside of: /tmp/
This worked! I am hoping there may be some cached information in this zip file from the system user, but there's only one way to find that out. From the /tmp/ folder I was able to move the zip to the /fileadmin/ folder and download it to my machine. Perfect.
After browsing through the default-release files, I found one of them had a login file which hosted an encrypted username and password. I searched "firefox decrypt" and came across this neat tool python tool by https://github.com/unode.
Never using this tool before, I had to tinker with it a bit and came across a problem
I need a way to point this tool to the login file I found. I first tried copying the login file to the 8mk directory, but it didn't like that
When I tried running the tool directly on the login.json file, I got a warning that profile.ini was not found. I found that file in the firefox directory and added a new profile to it
then ran the tool one more time after making sure each profile had a unique profile number and got the information I was after
I used that password to ssh into the server as the system user. Now I can get the flag
I explored my new home directory and saw a folder name that seemed unusual. The Utils folder seemingly had a few different tools inside of it. I discovered they were all dynamically linked ELF files. The last time I dealt with and ELF file, I was able to spawn a shell. To figure that out, I had to learn about the getcap command. You can see what I did here when I first encountered a similar situation. So to begin, I decided to take a similar approach and see what capabilities these files may have. This seemed to work perfectly.
Referencing this webpage here I see that =ep means all capabilities are effective and permitted. This sounds cool but I still don't know what to do about it yet. GTFObins seems to always have the answers so I search "gtfobins openssl".
Worked like a charm:
HACK=/etc/sudoers && echo "system ALL=(ALL) NOPASSWD:ALL" | ./openssl enc -out "$HACK"
Using the capabilities of the openssl file, I was able to make a privileged write to the /etc/sudoers file and give the system user sudo privileges and move to the root user, gaining full access to the server.
