一、概述

由于WordPress处理权限的方式存在缺陷，可能会导致WordPress插件中出现权限提升的问题。这一问题直接影响WooCommerce插件，这是一个更受欢迎的电子商务插件，其安装量已经超过400万。这一漏洞允许商店管理员删除服务器上的某些文件，同时能够接管任何管理员账户。

 

二、影响

我们发现并报告了WooCommerce中的文件删除漏洞，该漏洞已经在3.4.6版本中实现修复。在大多数情况下，任意文件删除漏洞都不被认为是关键问题，因为攻击者借助这一漏洞，最多只能删除网站的index.php，从而导致拒绝服务。本文详细说明了如何删除WordPress中的某些插件文件，从而禁用安全检查，然后导致攻击者完全接管网站。这一漏洞源自于WordPress特权系统中某些未修复的设计缺陷。目前，有400万WooCommerce商店受到这一漏洞影响。要实现攻击，只需要攻击者事先拥有一个商店经理的权限。商店经理是商店的员工，具有管理订单、产品和客户的权限。攻击者可以通过XSS漏洞或 *** 钓鱼攻击来获取此类权限，一旦利用这个漏洞，商店经理就可以接管任何管理员账户，然后在服务器上执行代码。演示视频：https://blog.ripstech.com/videos/wordpress-design-flaw.mp4

 

三、技术分析

3.1 漏洞位置

WordPress的权限控制方式是将不同的功能分配给不同角色。在定义商店经理角色之后，会为其分配edit_users功能，以便他们编辑商店中客人的帐户。这一过程，在插件的安装过程中进行。woocommerce/includes/class-wc-install.php：

// 商店经理角色

add_role(

    'shop_manager',      // 新角色的内部名称

    'Shop manager',      // 显示的标签

    array(               // 功能

                ⋮

        'read_private_posts'     => true,

        'edit_users'             => true,

        'edit_posts'             => true,

                ⋮

    )

);

然后，该角色将作为WordPress的核心设置，存储在数据库中。这意味着，此时用户角色已经独立于插件。即使插件处于非活动状态，用户也会存在。经过身份验证的用户每次尝试对另一个用户进行编辑时，都会调用current_user_can()，以确保只有特权用户才能执行该操作。调用current_user_can()的样例：

$target_user_id = $_GET['target_user_id'];

if(current_user_can('edit_user', $target_user_id)) {

    edit_user($target_user_id);

}

其调用逻辑是：判断用户是否可以以ID为$target_user_id的身份尝试编辑特定用户。默认情况下，edit_users功能允许拥有这一权限的用户（例如商店经理）编辑任何用户，甚至包括管理员，同时也能够执行更新密码等操作。但出于安全原因，WooCommerce允许商店经理编辑仅具有客户角色的用户。因此，WooCommerce这类插件添加了元功能。元功能是以被current_user_can()调用的函数来实现的。元特权函数的返回值将决定当前用户是否可以执行该操作，因此它并不会简单地默认返回True。WooCommerce元特权过滤器的简化版本如下所示。元功能样例：

function disallow_editing_of_admins( $capability, $target_user_id ) {

    // If the user is an admin return false and disallow the action

    if($capability == "edit_user" && user_is_admin($target_user_id)) {

        return false;

    } else {

        return true;

    }

}

add_filter( 'map_meta_cap', 'disallow_editing_of_admins');

例如，当调用current_user_can(‘edit_user’, 1)时，将执行过滤器，从而确定ID为1（$target_user_id）的用户是否为admin。如果是，则禁止编辑操作，并返回False。否则，将会让用户继续下一步操作。针对WooCommerce，更复杂的元功能存储在第408行的woocommerce/includes/wc-user-functions.php中。

3.2 设计缺陷

尽管这些过滤器能实际工作，但只有当插件处于活动状态时才会执行。这里的关键在于，用户角色将存储在数据库中，即使禁用了插件，这些用户角色也会存在。这就意味着，如果由于某种原因WooCommerce被禁用，那么负责限制商店经理不能对管理员用户进行编辑的元权限检查将无法执行，WordPress将恢复到默认状态，即允许具有edit_users功能权限的用户编辑任何用户（包含管理员）。这样一来，就允许商店经理更新管理员帐户的密码，从而接管整个站点。

3.3 如何以商店经理身份禁用插件

默认情况下，只有管理员可以禁用插件。然而，我们发现的任意文件删除漏洞，允许商店经理删除服务器上任何可写的文件。假如以商店经理身份，删除WooCommerce的主文件woocommerce.php，那么WordPress将无法加载插件，随后会将其禁用。在WooCommerce的日志记录功能中出现了文件删除漏洞。日志以.log文件的形式，存储在wp-content目录中。当商店经理想要删除日志文件时，会将文件名作为GET参数提交。如下面的代码片段所示，这是一个不安全的处理方式。woocommerce/includes/admin/class-wc-admin-status.php：

class WC_Admin_Status{

    public static function remove_log()

    {

    ⋮

        $log_handler = new WC_Log_Handler_File();

        $log_handler->remove(wp_unslash($_REQUEST['handle']));

    }

woocommerce/includes/log-handlers/class-wc-log-handler-file.php：

class WC_Log_Handler_File extends WC_Log_Handler

{

    public function remove($handle)

    {

    ⋮

        $file = trailingslashit(WC_LOG_DIR) . $handle;

    ⋮

    unlink($file);

关键问题在于，当文件名（$handle）被附加到Log目录（wp-content/wc-logs/）后，会被传递到unlink()。当设置$handle../../plugins/woocommerce-3.4.5/woocommerce.php文件时，wp-content/wc-logs/../../plugins/woocommerce-3.4.5/woocommerce.php文件将会被删除，从而导致WooCommerce被禁用。

我们使用SAST解决方案的RIPS自动检测到文件删除漏洞，相关报告请参考：http://demo.ripstech.com/projects/woocommerce_3.4.5/

 

四、时间节点

2018年8月30日 将任意文件删除漏洞报告给Hackerone的Automattic安全团队

2018年9月11日 该漏洞由安全团队进行分类和验证

2018年10月11日 补丁发布。

五、总结

在之前的文章中，我们演示了如何利用WordPress中的文件删除漏洞，以及如何将文件删除漏洞提升为远程代码执行漏洞。该 *** 的缺点是导致目标站点上的所有数据丢失。而本文中所提出的 *** 主要利用WordPress插件中的文件删除漏洞，针对元权限实现权限提升。这样的设计缺陷仍然存在。文件删除漏洞并不罕见，甚至有可能发生在WordPress的核心部分之中。在某些情况下，文件删除漏洞也可以通过Phar反序列化来利用。