Oopsie (Tier 2)

Description

Tier -> 2
Difficult -> Very Easy
OS -> Linux
Tags -> PHP / Custom Applications / Apache / Reconnaissance / Web Site Structure Discovery / Cookie Manipulation / SUID Exploitation / Authentication bypass / Clear Text Credentials / Arbitrary File Upload / Insecure Direct Object Reference (IDOR) / Path Hijacking

Write-up

With a little research, I started answering the first question

Answer: Proxy

Then I did an initial port scan using Nmap

nmap 10.129.123.87 -p- -Pn --min-rate 2500 -oN scan.txt

After that I also did an exhaustive scan to know about the services running on the open ports

nmap 10.129.123.87 -p22,80 -sVC -oN serv_scan.txt

I found an HTTP service running on port 80, which meant a web page was being deployed. So, I went and checked it on the browser and found a simple page where none of the buttons seemed to work. The only relevant thing I saw was an email at the bottom of the site

To learn more about the HTTP protocol you can go here

So to get more information I tried to find some possible directories and files exposed on the web through fuzzing. To help me with that, I used Gobuster and a common dictionary from SecLists. But even trying various dictionaries, I didn't find anything relevant apart from some basic server routes for which didn't have access permissions

gobuster dir -u http://10.129.123.87 -w /usr/share/wordlists/SecLists/Discovery/Web-Content/common.txt -o fuzz.txt

So I reviewed the source code of the website, and in the final part, I found a script tag that was calling a JavaScript file from another URL that seemed to be a login. With this, I tried navigating to that route and fortunately, I found a login page

With this, I answered the next question

Answer: /cdn-cgi/login

I tried to log in with common credentials but it didn't work. Also, I saw there was an option for login as a guest, so I used it and went to an administration page. Exploring the tabs what I found the most relevant was the Uploads tab where maybe I could abuse a File Upload vulnerability, but the page asked us for admin permissions

To learn more about File Upload exploitation you can go here

I continued checking the Account tab where I saw what seemed to be information about the current user, including that the site assigned an Access ID to every user. Also, I noticed that in the URL a parameter id was being queried to display the page but wasn't the same Access ID. So I tried to modify it setting its value to 1 and I found this section was vulnerable to IDOR revealing information about the admin user

To learn more about the Insecure Direct Object Reference (IDOR) vulnerability and its exploitation you can go here

With this, I had more information to find a way to access the Uploads section. So to check how it was working, I tried intercepting the petition with FoxyProxy and sending it to Burpsuit to analyze it and replicate it

I saw a Cookie header was being sent in the petition with the parameters user and role, noticing the value of user was the Account ID I could see in the Account section. I tried modifying this value with the one leaked for the admin user and then forwarding the petition, and it gave me access to the Uploads panel with administration permissions, impersonating the user

With this information, I answered the next questions

Answer: Cookie

Answer: 34322

To abuse this functionality, and knowing that the page was made in PHP thanks to Wappalyzer, I tried uploading a Reverse Shell for PHP. At the moment of sending the petition, I modified again the user parameter to retain the privileges and saw the process worked and the file was uploaded

To learn more about how to create a script for a Reverse Shell you can go here

I needed to find a form to invoke our file in the system but didn't know exactly where the file was. So going back to the fuzzing results, there was a /uploads route, which is a default route for uploaded files in PHP. So assuming here would be the file, I set up a Netcat listener and went to this route calling the file, and fortunately, I caught a shell from the target machine as the www-data user. Also, I sanitized the terminal to work more comfortably with it

nc -nvlp 4444

To learn about the sanitization process you can go here

With this, I answered the next question

Answer: /uploads

Then, I had to find a way to make lateral movement to another user as www-data is the default for some web servers and usually doesn't have permission for some actions. I explored the filesystem starting with the /var/www/html route, where the information of the web server is usually found. There, I found in the cdn-cgi/login folder, there was a db.php file that seemed to be database information, and reading its content we found some exposed credentials for the user robert

With this, I answered the next question

Answer: db.php

With this information, I tried changing to the user robert and it worked successfully, being able to navigate to the home folder of this user where I found a user.txt file and reading it I retrieved the user flag

What was left, was to find a way to escalate privileges. I started looking at the execution permissions for the sudo command, but nothing was enabled. Then, I searched for executables with SUID permissions that we could abuse, and found that there was a binary named bugtracker with special permissions as the root user, and for the members of the group bugtracker. I checked and fortunately, our user was in this group so I could abuse it

sudo -l
find / -type f -perm -04000 -ls 2>/dev/null | grep bin

To learn more about SUID/SGID abuse for privileges escalation you can go here

With this and a little research, I answered the next questions

Answer: find

Answer: root

Answer: Set Owner User ID

So I tried running the binary to see how it worked. It displayed a report of bugs based on a provided ID value, but when given an arbitrary number whose report was not in the system it gave us an error where the content of a file couldn't be found and displayed, apparently using the cat command

Also, I noticed it seemed to be using the relative route for calling the cat binary instead of the absolute route, and that could make it vulnerable to a Path Hijacking attack. So to confirm, I used the command strings on the binary hoping to get some information about the code with which it was built, and in fact, I saw it was calling it relatively

strings /usr/bin/bugtracker

With this and the previously found user flag, I answered the next questions

Answer: cat

Answer: f2c74ee8db7983851ab2a96a44eb7981

So I tried performing this attack by adding the /home/robert route to the PATH environment variable and creating an arbitrary version of the cat binary to invoke a shell with privileges. Then I executed again the bugtracker binary which would call my version of the binary, noticing it worked and getting a shell as the root user

To learn more about Path Hijacking exploitation you can go here

Finally, I went to the /root folder to look at its content, noticing a root.txt file. Before reading it I rolled back the PATH variable to its default, to ensure the cat command would work normally again, and with this, I finally retrieved the root flag

With this, I got the root flag and pwned the machine

Answer: af13b0bee69f8a877c3faf667f7beacf

PreviousArchetype (Tier 2)NextVaccine (Tier 2)

Last updated 4 months ago