前言
前期信息收集
前端大概就这样.
Web整体架构:
操作系统: Ubuntu
Web服务器: Nginx1.18.0 + Java
端口开放信息: 80 443
先进行一波目录扫描
挨个测试
可以看到,扫描到了一个”jira”目录,看这眼熟的目录盲猜是Jupyter NoteBook 组件。
访问果不其然,Jupyter NoteBook组件的登陆点
然后我们挨个其他3个有效目录,都是登陆点
- /gitlab
-
/owncloud
-
/confluence
我晕~要让我爆破吗。这三个登陆点先放着。由于是Jupyter Notebook组件,印象中应该是有相关漏洞的。当机立断去Google一波历史漏洞
2处信息泄露+未授权访问RCE
信息泄露
利用信息泄露可以用来爆破用户
Exp1:
/jira/secure/ViewUserHover.jspa?username=admin
Exp2:
/jira/rest/api/latest/groupuserpicker?query=admin&maxResults=50&showAvatar=true
存在用户的话是会返回用户信息的,然后爆破~
欸我这一看,爆破出一个”Kevin”用户。
掏出我们陈年密码本再继续爆破一波密码
上个厕所回来一看,啥都没从来.爆破这事儿就此告一段落。
未授权访问
看了网上几篇相关此组件未授权访问漏洞,都是直接访问能够在控制台运行”Terminal”直接执行命令.但是这边我拿到的域名访问是大学的某系统,猜测修复了未授权漏洞,加了验证。
突破点
想起之前官网主页跳转的登陆口,貌似好像就是修复了未授权漏洞加的验证点,需要输入密码登陆。
来到之前登陆口,随手输入一个”123456″,点击登陆
竟然…给我进来了(这开发真的是,这里弄个平民口令)
那么进来了就好办了,按照历史漏洞
New->Terminal
打开了一个终端
直接可以执行命令
习惯性的去根目录,看看有啥文件
看到’.dockerenv’文件,不是吧不是吧,在裸奔的我有点慌,难道踩罐了?
为了验证我的想法,查询系统进程的cgroup信息
是Docker没错了,猜想为蜜罐的可能性不大,部署的是某大学的一个办公系统.
Docker逃逸
由于在Docker容器中,想到”Docker逃逸”这个漏洞,也不知道能不能逃逸出来,于是想尝试一下.
之前从没实战碰到过Docker,也没复现过Docker逃逸这个洞,查阅了大量文章.这个点就折腾的比较久.
参考文章:
https://www.freebuf.com/articles/web/258398.html
CVE-2019-5376这个漏洞是需要重新进入Docker才能触发弹shell.而我们上面正好是可以直接进入Docker终端,于是尝试利用
Poc:
https://github.com/Frichetten/CVE-2019-5736-PoC
修改main.go文件,此处更改为弹shell命令
完了之后发现自己没有Go语言环境
听说Mac自带Go语言环境,认识个表哥正好用的Mac,于是找他帮忙编译
原来这就是”尊贵的Mac用户”~~
自己又倒腾了一套Go语言环境.然后编译我们的Poc
到go文件同目录下,使用命令:
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build main.go
(注: GOOS参数为生成的可执行文件运行环境,由于我们标靶站点是Linux,故此处使用Linux)
到之前弱口令进入的Jupyter NoteBook控制台上传Exp到默认目录
我们这边VPS监听1314端口
靶机运行我们的Exp
然后我们回到Jupyter控制台,重新进入终端界面
VPS等待一会儿没弹回来shell,后面才发现是我自己VPS端口策略问题,换个连通的端口,重复步骤,Exp生效,成功弹回来主机shell
结语
貌似是部署在阿里云的服务器,未授权原因就不再继续深入了.其实一开始的想法是弄个Webshell的,但是对这种架构不熟悉,知识欠缺.没找到Web目录~~(果然还是我太菜了哈哈)
(相关漏洞已提交至edusrc)
来源:freebuf.com 2020-12-23 21:24:09 by: Rluck1127
请登录后发表评论
注册