2019中关村杯show_me_your_image题目writeup

0x00 关于这道题

         这道题出现在2019年中关村杯CTF,难度较大,值得一看

0x01 题面

         这题打开就是个上传界面,干干净净,没有什么HINT可以看

       


0x02 上传

         首先上传正常文件,寻求上传的文件地址,但是服务器只返回一个session回来,再退回主界面发现上传的东西会在 /img.php?name=<???>中显示出来。
         尝试改后缀为fuck,之所以我改成fuck是想要测试服务器是否是白名单机制的,即只接收图片格式而不接收其它任何格式。因为如果服务器是黑名单机制就暗示我们要绕开它上传,而白名单限制很死,绕过往往是不可能的,只能另寻它途。很不幸这次就是白名单的。
         接着再直接把webshell开为jpeg后缀看看能不能利用img.php可能存在的文件包含漏洞,失败
         尝试解析漏洞,失败
         暴力扫目录扫php查看有没有别的PHP,一无所获。之所以扫目录是因为之前有题就是藏个phpinfo在那儿,暗示利用Imagick漏洞进行攻击的
         看起来上传Getshell这条路被堵死了。泪,流了下来

0x03 发现

         session长得很奇怪,有一种...说不出的眼熟,拿去base64解密居然解了部分,后面解不开的是一个.后面的东西,解密出来了有个不完整的JSON,其中包含了一个叫b的参数,这个参数Base64解码之后就是代入img.php的name,这熟悉的客户端session,让我想起了Flask的session,难道...难道这个其实是Flask伪装的?
      (PS:在下午主办方给了Hint之后,不需要能够发现session眼熟也能知道是Base64,但最好还是别过多依赖Hint,解码勤快点,万一下次不给Hint呢)
         我向来是不惮以最坏的恶意来揣测出题人的,然而我还不料,也不信竟会下劣凶残到这地步。况且始终后缀是PHP的网站,更何至于是Python伪装的呢?然而很快证明是事实了,作证的便是参数污染探测。
         先讲讲参数污染探测,说的多么神秘无非就是提交重复参数罢了,但是在这种涉嫌伪装的情况下却能够轻易识破。众所周知,PHP在被参数污染的情况下会取最后面的参数,而经过本人测试Flask在被参数污染的情况下会取最前面的参数。而我测试img.php之后发现它取最前面的参数,这便证明了后端并不是PHP!
         发现这个惊天秘密似乎对做题并没有什么帮助的样子,我还是继续上传文件。我发现我的文件名不变,参数b不变,文件名越长,参数b越长,并且有一定的对应规律,似乎是变种的Base64?这个猜想正好契合主办方给的Hint,那看来我们需要做的就是通过大量的文件名来拿到Base64的字符串编码表然后自己实现编码利用LFI漏洞拿到Flag!

0x04 破译

         到了这一步我整个人已经崩溃了,我操你妈我是个搞Web的,闲时学学二进制,现在叫我搞密码学有没有人性啊?但是思路也就这一条,而且和它的Hint也吻合,所以硬着头皮上吧。
         关于Base64,这里有一个很好的讲解,做题我就是看这个讲解来搞定这个编码表恢复的,原理我就不过多重复叙述了。
         Base64首先需要把字符串二进制编码填充,再按照六个六个的顺序分开又二进制转换为十进制得到一串由数字列表,接着再把列表里面的数字和按照编码表索引来拿到值。那我要做的就是生成大量文件名得到其自定义Base64的编码,用文件名得到的数字列表和题目自定义的Base64编码结果一一对应获取其编码表。
         花了点时间撸出了一份代码,跑得样子是这样的
         但是由于我们穷举的是可见字符,非常不幸有几个出不来,但因为我们最后搞LFI利用也不需要不可见字符,就随便填进去生成虽不准确但能用的Base64编码表
         最后使用的编码表如下
/d3yiNmo7CzalDw2qWZ5JPYL0MTAjS6Gefxk9VXgvsRcuF+8pH4B1rOUbhKQtnEI

0x04 LFI

         到现在需要做的就是用LFI读文件了,把目录用自定义编码表编码,然后交到img.php?name= 里面去。
         尝试../../etc/passwd成功,且确认文件目录两层
         但是flag找不到,各种找templates/upload.html也找不到,心里MMP,几个月前国赛就是这样的,明明能任意读文件了就是找不到flag
         在暴力尝试很久之后我尝试读取下进程相关的东西。关于/proc/<pid>下能读的内容在这里可以找到,我遍历了/proc/<PID>/cmdline 从1到10000的PID,发现就PID=1是个python程序。命令行是个python3 app.py sleep 3000(cmdline读出来没有空格这个空格是我自己脑补充的)但是读也读不到app.py。于是我手动查看/proc/<PID>/目录下面有什么能泄漏路径的东西。
         突然发现/proc/<PID>/cwd下面居然和进程工作目录相等,那我立即去读../../../../proc/1/cwd/templates/upload.html读出了文件,发现注释<!-- flag in /root/flag.txt ! Get it ! -->。心里又喜又怒,妈的找了半天flag就在/root/flag.txt下面,害我瞎折腾了那么久,且过去读,就能直接读到flag

评论

此博客中的热门博文

局域网监控软件WFilter ICF 鸡肋0day RCE漏洞挖掘

别想偷我源码:通用的针对源码泄露利用程序的反制(常见工具集体沦陷)

反-反蜜罐:以三个反蜜罐插件的缺陷为例