Ntopng权限绕过漏洞(CVE-2021-28073)深度分析与实战复现
1. Ntopng权限绕过漏洞初探
第一次听说Ntopng这个工具还是在2018年做企业内网流量监控项目时。当时为了实时监控网络流量，我们测试了多款开源工具，Ntopng凭借其直观的Web界面和丰富的流量分析功能脱颖而出。没想到三年后，这个看似安全的工具竟然爆出了严重的权限绕过漏洞。
Ntopng本质上是一个网络流量分析工具，可以理解为网络流量的"显微镜"。它能实时显示哪些IP在通信、使用什么协议、传输多少数据等关键信息。管理员通过Web界面就能一目了然地掌握网络状况，这对运维人员来说简直是神器。但正是这个便利的Web接口，在4.2及之前版本存在致命缺陷。
漏洞的核心在于认证绕过，简单说就是"走后门"。正常情况下，访问Ntopng的管理接口需要先登录，就像进小区要刷卡一样。但这个漏洞让攻击者能绕过门禁，直接进入小区内部。更危险的是，结合其他漏洞还能实现远程代码执行，相当于不仅能进小区，还能撬开住户家门。
2. 漏洞原理深度解析
2.1 认证机制的设计缺陷
Ntopng的Web接口采用Lua脚本处理请求，所有请求都会经过handle_lua_request函数。这个函数有个关键处理逻辑：它会用snprintf将用户请求的URL写入到path数组中。这里就埋下了隐患的种子。
path数组的长度被固定为255字节，而snprintf会在字符串末尾自动添加\0结束符。这就导致当URL路径超过254字节时，超出的部分会被截断。聪明的攻击者可以利用这个特性，精心构造超长URL来"欺骗"系统。
2.2 路径截断的魔法
想象一下，你有一把能剪断绳子的剪刀。如果有人递给你一根很长的绳子，你只能剪下前254厘米。攻击者就是利用这个特性，在URL中塞入大量"./"（相当于在绳子上打很多结），使得真正重要的部分恰好落在254字节之后被剪掉。
具体来说，攻击者可以构造这样的URL：
/lua/../../../（重复多次）target.lua.css当这个超长URL被处理时，".css"部分会被截断，系统最终执行的却是target.lua。由于Ntopng对.css后缀的请求不做认证检查，这就实现了权限绕过。
3. 漏洞复现实战指南
3.1 环境搭建
建议使用Docker快速搭建测试环境：
docker run -p 3000:3000 -d ntop/ntopng:4.2启动后访问http://localhost:3000，默认账号密码都是admin。记得首次登录后修改密码，这是个好习惯。
3.2 手工复现步骤
- 登录后访问任意接口，比如/lua/find_prefs.lua，确认正常访问
- 退出登录，再次访问该接口，应该被重定向到登录页
- 使用PoC脚本计算基础路径长度：
python3 poc.py --url http://localhost:3000/ baselength- 假设返回长度是36，生成绕过认证的URL：
python3 poc.py --url http://localhost:3000/ generate -l 36 -p find_prefs.lua- 访问生成的URL，应该能直接看到接口返回数据
3.3 PoC脚本解析
PoC脚本的核心是get_base_length函数，它通过尝试不同长度的路径来探测系统截断点。这个过程就像用不同长度的钥匙试开锁，直到找到能打开的那把。
关键代码段：
url = base_url + '/lua/' + '%2e%2f' * i + 'as_stats.lua.css' response = session.get(url, allow_redirects=False) if response.status_code < 300: return 255 - 1 - i * 2 - len('as_stats.lua')这段代码通过不断增加"../"的数量，观察服务器响应，直到找到能绕过认证的临界点。
4. 漏洞利用与防御
4.1 潜在攻击场景
攻击者利用此漏洞可以：
- 获取网络拓扑信息
- 窃取流量统计数据
- 结合其他漏洞实现RCE
- 作为内网渗透的跳板
去年某次渗透测试中，我们就发现客户内网的Ntopng存在此漏洞，最终通过它获取到了整个网段的设备信息。
4.2 修复方案
官方修复方案很简单——升级到4.3及以上版本。但实际环境中，很多企业由于兼容性问题不敢轻易升级。对于这种情况，可以采取临时措施：
- 修改Nginx/Apache配置，限制URL最大长度：
server { ... client_max_body_size 1k; large_client_header_buffers 4 1k; ... }- 添加WAF规则，拦截包含大量"../"的请求
- 将Ntopng放在VPN后，不直接暴露在公网
5. 深入思考与经验分享
这个漏洞给我最大的启示是：边界检查永远不能马虎。开发时我们常常关注功能实现，却忽略了最基本的输入验证。就像这个案例，如果对URL长度做严格限制，或者对路径规范化处理，就能避免这个问题。
在实际测试中，我发现不同Linux发行版上路径长度计算可能有细微差异。在CentOS上复现成功的payload，到Ubuntu上可能需要微调。这也说明安全测试不能只在一个环境验证就完事。
最后给安全研究新手的建议：复现漏洞时一定要在隔离环境进行，别拿生产系统开玩笑。我见过有人为了测试把公司监控系统搞崩的惨案，那可不是写份报告就能了事的。