Spring Actuator 暴露在攻防中的利用

Spring Actuator

暴露在攻防中的利用

Spring Boot Actuator简介

Spring Boot Actuator 是 Spring Boot 生态系统中的一个强大模块，用于提供生产环境中的应用监控、管理和诊断能力。它通过一系列预定义的端点暴露与应用程序运行状态相关的信息，包括健康检查、环境属性、应用配置、线程池状态、内存使用情况等。

Actuator 专为方便运维、开发、测试人员设计，因此在微服务架构和分布式系统中起到了非常重要的作用。它支持多种协议和接口（如 HTTP、JMX），允许用户轻松集成到监控系统（如 Spring Boot Admin、Prometheus 等）。

然而，其强大的功能在带来便利的同时，也埋下了潜在的安全隐患。如果某些关键 Actuator 端点（如 /heapdump、/gateway、/logfile）未被妥善保护，可能导致敏感信息被泄露、漏洞利用等，给系统安全带来重大威胁。

Actuator 默认提供了以下一些端点（注意：并非所有端点在默认情况下都启用）：

如何识别

在实战过程中首要的是识别后端是否是Java spring构建的服务，比较明显的一个特征是在访问不存在的页面会返回默认的错误页如下图：

如果没有WAF，也可以直接使用目录扫描工具进行探测，如开源的dirsearch，下述链接指向了该工具默认字典中actuator的部分：https://github.com/maurosoria/dirsearch/blob/46f57e51f6c36e8c5043a9ccc60d0e1b0f844ca4/db/dicc.txt#L2086。

这里需要注意的是，常见如下两种情况会导致无法直接通过系统前台域名发现actuator：

1、很多现代spring应用采用前后端分离的设计，后端可能有独立的域名或者全局path设置

例如，下面的application.yml配置使得后端api在统一添加了/api的prefix

server:    servlet:        context-path: /api

应对方法，通过JS分析或抓包（例如登录、验证码等permitAll权限接口）即可得到正确的后端地址。

2、大型的spring部署常用gateway功能，不同的业务模块分别运行，每个业务有独立的域名或path，每个业务是否启用actuator以及暴露的endpoint也不尽相同。

这种情况下，需要分析js或者扫描根目录很有可能存在actuator/gateway/routes接口，应遍历拼接全部后端模块的地址并逐一测试actuator是否暴露。

利用方法

heapdump和env是两个最常见的actuator信息泄露的利用接口。前者是app的内存转储，包含了如数据库连接凭据、HTTP会话缓存、jwt secret、api key、ftp password、oss ak/sk等敏感信息的明文。

heapdump读取和分析使用工具Eclipse Memory Analyzer (MAT)，官方下载地址为https://eclipse.dev/mat/。

在GitHub亦有一些开源脚本可自动化利用和批量分析，但本文介绍原理且出于数据安全考虑，这些脚本不做介绍。

heapdump由于可读性比较差，一般配合env接口一起分析，env接口返回全部环境变量但会将带有password、secret等常见的敏感字段值替换为掩码******。

实践中反而可以直接全文搜6个星号快速找到敏感信息，或搜索常见的”datasource"、"password"等关键字，然后在heapdump搜索对应的键名。

如下图，打开转储后使用（1）进行OQL搜索，语句中（2）位置填入上文得到的感兴趣的关键词，按（3）执行后逐一展开查看结果，（4）即为对应的值。

select * from java.util.LinkedHashMap$Entry x WHERE (toString(x.key).contains("password"))

除了获取环境变量和配置信息，还可以抓取HTTP请求cache用于进一步获取应用系统的权限。比如，在认证模块可以抓到用户密码、集成模块可以抓到api key、一般业务模块可以抓到session token。

但是由于Java的垃圾清理，缓存并不会保持很久，此方法需要在业务访问比较频繁的时机进行heapdump才有显著效果，否则可能找到的cache只要自身请求heapdump接口的一条，没有价值。

可通过如下OQL搜索，使用如"cookie"、"HTTP/1.1"等关键词搜索。

SELECT toString(s) FROM byte[] s WHERE toString(s).contains("keyword")

某些案例中还会暴露logfile端点，可能存在由于开发人员安全意识不足导致的敏感信息记入日志，例如：

·完整HTTP body数据导致可获取用户登陆密码

·构造畸形请求触发backtrace包含一些拼接的应用连接敏感信息

·其他敏感信息便于攻击者分析程序行为

此方法主要用于前者信息泄露的补充，以及需要进一步分析业务系统逻辑深挖时的调试手段。

三年前的RCE但是相当好用，只要有如下版本且未修补的spring cloud gateway即可getshell。

·Spring Cloud Gateway

（1）3.1.0

（2）3.0.0 to 3.0.6

（3）Older, unsupported versions are also affected

POC可以参考：https://github.com/crowsec-edtech/CVE-2022-22947

利用方法和原理在网络上很多相关文章，本文不再赘述。在此分享一个攻防中遇到的挑战和解法：

1、复杂的命令用上面的POC可能无法成功执行，建议进行额外的编码保证特殊符号和空格不会被意外的截断，参考处理代码如下：

command = "bash -c {echo," + str(base64.b64encode(command.encode('utf-8')),'utf8') + "}|{base64,-d}|{bash,-i}"

2、有些业务使用负载均衡，由于poc需要发出多个请求，多个请求可能被分发到不同的后端服务，导致误判为漏洞不存在。比较明显的特征是/gateway/routes返回的内容存在差异且有周期性变化。遇到这种建议手动发送每个请求，确保一个连贯poc动作中的全部请求在同一个后端服务中得到执行；

3、还有的业务部署在docker，拿到的shell是容器内的shell，无法执行常见Linux命令，可以先判断环境再设计后利用的姿势。

后利用

实战中，很多actuator问题存在于测试或者开发站点，而非正式环境。不过可以尝试如下方法进行横向：

1、收集密码本，很多开发环境的凭据复用于生产环境，可以撞库；

2、nacos配置（如有）横向，开发人员可能并没有给nacos设置合理的权限，公用账号导致测试系统亦可拿到生产环境的配置；

3、数据库、OSS（如有）横向，A应用测试环境的数据和B应用生产环境数据位于相同的实例，且未作合理的用户权限限制；

4、FTP/SFTP（如有）横向，很多自建FTP业务使用Linux自身用户体系，FTP用户除了可以通过FTP协议访问文件以外还有shell权限，可用作网络跳板；

5、用户HTTP请求中包含host限制不严格的cookie，可通过这些cookie获取其他应用系统权限；

6、根据实际情况和业务复杂度，可玩性还是很大的，可以分析程序逻辑仔细挖掘……

防御和修复

1、最小化暴露的端点：

（1）默认只暴露必要的 Actuator 端点，例如 health；

（2）可以通过以下配置限制端点：management.endpoints.jmx.exposure.include=health,info。

2、实施访问控制：

（1）使用 Spring Security 为敏感端点 (如 heapdump、env 等) 添加认证；

（2）配置基于权限的访问策略。

3、网络层的防护：

（1）确保 Actuator 端点仅在内部网络中可访问，避免在公网直接暴露这些端点；

（2）添加防火墙和反向代理限制。

4、审查和更新：

（1）经常审查暴露的端点内容，避免过度暴露敏感信息；

（2）定期更新 Spring Boot 和相关依赖到最新版本以获得安全补丁。

● 联想全球安全实验室 “放大招”：让AI换脸诈骗无处遁形！

● 客户端来源IP伪造攻击与防护指南

● 首站补天白帽黑客城市沙龙圆满收官，全球安全实验室（中国）赋能AI安全新征程

● 物联网安全之漏洞利用三部曲（模拟仿真、逆向分析及ROP利用）

● CPU微码安全杂谈

● 大模型投毒事件之Pickle反序列化漏洞及防御

● Java安全之CC4链分析

● 联想全球安全实验室热招安全领域精英，欢迎志同道合的小伙伴加入!（联系方式见图文末）

● LLM应用安全风险演进：OWASP LLM应用Top10风险2023版与2025版对比分析

● 驭势AI，聚力奋进!