换了套组合拳打出一个 webshell 你敢信

本文作者：Z1NG（信安之路核心成员）

大概是运气好，又在这款某 CMS 挖到一处后台 getshell。老搞这款 CMS 我都觉得不好意思了。。个人感觉这个洞挖的还是蛮有意思的。

山穷水尽疑无路

大概是因为爱情吧，在如下图的那么多个文件夹中，我只看了这一个文件夹，里面的一个 PHP 文件夹吸引了我，而这里面确实藏有惊喜。

抓取远程文件的注释激起了我的兴趣，第一个想法是否能够从我自己的服务器上抓取到一个文件来 getshell 呢？

于是进行了如下测试：

先将流程控制到 catchimage 这来，然后用 post 传递一个数组 source。

source 就是目标服务器的 URL,简单的构造发包，看看结果。

个人觉得黑盒加白盒的测试效果好。

得到的结果如上图所示，感觉是把文件保存下来了，于是去看看文件夹里有没有多了什么东西。如下图所示，可以看到我们请求的文件被保存下来了。但是里面的内容是一句 warning，一看到这个，喜忧参半吧。

这边是测试发现 php 文件不可以创建，所以就选择了 phtml 这个来替代。

仔细观察，可以看到 readfile 里的内容是我们可以控制的。随即一个想法，就是用<?php phpinfo();?>a.phtml做文件名，这样就把 PHP 代码注入到这个文件里，不就拿到 shell 了吗？试试看。构造好 payload 发送后。

我们来看看文件夹里的变化：

可以看到，<>这些特殊符号被替换成空了，safe_url() 函数就是阻止我们 getshell 的罪魁祸首。

真的没办法利用了吗？惆怅的假装点了根烟，冷静了一下。

柳暗花明又一村

根据上文，我们已经可以创建一个脚本文件了，那么现在如何给这个脚本文件里注入恶意代码呢？

也就是如何控制里面的内容?

这里我没有再深究 down_url() 是干嘛的，也许里面有内容可控的部分，但感觉里面代码蛮复杂的不想看了。

细细回想起之前挖掘到这款 CMS 路径遍历可修改任意非 PHP 文件的漏洞。而我们创建的是 phtml 后缀的脚本，所以不在黑名单之内，那么问题就迎刃而解了。

如下图，构造 payload，修改我们前面创建的 a.phtml

访问目标文件，即可执行 phpinfo();

注：此处需要 apache 支持解析 phtml

写在最后

由于是在后台，如果有机会的话，可以加上 CSRF 稍微降低一些攻击门槛（其实差不了太多）。有时候可能在某处产生的漏洞点只是一个小问题，而许多个小问题加起来，也许小洞就变大洞了。俗话说，千里之堤毁于蚁穴，就是这个道理。