记一次SSRF+文件上传组合拳:复盘我是如何组合漏洞一步步Getshell的
好的,我现在需要帮用户总结这篇文章的内容,控制在100字以内。首先,我得仔细阅读文章,理解其主要观点和步骤。 文章主要讲述了一个安全研究人员如何通过漏洞攻击一个Java Spring Boot项目的过程。他首先进行了信息收集,发现这是一个前后端分离的应用。接着,他利用SpringBootScan工具找到了敏感接口和Druid登录页面,成功利用弱口令漏洞进入系统。 然后,他尝试了XSS漏洞,并通过Swagger文档发现了文件上传接口的漏洞。进一步的审计中,他发现了kkFileView组件的版本信息,并利用了其中的文件读取和SSRF漏洞。最终,通过反编译源码发现了路径穿越漏洞,上传了JSP木马,成功获得了服务器权限。 总结时,我需要涵盖这些关键点:信息收集、Druid弱口令、XSS、文件上传、组件漏洞、路径穿越和权限获取。同时要保持简洁,不超过100字。 可能的结构是:先总述攻击过程,然后列举关键步骤。确保每个步骤都简明扼要。 最后检查字数是否符合要求,并确保语言流畅自然。 </think> 文章描述了一次针对Java Spring Boot项目的渗透测试过程。通过信息收集、利用Druid弱口令、XSS漏洞、 Swagger文档分析、组件kkFileView版本漏洞(文件读取和SSRF)、以及最终反编译源码发现路径穿越漏洞并上传JSP木马成功获取服务器权限的过程。 2026-3-6 06:47:38 Author: www.freebuf.com(查看原文) 阅读量:4 收藏

freeBuf

主站

分类

云安全 AI安全 开发安全 终端安全 数据安全 Web安全 基础安全 企业安全 关基安全 移动安全 系统安全 其他安全

特色

热点 工具 漏洞 人物志 活动 安全招聘 攻防演练 政策法规

1.前期对这个web应用做信息收集时,没有收集到任何有用的信息,它看上去就像是一个简单静态页面展示。但是当我打开浏览器devtools进行抓包时,发现其存在网络请求,并且每个请求包的一级路由都是相同的,在查看服务器信息发现是ngnix → 推断为前后端分离的项目。

2.如果是前后端分离的项目,首先想到的就是java web应用(按目前市面上主流开发来看的话)。并且如果是spring的项目话一般是会有默认报错页面的,这里为了验证猜测,我直接在浏览器访问了这个路由。

3.显而易见,这是一个java spring的项目。spring项目一般是存在很多敏感目录和敏感文件的,我们可以使用字典来进行进一步的信息收集。这里我用的是曾哥的SpringBootScan:

4.发现接口文档路径和druid的登陆页面,这里我先打开druid的页面看是否存在未授权或者弱口令。

5.好吧没有未授权,但是存在登陆页面,只能默认密码或者弱口令爆破了。结果直接默认密码登陆成功了,成功拿到一个druid的弱口令漏洞。

6.然后我就想能否找到后面页面,通过druid的session监控里面的session爆破session登陆到后台,可惜并没发现任何后台地址或路由信息。到这里只能放弃了。

1.根据前面SpringBoot敏感信息收集的swagger文档里面,我找到了一个文件上传接口(存在未授权访问)。由于是一个jar包启动的项目,他不像tomcat中间件启动的项目能够解析jsp文件以便于我们获取webshell,对于这类java项目通过文件上传的方式获取shell是不太可能的。于是我就想能否上传一个html页面,实现一个xss。请求包构造payload发送结果如下:

2.他是一个图片上传接口,但是我将后缀改为html是没有任何校验的,得到这个返回结果发现只是将文件名重写了并未重写后缀,访问页面,成功拿到一个xss漏洞:

1.swagger文档没有获取到其他可以利用的点,跑回前端对前端代码做一个简单的审计(主要目的是挖掘更多的路由、url、资产地址等),这个位置存在了大量的接口地址信息,并且有一个地址很独特,看名字像是一个图片预览地址:/preview/onlinePreview?url=

2.访问地址/preview/onlinePreview?url=,页面如下:

3.直接拼上百度地址首页图片是springboot默认页面报错,虽然是500报错码,但没有具体报错信息,无法进一步利用。

4.然后我就去掉了url参数意外发现了报错信息,这里比较关键的是这个包信息:cn.keking → 进行进一步收集发现是一个叫做kkFileView 的java组件

5.查看官方的文档说明,发现其是一个单独的springboot项目,并且存在一个主页面,上面会记录其最新版本更新说明。 思考:如果我能获取到目标的这个kkFileView服务主页面的更新说明,能否根据其版本信息查询到一些历史漏洞呢?→ 最终得到其版本信息为v4.0.0

6.收集版本对应历史漏洞主要如下:
1)存在zip slip文件解压进行文件替换造成的RCE
2)SSRF
3)文件读取

(第一个漏洞危害有点大了,他会替换文件,实在不行再考虑利用)

文件读取漏洞

这里我们主要是用了ssrf和文件读取,最终利用成功,这里我读取了/etc/passwd:

ssrf漏洞

然后读取云服务信息,这里通过whois查询发现是腾讯云服务器,读取元数据信息: 后续我想通过元数据信息拿到accesskey接管其账号,没有利用成功(有厉害的大佬可以交流一下),貌似其并没有开通ram信息接口地址等导致我无法获取临时的token。

1.最终我还是想拿到服务器权限,有没有什么其它方式呢? → 把想到了办法都用了,搞了半天,最终还是审计源码给了我突破口。

(分享点小经验,当找不到服务源码具体路径或者其它文件路径时:不妨查看一下.bash_history,说不定有惊喜)

2.通过file协议对其服务jar包进行下载,反编译后审计,找到一个文件上传接口存在路径穿越:

3.第一部分path是获取的config.properties配置的路径信息,第二部分filename是file.getOriginalFilename()获取的全文件名,后续代码并未对其进行过滤直接进行了路径拼接。这里有一个问题:如果存在文件名为../../../,将会达到一个任意目录穿越的效果,最终形成任意文件上传到任意目录的一个漏洞。

4.这里由于前期的信息收集,我是发现其存在一个tomcat的服务。于是我利用这个任意目录的任意文件上传,上传jsp后们到了tomcat服务中。数据包构造如下:

5.通过哥斯拉连接后门,成功拿下服务器权限:

免责声明

1.一般免责声明:本文所提供的技术信息仅供参考,不构成任何专业建议。读者应根据自身情况谨慎使用且应遵守《中华人民共和国网络安全法》,作者及发布平台不对因使用本文信息而导致的任何直接或间接责任或损失负责。

2. 适用性声明:文中技术内容可能不适用于所有情况或系统,在实际应用前请充分测试和评估。若因使用不当造成的任何问题,相关方不承担责任。

3. 更新声明:技术发展迅速,文章内容可能存在滞后性。读者需自行判断信息的时效性,因依据过时内容产生的后果,作者及发布平台不承担责任。

本文为 独立观点,未经授权禁止转载。
如需授权、对文章有疑问或需删除稿件,请联系 FreeBuf 客服小蜜蜂(微信:freebee1024)


文章来源: https://www.freebuf.com/articles/web/472700.html
如有侵权请联系:admin#unsafe.sh