ブログ
WordPressを監査する?まずはプラグインから始めよう
WordPressコアの監査をやめて、プラグインの監査を始めましょう。小規模チーム向けの実践的なプラグイン優先セキュリティ監査です。
概要
ほとんどのWordPressセキュリティ監査は逆さまです。コアの更新とスキャナーのレポートを重視しますが、実際に被害を及ぼす脆弱性はプラグインにあります。SANSのホワイトペーパーによると、エコシステムの脆弱性の96%以上がサードパーティのプラグインに由来し、約43%は認証を必要としません。この記事では、社内の小規模マーケティングチーム向けのプラグイン優先監査を説明します。誰もが間違ったレイヤーをスキャンしていたためにハッキングされたサイトのストーリーを用いています。すべてのプラグインを棚卸しして分類し、認証されていない攻撃対象をテストし、ユーザーとログを手動でレビューし、結果を技術に詳しくない上司が理解できるリスク言語に変換する方法を学べます。その結果は、チェックボックス演習ではなく、四半期ごとのトリアージの習慣です。
ほとんどのWordPressセキュリティ監査は劇場です。午後を使ってコアを更新し、管理者パスワードを変更し、「重大な問題はありません」と誇らしげに報告するプラグインスキャナーを実行します。その間、ファイルアップロードを受け付け、3年前に最後に更新されたプラグインは、アップロードディレクトリに静かに置かれ、ゲストリストに載っていない誰かを待っています。
数字がこれを裏付けています。WordPressプラグインのスキャンに関するSANSのホワイトペーパーによると、WordPressエコシステムの脆弱性の96%以上がサードパーティのプラグインに由来し、テーマは4%、コアは1%未満です。それらの欠陥の約43%は、認証なしで悪用される可能性があります。したがって、監査がエネルギーのほとんどをコアに費やすとき、あなたは木々を調べている一方で、隣のプラグインディレクトリで山火事が始まっています。
これはコアについてパニックを呼びかけるものではありません。最近公開されたエクスプロイトが公開されたwp2shell RCEのようなコア脆弱性は、発表された日にパッチを適用する必要があります。しかし、それらは十分にまれであり、監査時間の大部分を割く価値はありません。大部分はプラグインに属し、そこから実際のワークフローが始まります。
ビフォーシナリオを想像してください。日曜の朝、サイトがカジノのページにリダイレクトされ、上司から「セキュリティはあったはずだ」というメールが届きます。確かにセキュリティはありました。チェックボックス監査があったのです。アフターシナリオは、プラグインを実際の攻撃対象として扱い、外部からテストし、スキャナーが見えないものをチェックするトリアージシステムです。
あなたは2017年から稼働しているWordPressサイトを持つ小規模なマーケティングチームにいます。2019年にフリーランサーが構築したカスタムイベント登録プラグイン、ファイルアップロードフィールドを持つお問い合わせフォームプラグイン、販売され公開アップデートページがなくなったスライダープラグインがあります。これは珍しい構成ではありません。ここから監査が始まります。
プラグインの棚卸しはセキュリティポリシーです
すべてのプラグインとテーマを棚卸しします。バージョン、最終更新日、ベンダーがまだ存続しているか、実際に誰かが使用しているかを書き留めます。次に、それぞれを分類します。維持され使用されている、維持されているが未使用、放棄されているが使用されている、放棄され未使用の4つに。未使用のものはすぐに削除します。「月額50ドルだけだ」という言い訳は無視してください。未使用のプラグインは負債であり、機能ではありません。放棄されているが使用されているものについては、置き換えるか、リスクを受け入れて上司が見たリスクレジスターに書き留めるかを決定します。
イベント登録プラグインは、放棄されているが使用されているバケットに分類されます。支払いを受け取り、確認メールを送信するため、置き換えはプロジェクトになり、今は維持します。しかし、「これが将来の侵害の最も可能性の高い原因である」というメモを書き、テストリストの先頭に追加します。
| 攻撃対象 | WordPressの既知の脆弱性の割合 | 監査の優先度 |
|---|---|---|
| サードパーティのプラグイン | 96%以上 | 最高 — 棚卸し、スキャン、テスト、置き換え |
| テーマ | 約4% | 中 — カスタムまたは古い場合のみ |
| WordPressコア | 1%未満 | 低 — パッチを適用し、次へ進む |
SecurityWeekが2024年に8,000以上の新しいWordPress脆弱性を数えたとき、その大部分はこのタイプ、つまりコアのパッチではなくプラグインの問題でした。スキャナーは、開示されてCVEが割り当てられたものを教えてくれます。CVEのないカスタムフリーランサーコードについては、誰も注意深く調べたことがないため、教えてくれません。その手動による確認があなたの仕事です。プラグイン固有のチェックの詳細な手順については、WordPressプラグインの脆弱性監査ガイドを参照してください。
見知らぬ人のようにテストする:パスワード不要の43%
スキャナーは何も問題がないとすでに伝えています。今度は、それができないことを行います。ログインなしで外部からサイトを調べます。すべてのファイルアップロードフィールド、POSTを処理するすべてのフォーム、すべてのadmin-ajaxエンドポイントから始めます。アップロードは実際にファイルの内容をチェックしますか、それとも拡張子だけですか?アップロードされたファイルはどこに配置され、WebサーバーはそのディレクトリでPHPを実行できますか?認証を必要としないプラグインの欠陥の43%は、まさにこれらの場所にあります。認証されていない保存型XSS、任意のファイルアップロード、PHPオブジェクトインジェクションです。
お問い合わせフォームプラグインでは、訪問者が履歴書を添付できます。訪問者の元のファイル名を使用してファイル名を変更するため、「resume.php」をアップロードすると、設計上書き込み可能な /uploads/contact/ フォルダーに保存されます。サーバーがそのディレクトリでPHPの実行も許可している場合、攻撃者はWebシェルを手に入れたことになります。Fastlyは、WordPressプラグインにおける認証されていない保存型XSSの活発な悪用を記録しています。これはニッチなスライドデッキのリスクではありません。テストは簡単です。既知の内容のファイルを作成し、アップロードして、元の名前とタイプで返ってくるかどうかを確認します。次に、.phpファイルをアップロードしてみます。.phpとして返ってきたら、悪用可能な穴を見つけたことになります。
ここで「でもセキュリティプラグインにはWAFがある」という議論は崩れます。WAFは既知のペイロードをブロックできますが、それが依存するパス正規化ルールは、サーバーが実際に行うこととしばしば乖離します。OWASP Webセキュリティテストガイドは、どんなダッシュボードよりも優れたリファレンスです。ファイルアップロードの欠陥と保存型XSSを系統的にテストする方法を説明しています。そして、プラグインが放棄されていることを発見したら、クリーンアッププロトコルを適用する時です。放棄されたWordPressプラグインの隠れた危険性は、死んだ拡張機能を残しておくことが、削除してワークフローを調整するよりも悪い理由を説明しています。
スキャナーが見えないもの:ユーザー、ログ、古いコード
動的テストは、現在公開されているものを検出します。手動レビューは、すでに内部にあるものを検出します。ユーザーアカウントから始めます。管理リストを開き、自分が作成していないアカウントを探します。「support」という名前の、フリーメールアドレスで、背後に人間がいない管理者は、同僚ではなくバックドアです。wp-content/uploadsのファイルタイムスタンプをチェックして、自分のコンテンツではない最近変更されたものを探します。サーバーのアクセスログで、人間のブラウザーではなくボットのcurlコマンドのように見えるリクエストをチェックします。
イベントプラグインにはuploads/event-headshots/に保存される「スピーカー写真」アップロードがあります。テスト中に、自分のものではないファイル、ランダムな名前の小さなPHPファイルを見つけます。それがWebシェルです。2週間前にテストした同じアップロードの欠陥を通じてそこに到達しました。そして今でもスキャナーはそれを「見る」ことはありません。プラグインの脆弱性ではなく、その証拠だからです。手動レビューがそれを見つけて削除し、ログでそれを置いたIPアドレスを確認します。Invictiは、プラグインでのPHPオブジェクトインジェクションが増加していると指摘しています。悪意のあるオブジェクトは実行中にのみ実体化するため、ブラックボックススキャンではほとんど見えません。それを見つける唯一の方法は、ユーザー入力に対してunserialize()を呼び出すような危険なパターンを探すためにコードを読むことです。カスタムプラグインの数百行を読むことは、インシデントレスポンスのリテイナーを支払うよりも安価です。
ここで「セキュリティプラグインを増やせばいい」という標準的なアドバイスも限界に達します。3つのセキュリティプラグインを重ねると、互いにブロックし合う重複したWAFルール、重複したログメールの濁流、そして自分自身の管理者ログインで時折「あなたは禁止されました」というエラーが発生します。適切に設定された1つのアクティブなセキュリティプラグインで十分です。何かを追加する前に、セキュリティプラグインが多すぎると逆効果になる理由をお読みください。
パニックを起こさずに上司に真実を伝える
上司はCVSSスコアやPHPオブジェクトインジェクションを気にしません。サイトがダウンすること、ストアが注文を受け付けないこと、IT予算に関心があります。翻訳は簡単です。「このプラグインには、認証されていない既知のリモートコード実行の欠陥があります。見知らぬ人がサイトのコンテンツを削除したり、バックドアをインストールしたりできます。今期中に置き換える必要があります。」次に、優先リストを示します。イベントプラグインを置き換える、ファイルタイプを適切に検証するまでお問い合わせフォームのファイルアップロードを無効にする、すべての管理者認証情報をローテーションする、次の四半期レビューをスケジュールする。
また、言語的な利点もあります。CISAは既知の悪用された脆弱性カタログを維持しており、公開された欠陥のうちどれが実際に悪用されているかを正確に教えてくれます。プラグインがそこに含まれていれば、議論はもはや理論的ではありません。既知のエクスプロイトが存在し、あなたは時間と戦っています。含まれていなくても、「緊急」の意味の基準として使用してください。CISAの追跡により、技術に詳しくない上司に、これはフィッシングメールではなく、攻撃者が現在何をしているかに関する公開データベースであると説得しやすくなります。四半期が終わると、一度きりのチェックボックス演習ではなく、是正ワークフローが得られます。脆弱性をパッチサイクルに変えるワークフローが習慣を維持します。
ビフォーは壊れたサイト、慌ただしいメール、何も問題がないと言ったクリーンなスキャナーレポートでした。アフターは四半期ごとの儀式です。棚卸し、分類、外部からのテスト、ユーザーとログのレビュー、そして下した決定と受け入れたリスクを書き留めます。スキャナーは、健康証明書ではなく、どこを見るべきかの地図になります。プラグインは名前で把握できるリストになります。そして次に上司が監査について尋ねたとき、指を交差させない答えが得られます。
