Wordpress4.9.6 reproduce any file deletion vulnerability analysis

Chapter One Introduction vulnerability and hazard analysis

Vulnerabilities 1.1 Introduction

WordPress can be said of today's most popular (I want to say no one) PHP-based open source CMS, its current up to several million users worldwide, and has more than 46 million times ultrahigh downloads. It is an open source system, followed by its function is very powerful, the source code can be found here . Which is why, WordPress has become the goal of many hackers, which means once succeeded millions of users fall. This broad adoption makes it an interesting target for cybercriminals. The experiment is a vulnerability in the WordPress core of any authenticated document removes the vulnerability CVE-2018-20714

The vulnerability could allow an attacker to execute arbitrary code. Since the discovery of the vulnerability reported to the WordPress security team to 7 months , but has not yet repair. Since the first report has passed a long time without any patches or specific plans. Now wordpress4.9.6 and the following versions of this vulnerability.

1.2 Conditions of use loopholes

To exploit the vulnerability discussed below, the attacker needs to get advance permission to edit and delete media files. That is, have author permissions. Here we have to look at what wordpress user permissions.

• Super Administrator (Super Admin) - the right to access the site network management functions and all other functions.
• Administrator (Administrator) - all have access to management functions within a single site.
• Editing (Editor) - can publish and manage posts, including the posts of other users.
• Author (Author) - can publish and manage their own posts.
• Contributor (Contributor) - You can write and manage their posts but not publish.
• Subscribers (Subscriber) - who can only manage their personal information.

We found that users had only Author permissions can publish and manage their own posts, but by this vulnerability but can hijack the entire site and execute arbitrary code on the server, WordPress is by this flaw, an attacker can easily control the site.

One of the core functions of WordPress vulnerability exists when the user permanently deletes the thumbnail image upload running in the background.

1.3 Hazard Vulnerability

It requires at least one of the accounts will automatically reduce the severity of this vulnerability to some extent, which may be exploited by hackers or rogue content writer phishing, password reuse, or otherwise offensive obtain the author's credentials in some way exploited .

Exploit this vulnerability could allow an attacker to delete any files WordPress installation (+ PHP process user with any other file on the server to delete permissions). In addition to the possibility of erasing the entire WordPress installation, if there is no current backup available could bring disastrous consequences, an attacker can take advantage of the ability to delete any file to circumvent security measures and execute arbitrary code on a Web server. More precisely, you can delete the following files:

• .htaccess : Typically, delete the file without any safety consequences. However, in some cases, .htaccess file contains the constraints related to the security (for example, access to certain folders constraints). Delete this file will disable these security constraints.
• index.php file: usually empty index.php file in the directory in order to prevent the Web server can not perform the directory listing for this operation. Deleting these files will be awarded to the attacker by this measure to protect the directory listing of all files.
• config.php-WP : delete the file will install WordPress WordPress installation process is triggered when the next time you visit the site. This is because the wp-config.php contains database credentials, and without its presence, WordPress has not been installed just the same. An attacker can delete this file, he chose to use for the administrator account credentials installation process, and finally execute arbitrary code on the server.

However, it should be noted that, since the attacker can not read the contents of wp-config.php file directly to know the existing "database name", "mysql username" and "password", so he can re-set the target site using a remote database server under his control. Once completed, the attacker can create a new administrator account and complete control of the site, including the ability to execute arbitrary code on the server. "In addition to the possibility of deleting the entire WordPress installation, if there is no current backup available will result in disastrous consequences, an attacker can use any file deletion functions to circumvent security measures and execute arbitrary code on a Web server

 

Chapter Two vulnerabilities environment to build and reproduce

2.1 build environment

Go wordpress Chinese official website https://cn.wordpress.org/download/releases/ download version has this vulnerability

(1) Installation wordpress

WordPress 4.9.6

 

After successful installation, in the background add an "author" privilege account "xy" only writing features for testing

2.2 vulnerability testing reproducibility

(1) with the landing of the newly added user permissions to the site background

(2) add media, upload an image

  

(3) Click Edit

(4) identify _wpnonce value in the page source code, find the value of "388054b4f3" cookie copy and page down by source.

 

(5) and then use the curl, or burp configured http request.

Configured to send the packet repeater then transmits the packet post (required value into the cookie)

payload: action=editattachment&_wpnonce=388054b4f3&thumb=../../../../wp-config.php'   

POST /wp-admin/post.php?post=21&action=edit HTTP/1.1 

发送成功会返回302状态

 

（6）此时在点击删除按钮

（7）抓包查看，也是返回302包

（8）再次访问主网站就会要求重新安装wordpress

 

 

第三章 漏洞代码审计以及临时手动修复

 

3.1 源码审计

（1）既然是任意文件删除漏洞，那我们就从删除功能入手，先来看wp-admin/post.php的246-268行：

case 'delete':

    check_admin_referer('delete-post_' . $post_id);

 

    if ( ! $post )

        wp_die( __( 'This item has already been deleted.' ) );

 

    if ( ! $post_type_object )

        wp_die( __( 'Invalid post type.' ) );

 

    if ( ! current_user_can( 'delete_post', $post_id ) )

        wp_die( __( 'Sorry, you are not allowed to delete this item.' ) );

 

    if ( $post->post_type == 'attachment' ) { //删除附件

        $force = ( ! MEDIA_TRASH );

        if ( ! wp_delete_attachment( $post_id, $force ) )

            wp_die( __( 'Error in deleting.' ) );

    } else {

        if ( ! wp_delete_post( $post_id, true ) )

            wp_die( __( 'Error in deleting.' ) );

    }

 

    wp_redirect( add_query_arg('deleted', 1, $sendback) );

    exit();

 

（2）由于我们删除的是图片附件，所以程序会进入wp_delete_attachment函数，跟进：  wp-include/post.php，函数太长，只截取关键部分。

function wp_delete_attachment( $post_id, $force_delete = false ) {
.... 
    if ( ! empty($meta['thumb']) ) {
    // Don't delete the thumb if another attachment uses it.
    if (! $wpdb->get_row( $wpdb->prepare( "SELECT meta_id FROM $wpdb->postmeta WHERE meta_key = '_wp_attachment_metadata' AND meta_value LIKE %s AND post_id <> %d", '%' . $wpdb->esc_like( $meta['thumb'] ) . '%', $post_id)) ) {
        $thumbfile = str_replace(basename($file), $meta['thumb'], $file);
        /** 该过滤器记录在wp-includes / functions.php中 */
        $thumbfile = apply_filters( 'wp_delete_file', $thumbfile );
        @ unlink( path_join($uploadpath['basedir'], $thumbfile) );
    }
}
. . . .
 
wp_delete_file( $file );

 

$meta['thumb']来自与数据库，是图片的属性之一。代码未检查$meta['thumb']的内容，直接带入unlink函数，如果$meta['thumb']可控

 (3) 那么可控点在哪呢？还记得漏洞利用的第一步吗？现在我们就回到wp-admin/post.php看一下具体代码

/wp-admin/post.php

 
//178-189行
case 'editattachment':
    check_admin_referer('update-post_' . $post_id);
 
    // Don't let these be changed
    unset($_POST['guid']);
    $_POST['post_type'] = 'attachment';
 
    // Update the thumbnail filename
$newmeta = wp_get_attachment_metadata( $post_id, true ); 
//获取附件的属性
    $newmeta['thumb'] = $_POST['thumb'];
 
wp_update_attachment_metadata( $post_id, $newmeta );
 //更新数据库中的信息

代码片段/wp-admin/post.php表示如何将属于附件的缩略图的文件名保存到数据库中。在从保存的用户输入检索$_POST[‘thumb’]和保存到数据库wp_update_attachment_metadata()之间，没有安全措施来确保该值确实代表正在编辑的附件的缩略图。值$_POST[‘thumb’]可以变更修改为相对于WordPress上传目录的任何文件的路径，当附件被删除时，文件将被删除，如第一个列表中所示。

总结一句就是该漏洞出现的原因是由于在WordPress的wp-includes/post.php文件中wp_delete_attachement()函数在接收删除文件参数时未进行安全处理，直接进行执行导致。

3.2临时手动修复

（1）在上面我们了解了漏洞生成的原因之后，我们将进行尝试性的漏洞修复。

首先针对漏洞细节提出修复方向

1. 过滤. \等关键字符

2. 挂钩wp_update_attachement_metadata()调用并确保为meta[‘thumb’]值提供的数据thumb不包含任何可以进行路径遍历的部分.

3. 将$newmeta['thumb'] = $_POST['thumb'];改为$newmeta['thumb'] = basename($_POST['thumb']);

（2）修复代码

通过将修复程序添加到functions.php当前活动的主题/子主题的文件中，可以将修复程序集成到现有的WordPress安装中。

add_filter('wp_update_attachment_metadata','rips_unlink_tempfix';
 
function rips_unlink_tempfix( $data ) {
    if( isset($data['thumb']) ) {
        $data['thumb'] = basename($data['thumb']);
    }
 
    return $data;
}

 

我们将补丁放入指定位置之后，再来测试漏洞。

 

可以看到在手动打了补丁之后，虽然发包和回显跟之前区别不大，但是已经无法任意删除文件了

 

第四章 漏洞操作的流量分析

总体操作与上文漏洞复现差不多，但为了监控流量和避免干扰便于分析，本次操作在虚拟机中进行并使用wireshark分析流量。

（1）使用wireshark捕获恶意操作的流量数据

 

 

 

服务器返回302

我们发现恶意数据最主要的特征就是向服务器传入了一个“thumb”自定义的值

（2）我们追踪这个包的tcp流

 

 

 

也出现了我们构造的关键代码，但由于这个漏洞可以删除任意文件，所以我们需要关注的就是thumb传入的数值，不管上传请求的方式是什么，总需要传入

thumb=xxxx

所以当流量中出现这些异常并指定thumb的值的时候，就需要引起我们的注意，要查看数值是否合法。