JumpServer堡垒机未授权访问漏洞实战：从探测到加固的攻防演练

1. 项目概述：从一次内部安全演练说起

前段时间，公司内部组织了一次红蓝对抗演练，我作为蓝队成员，负责对内部资产进行安全评估。在梳理资产清单时，发现运维团队部署了一套JumpServer堡垒机用于统一管理服务器。堡垒机作为运维安全的“看门人”，其自身的安全性至关重要。于是，我决定将其作为重点评估对象。这次评估的目标，并非恶意攻击，而是模拟攻击者视角，全面审视一个部署不当或存在未修复漏洞的JumpServer实例可能面临的风险，并最终形成加固建议。整个过程下来，我发现围绕JumpServer的“未授权访问”问题，其攻击面比想象中要广，从简单的配置错误到复杂的漏洞链利用，都有可能让这道安全防线形同虚设。今天，我就把这次“攻防实战”中梳理的思路、验证的方法以及核心的加固点，系统地分享出来，希望能帮助各位安全从业者和运维工程师更好地守护自家的“大门”。

JumpServer作为一款广受欢迎的开源堡垒机，其核心价值在于对运维操作进行审计、控制和隔离。但正因其处在核心运维通道上，一旦出现安全问题，攻击者就可能借此作为跳板，长驱直入内网核心资产。本次分享将聚焦于“未授权”这一核心突破口，详细拆解如何识别、利用由配置疏忽或已知漏洞导致的未授权访问点，并最终实现权限提升或信息窃取。无论你是负责安全评估的工程师，还是管理JumpServer的运维人员，理解这些路径都至关重要。

2. 漏洞环境搭建与核心思路解析

2.1 为什么选择Docker-Compose部署作为测试环境？

在开始漏洞验证之前，一个与生产环境尽可能相似的测试环境是必不可少的。我强烈推荐使用JumpServer官方提供的 docker-compose 部署方式搭建靶场。这主要有几个考量：首先， docker-compose 部署能一键还原一个包含核心组件（如Core、Koko、Lion等）的完整环境，避免了从源码编译或复杂配置的麻烦，能快速聚焦于安全测试本身。其次，这种部署方式与很多中小型企业的实际生产部署模式一致，发现的漏洞和利用方式更具参考价值。最后，Docker环境具有良好的隔离性，测试完成后可以轻松销毁，不会对宿主机造成影响。

搭建过程本身并不复杂，从GitHub拉取官方仓库，根据 quick_start 脚本执行即可。但这里有一个关键细节： 为了模拟真实的“不安全配置”，在部署完成后，我们需要有意地留下或制造一些常见的“安全缺口” 。例如，保持默认的弱密码、开放不必要的调试接口、或者使用存在已知漏洞的旧版本镜像。我的做法是，在 docker-compose.yml 文件中，将核心服务的镜像标签固定到一个已知存在漏洞的旧版本（如某些存在RCE漏洞的版本），而不是使用 latest 标签。这样，我们的测试环境才具有真正的验证意义。

2.2 未授权访问的攻击面梳理与探测方法论

“未授权访问”听起来简单，但在一个像JumpServer这样由多个微服务构成的复杂应用中，其表现形式多种多样。不能只盯着一个登录接口。我的方法是进行“立体化”探测，将攻击面分为几个层次：

1. Web控制台层面 ：这是最直观的入口。除了主登录页，需要检查是否有遗漏的、不需要认证的API端点或静态资源路径。例如，某些健康状况检查接口（ /api/health/ ）、版本信息接口（ /api/v1/version/ ）或Swagger文档接口（ /swagger/ ， /api/docs/ ）可能未做鉴权。
2. 组件服务层面 ：JumpServer包含多个服务。Koko（SSH/WEB终端代理）、Lion（RDP代理）等组件除了接收Core的指令外，自身是否会对外暴露管理API？这些服务的默认端口（如Koko的2222、Lion的3389）是否可以被直接访问？需要扫描这些端口的banner信息和服务响应。
3. 数据库与中间件层面 ：JumpServer依赖Redis、MySQL等。如果这些服务配置不当（如Redis绑定在0.0.0.0且无密码），攻击者可能直接绕过应用层，通过操作数据库来添加管理员用户或窃取凭据。
4. 文件与目录层面 ：Web根目录下是否存在备份文件（ .bak ， .sql ）、配置文件（ .env ， config.json ）、日志文件（ /logs/ ）等，这些文件可能被直接下载，泄露数据库连接信息、密钥或会话令牌。

基于以上思路，我通常会使用一个组合工具链进行探测： nmap 进行端口和服务发现； dirsearch 或 gobuster 进行Web路径爆破；针对发现的API端点，使用 curl 或 Postman 手动构造请求测试响应；对于Redis等服务