Snoopy
Gaining Access
Nmap scan:
$ nmap -p- --min-rate 5000 10.129.85.193
Starting Nmap 7.93 ( https://nmap.org ) at 2023-05-09 05:05 EDT
Warning: 10.129.85.193 giving up on port because retransmission cap hit (10).
Nmap scan report for 10.129.85.193
Host is up (0.16s latency).
Not shown: 65305 closed tcp ports (conn-refused), 227 filtered tcp ports (no-response)
PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain
80/tcp open httpWe can add snoopy.htb to our /etc/hosts file as per standard HTB practice.
DNS and HTTP Enumeration
This was a corporate page that provides DevSecOps services:
Looking around, there's another subdomain present in the form of a mail server.
It syas that the DNS records are being migrated to another domain and that their email server is offline. We can run both a gobuster directory and wfuzz subdomain scan first. The subdomain scan reveals a mm subdomain present.
Interesting. Since DNS is open, and there is already a hint for DNS being in play somehow, we can enumerate that using dig.
It seems that mm stands for MatterMost. There's another provisions and postgres subdomain that is present on the local network within the machine, which I probably need to enumerate after gaining a foothold. It appears that snoopy.htb and mm.snoopy.htb are on the same IP address, while the others are not, meaning that we cannot access the others yet probably.
The last thing is that mail.snoopy.htb is not present within the records and is indeed offline.
We can visit the mm subdomain to verify that it is running:
We don't have any credentials, but there is a Password Reset in use here that requires an email address:
Lastly, there are some emails present:
Download LFI -> DNS Vuln
On the main page, there is an option to download files. When we click that, this HTTP request is sent:
The announcement.pdf file had nothing interesting itself, but this looks vulnerable to LFI. Inital testing reveals this isn't vulnerable at first:
After using ....// instead, we can see that a file is generated:
When the file is downloaded and viewed, we see that it works!
These were the most interesting users, and there was a clamav and bind user, which was something I don't usually find. This means that these softwares must be downloaded on the machine. Anyways, the process for LFI is quite long and slow, so to quickly enumerate the machine, I made a quick Python script to do so:
This made enumeration a lot easier. Now, we can proceed with enumeration of the file system and other sensitive files. We can start with /etc/nginx/sites-available/default.
There's nothing much here. Earlier we found that bind was running on the server. bind is a nameserver program that assigns the domain names to IP addresses. In this case, since the mail server is offline as DNS records are being migrated, we might be able to exploit this by making the machine resolve mail.snoopy.htb to our machine and then using it to reset passwords on MatterMost.
Quick googling reveals that the /etc/bind/named.conf folder contains the configuration for it.
This contains a secret of some sort, and it is clear that updating the DNS records to point to our machine is the exploit here. A bit of Googling about how to update DNS records led me to the nsupdate documentation page:
We can use the entire key "rndc-key" part as the key file specified using -k. Then, we can run the following commands to update the records AND set up a SMTP server:
Now we need to find a user who exists on the MatterMost software. After some testing, it seems that sbrown@snoopy.htb works based on the emails we found, because sending a password reset using that email works!
The token has some weird signs in the middle of it, which is not normal actually. Although the link is valid, the token is not. In the above's case, we can ignore all the = and 3D parts, so the correct link is:
Afterwards, we can reset the password and see that it works here:
Then we can login.
MatterMost -> SSH MITM
When we login, we can see a ton of chat logs:
It talks about ClamAV being used as the anti-virus, and also about some provisioning server. We can view the different commands present on this:
There was a weird command /server_provision without any description. When run, it opens up a UI that seems to spawn a server:
We can fill it in to have our credentials and required details. It appears that Windows is disabled too:
Anyways, after filling in the fields and clicking submit, we get this weird thing on a listener port:
I thought that it would be a shell and hence ran id, but it quickly closed. In this case, I took a look at the traffic within wireshark but wasn't able to find out much. I tried out a few methods from the SSH page of Hacktricks, and found ssh-mitm.
This was a program that would intercept SSH traffic and find a password, similar to what responder does.
I couldn't get the ssh-mitm binary to work properly, but thankfully there's a Python module for it. We can run it, then we can view the logs:
We have a credential! With this, we can ssh in as the user cbrown:
Privilege Escalation
No user flag yet.
Sudo Git Apply -> User
Checking our sudo privileges, we see this:
We can run commands as sbrown using git apply *. This means using a diff output, we can use this to overwrite any file that sbrown owns. In this case, we can put our public SSH key within the .ssh/authorized_keys folder.
Then, we can use diff on a random folder and this folder. We can use the .bash_history file of cbrown because it has nothing within it:
Then, we can redirect the above to another file like /tmp/diff. Afterwards, we need to change the target file (the one below) to sbrown/.ssh/authorized_keys in order to write the key within it.
Here's the final diff file I used:
Afterwards, just run the sudo command on the /tmp/diff file. This would put our public key within the sbrown directory since we are running the command as sbrown. Then, we can ssh in.
Grab the user flag.
Sudo Clamscan -> Root
When checking sudo privileges again, I found that we can run clamscan as root.
clamscan is a scanner that checks for malware and other things within binaries:
Based on the documentation, since we can run this as root, we should be able to read files like /etc/shadow. This can be done using the -f flag and it works as shown:
Then, we can simply read the private SSH key of root located at /root/.ssh/id_rsa.
After some tidying up, we can ssh in as root.
Rooted!
Last updated