本文作者： 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 稍微降低一些攻击门槛（其实差不了太多）。有时候可能在某处产生的漏洞点只是一个小问题，而许多个小问题加起来，也许小洞就变大洞了。俗话说， 千里之堤毁于蚁穴 ，就是这个道理。