【摘要】2017年10月24日，Typecho被爆出install.php文件存在后门可以直接执行任意代码导致使用此系统的网站直接被getshell。攻击难度：低。危害程度：高。官方修复情况如下：https://github.com/ty...

    https://github.com/typecho/typecho/commit/e277141c974cd740702c5ce73f7e9f382c18d84e

    此漏洞的根源在于系统的安装文件install.php，因为在系统安装完之后是不会自动删除install.php文件的。
在install.php文件中，当设置了正确的referer（网站url即可），并且finish=1，然后就会执行下面这样一段代码：

    在这里系统从cookie中获取了键为__typecho_config的内容，然后base64解密并且使用不安全的unserialize函数反序列化，那么我们很容易想到：如果在cookie中的__typecho_config中构造特定的数据是不是就可以执行任意PHP代码了？

    下面我们就要分析系统代码，寻找并构造可以被执行的特定代码。

    注意上面的代码，可以看到被反序列化后的内容$config[‘adapter’]作为构造参数进入了Typecho_Db实例中，继续跟进Db.php文件中Typecho_Db类的构造函数：

    这里的$adapterName就是$config[‘adapter’]，然后$adapterName进行了一个字符串拼接操作继续赋值给$adapterName。

    到这里如果有经验的大佬或者脑回路够大的话会想到，如果$adapterName是一个实例对象的话，那么这里进行字符串操作就会自动调用当前实例的__toString()魔术方法，当然这也有要对对象注入有一定的了解。

    不过你不了解对象注入、没有太多经验、脑回路也不够大的话那么我们审计到这里就先打一个问号，保存疑点，然后继续。

我们共可以发现三个疑点，将其结合起来：
    第一个疑点中的可控变量$adapterName进行字符串操作时，我们将$adapterName赋值为文件Feed.php中的Typecho_Feed类实例的话，这里就会调用Typecho_Feed类的__toString魔术方法；
    第二个疑点中我们把属性$this->_params和$this->_filter被设置为恶意的内容的Typecho_Request类实例赋值给第三个疑点中的$item[‘author’]，当访问$item[‘author’]的属性screenName的时候就会执行到Request.php中的call_user_func危险函数，触发恶意代码的执行。

防护方案：
    请升级到官方的最新版即可。
参考链接：
    https://github.com/typecho/typecho/issues/619 

 小东
 简介：专业团队网站开发、安全运维，合作意向请联系！