任意のファイル削除の脆弱性分析を再現Wordpress4.9.6

第一章はじめに脆弱性と危険分析

脆弱性1.1はじめに

WordPressは、今日の最も人気のある（私は誰も言わないしたい）PHPベースのオープンソースCMS、全世界で数百万のユーザーに、現在の最大の言った、ダウンロード超4600万以上の時間を持ってすることができます。これは、その機能が続き、オープンソースのシステムで、非常に強力ですが、ソースコードはここで見つけることができます。これは、なぜ、WordPressは手段は、かつて数百万人のユーザーが落ちる成功した、多くのハッカーの目標となっているされています。この幅広い採用は、サイバー犯罪者のための興味深い標的になります。実験は、任意の認証された文書のワードプレスコアの脆弱性は、脆弱性CVE-2018から20714を削除しています

この脆弱性は、攻撃者が任意のコードを実行する可能性があります。脆弱性の発見はにWordPressのセキュリティチームに報告以来7 ヶ月、まだ修理をしていません。最初の報告以来パッチや具体的な計画なしに長い時間が経過しました。今wordpress4.9.6と、次のこの脆弱性のバージョン。

使用抜け穴の1.2条件

以下で説明する脆弱性を悪用するには、攻撃者のニーズは、編集および削除のメディアファイルへの事前の許可を取得します。つまり、持っている作者の許可を。ここでは、どのようなワードプレスのユーザー権限を見ています。

• スーパー管理者（スーパー管理者） - サイトのネットワーク管理機能および他のすべての機能にアクセスする権利。
• 管理者（管理者） - すべての単一サイト内の管理機能へのアクセス権を持っています。
• （編集）編集する - 他のユーザーの投稿を含め、投稿を公開し、管理することができます。
• 著者（著） - 自分の投稿を公開し、管理することができます。
• コントリビュータ（寄稿） - あなたが書き、自分の投稿を管理するが、公開することはできません。
• 加入者（加入者） - 唯一の自分の個人情報を管理することができます。

私たちは、ユーザーが唯一の著者の許可を公開し、自分の投稿を管理しますが、この脆弱性ではなく、サイト全体をハイジャックして、WordPressのは、この欠陥により、攻撃者は簡単にサイトを制御することができているサーバー上で任意のコードを実行することができなかったことがわかりました。

ユーザが永続的にバックグラウンドで実行されているサムネイル画像のアップロードを削除するとき、ワードプレスの脆弱性のコア機能の一つが存在します。

1.3ハザードの脆弱性

それは、アカウントの少なくとも一方が自動的にある程度、この脆弱性の深刻度が低くなるだろう必要がハッカーや不正なコンテンツフィッシングライター、パスワードの再利用、またはその他の攻撃によって悪用される可能性が何らかの方法で著者の資格を取得し活用しました。

この脆弱性は、攻撃者が任意のファイルのWordPressのインストール（削除権限をサーバー上の他のファイルとの+ PHPのプロセスのユーザー）を削除する可能性がありエクスプロイト。利用可能な現在のバックアップが悲惨な結果をもたらすことができなかったがある場合、全体のWordPressのインストールを消去する可能性に加えて、攻撃者が回避セキュリティ対策に任意のファイルを削除して、Webサーバー上で任意のコードを実行する機能を利用することができます。より正確には、次のファイルを削除することができます。

• .htaccessファイル：一般的に、任意の安全性への影響せずにファイルを削除します。しかし、いくつかのケースでは、.htaccessのファイルは、（特定のフォルダの制約例えば、アクセス）セキュリティに関連する制約が含まれています。これらのセキュリティ上の制約を無効にします。このファイルを削除します。
• index.phpのファイル：通常、空のindex.phpこの操作にディレクトリ一覧を実行することはできませんWebサーバーを防ぐために、ディレクトリ内のファイルを。これらのファイルを削除すると、すべてのファイルのディレクトリ一覧を保護するために、この措置により、攻撃者に授与されます。
• config.phpの-WP ：次回は、あなたがサイトを訪問したときにワードプレスWordPressのインストールプロセスをインストールするファイルを削除がトリガされます。これは、あるWP-config.phpには、データベースの認証情報が含まれており、その存在せず、WordPressはちょうど同じインストールされていません。攻撃者がこのファイルを削除することができ、彼は管理者アカウントの資格情報のインストール・プロセスのために使用し、最終的にサーバー上で任意のコードを実行することにしました。

しかし、彼が標的部位に再設定することができますので、攻撃者は、既存の「データベース名」、「MySQLのユーザ名」と「パスワード」を知るために、直接のwp-config.phpのファイルの内容を読み取ることができないため、ことに留意すべきです彼の制御の下で、リモート・データベース・サーバーを使用して。完了したら、攻撃者はサーバー上で任意のコードを実行する機能など、新しい管理者アカウントとサイトを完全にコントロールを作成することができます。「悲惨な結果になります何の現在のバックアップ可能な存在しない場合、全体のWordPressのインストールを削除する可能性に加えて、攻撃者が回避セキュリティ対策に任意のファイル削除機能を使用することができますし、Webサーバー上で任意のコードを実行します

 

ビルドと再生への第二章の脆弱性環境

2.1ビルド環境

ゴーwordpressの中国の公式サイトhttps://cn.wordpress.org/download/releases/ダウンロード版はこの脆弱性を持っています

（1）インストールワードプレス

ワードプレス4.9.6

 

インストールが成功した後、バックグラウンドでのみテストのための機能を書いて「作者」の特権アカウント「XY」を追加

2.2脆弱性テスト再現

（1）サイトの背景に新たに追加されたユーザ権限の着陸と

（2）メディアを追加する画像をアップロード

  

（3）[編集]をクリックします

（4）ソースによって「388054b4f3」クッキーコピーおよびページダウンの値を見つける、ページのソースコードで_wpnonce値を識別する。

 

次に、（5）及びカール、またはげっぷ構成されたHTTP要求を使用。

次いで、パケット中継を送信するように構成すると、パケットのポスト（クッキーに必要な値）を送信します

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的值的时候，就需要引起我们的注意，要查看数值是否合法。