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等服务，使用对应的客户端工具进行连接测试。整个过程需要耐心和细心，因为真正的漏洞往往藏在不起眼的角落里。

3. 核心漏洞利用链的深度拆解

3.1 从信息泄露到权限提升：API未授权访问实战

在一次测试中，我发现目标JumpServer的 /api/v1/users/ 接口存在未授权访问漏洞。直接访问该API，竟然返回了所有用户的列表信息，包括用户名、邮箱甚至部分哈希后的密码信息（取决于版本和配置）。这本身就是一个严重的信息泄露漏洞。但攻击者不会止步于此。

获取用户列表后，我注意到返回信息中包含了用户的 id 和 role 字段。虽然不能直接修改，但结合其他漏洞，这些信息极具价值。例如，如果同时存在一个“用户密码重置”功能点的未授权访问或逻辑漏洞，攻击者就可以利用已知的用户ID，尝试为特定用户（如管理员）重置密码。更常见的一种链式利用是： 信息泄露 + 默认弱密码或密码复用 。很多运维人员可能为JumpServer管理员账户设置了与内网其他系统相同的密码。通过泄露的用户名，攻击者可以尝试进行密码喷洒攻击。

实操心得 ：测试API未授权时，不要只测试 GET 方法。一定要尝试 POST 、 PUT 、 DELETE 等方法。例如，尝试向 /api/v1/users/ 发送一个 POST 请求，模拟创建用户。即使返回403错误，其错误信息也可能透露更多关于后端验证逻辑的细节。我曾遇到一个案例， PUT /api/v1/users/{id}/ 接口对“自我信息更新”和“管理员更新他人信息”的权限校验逻辑不一致，导致低权限用户通过构造特定请求包，可以修改自己的权限组。

3.2 会话接管与RCE：Luna组件文件上传漏洞的利用

JumpServer的前端组件Luna（在较新版本中已重构）历史上曾出现过文件上传漏洞。攻击路径大致如下：首先，通过某种方式（如另一个低危漏洞或社会工程学）获取一个低权限用户的会话Cookie。然后，利用Luna组件中某个未充分校验上传文件类型和路径的接口，上传一个恶意的Webshell文件（如JSP、PHP文件，取决于部署环境）。

这个漏洞的可怕之处在于，它可能绕过堡垒机对运维操作的审计。因为攻击发生在堡垒机的Web应用层本身，上传的Webshell在堡垒机服务器上执行，从而能够直接访问堡垒机数据库、读取保存在本地的服务器私钥、或者利用堡垒机的高权限网络位置向内网其他机器发起攻击。

在复现这个漏洞时，关键点在于找到正确的上传点和对有效载荷的构造。由于JumpServer是Python（Django）应用，传统的JSP Webshell不适用。需要上传一个包含Python代码的恶意模板文件或利用Django的某些特性执行命令。例如，可以尝试上传一个伪装成正常静态文件（如CSS、JS）但内嵌恶意代码的文件，并利用路径遍历或解析特性使其被执行。

避坑指南 ：在测试文件上传漏洞时，浏览器的开发者工具（Network标签）是你的好朋友。仔细观察一个正常文件上传的HTTP请求流程：用了哪个端点（Endpoint）、Content-Type是什么、参数名是什么、服务器返回的路径是如何拼接的。然后，使用Burp Suite或类似的代理工具拦截并重放这个请求，逐步修改文件名、文件内容、Content-Type头部，尝试路径遍历（ ../../../ ），观察服务器的反应。很多时候，漏洞就藏在服务器对文件名后缀的“黑名单”校验疏漏中。

3.3 数据库直接攻击：Redis未授权访问的致命影响

这是最具威胁性的场景之一。如果JumpServer的Redis服务配置为 bind 0.0.0.0 且未设置密码（ requirepass ），那么任何能访问到该Redis端口的攻击者都可以获得一个直接的、高权限的入口。

Redis未授权访问的利用方式非常直接。通过 redis-cli -h 连接后，攻击者可以遍历所有键（ keys * ）。JumpServer会使用Redis存储多种信息，例如：

• 会话信息 ：键名可能包含 session: 前缀。攻击者可以读取这些键的值，其中可能包含序列化的用户会话对象。通过精心构造，可能反序列化这些数据或直接提取有效会话ID，实现会话劫持。
• 缓存数据 ：可能缓存了用户信息、权限数据等。
• Celery消息队列 ：如果JumpServer使用了Celery异步任务，其配置和消息也可能在Redis中。理论上，通过向特定的队列键写入恶意任务数据，可能触发远程代码执行。

更直接的一种攻击方式是，如果JumpServer使用Redis作为Django的缓存后端，并且Django配置了 SESSION_ENGINE = django.contrib.sessions.backends.cache ，那么会话就完全存储在Redis中。攻击者可以轻易地伪造一个管理员会话。

复现步骤示例 ：

1. 使用 nmap 扫描发现6379端口开放，且 redis-cli 可以无认证连接。
2. 连接后，执行 keys * 查看所有键。寻找类似 :1:django.contrib.sessions.cache 或 session:* 的键。
3. 使用 get 命令读取一个会话键的值。这个值通常是序列化的。
4. 我们需要在本地搭建一个与目标相同版本、相同SECRET_KEY的Django测试环境，通过Django的 SessionStore 类来解码和操纵这个会话数据，将自己的用户ID植入到会话中，然后再序列化写回Redis。
5. 最后，在浏览器中载入这个被篡改的会话Cookie，即可登录为目标用户。

这个过程技术要求较高，但自动化攻击工具可以简化它。这充分说明了 中间件安全配置是堡垒机安全的基石 。

4. 漏洞扫描与利用的实操流程

4.1 手工探测与工具化扫描的结合

完全依赖自动化工具会遗漏很多逻辑漏洞和深度利用点，而纯手工探测效率太低。我的策略是“工具广撒网，手工深钻探”。

第一阶段：信息收集与初步扫描

• 子域名/端口发现 ：使用 subfinder 、 amass 收集可能相关的子域名，使用 nmap -sV -p- 进行全端口扫描，识别所有JumpServer相关服务（80/443 Web， 2222 Koko, 3306 MySQL, 6379 Redis等）。
• Web目录与API探测 ：使用 dirsearch 搭配大字典，扫描Web路径。同时，使用 Arjun 或自定义的Python脚本，针对已发现的API路径（如 /api/ 下的各种端点）测试未授权访问。这里的关键是有一个好的API路径字典，可以从JumpServer源码、API文档或其他安全研究者的分享中积累。
• 框架指纹识别 ：使用 Wappalyzer 或 whatweb 识别Web框架、前端组件版本，为寻找对应版本的已知漏洞做准备。

第二阶段：深度测试与漏洞验证

• 针对识别出的可疑点 ：例如，发现 /api/v1/users/ 未授权，则手动用 curl 或浏览器访问，分析返回的JSON数据结构，思考如何利用。
• 登录框测试 ：测试默认口令（admin/admin）、暴力破解（需注意锁定策略）、密码重置逻辑漏洞。
• 接口参数测试 ：对需要认证的接口，尝试删除Cookie、Token等参数，或修改为简单值（如 Token: 1 ），观察响应。测试接口的HTTP方法混淆（GET vs POST）。
• 文件处理功能测试 ：找到任何上传、导入、下载文件的功能点，进行文件上传漏洞测试。

第三阶段：漏洞利用与权限提升

• 根据前两阶段的发现，组合利用漏洞。例如，通过未授权API泄露用户ID -> 利用密码重置逻辑漏洞修改其密码 -> 登录后寻找文件上传点获取Webshell。
• 如果获得了一个低权限Webshell，尝试在容器内进行横向移动，读取环境变量、配置文件，寻找数据库密码、其他服务的访问密钥等。

4.2 常见安全配置错误清单与自查表

很多“漏洞”其实并非代码缺陷，而是错误的部署配置导致的。以下是我总结的JumpServer常见安全配置错误清单，你可以直接用于自查：

5. 加固建议与事件响应预案

5.1 针对性的安全加固措施

基于以上漏洞利用分析，我们可以从以下几个层面进行加固：

1. 网络与访问控制层 ：

   • 最小化暴露面 ：确保只有JumpServer的Web端口（通常是80/443）对必要访问源开放。Koko、Lion、Redis、MySQL等组件的端口 绝对不应 被公网访问。使用防火墙或安全组策略严格限制。
   • 部署网络隔离 ：将JumpServer部署在一个独立的运维VPC或网段，并通过跳板机或VPN进行访问。堡垒机本身不应该能被互联网直接访问，除非有绝对必要且配备了强认证（如证书+双因素）。
   • 使用WAF ：在JumpServer前端部署Web应用防火墙，可以有效拦截一些通用的漏洞利用攻击，如路径遍历、SQL注入尝试等。

2. 应用与配置层 ：

   • 及时更新 ：密切关注JumpServer官方发布的安全更新和版本，建立及时的补丁管理流程。不要长期运行旧版本。
   • 强化认证 ：启用并强制使用双因素认证（2FA）。避免使用默认账户和弱密码。定期审查和清理僵尸账户。
   • 安全配置 ：严格按照上文的“自查表”检查每一项配置。特别是Redis和MySQL的密码与访问控制。Django的 SECRET_KEY 必须使用强随机值并通过安全方式传递。
   • 最小权限原则 ：为JumpServer的数据库账户、系统账户分配仅能满足其功能所需的最小权限。

3. 监控与审计层 ：

   • 开启详细审计 ：确保JumpServer的所有用户登录、命令操作、文件传输等日志都被完整记录，并传输到独立的日志服务器或SIEM（安全信息与事件管理）系统。
   • 部署HIDS ：在部署JumpServer的宿主机上安装基于主机的入侵检测系统，监控异常进程、文件改动和网络连接。
   • 建立基线监控 ：监控JumpServer容器的异常资源使用（CPU、内存暴增）、异常网络外连（可能为反弹Shell），以及针对未授权API端点的访问尝试。

5.2 假设被入侵：应急响应关键步骤

即使防护再严密，也需要做好最坏的打算。如果怀疑或确认JumpServer已被入侵，应立刻启动应急响应流程：

1. 立即隔离 ：在不影响核心业务的前提下，最快速度将JumpServer从网络中断开（拔网线或修改安全组），防止攻击者持续利用或向内网横向移动。如果无法立即下线，则通过防火墙封锁所有对JumpServer的入站和出站连接，仅保留应急管理通道。
2. 保护现场 ：在采取任何修复动作之前，先进行取证。对JumpServer所在的虚拟机或容器制作完整的内存镜像和磁盘快照。备份所有日志文件（JumpServer审计日志、系统日志、容器日志、数据库日志）。这些是后续分析攻击路径、定位失陷范围和追责的关键证据。
3. 初步分析 ：
   • 检查用户与日志 ：立即审查最近一段时间内的所有登录记录（尤其是非工作时间、异常IP的登录）、特权命令执行记录。对比现有用户列表与备份中的列表，查找新增的、可疑的管理员账户。
   • 检查进程与连接 ：在宿主机上使用 netstat -antp 、 ps auxf 等命令查看异常进程和网络连接。
   • 检查文件系统 ：查找近期被修改的Web文件（如.php, .jsp, .py等）、在Web目录下新增的可疑文件、以及计划任务（crontab）、启动项等持久化位置。
4. 清除与恢复 ：
   • 如果发现Webshell等后门文件，记录其路径、哈希值和创建时间后，立即删除。
   • 重置所有用户密码（尤其是管理员），并强制下次登录时修改。
   • 重置所有SSH密钥对、API令牌等凭据。
   • 审查并回滚任何被篡改的系统或数据库配置。
5. 根源修复与重建 ：
   • 根据取证分析结果，定位导致入侵的根本原因（是未修复的漏洞、弱密码还是错误配置）。
   • 修复该根本原因。 强烈建议不要直接在已被入侵的环境上修复，因为可能存在难以发现的隐藏后门。
   • 最佳实践是从头开始，在一个干净的环境中，使用最新的安全版本和强化的安全配置，重新部署一套全新的JumpServer。 然后将原有数据库中的审计日志等必要数据（经过严格审查后）迁移至新系统。
   • 在新系统上线前，完成全面的渗透测试和安全评估。
6. 复盘与改进 ：召开复盘会议，更新安全配置基线，完善监控告警规则（例如，针对未授权API访问的告警），并加强相关人员的安全培训。

安全是一个持续的过程，堡垒机作为关键资产，更需要我们以“攻击者”的视角去审视和守护。通过常态化的安全评估、严格的配置管理和完善的应急准备，才能确保这道最后的运维防线坚不可摧。