Wordpress未授权查看私密内容漏洞 分析（CVE-2019-17671）

目录

  • 0x00 前言
  • 0x01 分析
  • 0x02 思考
  • 0x03 总结
  • 0x04 参考

0x00 前言

没有

0x01 分析

这个漏洞被描述为“匿名用户可访问私密page”，由此推断是权限判断出了问题。如果想搞懂哪里出问题，必然要先知道wp获取page(页面)/post(文章)的原理，摸清其中权限判断的逻辑，才能知道逻辑哪里会有问题。

这里我们直接从wp的核心处理流程main函数开始看，/wp-includes/class-wp.php:main()

public function main( $query_args = '' ) {
    $this->init();//获取当前用户信息
    $this->parse_request( $query_args );//解析路由，匹配路由模式，取出匹配的路由中的用户输入参数（比如year,month等）赋值给$this->query_vars。（并将部分用户参数绑定到$this->query_vars中）。然后进行一些过滤操作。
    $this->send_headers();//设置HTTP响应头，比如Content-Type等
    $this->query_posts();//根据$this->query_vars等参数，获取posts/pages
    $this->handle_404();
    $this->register_globals();

    do_action_ref_array( 'wp', array( &$this ) );
}

$this->init()底层直接调用wp_get_current_user()获取全局变量$current_user，这是一个WP_User类，里面存储当前用户的元信息，未登录时$current_user->ID===0。

然后进入$this->parse_request，这个函数主要用于处理路由，初始化$this->query_vars。主要分为两部分来看，第一部分是处理路由，匹配rewrite路由模式。

public function parse_request( $extra_query_vars = '' ) {
    global $wp_rewrite;

    ...

    // Fetch the rewrite rules.
    $rewrite = $wp_rewrite->wp_rewrite_rules();//加载所有路由重写规则，用于与当前请求路径进行匹配

    if ( ! empty( $rewrite ) ) {
        ...
        if ( empty( $request_match ) ) {
            ...
        } else {
            foreach ( (array) $rewrite as $match => $query ) {//匹配路由规则
                ...
                if ( preg_match( "#^$match#", $request_match, $matches ) || preg_match( "#^$match#", urldecode( $request_match ), $matches ) ) {
                    ...
                    // Got a match.
                    $this->matched_rule = $match;//找到匹配成功的rewrite规则，立即break
                    break;
                }
            }
        }
        if ( isset( $this->matched_rule ) ) {
            ...
            $query = addslashes( WP_MatchesMapRegex::apply( $query, $matches ) );//规则化用户请求url，以与路由进行完美对应

            $this->matched_query = $query;

            // Parse the query.
            parse_str( $query, $perma_query_vars );

            ...
        }

        ...
    }

第二部分，解析用户参数，配置$this->query_vars的值

class WP{
    ...

    public $public_query_vars = array( 'm', 'p', 'posts', 'w', 'cat',
'withcomments', 'withoutcomments', 's', 'search', 'exact', 'sentence',
'calendar', 'page', 'paged', 'more', 'tb', 'pb', 'author', 'order',
'orderby', 'year', 'monthnum', 'day', 'hour', 'minute', 'second',
'name', 'category_name', 'tag', 'feed', 'author_name', 'static',
'pagename', 'page_id', 'error', 'attachment', 'attachment_id',
'subpost', 'subpost_id', 'preview', 'robots', 'taxonomy', 'term',
'cpage', 'post_type', 'embed' );

    ...
public function parse_request( $extra_query_vars = '' ) {
    ...
    ...

    <接上第一部分>

    foreach ( $this->public_query_vars as $wpvar ) {
        if ( isset( $this->extra_query_vars[ $wpvar ] ) ) {
            $this->query_vars[ $wpvar ] = $this->extra_query_vars[ $wpvar ];
        } elseif ( isset( $_GET[ $wpvar ] ) && isset( $_POST[ $wpvar ] ) && $_GET[ $wpvar ] !== $_POST[ $wpvar ] ) {
            wp_die( __( 'A variable mismatch has been detected.' ), __( 'Sorry, you are not allowed to view this item.' ), 400 );
        } elseif ( isset( $_POST[ $wpvar ] ) ) {
            $this->query_vars[ $wpvar ] = $_POST[ $wpvar ];
        } elseif ( isset( $_GET[ $wpvar ] ) ) {
            $this->query_vars[ $wpvar ] = $_GET[ $wpvar ];
        } elseif ( isset( $perma_query_vars[ $wpvar ] ) ) {
            $this->query_vars[ $wpvar ] = $perma_query_vars[ $wpvar ];
        }
        ...
    }
    ...
}

可以看到，这里遍历$this->public_query_vars成员变量，如果用户传来了与键名相同的参数，则直接赋值给$this->query_vars。这里也就是说，我们只能控制$this->query_vars中在$this->public_query_vars中的键名的值，也就是只能控制这些键：

array( 'm', 'p', 'posts', 'w', 'cat',
'withcomments', 'withoutcomments', 's', 'search', 'exact', 'sentence',
'calendar', 'page', 'paged', 'more', 'tb', 'pb', 'author', 'order',
'orderby', 'year', 'monthnum', 'day', 'hour', 'minute', 'second',
'name', 'category_name', 'tag', 'feed', 'author_name', 'static',
'pagename', 'page_id', 'error', 'attachment', 'attachment_id',
'subpost', 'subpost_id', 'preview', 'robots', 'taxonomy', 'term',
'cpage', 'post_type', 'embed' );

回到最开始的main()函数：

public function main( $query_args = '' ) {
    $this->init();//获取当前用户信息
    $this->parse_request( $query_args );//解析路由，匹配路由模式，取出匹配的路由中的用户输入参数（比如year,month等）赋值给$this->query_vars。（并将部分用户参数绑定到$this->query_vars中）。然后进行一些过滤操作。
    $this->send_headers();//设置HTTP响应头，比如Content-Type等
    $this->query_posts();//根据$this->query_vars等参数，获取posts/pages
    $this->handle_404();
    $this->register_globals();

    do_action_ref_array( 'wp', array( &$this ) );
}

接下来的$this->send_headers()用于设置一些HTTP响应头，这里不再跟进，直接跟进到下面一行的$this->query_posts()，这里就是用于显示一些post/page的地方，也就是本次分析的重点。

query_posts()先经过一些设置成员变量的初始化之后进入到/wp-includes/class-wp-query.php:get_posts()。由于这里代码太多，以及本文是针对“未授权查看私密page”漏洞的，所以这里主要盘一下显示post/page以及鉴权的逻辑，其他的细节不再跟入。

这里先是构造SQL语句查询post/page，然后将查询出的结果赋值给$this->posts。

$split_the_query = apply_filters( 'split_the_query', $split_the_query, $this );

if ( $split_the_query ) {
    $this->request = "SELECT $found_rows $distinct {$wpdb->posts}.ID FROM {$wpdb->posts} $join WHERE 1=1 $where $groupby $orderby $limits";
    ...
    $ids = $wpdb->get_col( $this->request );//查询数据库，获取post/page的id
    if ( $ids ) {
        $this->posts = $ids;
        $this->set_found_posts( $q, $limits );//通过id获取page/post
        _prime_post_caches( $ids, $q['update_post_term_cache'], $q['update_post_meta_cache'] );
    } else {
        $this->posts = array();
    }
} else {
    $this->posts = $wpdb->get_results( $this->request );//获取post的内容
    $this->set_found_posts( $q, $limits );
}

这里有两种方法获取，由$split_the_query决定使用哪种方法。目前来看两种方法没有什么区别因此先不跟进split_the_query。

第一次我未登录，并请求urlwordpress-5.2.3/index.php，我们来看一下这里构造成的SQL语句

SELECT SQL_CALC_FOUND_ROWS  wp_posts.ID FROM wp_posts  WHERE 1=1  AND wp_posts.post_type = 'post' AND (wp_posts.post_status = 'publish')  ORDER BY wp_posts.post_date DESC LIMIT 0, 10

这里通过wp_posts.post_status = ‘publish‘限制我们只能看到public状态的post_type=‘post‘的记录，也就是post。

第二次登陆为管理员，访问同样的url，SQL语句变成如下这样

SELECT SQL_CALC_FOUND_ROWS  wp_posts.ID FROM wp_posts  WHERE 1=1  AND wp_posts.post_type = 'post' AND (wp_posts.post_status = 'publish' OR wp_posts.post_status = 'private')  ORDER BY wp_posts.post_date DESC LIMIT 0, 10

除了多了一个OR wp_posts.post_status = ‘private‘其他部分都一模一样，也就是说管理员账号可以看到状态为private的post（废话），因此这里猜测，构造wp_posts.post_status=?的附近可能做了鉴权操作。

往上找，找到了构建where post_status语句的地方

$q_status = array();
if ( ! empty( $q['post_status'] ) ) {//由于本路由中无法设置post_status的值，因此第一个if语句块不看
    $statuswheres = array();
    $q_status     = $q['post_status'];

    ...//根据$q_status构造where子句

} elseif ( ! $this->is_singular ) {
    $where .= " AND ({$wpdb->posts}.post_status = 'publish'";

    ...

    if ( $this->is_admin ) {
        // Add protected states that should show in the admin all list.
        $admin_all_states = get_post_stati(
            array(
                'protected'              => true,
                'show_in_admin_all_list' => true,
            )
        );
        foreach ( (array) $admin_all_states as $state ) {
            $where .= " OR {$wpdb->posts}.post_status = '$state'";
        }
    }

    if ( is_user_logged_in() ) {
        // Add private states that are limited to viewing by the author of a post or someone who has caps to read private states.
        $private_states = get_post_stati( array( 'private' => true ) );
        foreach ( (array) $private_states as $state ) {
            $where .= current_user_can( $read_private_cap ) ? " OR {$wpdb->posts}.post_status = '$state'" : " OR {$wpdb->posts}.post_author = $user_id AND {$wpdb->posts}.post_status = '$state'";
        }
    }

    $where .= ')';
}

这里我们只需要看elseif()语句块，里面显示拼接一个public，然后根据is_admin和is_user_logged_in()来添加一些其他的post_status比如private。由于我们的目标是‘未登录用户访问private内容’，这里暂且不考虑是否能绕过is_admin或者is_user_logged_in()底层的缺陷（当然也不太可能），仅从逻辑上看，如果我们不进入这个elseif语句块，不构建这个where岂不是能读到所有的page/post了？

这个elseif的条件是(!$this->is_singular)，我们的目标是让$this->is_singular为正逻辑即可（比如true）。回溯这个变量，找到一处

$this->is_singular = $this->is_single || $this->is_page || $this->is_attachment;

我们只要让这三个变量的任何一个值为true即可，向上找，比较明显的是这处：

if ( ( '' != $qv['attachment'] ) || ! empty( $qv['attachment_id'] ) ) {
    $this->is_single     = true;
    $this->is_attachment = true;
} elseif ( '' != $qv['name'] ) {//wp_posts.post_name
    $this->is_single = true;
} elseif ( $qv['p'] ) {//wp_posts.ID
    $this->is_single = true;
} elseif ( ( '' !== $qv['hour'] ) && ( '' !== $qv['minute'] ) && ( '' !== $qv['second'] ) && ( '' != $qv['year'] ) && ( '' != $qv['monthnum'] ) && ( '' != $qv['day'] ) ) {
    $this->is_single = true;
} elseif ( '' != $qv['static'] || '' != $qv['pagename'] || ! empty( $qv['page_id'] ) ) {
    $this->is_page   = true;
    $this->is_single = false;
} else {
    ...
}

可见我们只要设置$qv的几个键就好了，比如：attachment、name、p、static等。通过回溯$qv，发现$qv=&$this->query_vars;。query_vars中我们能控制的键只有上文中的$this->public_query_vars里的那些也就是

array( 'm', 'p', 'posts', 'w', 'cat',
'withcomments', 'withoutcomments', 's', 'search', 'exact', 'sentence',
'calendar', 'page', 'paged', 'more', 'tb', 'pb', 'author', 'order',
'orderby', 'year', 'monthnum', 'day', 'hour', 'minute', 'second',
'name', 'category_name', 'tag', 'feed', 'author_name', 'static',
'pagename', 'page_id', 'error', 'attachment', 'attachment_id',
'subpost', 'subpost_id', 'preview', 'robots', 'taxonomy', 'term',
'cpage', 'post_type', 'embed' );

可以看到：attachment、name、p、static这几个键我们都能控制，只要在url参数中直接传就好了。可是通过对比可以很明显的发现，除了最后一个elseif语句块里的is_single为false，其余都为true，也就是只取一条post/page/attachment，通过参数名也可以看出来，如果传递p参数，则只在数据库中找wp_posts.ID匹配的数据，传递name参数则只匹配wp_posts.post_name相同的数据。因此经过对比，这里只有传入static=xxx时，既能绕过后面的where private的限制，也能取出所有数据。

下面开始限制请求的数据类型，page/post/attachment。

if ( 'any' == $post_type ) {
    $in_search_post_types = get_post_types( array( 'exclude_from_search' => false ) );
    if ( empty( $in_search_post_types ) ) {
        $where .= ' AND 1=0 ';
    } else {
        $where .= " AND {$wpdb->posts}.post_type IN ('" . join( "', '", array_map( 'esc_sql', $in_search_post_types ) ) . "')";
    }
} elseif ( ! empty( $post_type ) && is_array( $post_type ) ) {
    $where .= " AND {$wpdb->posts}.post_type IN ('" . join( "', '", esc_sql( $post_type ) ) . "')";
} elseif ( ! empty( $post_type ) ) {
    $where .= $wpdb->prepare( " AND {$wpdb->posts}.post_type = %s", $post_type );
    $post_type_object = get_post_type_object( $post_type );
} elseif ( $this->is_attachment ) {
    $where .= " AND {$wpdb->posts}.post_type = 'attachment'";
    $post_type_object = get_post_type_object( 'attachment' );
} elseif ( $this->is_page ) {
        $where .= " AND {$wpdb->posts}.post_type = 'page'";
    $post_type_object = get_post_type_object( 'page' );
} else {
    $where .= " AND {$wpdb->posts}.post_type = 'post'";
    $post_type_object = get_post_type_object( 'post' );
}

可以看到post_type为空时，如果is_page为true则设置post_type为page，因此只能获取page类型的数据。

通过设置static=xxx，调试之后可以看到最终的SQL语句如下，已经没有了post_status是public还是private的限制：

SELECT   wp_posts.* FROM wp_posts  WHERE 1=1  AND wp_posts.post_type = 'page'  ORDER BY wp_posts.post_date DESC

此时所有的page已经全部存储到$this->posts中，下面要看看这些posts是否会渲染出来。以下是相关代码


// Check post status to determine if post should be displayed.
if ( ! empty( $this->posts ) && ( $this->is_single || $this->is_page ) ) {
    $status = get_post_status( $this->posts[0] );//获取$this->posts中的第一个元素的post_status
    ...
    $post_status_obj = get_post_status_object( $status );

    // If the post_status was specifically requested, let it pass through.
    if ( ! $post_status_obj->public && ! in_array( $status, $q_status ) ) {//如果post_status_obj的public属性为true或post_status在$q_status中，则不进入此if。由于本文前面已经分析$q_status不可控且为空，因此主要看第一个条件。

        if ( ! is_user_logged_in() ) {
            // User must be logged in to view unpublished posts.
            $this->posts = array();//无权限查看
        } else {
            if ( $post_status_obj->protected ) {
                ...更细的鉴权
            } elseif ( $post_status_obj->private ) {
                if ( ! current_user_can( $read_cap, $this->posts[0]->ID ) ) {
                    $this->posts = array();//无权限查看
                }
            } else {
                $this->posts = array();//无权限查看
            }
        }
    }

    ...
}

由于$this->posts是我们要读的pages，且is_page为true，因此第一个if判断是必进的。接下来就是有意思的地方了，下面获取了$this->posts中的第一篇文章，如果其是public就可以不进入第二个if语句，从而就直接绕过了“回显鉴权”这一部分。所以我们只要保证$this->posts的第一篇文章为public状态的即可。通过order by我们可以把最旧的文章放在最上面，也就是正序asc查询，因为一般来说旧的文章权限为public的可能性大一些。

之前的SQL语句为

SELECT   wp_posts.* FROM wp_posts  WHERE 1=1  AND wp_posts.post_type = 'page'  ORDER BY wp_posts.post_date DESC

通过回溯发现可以通过$this->query_vars[‘order‘]来控制升序还是降序，因此我们只要在url中加上order=asc即可。

回顾上面的分析整理一下逻辑，传入static=xxx -> is_page===true -> is_singular===true -> 不使用where子句限定private/public/... -> 获取所有page -> 最后显示前鉴权时仅检查第一个page的权限。

把这个逻辑抽象出来可以知道，在只取得一个page/post时是没问题的，因为最后display之前会进行一次鉴权。我们的主要关注点是获得多条数据，因为这样会绕过最后display之前只验证第一条数据的鉴权操作。保证获得多条数据的同时又要保证$this->is_single，$this->is_page，$this->is_attachment其中一个是true才能绕过where子句的限制。

逻辑出来了，官方补丁是删除了static变量，是否可以绕过这个补丁？首先回顾一下初始化这几个成员变量的地方：

if ( ( '' != $qv['attachment'] ) || ! empty( $qv['attachment_id'] ) ) {
    $this->is_single     = true;
    $this->is_attachment = true;
} elseif ( '' != $qv['name'] ) {//wp_posts.post_name
    $this->is_single = true;
} elseif ( $qv['p'] ) {//wp_posts.ID
    $this->is_single = true;
} elseif ( ( '' !== $qv['hour'] ) && ( '' !== $qv['minute'] ) && ( '' !== $qv['second'] ) && ( '' != $qv['year'] ) && ( '' != $qv['monthnum'] ) && ( '' != $qv['day'] ) ) {
-$this->is_single = true;
} elseif ( '' != $qv['static'] || '' != $qv['pagename'] || ! empty( $qv['page_id'] ) ) {
    $this->is_page   = true;
    $this->is_single = false;
} else {
    ...
}

把这几个if条件都带入程序中走一遍发现，除了static这个语句块，其之前的所有if条件都将查询的结果限制到了<=1条，从而不会存在逻辑问题，这也是is_single的含义。官方修复的补丁是将这个static参数去掉，变成了elseif(‘‘!=$qv[‘pagename‘] || !empty($qv[‘page_id‘]))，而这个条件也限制了只能取得一页，但是is_single这里是false不知道是什么原因。似乎是安全的？

0x02 思考

经过一番思考之后感觉这个补丁并没有从根本上解决问题，如果可以获得多条数据并且没有where子句的限制仍然可以触发漏洞。刚刚说了，那几个if条件都将查询的结果限制到了<=1条，但是这样真的就安全了？如果程序将这些参数拼接到类似于where ... wp_posts.post_name like $qv[‘name‘]还是会出现问题，这里就不展开说了。我大概找了一下，明显的地方没有看到这样的用法，但是还有一些稍微底层的函数没有跟，这里先留了一个坑。

0x03 总结

在分析漏洞时一直在尝试逆推作者的挖洞思路，可是由于我之前分析SQL注入、反序列化这类漏洞比较多，对于这种逻辑漏洞的挖掘还是有些陌生的。对于逻辑漏洞，我认为分析时不适合SQL注入、XSS那种通过漏洞点反推的方式，不够‘自然’，而是应该先通过了解出现逻辑错误的功能模块的实现，然后结合官方diff来做会好一些。

0x04 参考

CVE-2019-17671
受影响版本
Wordpress 5.2.3 未授权页面查看漏洞（CVE-2019-17671）分析

原文地址：https://www.cnblogs.com/litlife/p/11980530.html

时间： 2024-11-13 12:24:15

Wordpress未授权查看私密内容漏洞 分析（CVE-2019-17671）的相关文章

jboss 未授权访问漏洞复现

一.漏洞描述 未授权访问管理控制台,通过该漏洞,可以后台管理服务,可以通过脚本命令执行系统命令,如反弹shell,wget写webshell文件. 二.漏洞环境搭建及复现 1. 这里用CVE-2017-7504的漏洞环境,启动环境 docker-compose up -d 2. 浏览器访问http://172.17.0.1:8080/ 3.发现jboss默认页面,点击进入控制页 4.点击jboss.deployment进入应用部署页面 5.使用apache搭建远程木马服务器 6.通过addurl

[CVE-2017-5487] WordPress &lt;=4.7.1 REST API 内容注入漏洞分析与复现

不是很新的漏洞,记录下自己的工作任务 漏洞影响: 未授权获取发布过文章的其他用户的用户名.id 触发前提:wordpress配置REST API 影响版本:<= 4.7 0x01漏洞复现 复现环境: 1) Apache2.4   2) PHP 7.0   3) wordPress 4.7.1 https://wordpress.org/wordpress-4.7.1.tar.gz)并安装 (点击下载) 确认 Httpd-conf  Allowover All Exploit: https://w

Memcached 未授权访问漏洞及加固

memcached是一套分布式的高速缓存系统.它以Key-Value(键值对)形式将数据存储在内存中,这些数据通常是应用读取频繁的.正因为内存中数据的读取远远大于硬盘,因此可以用来加速应用的访问. 漏洞成因: 由于memcached安全设计缺陷,客户端连接memcached服务器后 无需认证就 可读取.修改服务器缓存内容. 漏洞影响: 除memcached中数据可被直接读取泄漏和恶意修改外,由于memcached中的数据像正常网站用户访问提交变量一样会被后端代码处理,当处理代码存在缺陷时会再次导

记录一次攻击事件(redis 未授权漏洞利用直接登录服务器)

听到朋友说接到阿里云的报障,提示黑客把他的服务器当肉鸡了,当时有点怕怕,继而官方的网络带宽也爆了进而系统处于瘫痪,当时我需要帮他处理这个问题 1 在没有查到杀手之前我是先把带宽&端口用iptables 做了限制这样能保证我能远程操作服务器才能查找原因 2 在各种netstat –ntlp  的查看下没有任何异常 在top 下查到了有异常进程还有些异常的这里就截图一个 3 结果果断把进程给kill -9  了  没想到再去ps的时候又来了意思就是会自动启动它 这就让我想到了crond 这个自动任务

Redis未授权访问漏洞的利用及防护

Redis未授权访问漏洞的利用及防护 什么是Redis未授权访问漏洞? Redis在默认情况下,会绑定在0.0.0.0:6379.如果没有采取相关的安全策略,比如添加防火墙规则.避免其他非信任来源IP访问等,这样会使Redis服务完全暴露在公网上.如果在没有设置密码认证(一般为空)的情况下,会导致任意用户在访问目标服务器时,可以在未授权的情况下访问Redis以及读取Redis的数据.攻击者在未授权访问Redis的情况下,利用Redis自身的提供的config命令,可以进行文件的读写等操作.攻击者

Redis未授权访问漏洞复现

漏洞复现 攻击机 kali  ip:192.168.70.140 靶机 Ubuntu 16.04   ip:192.168.70.133 一.环境搭建 1.下载安装redis wgethttp://download.redis.io/releases/redis-3.2.11.tar.gz 2. 解压压缩包 tarzxvfredis-3.2.11.tar.gz. 3.进入解压目录redis-3.2.11 执行make命令 4. 进入src目录 cd redis-3.2.11/src 5.将red

Redis未授权访问漏洞分析

catalog 1. Redis简介 2. 漏洞概述 3. 漏洞利用方式 4. 修复方式 1. Redis简介 Relevant Link: http://www.cnblogs.com/LittleHann/p/3901588.html 2. 漏洞概述 Redis 默认情况下,会绑定在 0.0.0.0:6379,这样将会将 Redis 服务暴露到公网上,如果在没有开启认证的情况下,可以导致任意用户在可以访问目标服务器的情况下未授权访问 Redis 以及读取 Redis 的数据.攻击者在未授权访

修补--Redis未授权访问漏洞

--------------------------------阿里云解决方案----------------------------------- 一.漏洞描述 Redis因配置不当可以导致未授权访问,被攻击者恶意利用.当前流行的针对Redis未授权访问的一种新型攻击方式,在特定条件下,如果Redis以root身份运行,黑客可以给root账户写入SSH公钥文件,直接通过SSH登录受害服务器,可导致服务器权限被获取和数据删除.泄露或加密勒索事件发生,严重危害业务正常服务. 二.Redis安全漏洞

Linux 由于redis未授权漏洞被攻击

早上睡觉被一条条的阿里云服务器告警信息惊醒,提示我的服务器CPU使用率超过80%,我就纳闷了我的服务器平时CPU使用率还不到10%,这次怎么会这么高.服务器有异常是肯定的了,我的服务器在云控制台配置了安全组策略,服务器修改了ssh端口,开启了防火墙,设置了hosts.allow hosts.deny等防范措施.这都能被攻击我也是醉了. 登上服务器,首先用top查看 [[email protected] ~]# top top - 08:35:19 up 127 days, 13:32,  2 u