Pwnhub 2013的国庆 writeup
不让人过节系列||没女朋友只能撸题系列的CTF题。。。
Step 0
首先是.DS_Store
信息泄露,下载下来是一个二进制文件,需要解析,google搜一搜就有了:
1 | from ds_store import DSStore |
Step 1
根据提示:2017.10.02 15:45:49Nginx 虽然有过很多问题,但是它是个好 server
猜测应该是利用一个NGINX的CVE
然后在上一步发现一个奇怪的地方,最后一个是uploap[space]
目录而不是uploap
目录,有一个空格。
根据这些信息,搜到一个CVE,编号是CVE-2013-4547
….题目关了,搞不到图了。
payload是:GET upload /../pwnhub/ HTTP/1.1
这里不能使用浏览器,因为浏览器会把这url变成/pwnhub/
得到一个路径:6c58c8751bca32b9943b34d0ff29bc16/index.php
Step 2
6c58c8751bca32b9943b34d0ff29bc16/index.php
是一个文件上传的服务
1 |
|
一开始尝试上传各种文件,都能成功,但是配置更新成功并没有显示任何内容,包括上传tar文件,懵逼了一会。。。
然后发现,这个目录也有.DS_Store
泄露:
1 | with DSStore.open("DS_Store", "r+") as f: |
有一个untar.py文件:
1 | import tarfile |
很明显了,要压缩一个cfg文件
1 | echo "fjwopqafjasdo" > /tmp/test.cfg |
然后上传test.tar,更新配置成功后终于成功返回内容了。
但是该怎么利用又卡住了,然后看到hint:2017.10.03 11:24:40想办法把它变成任意文件读取,但 Flag 不在这儿 ,当作一次真实渗透玩吧!
想到了软链接,PoC如下:
1 | #! /usr/bin/env python |
Step 3
到了任意文件读取的步骤了,然后各种文件读读,照例我都会读读/proc/self
下的文件,然后发现:
1 | python 2013_read_file.py /proc/self/mountinfo |
发现一个脚本:/home/jdoajdoiq/jdijiqjwi/jiqji12i3198uax192/cron_run.sh
1 | python 2013_read_file.py /home/jdoajdoiq/jdijiqjwi/jiqji12i3198uax192/cron_run.sh |
Step 4
得到一个邮箱,然后尝试去登录看看,然后在收件箱看到一个发送vpn邮箱发送失败的返回邮件,然后去发件箱得到一个vpn:
1 |
|
这里想找个linux图形界面连IPsec的软件,但没找到,还是切换到Mac了。。
VPN连上后应该就是内网找服务了,因为nmap探测的很慢,所以只探测80端口
咸鱼了一会后发现几台主机:
1 | 172.17.0.1 |
从这可以看出来这是一个docker,其中1是外网那个服务的容器,其他80端口都是nginx默认端口,然后扫描3发现还开了8090,根据之后的提示:搞 Discuz 不是目的,谁说鸡肋就没用,看 Discuz 送助攻
Step 5
8090端口开的就是一个dz x3.2服务,然后就知道是搞这个了,找了下dz的漏洞去尝试,发现只有ssrf,有最新的任意文件删除的是有效的。
然后发现自己太菜了,根本不会做web,日不动dz。。。。。。
然后偶然间发现。。。。80端口变了,竟然不是默认的nginx服务了, 是一个跳转到index.php
的html页面,index.php
页面如下:
1 |
|
尝试访问:http://172.17.0.3/index.php?passwd=jiajiajiajiajia
当然是失败的,因为有个safe.php
然后根据前面dz获取到的信息,猜测safe.php是ip过滤,然后我得到一个思路(当然是错误的思路): 利用dz的ssrf访问http://127.0.0.1/index.php?passwd=jiajiajiajiajia
, 因为dz的ssrf是一个远程图片下载的,所以会把请求到的信息下载下来保存到本地,然后/data
目录是可遍历的,文件会下载到data/attachment/profile/201710/0x
目录下。
但是目录遍历到201710就没法遍历了,发现是有一个index.html,然后有了一个思路,是利用任意文件删除漏洞把index.html删除,成功了,可以看到data/attachment/profile/201710/04/
目录下的文件了,然后尝试ssrf,但是是失败的,源码审计看了一会,原来dz把ssrf请求下来的保存成文件后会获取图片信息,如果获取失败会删除。
想了想竞争,但是从保存文件到删除文件,间隔时间太短了,竞争不靠谱。。。又陷入僵局
然后出题人半夜改题了,一个开始80是nginx服务,dz是apache服务。然后换成了80是apache,dz是nginx。
然后我之前的思路就完成GG了,因为无法获取到下载下来的文件名。
然后就只剩一个思路了,利用dz的任意文件删除漏洞,删除safe.php
最开始我也想过这个,但是这个思路的问题太多了,一个是两个不同服务,凭啥有权限删除,safe.php又不是在upload这种会777的目录下,第二就是,一个人做出来了其他人不也做出来了
半夜2点多的时候尝试删除safe.php,失败,睡觉,早上9点多起来发现已经3血了,再次尝试,成功。。。。。。。。。。。。。。。。。。
没有写PoC,手工做题,首先python先跑起来:
1 | while True: |
然后使用burp,首先是请求:
1 | POST /home.php?mod=spacecp&ac=profile&op=base HTTP/1.1 |
然后再请求:
1 | POST /home.php?mod=spacecp&ac=profile&op=base&deletefile[birthprovince]=aaa HTTP/1.1 |
然后成功getflag:
1 | File not found. |
PS: 这题我给的评分是4,我觉得最后一步是本题的败笔,首先环境的问题就不说了。主要是这个思路,只是为出题而设置的,没啥其他意义。。。。前面的思路都挺好的。
本文就附一张图:
Pwnhub 2013的国庆 writeup