typecho ssrf 分析

typecho 在2017年10月左右爆出过一个ssrf漏洞，可用于攻击内网服务。本文从 php 代码层面分析了一下漏洞的触发原理，希望能对阅读者有一定帮助。

通过diff发现var\Widget\XmlRpc.php文件有如下修改：

旧版本2048行：

新版本则吧这个检查放在了pingbackPing函数的开头：

漏洞分析

XmlRpc是方便第三方 工具 管理typecho的接口，当其被调用时，首先会运行XmlRpc.php的2189行：
      public function action()
      .....


在2249行new了一个IXR_Server，随即走到了他的构造函数：

然后跟入serve函数：

可以看见我们post的内容都传入了$GLOBALS['HTTP_RAW_POST_DATA']，然后赋值给$data，后面new了一个IXR_Message并把$data作为参数传入，跟入parse()：

这个函数在新建一个xml解释器，xml代码为我们post的内容。

xml_set_element_handler设置了xml文档中的起始和终止调用的函数，这里就是'tag_open'和'tag_close'。

xml_set_character_data_handler函数规定当解析器在 XML 文件中找到字符数据时所调用的函数。

关键代码如下(由于代码较长，所以只贴出关键代码)，位于tag_close函数的142行

function tag_close($parser, $tag) {

当有一个标签为methodName时，_currentTagContents也就是methodName的内容会赋值给$this->methodName。

而当标签为string时，内容赋值给$value并在163行：

     $this->params[] = $value;

往后运行到server.php的call函数：

其中$methodname和$args都是我们通过xml标签传递的值，在最后一行call_user_func_array中，即可调用相应的函数。

然后回到漏洞触发点：

var\Widget\XmlRpc.php 的2049行：

        if (!($http = Typecho_Http_Client::get())) {

这里调用的get方法加载了var\Typecho\Http\Client\Adapter\Curl.php和ar\Typecho\Http\Client\Adapter\Socket.php两个文件，当发起请求时首先会尝试使用curl，否则使用Socket。

紧接着后面：

$http->setTimeout(5)->send($source);

$source为我们可传入字符,跟踪send函数：

public function send($url)
    {
        $params = parse_url($url);

        if (!empty($params['host'])) {
            $this->host = $params['host'];
            .....

用parse_url拆分传入的url，并依次添加到$this中，除此外还添加了cookie和hearder，在338行：

前面都在设置curl选项，然后在最后执行，一路畅通无阻，所以造成ssrf。

在XmlRpc.php的2058行：

可看见response如果状态为200，且x-pingback为空、原地址不支持PingBack，就返回源地址不支持PingBack，否则会返回源地址服务器错误。

所以我们可以通过输出来探测ip和端口，如果返回源地址服务器错误，则主机/端口关闭，如果返回源地址不支持PingBack，则主机/端口存在。

当然不光是端口和主机探测，我们也可以进一步盲打内网中的 redis 和FastCGI。

payload 

post以下内容到http://127.0.0.1:8888/typecho/index.php/action/xmlrpc:

其中http://127.0.0.1:80就是上文中的$source。