往下翻这几个点击全部跳转到了一个登陆口

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)