Base (Tier 2)
Description
Tier -> 2
Difficult -> Very Easy
OS -> Windows
Tags -> Vulnerability Assessment / Custom Applications / Source Code Analysis / Authentication / Apache / PHP / Reconnaissance / Web Site Structure Discovery / SUDO Exploitation / Authentication bypass / Clear Text Credentials / Arbitrary File Upload / Information Disclosure / PHP type juggling
Write-up
I started doing an initial scan using Nmap
nmap 10.129.93.15 -p- -Pn --min-rate 2500 -oN scan.txt
With this, I answered the first question
Answer: 22,80
Then to learn more about the services running on the open ports, I did an exhaustive scan
nmap 10.129.93.15 -p22,80 -sVC -oN serv_scan.txt
I found the HTTP protocol running on port 80 so I went to the browser to explore the content and found a website for the services of a company. I explored the sections of the site but for the moment the only interesting thing was the Contact section, which had a form that I filled out, but trying to submit, it didn't work and showed an error message
To learn more about the HTTP protocol you can go here
I continued exploring the sections, reaching the Login button which redirected me to a login page. I tried logging in with common credentials but it didn't work. What caught my attention was the route to this site on the URL, which wasn't calling the source file directly but using a relative route. Based on this, I tried reaching just the folder from which it was being taken and noticed other exposed files
With this and a little research, we answered the next questions
Answer: /login/login.php
Answer: 3
Answer: .swpstrcmp()
With a little research, I found that the .swp extension is for temporary files from text editors such as vi, vim, nvim, etc... so I downloaded the login.php.swp file and used the
vimcommand with the-rflag to recover the file, save it to a new file and read its content, now visualizing the source code properly. We noticed it was making a comparison for the confirmation of the credentials using the strcmp function
vim -r login.php.swp
# Inside vim
:w login.php
:q!
With this, I answered the next question
Answer: strcmp()
So searching about this function and its possible flaws, I found out that it could be affected via PHP Type Juggling, by passing the parameters from the request as arrays instead of variables. So I intercepted the petition to modify it using FoxyProxy and Burpsuite, then forwarded it, and reached a new page with an upload option
To learn more about PHP Type Juggling you can go here
Once here, I tried uploading a script for getting a reverse shell in PHP, and it worked, but I didn't know where the files were being saved. So, to find the location, I tried fuzzing the URL to find possible routes, and after some attempts and finding the correct dictionary, I found a route /_uploaded which seemed to be the correct location. Then I went to that route and confirmed the file was there
gobuster dir -u http://10.129.93.15 -w /usr/share/wordlists/SecLists/Discovery/Web-Content/big.txt -o fuzz.txt
With this, I answered the next question
Answer: /_uploaded
So, to gain the reverse shell, I set up a Netcat listener to catch the connection and tried accessing the file from the browser. I noticed it kept loading, and the listener successfully caught the connection. Then, I sanitized the terminal to interact better with it and checked with which user I had accessed
nc -nvlp 4444
As I was a default user from the web server, I had to find a way to make lateral movement to another user on the system with less restricted actions. First, I went to explore the server files in the default folder /var/www/html finding a curious file under the /login folder named config.php, and checking its content I found a password for the admin user was being leaked
I had the credentials for a user on the website, but I was looking for one on the system, so maybe these credentials could work also there. I tried changing to the user admin but it failed, so it wasn't a user on the system. So I went to the /home folder to see if there was any folder related to another user and found one named john. Once again I tried changing to that user assuming it would have the same password, and it worked successfully
With this, I answered the next questions
Answer: john
Answer: thisisagoodpassword
Once there, I went to its /home folder, found a user.txt file, and retrieved the user flag from its content
What was left was to escalate privileges, so I checked the
sudoexecution permissions for this user and it could execute thefindcommand as a privileged user
With this, I answered the next questions
Answer: /usr/bin/find
Answer: exec
Answer: f54846c258f3b4612f78a819573d158e
Knowing that, I went to GTFOBins to see if there was any related exploitation for the
sudopermissions on this binary and fortunately, it was, so I used it and successfully gained a shell as the root user
sudo find . -exec /bin/sh \; -quit
Finally, I went to the /root folder and listed its content noticing a root.txt file, which after reading it, gave me the root flag
With this, I got the root flag and pwned the machine
Answer: 51709519ea18ab37dd6fc58096bea949
Last updated