nctf2020终于结束了。我手头的题目也基本无了 XD
因为这次nctf学长他们要来的奖励挺丰厚的(xray license我也想要啊),所以就把手头的题都放出来了。如果难度对新生有些劝退的话还请多多包涵。校赛前几天，甚至以为yypl要来就临时赶出了一道bg_laravel,结果被忽悠了。最后大部分师傅可能都去做祥云杯了，所以没能过来打，算是比较可惜了。
这次我的题目除了bg_laravel以外全都有人解出.(rmb师傅还有其他师傅tql)题目环境放github上了,可以自取复现。
https://github.com/baiyecha404/My-NCTF2020-Challs
JS-world [11 solves]
这道是专门为校赛准备的签到题目。整体思想上其实就是想展示下js在前后端的通用性。只要理解了前端源码就能推断后端逻辑。同时也想说明前端的waf等于没有waf :).加上powered by ejs的提示,应该不难看出用的是ejs来渲染html代码。那么直接用ejs的语句就可以RCE了.
比赛的时候本来一血很快就出了的，结果后来半天没人解。我看了眼html发现有的师傅已经可以RCE了结果就是不去看根目录的flag.txt.阿这......
Mango [3 solves]
Mango 自然是为了玩一个mongo <-> mango的梗。这道题的起源比较有意思，来自于上半年某国际赛的赛题。当时题目考点是node-serialize的反序列化,不过我在黑盒测的时候意外发现那道题目还有nosql注入的漏洞存在。于是后来getshell后索性dump源码下来研究了下，也大致明白了为什么他的配置会产生nosql注入。加上后来发现这样的代码写法其实还挺常见的，所以干脆单独剥出来做成nosql注入了。
但是我的定位只是中等难度，最后只有3 solves我也很迷。不知道是因为大家没有接触过nosql注入还是什么的。我现在见过的大部分nodejs写的项目数据库都是用的mongodb,感觉出现nosql的概率还是不小的。稍微需要更换方式fuzz的地方就是json传递数据了。这个也算是比较常见的trick吧,node由于传递json导致与对象混淆的问题简直不要太多。所以第二个提示给出了app.use(express.json())。手抖加一个json中间件或者因为某个需求不得不加中间件(写api时),很有可能带来奇怪的问题。所以写node传参一定要记得类型检查啊。
PackageManager v1.0/v2.0 [7 solves / 3 solves]
PackageManager 系列放了两道题。其实源码基本相差不大，2就是1的升级版。一开始的PackageManager 6月份就出好了。不过后来过了几个月后意外发现居然存在非预期。于是索性就把非预期放到第二版里并且加难了。考点其实是我觉得很值得去学习的用子进程来prototype pollution to RCE的一种手段.相比深挖模板污染属性的利用方法，子进程导致RCE算是大大降低了利用难度。然而国内相关文章貌似主要是先知上的一篇kibana cve分析,不过就子进程利用范围上有些差错。所以希望借此让大家重新关注下。
当然，后来意外发现这个考点第5空间线下貌似也出现过,不过我题目先出好的233。
v2除了达成RCE以外,为了增加一点难度，特意就把flag放到mongodb中了。这点根据hint.txt以及目录下的文件来推断应该不成问题。其实目的是模拟一个开发上线到生产环境的情景。比如像我这样,容易装了某个依赖写个demo，然后字段留到package.json里了,本地删了相关js代码后拿到生产环境下直接npm install ,就多装了没有用的依赖。所以这里就能用mongodb依赖连接内网mongodb拿flag.
然后比赛就翻车了......nunjucks把我给害了。之所以选nunjucks做模板引擎本来是因为我所知道的引擎除了nunjucks外，像hbs,ejs,pug,jade都是可以污染模板RCE的。所以没有跟源码就直接想看看有没有人非预期污染nunjucks属性的（p1g3师傅应该是找了nunjucks的污染，但是只能等我靶机每分钟重启才能看一次执行结果,没有预期解方便）。结果发现nunjucks直接模板注入根本不受这些影响...... 我v2本来目的就是说明其实不止fork,任意子进程都可以结合污染环境变量然后RCE,所以就用了execSync('whoami')。中间件里还考察了一个trick绕过debug路由的限制.结果模板注入直接通杀v1,v2 orz
不过貌似看v2的人不多，所以最后rmb跟p1g3师傅应该是预期做的。一血的Somnus师傅就直接非预期模板注入了......不过非预期什么的无所谓,能拿flag都是好方法,大家能学到子进程污染的知识我就比较满足了。最后比较普遍的问题是有的师傅连接mongodb代码写好后没有db.close().那这本地必然是拿不到查询结果的。
SimpleSimplePie [1 solves]
挖链子是不可能的，所以只能自己手写几个乱七八糟的类来构造pop链了。整体思路我感觉跟tp系列的pop chain 差不多？就是个super-mini版的__toString() -> __call() -> call_user_func调用自身函数。
然后利用则比较有意思。灵感当然就是之前做htb时发现的新姿势 ssrf 打memcache触发反序列化. 后来意外发现这样的利用其实实战中还挺不少的，比如之前安恒俊杰师傅的ssrf -> RCE的艰难利用就是ssrf 打redis触发thinkphp反序列化.我的题相比实战还是简单多了。
这里pop链里有个小坑就是链子的起点选__wakeup最好。我自己当初调试的时候就发现如果用__destruct做起点，会因为序列化数据的一些内容触发simplepie的报错。所以写利用类时故意刁难加了个__destruct希望踩个坑(我爬了)。但是唯一解出的rmb师傅在选择了__destruct做起点后是用了phpggc里的fast destruct 来进入__destruct。这倒确实出乎我意料,学到了。
bg_laravel [0 solves]
没想到最后laravel成了防ak题......因为时临时赶的，所以很多地方写的不是很好，还请见谅。甚至由sql注入到上传getshell都是灵光一闪想出来的。
题目之所以用了保国当然是因为最近被马老师的鬼畜给洗脑了233。所以我的题目上传不给回显路径，其实是年轻人不讲武德不告诉你文件名 :)
首先在国内CTF laravel的反序列化早就被打烂了，所以我就想能不能出点新意。说起来之前七月火师傅的laravel文章下居然有人说没人这么写控制器所以反序列化没有用，这就来打脸。众所周知,phar反序列化直接扩宽了php反序列化的利用面。一个laravel站里出现的文件流操作绝对不少，那么如果能有可控点触发phar反序列化,结合pop链直接就能getshell.
但是这么考太简单了，所以自然是加点花。
刚好我最近接触到了laravel 5.8.10的很冷门的sql注入。冷门主要是因为github上修复都只是说修复了逃逸单引号的漏洞,而不是明说的sql注入漏洞。而且利用条件也有点苛刻，一个是要输入可控,另一个是回显得有json数据,否则json_extract()会报错。wp里给的参考文章也只是说了addSelect(),select() + json回显的数据可能会导致sql注入。可实际上，题目中出现的orderby()也是可以注入的。这就要看师傅们自己debug了。我自己是当初直接wrapJsonPath那下断点碰运气在可控位置一个个尝试触发才发现的。
sql注入怎么跟phar反序列化结合呢？除开可控的phar://输入点，我第一想法是把上传的文件名随机化，然后把文件名之类的保存在mysql里。但是很有意思的是，我在网上找了不少laravel的文件上传都用了ORM,也就是说,File类是个Eloquent model.执行$file->save()时对应的数据就都到了数据库里了,正合我意。
所以可能大部分师傅被这个冷门的laravel sql注入给难住了。所以还是要多谷歌+查看官方这个版本的一些小改动,说不定就能定位漏洞点了。
summary
总之这次比赛能看到师傅们做自己的题,顺便交流下思路还是比较开心的。希望大家明年能接着来玩，也可以期待下不知道有没有的X1CTF