LCTF-2017 Web WP

5/6, SSRF肝不动了 🙁

Simple Blog

备份文件.admin.php.swp .login.php.swp, 关于这样的动态备份文件, 用静态的扫描器较难找到, 需要配合爬虫的动态fuzz, 之前在cdxy的博客中有关于这些敏感文件探测的思考

直接上关键代码:

padding oracle, 太久没碰了十分生疏, admin admin登陆拿到session, padding出的id第一位需要在之后登陆的时候爆破

成功登陆进行注入, 看到两次sprintf的使用想到格式化字符串的漏洞, 前段时间的wordpress, 用%1$可以逃逸单引号, payload类似 %1$' union select 1,2,(select group_concat(column_name) from information_schema.columns where table_name=0x6b6579)--+, 最后在key表的f14g字段里找到flag,

萌萌哒报名系统

.idea目录导致源码泄露xdcms2333.zip

几处关键代码:

重点在于账号密码的验证和身份的验证是分开的, 并且member中关于identity的验证是查询成功取出数据并且$sth->fetch()[0] === 'GUEST', 所以即使没有查询成功也可以绕过验证, 周六中午看了下, 没什么思路下午就去捏泥巴了 🙁
回来以后队友在讨论条件竞争, 关键点在注册的时候如何让插入identity的语句尽可能拖慢时间, 利用成功插入用户名密码但是identity还没被插入的这个时间差直接登录, 注意到插入identity之前有一个正则的匹配, 首先想到的是之前360正则库审计的一个文章, 但是尝试后没起作用, 后面找到php正则在处理一个超长数据的时候会很慢, 于是考虑构造一个超长并且符合正则的code来延长正则匹配的时间从而增加竞争成功几率

然后就又遇到了一次坑, 因为我的源码是中午的时候拖下来的, /^(xdsec)((?:###|*))$/i那时是这样的一个正则, 但是之后发现队友下午拖的是/^(xdsec)((?:###|\w)+)$/i, 最后是后面这个正则, 于是构造'xdsec'+'###'*5000可以让正则拖慢, 然后是is_file的验证, 用php://filter绕过, 于是开registe, login, readfile三个同时竞争就行了

他们有什么”秘密”呢

发现可以报错, 但是information_schema被ban, 然后发现Polygon都被ban了, 但是linestring没被ban, 用linestring爆出表名然后用

1 and (select name from product_2017ctf where id=1 and (select * from (select * from product_2017ctf as a join product_2017ctf as b using(pro_id,pro_name,owner,d067a0fa9dc61a6e)) as c));

得到列名, 然后用order by 的盲注拿到下一关

非常有趣的地方, 可以在沙箱里创建任意名字的文件, webshell被限制在7个字符里, 很容易找到

这样的webshell, 然后通过执行本地文件名字的命令拿到shell, 有点类似HITCON里的baby first

经过测试发现这样的webshell只会执行排在第一位的文件名的命令, 然而在题目上创建一个名为ls的文件后怎么样都无法执行, 这里卡了很久, 最后发现沙箱内有一个自带的index.html, 这个文件排序在ls前面, 所以导致ls无法执行, 那么首要的问题是删除掉这个index.html, 在i之前的命令, 可以用bash, 执行一个rm -f *这个刚好7字节的脚本

于是得到思路:

wanna hack him?

首先随便填一个payload收bot的请求查看请求头和浏览器版本, Chrome60, 题目都不看了直接上UXSS

iframe里不能直接嵌入mhtml, 于是在iframe里引入一个html

<iframe src="http://x.x.x.x/1.php">:

用window.open打开我们的PoC:

flag在cookie里

签到题

fuzz一下可以看出后台用parse_url来取得host进行验证, 然后调用curl访问, 在orange的BH议题里有关这部分的内容

http://1@127.0.0.1:80@www.baidu.com

http://1@127.0.0.1 @www.baidu.com

这样一个url, parse_url取出的host为www.baidu.com, 但是curl_exec请求的却是127.0.0.1:80, 第一个payload在curl 7.54中已经被修复, 但是第二个payload官方明确表示不会修复, 但是题目上第一个payload仍然可用

然后扫下端口, 没什么特殊的东西, 过了一段时间才发现有个hint是本地, 于是考虑怎么用file协议

因为之前在尝试用http://1@127.0.0.1:80@www.baidu.com/test.php访问回来的时候发现实际请求的url为http://1@127.0.0.1:80@www.baidu.com/test.php/, 末尾多了一个斜杠导致请求404, 所以用?加在末尾让curl认为/是一个参数, 所以最后用file协议的payload如下:file://1@127.0.0.1:80@www.baidu.com/etc/passwd?

/etc/passwd里有一个lctf用户/home/lctf/flag里找到flag

L playground

没肝出来, 做题太慢没时间了 Orz 把思路写了吧

题目有两个SSRF, 第一个在80端口, 请求用的python requests, 用http://0/绕过对localhost的过滤, 用这个SSRF进行内网端口探测, 发现8000端口开了Web服务, 6379开了Redis

发现8000端口也是一个SSRF, 后台用urllib/ 3.4请求, 存在2016年的一个CRLF漏洞, ban了0, 但是用302跳转可以跳转回localhost

于是可以尝试用SSRF控制redis, 结合放出的hint猜测是用redis序列化存储了80端口django的用户session

感觉整道题都出现在ph的博客里了////

总结

好久没写WP了, 因为之前的比赛打的都很难受, 题都做不出也没什么可以写的