Drive - Hack The Box
The Drive machine is a hard Linux system that needs reverse engineering, and performing a SQL injection on a binary.
Web Enumeration
The website is a platform similar to Google Drive, where it is possible to register and upload files.
The files are obtained by a request to /id/getFileDetail/. To enumerate possible files, it is possible to use Burpsuite in Intruder mode by parameterising the id of the file. In this way, depending on the server response (Not Found vs. Unauthorised), it is possible to identify files of other users.
One of the ids found is 79. When entering drive.htb/79/, you get a Not Found message.
Blocking Functionality
The platform has a file “reservation” system, which allows to make files accessible to external users. Below we try to reserve a sample file to see how the web page behaves.
The file is successfully backed up.
Using this file as an example, the /id/block path is discovered which allows access to a reserved file. Thus, via the path /79/block/ one of the previously found files can be accessed.
This file contains a message to the development team with the credentials of “martin”.
These credentials give SSH access with the user martin.
After enumerating the system, in var/www/backups there are a number of backups encrypted in .7z, as well as a db.sqlite3 database.
With a server up with python3 -m http.server 8000, the database is downloaded to our system.
With sqlite3 we load the database and find a series of hashes.
Using hashid, we find the mode of the hash.
However, I was unable to crack these hashes, so I continued to enumerate the machine. It was probably a rabbit hole.
In the /usr/local/bin directory is a gitea binary for which you have execute permissions.
When running it, an error appears as the gitea server is already running, probably because another user already launched it.
Gitea
Gitea is accessed by port forwarding with the command ssh martin@10.10.11.235 -L 3000:drive.htb:3000.
This way, in localhost:3000 we find the Gitea platform.
Listing the platform, we find the users. One of them corresponds to the user martin, for which we have the SSH credentials.
With the SSH password of martin and the user martinCruz we get access. We found a repository of the DoodleGrive platform.
In the repository, there is a db_backup.sh file containing the credential that encrypts the backups we found earlier.
We then reuse the open http server with python to download these backups.
And unzip with the password found.
Each backup contains a database with different passwords each time, for a number of users. One of them, the most recent, has the credentials hashed with PBKDF2, so we ignore them for now.
The others use SHA1.
I gathered all the hashes and started a brute force attack with hashcat -m 124 -a 0 -O hashes.txt rockyou.txt.
Three similar passwords are found with this attack.
Trying SSH with the other user on the system, tom, all three credentials, we find that johnmayer7 works and we get access.
Privilege escalation
A README.txt message is found in the system indicating the development of a new project, “DoodleGrive self hosted”, a CLI tool that is still under development.
We transfer the binary to our system and check that when we run it, it asks for some credentials.
I used ghidra to scan the binary for any clues.
So, with the binary decompiled, in main are the credentials that the binary checks for when it asks the user for them.
When you use them and check that they work, you get six options related to accounts and the server.
One of them, number 5, attempts to activate the account of a given user. This allows it to receive a username and performs an action on a supposed database.
Digging into the binary, we find the query that the binary uses to perform this action.
You can see that the given user is a parameter of this query that updates the database, which leads us to think that a SQL injection can be performed in the database through the binary from the original system.
The query is /usr/bin/sqlite3 /var/www/DoodleGrive/db.sqlite3 -line 'UPDATE accounts_customuser SET is_active=1 WHERE username="%s";'.
To execute a Remote Code Execution (RCE) attack, the load_extension() function of SQLite3 is used.
The binary escapes certain characters, so the char() function must be used to send the compiled text to be executed in ASCII.
The payload will be +load_extension(char(46,47,122))+ where 46 is “.”, 47 is “/” and 122 is “z”, so you can execute “./z”.
The z.c file contains the code that will copy the flag, although you can also run a command to create a reverse shell.
We then run the payload.
And we can check that the flag appears in the intended path, /tmp/ab.txt.
With this we finish the Drive machine, very complete and complex at the same time.
