
1. 项目概述从监控页面到内网沦陷最近在内部安全评估和外部渗透测试项目中Druid监控页面的未授权访问漏洞CVE-2021-36749等出现的频率依然不低。很多开发团队在部署Spring Boot应用时为了方便运维会默认开启Druid的数据源监控功能但却忽略了访问控制直接将/druid/index.html这样的管理接口暴露在了公网。攻击者无需任何认证就能看到一个包含数据源状态、SQL监控、Web应用统计等敏感信息的控制台。这听起来似乎只是个信息泄露危害有限如果你也这么想那就大错特错了。这个“入口”的价值远比想象中要大。它不仅仅是窥探数据的窗口更可能成为攻击者打入内网、获取服务器权限、甚至拖走整个数据库的跳板。今天我就结合多个实战案例深入聊聊Druid未授权漏洞被忽略的那些“进一步利用”手法以及作为防御方我们到底该怎么彻底堵上这个口子。2. 漏洞原理与基础信息泄露2.1 Druid监控控制台的核心功能与风险点Druid是阿里巴巴开源的一款优秀的数据库连接池和监控组件。它的监控控制台提供了非常丰富的功能主要包括数据源监控展示所有配置的数据源如MySQL、Oracle连接池的实时状态包括活跃连接数、等待连接数、执行次数等。SQL监控记录并展示所有执行过的SQL语句、执行时间、影响行数等并且可以按照执行耗时排序。Web应用监控统计HTTP请求的URI、请求次数、并发数、请求时间等。Session监控如果启用可以查看当前Web应用的所有Session信息。JSON API控制台的功能背后是一系列提供JSON格式数据的API接口例如/druid/weburi.json用于获取URI监控数据。漏洞的根源在于这些功能强大的监控页面和API接口在默认配置或常见的不安全配置下缺乏有效的身份验证和授权机制。开发人员可能只在application.properties中简单配置了spring.datasource.druid.stat-view-servlet.enabledtrue和spring.datasource.druid.stat-view-servlet.url-pattern/druid/*却没有设置loginUsername和loginPassword或者虽然设置了密码但未配置允许访问的IPallow或拒绝访问的IPdeny导致控制台对全网开放。注意这里有一个常见的误区。很多人认为只要不把/druid路径映射出去就安全了。但在Spring Boot的默认约定下如果没有额外的安全框架如Spring Security拦截一旦你开启了StatViewServlet它就会对外提供服务。另一个误区是依赖网络层的防火墙认为应用部署在内网就没事。但在云原生和容器化环境下服务边界模糊内网应用也可能通过负载均衡器或API网关意外暴露。2.2 初始信息收集漏洞利用的第一步当攻击者发现一个未授权的Druid控制台例如http://target.com/druid/index.html时他的第一件事就是进行全方位的信息收集这远不止看看页面那么简单。数据源信息在“数据源”标签页攻击者可以直接看到数据库的连接池配置。虽然密码通常以星号显示但这里会暴露JDBC连接字符串。例如jdbc:mysql://192.168.1.100:3306/erp_db?useUnicodetrue。这立刻泄露了内网数据库服务器的IP地址192.168.1.100和端口3306。数据库名称erp_db这有助于后续针对性的攻击。数据库类型MySQL决定了后续的攻击工具和Payload。SQL监控信息这是真正的“富矿”。攻击者会查看“SQL监控”页并按“执行时间”降序排列。耗时最长的SQL往往是业务核心查询直接反映了应用的关键功能和数据结构。攻击者可以从中分析出数据库表名和字段名例如SELECT * FROM user WHERE username ?暴露了user表。业务逻辑频繁出现的带有特定WHERE条件的SQL揭示了业务规则如状态检查、权限验证。潜在的SQL注入点如果看到SQL语句中直接拼接了变量尽管Druid监控显示的是带占位符的格式但某些配置或历史记录可能暴露原始语句这给了攻击者明确的测试方向。Web应用与Session监控URI监控展示了所有被访问的URL路径。攻击者可以借此发现未在公开文档中记载的管理接口、API端点例如/admin/export,/api/v1/internal/upload扩大攻击面。Session监控如果启用可能直接列出当前活跃会话的Session ID。在某些场景下攻击者可能尝试使用这些Session ID进行会话劫持。实操心得在一次红队演练中我们正是通过SQL监控里发现的一条SELECT * FROM sys_config语句判断出目标使用了某款特定的开源管理系统进而利用其已知的Nday漏洞拿下了服务器。信息泄露的价值在于“串联”单个点可能无害但多个点结合就能勾勒出完整的攻击路径。3. 漏洞的深度利用与横向移动基础信息收集之后攻击便进入了实质性的“利用”阶段。Druid控制台本身可能不直接提供执行代码的能力但它提供的跳板和信息足以让攻击者打开局面。3.1 利用JSON API进行自动化信息提取Druid的控制台数据是通过后台JSON API获取的。攻击者不会满足于手动点击页面而是会编写脚本自动化抓取所有API数据构建更全面的信息地图。常用的API端点包括/druid/sql.json获取SQL统计。/druid/weburi.json获取URI统计。/druid/websession.json获取Session统计。/druid/datasource.json获取数据源详情。通过脚本循环抓取这些接口攻击者可以在短时间内收集大量历史SQL语句和请求数据用于离线分析寻找规律和弱点。3.2 作为跳板攻击内网数据库这是最常见也是最危险的利用方式。通过Druid控制台获取的内网数据库IP、端口和库名攻击者如果已经通过其他方式如SSRF漏洞、钓鱼邮件导致的内网终端失陷进入了目标网络或者该数据库错误地配置了公网访问他就可以直接进行连接尝试。弱口令爆破利用泄露的数据库类型和实例名攻击者会使用常见用户名密码字典如root/root, admin/admin123, 与应用名相关的密码等进行爆破。漏洞利用针对特定数据库版本的已知漏洞进行攻击。例如MySQL的CVE-2012-2122身份认证绕过漏洞或Redis未授权访问漏洞。数据窃取与篡改一旦连接成功整个业务数据库就暴露了。可以拖取用户表、订单表等敏感数据甚至可以篡改数据如修改管理员密码、增加余额造成直接业务损失。案例分享在某次应急响应中攻击者先是通过Druid未授权访问找到了一个内网Redis的地址。该Redis同样未设密码。攻击者通过Redis写入SSH公钥成功获取了服务器权限。整个攻击链的起点就是那个不起眼的Druid监控页面。3.3 与其它漏洞形成组合拳Druid未授权访问很少单独造成毁灭性影响但它是一个绝佳的“放大器”和“指示器”。配合SSRF服务器端请求伪造如果应用中存在SSRF漏洞攻击者可以诱使服务器向Druid泄露出的内网地址如数据库、Redis发起请求。由于请求来自内部可信网络很可能绕过防火墙策略直接攻击这些内网服务。定位Swagger等其他管理接口在URI监控中经常能看到/v2/api-docs、/swagger-ui.html这类路径。这提示应用可能同时存在Swagger未授权访问漏洞。攻击者可以转向Swagger界面那里可能直接提供了可交互的API文档甚至允许在线调用接口危害更大。识别框架与组件寻找Nday通过分析SQL语句、URI路径和请求特征攻击者可以推断出后端使用的框架如Jeecg、若依、Spring Cloud等。结合热词中提到的“jeecg 未授权用户注册漏洞”如果识别出是Jeecg框架攻击者就会直接尝试对应的已知漏洞进行利用。重要提示很多开发者在修复时只关注了“未授权”本身比如给Druid加了密码。但如果密码强度弱如admin/admin或者登录接口没有防爆破机制攻击者依然可以暴力破解。更糟糕的是如果应用其他地方如Swagger还存在未授权访问那么Druid加的密码就形同虚设。4. 防御策略与彻底修复方案面对Druid未授权漏洞简单的“加个密码”是远远不够的。我们需要一套纵深防御的策略。4.1 代码层配置最小化暴露与强认证这是最根本的修复必须在应用代码中完成。Spring Boot配置示例application.ymlspring: datasource: druid: stat-view-servlet: enabled: true # 明确控制开启 url-pattern: /druid/* login-username: your_strong_admin_user # 必须设置强用户名 login-password: Your_Very_Strong_Password_123!# # 必须设置强密码 allow: 127.0.0.1, 10.0.0.0/8 # 白名单只允许本地和特定内网IP段访问 deny: # 黑名单优先于allow reset-enable: false # 禁用重置功能防止攻击者清空统计数据关键点解析allow参数是重中之重。应该设置为运维管理终端的IP地址段例如公司办公网IP段或VPN IP段。切勿设置为空或0.0.0.0/0。login-password不要使用默认密码或简单密码应遵循密码复杂度策略。reset-enable: false建议关闭防止数据被清除影响问题排查和监控。4.2 网络层与部署层隔离代码配置是基础但网络隔离提供了另一层保险。生产环境隔离Druid监控控制台绝对不应该被部署在面向公众互联网的服务器上。最佳实践是将监控控制台部署在独立的管理后台应用中该后台仅限内网访问。或者通过跳板机Bastion Host访问所有运维操作必须经过跳板机认证和授权。使用Web应用防火墙WAF在网关或负载均衡层配置WAF规则直接拦截对/druid/*路径的公共访问请求。Kubernetes/容器网络策略如果应用部署在K8s中使用NetworkPolicy严格限制Pod的入站流量只允许来自特定命名空间如监控命名空间或带有特定标签的Pod访问Druid端口。4.3 依赖安全框架进行全局管控对于Spring Boot应用集成Spring Security是管理所有端点访问权限的标准化方案。基础Spring Security配置示例Configuration EnableWebSecurity public class SecurityConfig extends WebSecurityConfigurerAdapter { Override protected void configure(HttpSecurity http) throws Exception { http .authorizeRequests() .antMatchers(/druid/**).hasRole(ADMIN) // Druid路径需要ADMIN角色 .antMatchers(/swagger-ui.html, /v2/api-docs).denyAll() // 直接禁止Swagger的公共访问 .anyRequest().permitAll() // 其他请求按需配置 .and() .formLogin() .and() .httpBasic().disable(); // 根据情况禁用HTTP Basic } Bean Override public UserDetailsService userDetailsService() { // 配置内存中或从数据库加载的用户为管理员分配ROLE_ADMIN UserDetails admin User.withUsername(admin) .password(passwordEncoder().encode(securePassword)) .roles(ADMIN) .build(); return new InMemoryUserDetailsManager(admin); } Bean public PasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(); } }这样做的好处是访问控制与业务逻辑解耦统一由安全框架管理更加清晰和强大。4.4 针对“druid 1.2.21 把存过耗时情形改成10s怎么修复”的特别说明这个热词反映了一个具体问题在Druid 1.2.21版本中存储过程存过的监控耗时阈值被默认改为了10秒可能导致一些正常的长耗时存储过程被误统计为慢SQL干扰监控。修复方法不是去修改Druid源码而是通过配置调整 在application.properties或application.yml中添加以下配置# 将慢SQL记录的时间阈值设置为3秒3000毫秒可根据实际情况调整 spring.datasource.druid.filter.stat.slow-sql-millis3000 # 开启慢SQL日志记录 spring.datasource.druid.filter.stat.log-slow-sqltrue这个配置是针对StatFilter的它会覆盖默认值确保你的慢SQL定义符合实际业务性能要求。5. 应急响应与排查清单如果怀疑或已经确认系统存在Druid未授权访问漏洞应立即按以下步骤处理立即隔离修改防火墙或安全组策略立即阻断外部IP对应用服务器/druid/*路径的访问。如果条件允许临时下线或重启应用并在启动参数中禁用Druid监控Servlet-Dspring.datasource.druid.stat-view-servlet.enabledfalse。漏洞确认与影响评估检查应用日志特别是Druid的访问日志和Web请求日志搜索对/druid路径的访问记录确认访问来源IP、时间和频率。检查数据库、Redis等其他中间件的访问日志查看在Druid被访问的时间点前后是否有来自异常IP或大量异常请求。审查SQL监控中是否出现过敏感查询如select * from userselect * from sys_config等。修复与加固按照第4节的策略立即修改应用配置添加强密码和IP白名单。全面排查同一应用中是否存在其他未授权访问端点如Swagger、Actuator、H2 Console等。升级Druid到最新稳定版本并关注其安全公告。事后复盘漏洞是如何引入的是部署脚本的默认配置还是开发人员的安全意识不足现有的CI/CD流程中是否缺少安全配置的检查环节如何建立有效的监控告警以便未来能及时发现此类配置错误Druid未授权漏洞就像一扇忘记上锁的后门。对于攻击者而言它可能不是终点但一定是通往核心资产最便捷的起点之一。对于防御者我们需要做的不仅仅是锁上这扇门更要看清楚它连接着哪些房间并确保整个建筑的所有入口都处于受控状态。安全是一个持续的过程从每一次漏洞的深入理解和彻底修复开始。