Site Kit by Google 1.7.1及以下可授权攻击者访问Search Console

4月21日,Wordfence的威胁情报小组在Site Kit by Google插件中发现了一个漏洞,这是一个安装在300,000多个网站上的WordPress插件。漏洞使任何经过身份验证的用户(无论能力如何)都可以成为运行Google站点套件的任何网站的Google Search Console所有者。

Google Search Console 是谷歌官方的站长管理平台,和百度站长资源平台类似,都是用来提交网站数据以及监控收录信息的。

Site Kit by Google 是一个插件,用于从WordPress信息中心中的Google服务获取并显示有关网站访问者和搜索效果的洞察力,以及广告效果,页面速度洞察力和其他指标。为此,它首先连接到Google Search Console帐户,然后提供附加功能以连接到Analytics(分析),AdSense,PageSpeed Insights,Optimize和Tag Manager。

Wordfence于2020年4月21日向Google提交了安全问题报告。几周后的2020年5月7日,谷歌发布了补丁。

这被认为是至关重要的安全问题,可能导致攻击者在Google Search Console中获得所有者对您网站的访问权限。所有者访问权限使攻击者可以修改站点地图,从Google搜索引擎结果页面(SERP)中删除页面,或促进黑帽SEO广告系列。我们强烈建议立即更新此插件的最新版本。在撰写本文时,即Google的Site Kit版本1.8.0。

Wordfence Premium客户在2020年4月21日收到了一条新的防火墙规则,以防止针对此漏洞的攻击。免费的Wordfence用户将在2020年5月21日的30天后收到此规则。

为了与Site Kit和Google Search Console建立第一个连接,该插件会生成proxySetupURL,该URL用于将网站管理员重定向到Google OAuth,并通过代理运行网站所有者验证过程。

proxySetupURL披露

由于缺乏对操作的功能检查admin_enqueue_scripts,proxySetupURL作为管理页面的HTML源代码的一部分显示给访问/ wp-admin仪表板的任何经过身份验证的用户。

更具体地说,admin_enqueue_scripts操作触发了enqueue_minimal_admin_script使googlesitekit-base脚本入队的函数,并最终包含返回内联基本数据的'googlesitekit-base-data'。包括proxySetupURL。

new Script_Data(
            'googlesitekit-base-data',
            array(
                'global'        => '_googlesitekitBaseData',
                'data_callback' => function () {
                    return $this->get_inline_base_data();
                },
            )
        ),

这是inline_js_base_data函数的一部分,该函数检索数据以显示在WordPress仪表板的源代码中admin_enqueue_scripts。这包括proxySetupURL。

/**
 * Modifies the base data to pass to JS.
 *
 * @since 1.2.0
 *
 * @param array $data Inline JS data.
 * @return array Filtered $data.
 */
private function inline_js_base_data( $data ) {
    $first_admin_id  = (int) $this->first_admin->get();
    $current_user_id = get_current_user_id();
 
    // If no first admin is stored yet and the current user is one, consider them the first.
    if ( ! $first_admin_id && current_user_can( Permissions::MANAGE_OPTIONS ) ) {
        $first_admin_id = $current_user_id;
    }
    $data['isFirstAdmin'] = ( $current_user_id === $first_admin_id );
    $data['splashURL']    = esc_url_raw( $this->context->admin_url( 'splash' ) );
 
    $auth_client = $this->get_oauth_client();
    if ( $auth_client->using_proxy() ) {
        $access_code                 = (string) $this->user_options->get( Clients\OAuth_Client::OPTION_PROXY_ACCESS_CODE );
        $data['proxySetupURL']       = esc_url_raw( $auth_client->get_proxy_setup_url( $access_code ) );
        $data['proxyPermissionsURL'] = esc_url_raw( $auth_client->get_proxy_permissions_url() );
    }
 
    return $data;
}

仔细查看管理控制台的源代码中可发现的数据:

通过在操作中添加功能检查,此问题已在插件的最新版本中修复admin_enqueue_scriptsinline_js_base_data对于没有适当特权的用户(例如订户),这禁止将其包含在管理页面中。这样可以防止将proxySetupURL显示给未经授权的用户。

无保护的验证

除了向任何经过身份验证的用户显示proxySetupURL之外,我们还发现,用于验证网站所有权的验证请求是注册的管理员操作,同样,该操作没有任何功能检查。这允许验证请求来自任何经过身份验证的WordPress用户,包括那些权限最小的用户。

admin_action_googlesitekit_proxy_setup动作已在此处注册。

add_action(
        'admin_action_' . Google_Proxy::ACTION_SETUP,
        function () {
            $this->verify_proxy_setup_nonce();
        },
        -1
    );
 
    add_action(
        'admin_action_' . Google_Proxy::ACTION_SETUP,
        function () {
            $code      = $this->context->input()->filter( INPUT_GET, 'googlesitekit_code', FILTER_SANITIZE_STRING );
            $site_code = $this->context->input()->filter( INPUT_GET, 'googlesitekit_site_code', FILTER_SANITIZE_STRING );
 
            $this->handle_site_code( $code, $site_code );
            $this->redirect_to_proxy( $code );
        }
    );

这是处理验证请求的函数:

/**
 * Handles receiving a verification token for a user by the authentication proxy.
 *
 * @since 1.1.0
 * @since 1.1.2 Runs on `admin_action_googlesitekit_proxy_setup` and no longer redirects directly.
 */
private function handle_verification_token() {
    $verification_token = $this->context->input()->filter( INPUT_GET, 'googlesitekit_verification_token', FILTER_SANITIZE_STRING );
    $verification_type  = $this->context->input()->filter( INPUT_GET, 'googlesitekit_verification_token_type', FILTER_SANITIZE_STRING );
    $verification_type  = $verification_type ?: self::VERIFICATION_TYPE_META;
 
    if ( empty( $verification_token ) ) {
        return;
    }
 
    switch ( $verification_type ) {
        case self::VERIFICATION_TYPE_FILE:
            $this->authentication->verification_file()->set( $verification_token );
            break;
        case self::VERIFICATION_TYPE_META:
            $this->authentication->verification_meta()->set( $verification_token );
    }
 
    add_filter(
        'googlesitekit_proxy_setup_url_params',
        function ( $params ) use ( $verification_type ) {
            return array_merge(
                $params,
                array(
                    'verify'              => 'true',
                    'verification_method' => $verification_type,
                )
            );
        }
    );
}

看一下在此过程中发送的验证请求:
/wp-admin/index.php?action=googlesitekit_proxy_setup&googlesitekit_code=[SITEKIT-CODE]&googlesitekit_verification_token=[VERIFICATION TOKEN]&googlesitekit_verification_token_type=FILE&nonce=[NONCE]

在最新版本中已修复此问题,并在功能上添加了handle_verification_token功能检查,以验证在与具有通过Google插件设置Site Kit的管理权限的用户进行的合法身份验证会话期间是否发生了验证请求。

if ( ! current_user_can( Permissions::SETUP ) ) {
    wp_die( esc_html__( 'Sorry, you are not allowed to do that.', 'google-site-kit' ), 403 );
}

这两个缺陷使订阅者用户有可能成为任何受影响网站上的Google Search Console所有者。

影响

在Google Search Console中为财产设置新所有者后,会通过电子邮件发送一条消息,内容为:“财产所有者可以更改影响Google搜索与您的网站或应用交互方式的关键设置。”

攻击者可以通过多种方式利用网站的Google Search Console所有者访问权限。对于恶意攻击者而言,通过Blackhat SEO操纵搜索引擎结果页面的功能特别有吸引力。此外,攻击者可能将Search Console访问与另一种利用方式结合使用,后者涉及将恶意内容注入网站以获利。

Google Search Console中的所有者可以执行以下操作:请求从Google Search Engine中删除网址,查看竞争效果数据,修改站点地图等。

当攻击者从搜索结果中删除网址时,未经授权的Google Search Console所有者对网站的访问可能会损害网站在Google搜索结果中的可见性并影响收入。更具体地说,它可以用于帮助想要损害网站排名和声誉的竞争对手,从而更好地提高自己的声誉和排名。

验证Google Search Console所有权的完整性

幸运的是,有多种方法可以验证和监视是否添加了任何新的Google Search Console所有者,并且Wordfence防火墙为您的网站提供了保护。

由于我们的网站清理小组经常看到Google Search Console中的恶意财产所有者被添加到了被黑客入侵的网站中,因此我们提供了一些指导。

监控方式

每当添加新的Search Console所有者时,Google都会通过电子邮件提醒您。如果您收到其中一封电子邮件,并且最近未添加新的Google Search Console所有者,请立即采取行动并删除未知的所有者。

验证和删除不需要的所有者

即使您没有收到来自Google的任何电子邮件来提醒您有新的Google Search Console所有者,也可以从Google Search Console仪表板验证所有者。

检查Google Search Console用户:

  1. 登录您的Google Search Console,然后转到“设置”。在这里,您可以找到“用户和权限”
  2. 单击“用户和权限”。您会看到所有Google Search Console用户的列表,包括他们的姓名,电子邮件地址和角色。
  3. 查看列出的用户。验证没有列出未知的所有者。

如果您确实发现流氓Google Search Console所有者,请执行以下操作:

  1. 单击要删除的网站所有者旁边的三个点。
  2. 单击“管理财产所有者”。在这里,您可以看到验证请求的日志,可以确定何时添加所有者,以及取消验证任何站点所有者的能力。
  3. 对于您要删除的任何流氓所有者,单击“取消验证”。这将取消对该帐户的验证,并撤消对Search Console帐户的访问权限。

额外注意事项

Google的Site Kit提供了重置站点与Site Kit的连接的功能。如果您发现已添加了恶意的Google Search Console所有者,则建议您采取额外的步骤来重置WordPress网站上的Google Site Kit。

由Google重置网站工具包:

  1. 登录您的WordPress网站,然后通过Google的“设置”导航到网站工具包。
  2. 导航到“管理员设置”,然后单击“重置站点工具包”。出现提示时,单击“重置”以确认重置。这将重置您的站点工具包连接,并要求您重新连接以前连接的所有Google服务。

Wordfence可以保护您的网站

我们于2020年4月21日向Wordfence Premium用户发布了一条防火墙规则该规则将阻止任何非管理员进行的验证尝试,从而最终防止创建任何不必要的Google Search Console所有者。

由于某些限制,防火墙无法阻止ProxySetupURL在源代码中显示。但是,防火墙规则阻止验证请求足以使用Google的网站工具包的漏洞版本在网站上提供最佳保护。

免费的Wordfence用户将在2020年5月21日收到此规则。

披露时间表

20204月21日 –漏洞的初步发现和分析。已为Wordfence Premium客户发布了防火墙规则。我们通过Google的漏洞奖励计划提交了漏洞披露,因为这似乎是他们的主要漏洞披露渠道。
20204月22日 -漏洞报告由Google安全团队进行分类和分配。
20204月30日 – Google安全小组通知我们,该漏洞已经过验证并且已提交错误。
20205月4日 – Google Github存储库在站点工具包中出现了一次提交,似乎为该漏洞提供了补丁。
20205月7日 - 发布了补丁。
20205月21日 –免费的Wordfence用户将收到防火墙规则。

小结

在今天的文章中,我们详细介绍了一个漏洞,该漏洞使低级别的WordPress用户可以利用Google的Site Kit插件中的漏洞成为Google Search Console所有者。此漏洞已在1.8.0版中完全修复。我们建议用户立即更新到可用的最新版本。

自2020年4月21日以来,运行Wordfence Premium的站点已受到保护,免受此漏洞的攻击。运行免费版本的Wordfence的站点将于2020年5月21日收到此防火墙规则更新。如果您认识在其站点上使用此插件的朋友或同事,,我们强烈建议将此建议转发给他们,以便他们可以更新和保护其Google Search Console帐户和WordPress网站。

注:文本内容出自 Wordfence,由 WordPress大学 翻译整理。

声明:本站所有文章,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。
欢迎关注我们的微信公众号:WPDAXUE

倡萌

一个文科IT宅男,喜欢折腾WordPress和被它折腾 ^_^

暂无评论

发表评论