Week 3. Drive
TL;DR
This is an Ubuntu 20.04 host running a custom web app called doodleGrive which is used to share and edit files. A clear text password is uploaded into the tool which can be used to get an initial foothold. An internal Gitea server, used for config control, also contains clear text password which allows accessing database backups. For privilege escalation, reversing in a local binary and SQLite injection are needed. To get code execution, the SQLite load_extensions() function is used.
KEYWORDS
Gitea, port forwarding, reversing, Ghidra, C, SQLite injection.
REFERENCES
https://hashcat.net/wiki/doku.php?id=example_hashes
https://www.sqlite.org/loadext.html
https://www.w3resource.com/sqlite/core-functions-char.php
https://www.sqlite.org/loadext.html
ENUMERATION
Port scan.
Enumerate the open ports
Enumerate the site with Firefox. Register a new account, and spend some time understanding what its functionality is. You can upload files, reserve them, edit them, assign to teams, etc. Note that when a file is uploaded, a 3-digit folder is created (e.g. http://drive.htb/122/getFileDetail).
Also note that when reserving a file, the same 3-digit folder is used (e.g. http://drive.htb/122/block).
Let's list all blocked files fuzzing the 3-digit field. For this, first capture a block file request with Burpsuite, then right-click + copy and paste in a file called request.txt
In bash, edit the request.txt file to prepare it for ffuf. Edit with vim the 3-digit field we want to fuzz and save the field as request.txt
Prepare a wordlist with 200 items and launch ffuf using the request.txt file. Several documents are found.
Just browse the sites to find credentials for user martin: Xk4@KjyrYv8t194L!
Also, info related to the database is disclosed. Apparently, there is a scheduled daily backup plan where database is compressed and copied to /var/www/backups/. Backup will be protected with strong password.
Finally, enumerating the site we can also find a list of potential usernames (creating a group and then clicking on edit group).
We will use this user list later.
USER
Just use Martin's credentials to AAH in. First task is to enumerate system users. We see root is uid=0, git is uid=115, martin is uid=1001, cris is uid=1002 and tom is uid=1003
Scanning processes with pspy64, we find a Gitea web server running under the context of user git uid=115. This service was not discovered with nmap, so maybe it is an internal service.
In fact the web server is running internally on port 3000.
Let's forward port 3000 to our machine.
Now we can browse the Gitea server on http://localhost:3000, where martin's credentials are accepted. For this tool martin's username is martinCruz, as we found out previously.
In the DoodleGrive repository there is the database encryption script db_backup.sh, and the key they used to compress the 7z files. The password is H@ckThisP@ssW0rDIfY0uC@n:)
To unzip the files, first copy the files to Kali using scp, then unzip using the password.
Connect to the databases extracted using the sqlite3 command, and once inside the database, find a table called accounts_customuser. Dump the table to get some Django SHA-1 hashes.
To crack these hashes use Hashcat module 124.
Testing the cracked passwords, we find out the credentials working for the user tom are tom:johnmayer7. Login using SSH and get the user flag.
SYSTEM
Enumerate the system.
Inside Tom's home folder, there is a binary called doodleGrive-cli with SUID permissions. It seems it needs credentials to execute.
In order to get to know how the binary works, the best is to reverse engineer the binary with Ghidra. Open the application, add the binaries and let the tool analyze the source code. Turns out the application is written in C, and inspecting the main() function we find out the credentials to run the binary are hardcoded in the source code.
The credentials to run the binary are moriarty:findMeIfY0uC@nMr.Holmz!
Navigating to the main_menu() function we find the calls to the functions presented in the menu. The most interesting is the function called activate_user_account()
Navigating to the function activate_user_account() we find out several interesting things. First, we discover the app only reads the first 40 (0x28) characters from user's input. Secondly, application sanitizes the user input (function sanitize_string()). Finally, we can see the SQLite SQL request used to update the database with the user's input.
The %s represents the user's input parameter, note that the backslashes \ are just to escape the quotes. So in theory we could inject a SQL statement as long as starts with quotes and finishes with comment dashes.
But first we have to inspect the sanitization function to check what we can enter and what not.
We see the function removes several characters and replaces them with a null character \0. The forbidden characters include \/{|' along with spaces and null chars. Good news are dashes and quotes are not filtered.
The next goal is to investigate how to gain command execution using SQLite statements. This can be done using load_extensions() functions. Basically, this feature allows to load C code compiled as a .so shared library. In the link https://www.sqlite.org/loadext.html you can find instructions to compile the source code.
First step is to generate a C payload load extension called le.c
Next, compile following SQLite documentation.
Now we have to create an SQL injection to load the extension but keeping in mind the 40-char limitation and the forbidden characters. The final payload could be something like this.
However, this won't work because it contains forbidden chars. This can be bypassed using the sqlite3 function char() which translates characters from ASCII code (https://www.w3resource.com/sqlite/core-functions-char.php).
After doing some tests with an ASCII table and wc -c to fine tune the payload, we find a workable injection.
Final steps are injecting the payload in the tool.
And checking that everything went well.
You are root.
Last updated
