Drive

Gaining Access

Nmap scan:

$ nmap -p- --min-rate 3000 10.129.51.107           
Starting Nmap 7.93 ( https://nmap.org ) at 2023-10-18 01:24 +08
Nmap scan report for 10.129.51.107
Host is up (0.0072s latency).
Not shown: 65532 closed tcp ports (conn-refused)
PORT     STATE    SERVICE
22/tcp   open     ssh
80/tcp   open     http
3000/tcp filtered ppp

Did a detailed scan as well:

$ nmap -p 80,3000 -sC -sV --min-rate 3000 10.129.51.107 
Starting Nmap 7.93 ( https://nmap.org ) at 2023-10-18 01:25 +08
Nmap scan report for 10.129.51.107
Host is up (0.0071s latency).

PORT     STATE    SERVICE VERSION
80/tcp   open     http    nginx 1.18.0 (Ubuntu)
|_http-server-header: nginx/1.18.0 (Ubuntu)
|_http-title: Did not follow redirect to http://drive.htb/
3000/tcp filtered ppp
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

I added that domain to the /etc/hosts file.

Web Enumeration -> User Password

The website advertised an online file management system called 'Doodle Drive'.

When I registered a new user and logged in, there was a dashboard and upload file functions available:

Viewing the dashboard shows a file left by the admin user:

When the file is viewed, the URL changes and there's a hint to use the 'Contact Us' feature.

The first thing I noticed was that this particular file used an ID of 100. Perhaps there are other files for other users on the machine with different IDs. To test this, I used wfuzz with the various directories.

Out of all of these, only block and update worked. block redirected me back to the same page.

I noticed that there were quite a few directories for this group. Next, I wanted to check what other numbers were present. I first generated a word list using a simple for loop, then fed it to wfuzz. Found that using /FUZZ/block worked in detecting a few new files:

I checked 79 first, and found another file:

Using this password, I could ssh in as martin:

Privilege Escalation

Gitea -> DB -> Tom Password

Now I can start enumerating the machine. Firstly, there are some files within the /var/www/ directory worth taking a look at:

There are also a few other users on this machine:

There are also some local ports listening:

Earlier we saw that port 3000 was filtered, so I used chisel to forward that first.

Visiting port 3000 reveals a Gitea instance:

There are some users, and martin is part of them again:

I could login with the same password of Xk4@KjyrYv8t194L! from earlier. Afterwards, I was able to view the repositories from the other user cris.

The db_backup.sh file was the most interesting, and it contained a password:

Seems that I have to grab all the backups and unzip them to find a password of some sorts. I transferred all the backups to my machine using scp, and extracted them using 7z. Afterwards, I used sqlite3 to enumerate the stuff within:

Seems that there are some users and what not. Within the accounts_customuser table, there are some hashes:

The weird thing is that all the different archive files have different hashes in the same table.

I first tried to crack the sha1 hashes. A but of googling reveals that this uses hashcat -m 124, so I could crack some of them:

Using johnmayer7 allows us to su to tom.

Format String Vulnerability -> Stack Canary (unused)

The next part of this machine was glaringly obvious.

Some reverse engineering or pwn challenge is up next. First, I transferred this binary back to my machine via nc.

I ran a checksec first to see what protections this thing had:

There's a stack canary, but oddly there's no ASLR enabled. Testing it with a huge input shows an error:

Also, the binary prints out whatever username we give it, and I tested for format string vulnerabilities that would allow me to read the stack canary.

It worked! Using this, I can slowly read each byte of data.

LogoPage not found - HackTricksbook.hacktricks.xyz

The stack canary for Linux machines always ends with a null byte, so I first found out where was it along the stack. After some testing, it appears using %15$p prints out the stack canary consistently.

Ghidra -> SQL Injection

I took a pause here and used ghidra to disassemble the main function.

Firstly, I found the right username and password. The main_menu() function contains other options to be used:

Out of all of them, option 5 was the most interesting as it took user input and passed it to a command:

It might be possible to do SQL Injection from here, which makes sense as an intended method since the creator literally gave us the correct username and password to use, so it's likely that pwn is an unintended method.

I did some initial SQL Injection tests, and confirmed that it was possible due to syntax errors that were happening.

Now, I just needed to figure out what to do with the injection. There was one method on PayloadAllTheThings that showed using load_extension would execute a .dll file for Windows or .so file for Linux.

Now by default, this option is disabled, but for this machine it was enabled:

This means that we should be able to load whatever .so files we want. Using this, we can generate a .so reverse shell using msfvenom:

Then, download this to the machine in the same directory as the binary. After some testing with the syntax, I was able to make the binary accept an argument from me:

Spaces and + characters cannot be used in the above, so I used char to type out the name of the .so file. The load_extension function needs to take in ./a as the input:

This would spawn a reverse shell as root:

Rooted!

PreviousDevvortexNextHospital

Last updated