Oopsie (Tier 2)
Last updated
Was this helpful?
Last updated
Was this helpful?
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
With a little research, I started answering the first question
Answer: Proxy
After that I also did an exhaustive scan to know about the services running on the open ports
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
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
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
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
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
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
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
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
Then I did an initial port scan using
To learn more about the HTTP protocol you can go
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 and a common dictionary from . But even trying various dictionaries, I didn't find anything relevant apart from some basic server routes for which didn't have access permissions
To learn more about File Upload exploitation you can go
To learn more about the Insecure Direct Object Reference (IDOR) vulnerability and its exploitation you can go
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 and sending it to to analyze it and replicate it
To abuse this functionality, and knowing that the page was made in thanks to , 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
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 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
To learn about the sanitization process you can go
To learn more about SUID/SGID abuse for privileges escalation you can go
To learn more about Path Hijacking exploitation you can go
