ホームページ >CMS チュートリアル >&#&プレス >ワードプレスには脆弱性があるのでしょうか?
公式 CVE 脆弱性レポートによると、WordPress に新しい複合 rce 脆弱性があることがわかりました。脆弱性番号は CVE-2019-8943 および CVE-2019-8942 です。ソースをダウンロードしてください。脆弱性バージョンのコードを取得して分析します 脆弱性のトリガー プロセス、注意: 脆弱性が再発する場合、構築するにはネットワークを切断する必要があります WordPress は、インターネットに接続するとコード パッケージを自動的に更新します。脆弱性が発生する post.php ファイルを見つけます。WordPress には複数の post.php ファイルがあります。それぞれの機能について簡単に説明します。wp-includes/post.php が post のソース ファイルであり、wp-admin/includes/ post.php にはバックエンドがあります。許可された投稿インターフェイス、wp-admin/post.php はバックグラウンドでの投稿リクエスト処理用です。具体的な呼び出しコードは次のとおりです:
wp-admin/post.php:require_once( dirname( __FILE__ ) . '/admin.php' ); wp-admin/admin.php:require_once(ABSPATH . 'wp-admin/includes/admin.php'); wp-admin/includes/admin.php:require_once(ABSPATH . 'wp-admin/includes/post.php'); wp-admin/admin.php::require_once(dirname(dirname(__FILE__)) . '/wp-load.php'); wp-load.php:require_once( dirname( ABSPATH ) . '/wp-config.php' ); wp-config.php:require_once(ABSPATH . 'wp-settings.php'); wp-settings.php:require( ABSPATH . WPINC . '/post.php' ); define( 'WPINC', 'wp-includes' );
上記の呼び出しプロセスによると、脆弱性悪用プロセスは、画像をメディア ライブラリにアップロードしてから更新することです。次の図に示すように、操作では、wp-admin/post.php 関数を呼び出し、case:editpost に切り替えます。
# ここで edit_post は脆弱性関数であり、以下の図に示すように関数宣言を入力します。
$post_data はフィルタリングを行わない post 配列です。下の図に示すように、修復されたコードを比較してください。 手順:
見つけられなかったので、ここでもう少し説明します。 wordpress は最初にインターネットに接続すると自動的に更新されるため、次の図に示すように、別の同様の脆弱性ポイントを特定しました。コード内の$key (データベースのmeta_id) によると、$value[' key'] (データベースのmeta_key)、$value['value'] (データベースのmeta_value)、construct meta[1][key]=_wp_attached_file&meta[1][value]=123、そして最後に次のようなデータベースステートメントを実行します UPDATE `wp_postmeta` SET `meta_key` = '_wp_attached_file', `meta_value` = '123' WHERE ` meta_id` = 2 の場合、実装プロセスは次の図に示すとおりです。
#関連推奨: 「WordPress チュートリアル
#」 #次の図に示すように、meta_id に従って wp_postmeta テーブルのコンテンツを更新し、最後に do_action 関数を実行します。# #ただし、3 番目と 2 番目の関数には制限があるため、 4 番目の場合、実行が成功しない場合。これは、脆弱性の再発における興味深い点でもあります。次の図に示すように、追跡を続けます。利用可能なポイントを取得し、以下の図に示すように、コードに示されているように wp_updae_post 関数を入力します。
この関数は、いくつかの取得パラメーター操作を実行し、変数を抽出します。次の図に示すように、配列と値を割り当てて、脆弱性の発生ポイントを追跡します。 wp_insert_attachment 関数が返されることがわかり、この関数は次のように追跡されます。図に示すように、# wp_insert_post 関数に戻り、この関数を追跡し、次の図に示すように、この関数内の脆弱性の発生ポイントを特定します。
##したがって、上記の脆弱性ポイントに基づいて、meta_input[_wp_attached_file] =../evil.jpg?shell.php を渡し、SQL ステートメント UPDATE `wp_postmeta を実行できます。 ` SET `meta_value` = '../evil .jpg?shell.php ' WHERE `post_id` = 8 AND `meta_key` = '_wp_attached_file'. post_id はテスト条件の前提条件として知られている必要があります。ただし、通常の状況では, このパラメータは画像を更新するときに含まれます。テストの場合は観察できます。データベースに関連する内容を入力します。具体的なSQL文のネスト実行方法は以下の図の通りです。
#パラメータを渡し、対応するテーブル名と列名に値を代入し、最後に、以下に示すように do_action 関数を実行します。 表示:
ここで WordPress のディレクトリ トラバーサルの脆弱性を完了し、ローカル ファイル インクルードの脆弱性を使用して rce を実行します。WordPress は、次の図に示すように、GD および Imagick のイメージ ライブラリを公式に使用しています。
##Imagick には WordPress が付属しておらず、プラグインをダウンロードする必要があるため、デフォルトでは GD ライブラリをバイパスして任意のコードを実行できます。以上がワードプレスには脆弱性があるのでしょうか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。