Hack The Box: Starting Point - Oopsie
Enumeration
At the beginning of the penetration test, we usually have only the list of target IP addresses and nothing more. In order to exploit any machine, any information about the target is crucial. Thus, I'm going to enumerate running services with the help of nmap. This very important step will give me a direction to follow along the process.
The ssh service is running on the default port 22 and a web application is hosted on port 80. Furthermore, it appears that the machine is running Linux OS, a Ubuntu incarnation specifically. The obvious next step is to look at the application with the help of the HTTP protocol.
It's the site of MegaCorp Automotive and they are dealing with electric cars.
If you scroll down a little bit you will see that the application provides a login service. This resource it's not accessible from the main page, thus we can try to find it with dirb for instance.
These are all directories found by dirb with the default wordlist. There is no login directory in here but maybe we can find something using the Burpsuite and its crawler feature.
The crawler called Spider gives us the answer. Now it's clear that the login form has to be inside the cdn-cgi/login directory. Probably dirb would find this too but we would have to set a bigger wordlist for this particular task.
I didn't found any credentials inside the source code of the page. Hidden resources also don't contain what we are looking for. Cracking the username and the password with Hydra will probably take a great amount of time and its last resort. But remember that the machines from the Starting Point lab are chained together and they belong to the same network. That being said we can try to use the credentials stolen from the Archetype machine. Those credentials for admin account are -> administrator:MEGACORP_4dm1n!!. Unfortunately, the login failed and the server redirected me to the login form again. But admin username might be right since it's shorter and used more frequently.
As you can see the correct credentials are admin:MEGACORP_4dm1n!!. Now let's investigate the tabs.
The Account service displays information about the accessed account from the application's database. Those accounts are accessed by the id parameter via GET request. The application might be vulnerable to SQL Injection and I will probably test it after checking out the cards. Keep in mind that each account has the Access ID assigned. Most likely this is a unique number and maybe we can leverage this later.
For the Branding and Clients cards situation is the same as I've just described. But the Uploads part of the web app sounds pretty interesting. It looks like we can upload files on the server under certain conditions.
To be allowed of uploading files on the server we would have to be the superadmin. It means that we are still sending some data to authenticate us to the server. This has to be done using cookies. Let's look into the Burpsuite.
Now everything is clear. We are authenticating to the server on each request with the marked cookies. Maybe if I change the role to superadmin the server will allow me to upload files?
Nope, I'm constantly logged in as admin and nothing changed. Therefore the whole authentication process is based on the user cookie and to log in as superadmin the correct account_id has to be found. Thus, let's go back to the Account tab. As you know each record of the accounts table inside the database is accessed using the id GET parameter. Let's test this parameter if it's injectable.
If we were able to control the query we would get the whole accounts table displayed now. But as you can see the id parameter isn't injectable. That being said we can use the Intruder which is a Burp built-in tool for fuzzing stuff. I'm going to set the Intruder to make one hundred requests with the id parameter set from 1-100. It will give me the first one hundred accounts from the table and I will try to find the superadmin account in the returned data. After taking this approach I should get the account_id of the superadmin and get access to the Uploads tab. The Intruder should be set like this:
Target:
We want to increment the id parameter on each request. It can be achieved with the Sniper attack type.
Payloads:
The values that are put inside the marked position by the fuzzer are taken from the file and are delimited by the new line characters. This bash command will generate such a list.
for i in `seq 1 100`; do echo $i; done > list.txt
We are using the list so the payload type should be set to Simple list.
Options:
Now when everything is set let's start the attack by clicking Start attack on the Target pane.
And the ID that is used for authentication purposes is 86575. Now we can use it as the cookie value in the request to access the Uploads tab.
Request:
Response:
Setting user cookie to the specific value gives access to the restricted area of the application. As you remember this ID leaked easily, that's why the application has a dangerous security flaw.
Foothold
The upload form allows uploading images to the server. The superadmin of the app is able to add probably photos of the new parts offered for sale by the company. Uploading an image doesn't give us much but how about throwing php shell script into the server? Let's check if there is even a small filter implemented in the upload form. I'm going to test it with the /usr/share/webshells/php/php-reverse-shell.php reverse shell which is available on Kali Linux. Keep in mind that you have to be the superadmin each time you make a request to the Uploads tab. The user cookie value should be set to 86575 before passing the request to the server.
In these circumstances, any php file can be uploaded to the server. The uploaded files should be inside the uploads directory which was discovered at the beginning with the help of dirb. But before executing the reverse shell we need to set the listener. In my case, I'm going to listen on port 443. If we are ready to accept the reverse shell connection on the attacking system we can finally execute the shell. It can be achieved with curl.
Now we are finally inside the machine. The next thing to do before looking for the user flag is to establish the shell. We want to spawn the pty which is a terminal and it can be done using Python for example.
I thought that the user flag might be inside the home directory of the www-data user but this local account is useless when we are talking about flags. Instead of searching for the text file, I was looking for the database credentials that should be hardcoded in one of the php files of the application. Inside the cdn-cgi/login directory there is db.php file which is interesting and the credentials are there most likely.
I was right. Maybe this sensitive data can be used to login into the robert local system account?
And here it is. After finding the user flag it's time for the privilege escalation phase to get the root flag.
Privilege escalation
Gathering information is crucial in every aspect of the penetration test - this is my opinion. That's why the first thing that I usually do in the privilege escalation phase is digging deeper into the logged-in user account. What groups does the user belong to? Maybe these groups have special treatment in the local system and we can leverage it to raise privileges? The id command is useful in such research.
The bugtracker group is something unusual and I'm curious why this group really exists. To discover what the group is responsible for we can search for the files that belong to the bugtracker.
There is even a bugtracker file on the system. Any information about the finding could be useful.
We are much closer to get the root flag. The bugtracker binary setuid is set which means that the file is executed within the root context and can be executed by the members of the bugtracker group. After exploiting the bugtracker process we will become root. Let's executed the file and understand what is going on.
It simply prints out information about the bugs depending on the provided ID. Let's try to break the program by typing a negative number for example. It shouldn't be any report in the database assigned to the negative ID.
It looks like the input is concatenated with the /root/reports/ directory and the program tries to display the file from the created path. We can easily get the root flag by typing ../root.txt in the input field but we can also gain access to the root shell. First I will prove to you that the first approach really works.
And now I will show you that we can create a malicious file named cat and force the program to give us a shell in the context of root instead of printing a file. This cheat can be created this way:
The malicious cat file is now a trivial bash script that only executes the /bin/sh. The malicious cat working directory has to be added to the beginning of the PATH variable in order to force the system to execute our file instead of the real cat program. Now if you execute the bugtracker binary it should give you a root shell. Obviously, you can type whatever ID you want.
To execute the system cat command you have to turn the PATH into its primary form. Then you are allowed to simply print the root flag without any obstacles.
Post exploitation
Inside the /root directory there is the .config/filezilla directory. Filezilla is the FTP client and its configuration files are created in the XML format.
The credentials to the FTP server on the 10.10.10.46 machine are hardcoded. I encourage you to save them for later use. Probably they will be useful on the next machine in the Starting Point chain.
Sum-up
That would be all in this blog post. The machine was very good and it was fun for me to pwn it. Thanks for reading. Have a nice day and happy hacking!
Comments
Post a Comment