换了套组合拳打出一个 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 稍微降低一些攻击门槛(其实差不了太多)。有时候可能在某处产生的漏洞点只是一个小问题,而许多个小问题加起来,也许小洞就变大洞了。俗话说, 千里之堤毁于蚁穴 ,就是这个道理。

推荐阅读

原创 由 CSRF 引起的 XSS 漏洞小结

原创 近期关于代码审计的学习总结

原创 各种漏洞组合拳打出不一样的姿势

1 Like