Transcript
00:00:00WordPressで一連の脆弱性が相次ぎ発見されましたが、最新のものは非常に深刻で
00:00:04ハッカーが管理パネルを完全に制御できてしまいます。SQLインジェクションや
00:00:09シェルコマンド実行など、かなり危険です。自分には関係ないと思うかもしれませんが、全ウェブサイトの44%以上で
00:00:14WordPressが使われています。日頃利用しデータを渡しているサイトの多くが
00:00:19この脆弱なバージョンのWordPressで動いている可能性があります。仕組みはこんな感じです。
00:00:25ローカルに標準のWordPressをインストールしてあります。まず最初の
00:00:29スクリプトを実行して脆弱性があるか確認すると、レスポンスとして
00:00:34HTTP 207が返り、確かに脆弱であることが分かります。つまり、2つ目のチェックである
00:00:41インタラクティブシェルの起動が可能です。サイトにSQLインジェクションを実行して新しい管理者を作成し
00:00:47悪意のあるプラグインをアップロードすることで、このサイト上の任意のファイルにアクセスできるようになります。
00:00:52では、問題の詳細とその仕組みを詳しく見ていきましょう。
00:00:58こちらのレポジトリでは、脆弱性のあるWordPressサイトにSQLインジェクションを実行する方法が解説されています。
00:01:06対象は6.90〜6.94、または7.00〜7.01です。攻撃は認証不要の
00:01:14エンドポイント「batch v1」の呼び出しから始まります。本来は検証と権限チェックが必要なリクエストをまとめて送る場所です。
00:01:20バッチハンドラには、同期しているはずの「validation」と「matches」という2つの並列配列があります。
00:01:26しかしバグにより、無効なパスが原因で関数 `wp_pass_url_files` が失敗した際、「validation」のみが更新されました。
00:01:33その結果、両方の配列参照に使われる同じインデックスで不整合が生じます。POC（実証コード）はこれを利用しています。
00:01:411つのリクエスト（「v2 post」エンドポイントへのPOST）だけを含むバッチを送信し、それ自体にリクエストボディを持たせます。
00:01:48親リクエストはPOSTとして正常に検証されているため、ボディ内のリクエストはメソッド許可リストをバイパスでき
00:01:56GETリクエストを送信可能になります。内部バッチには存在しない投稿へのGETが含まれており、これが
00:02:02先ほどの非同期状態を引き起こします。WordPressは同じリクエストを `get_items` 関数経由で処理し
00:02:10そこで「author_exclude」フィールドが「author__not_in」にマップされ、脆弱なビルドが文字列としてSQLに埋め込みます。
00:02:18要するに、これら全てが実行される過程でSQLのエスケープが行われません。POCは一連のリクエストを使用し、最終的に「v2 users」へのPOSTで
00:02:25新しい管理者アカウントを作成します。レポジトリではこれら全ステップを詳細に解説しています。最初の5つは事前認証でバグを利用しますが、ステップ6は
00:02:35認証済みユーザーに対する標準的なWordPressの動作（悪意のあるパッケージのアップロード）です。冒頭で述べた通り、これは標準のWordPressです。悪意のあるプラグインを経由して発生する脆弱性ではありません。
00:02:46標準のWordPressをインストールするだけで発生します。まず、このチェック用スクリプトを実行して
00:02:52脆弱性が利用可能か検証します。次に、この `read` コマンドを実行すれば
00:02:57データベースのユーザー名やDB名などの情報を確認できます。また、サイトに対してSQLを実行できるようになるため
00:03:03実際に動作しているデータベースのバージョンなども判明します。しかし、これらはまだ序の口です。本当に最悪なのは
00:03:07悪意のあるプラグインをアップロードできる権限を持った管理者アカウントを実際に作成してしまうことです。今回は
00:03:15「web shell」と呼ばれるプラグインです。これによりサイトのシェルにアクセス可能になり、結果として
00:03:22このウェブサイト上のあらゆるファイルにアクセスできるようになります。この攻撃は動画の前半で解説した手順で行われます。
00:03:27管理者が作成された後、プラグインがアップロードされ、最終的にそのユーザーは削除されます。
00:03:34プラグインの存在や何が起きたのかを隠蔽するためです。被害の深刻さを示すために、別のスクリプトを作成しました。
00:03:38管理者を作成し、そのままシステムに残すスクリプトです。
00:03:40ここにユーザー名とパスワードがあります。ウェブサイトに戻り、`wp-login` のルートにアクセスして、それらの
00:03:47ユーザー名とパスワードを入力してログインすると、管理パネルへの完全なアクセス権が得られます。もし難しく感じても心配いりません。
00:03:54私も理解するのに長い時間がかかりました。今回の一連のエクスプロイトチェーンは恐ろしいほど
00:04:00複雑であり、人間のセキュリティ研究者が単独で発見し組み立てるには数週間、あるいは数ヶ月かかったと言われています。
00:04:05セキュリティ研究者が自力でこのエクスプロイトチェーンを10時間で見つけ出すことは
00:04:10AIなしでは不可能だったでしょう。これは非常に恐ろしいことです。悪意ある攻撃者がボットを使って
00:04:17レポジトリの巡回やURLチェックを行い、脆弱性の出現を待ってAIで記録的な速さで悪用できるからです。
00:04:23Redditのあるユーザーは、発覚からわずか2日後に自分のサイトが侵入されたと語っています。
00:04:27週末にしか更新作業を行わないため、攻撃者はその隙に新しい管理者を作成してログインできてしまいました。
00:04:33このエクスプロイトはバージョン7.0.2で修正されたのでアップデート可能ですが、本当に凄まじい事例です。
00:04:40POC実行に使用したレポジトリと記事はコメント欄に掲載しています。ついでに
00:04:46Better Stackをチャンネル登録して最新の技術ニュースをチェックしてください。楽しんでいただけたなら幸いです。
00:04:50それでは、いつものようにまた次回の動画でお会いしましょう。