こんにちは！セキュリティサービス部セキュリティ開発グループの今村です。
今回のブログでは、私が2023年8月に IPA に報告した脆弱性についての内容、また報告から公表までの経緯や脆弱性の探し方などをご紹介します。
＜免責事項＞
本記事は脆弱性情報を扱う性質上、攻撃手法の一部に触れますが、違法行為を助長するものではなく脆弱性の発見により安全なソフトウェアが増えることを目的としております。
本記事に掲載した行為を自身の管理下にないネットワーク・コンピューターに行った場合は、攻撃行為と判断される場合があり、法的措置を取られる可能性があります。脆弱性の検証を行う場合は、くれぐれも許可を取ったうえで自身の管理下にあるネットワークやサーバーに対してのみ行ってください。
はじめに
自己紹介
私は、23卒として SBテクノロジーに入社し、普段は主に、セキュリティ監視に使用するログ分析基盤の担当エンジニアとして働いています。
大学時代は、ブロックチェーン技術を使用したアプリの開発や、アルバイトとしてゲーム会社でプログラマーをしておりました。
ゲームシステムや UI は変更が頻繁に発生する影響で、開発したものがすぐ不要にとなり、また新しく作るというサイクルを繰り返していました。この経験で得たメンタルは現在の業務でも活かせています。
セキュリティに関しては、趣味で CTF に参加していた程度で、本格的に勉強を始めたのは SBテクノロジーに入社してからになります。
なぜ脆弱性探し・報告をしようと思ったのか
きっかけは大学生時代の先輩から突然送られてきた一通のメッセージでした。
一緒に最強を目指さないか？
どうやって「最強」を目指すのか。
そもそも、「最強」という定義は一体何なのか。
さまざまな疑問が私の頭の中を埋め尽くしましたが、気が付けば二つ返事で承諾していました。そして話し合った結果、脆弱性報告を目標にして、2人での活動が始まりました。
脆弱性報告のモチベーションが「最強を目指すため」というのは不純かもしれません。しかし一方で、セキュリティ業界で活動している者として、世に存在する脆弱性を少しでも減らすことに貢献したい。セキュリティを専門としていない方にも情報を届けたいという思いも大いにあります。
もちろん、脆弱性報告することが「最強」ではありませんし、「世に存在する脆弱性を減らす唯一の活動」でもないと私は思います。そのことを踏まえたうえで、なぜ脆弱性報告を目標にしたのかというと、「分かりやすかったから」というのが一番大きな理由です。
脆弱性報告をすることで、JVN/CVE が発行され、脆弱性を減らすことに貢献したという事実が対外的にも明らかになります。資格や経歴と同じように、対外的に分かりやすい実績を得ることは、ステップアップの一歩として、とても良いことだと思います。
報告した脆弱性と製品の概要
今回 IPA に報告した JVN#98946408（※1）・CVE-2023-40068（※2）は、WordPress 用プラグインの Advanced Custom Fields におけるクロスサイトスクリプティング（以下、XSS という）の脆弱性です。
XSS とは、悪意のあるユーザーが標的サイトにアクセスしたユーザーに対して攻撃する際に使用される一般的な攻撃手法です。攻撃者は、標的サイトの脆弱性を利用してスクリプトを注入し、標的サイトにアクセスしたユーザーに対して実行されるようにします。
実行された JavaScript コードによって、攻撃者はユーザーのクッキーやセッション情報を盗み取り、フォームに入力された住所やメールアドレスのような機密情報や認証情報の不正な使用、偽のコンテンツの表示など多岐にわたる攻撃を行うことができます。
XSS のより詳細な解説は、以下のサイトをご参照ください。
引用元：JVNDB
Advanced Custom Fields とは、WordPress 編集画面にフィールドを簡単に追加することができるプラグインであり、有効インストール数（プラグインがインストールされ、現在有効化されている数を示しています）が200万を超える人気プラグインです。
日本語を含む全31言語に対応しております。
以下の図1は、2023年1月～2023年10月間に日本で「advanced custom fields」と検索された月間平均数を示しています。月間平均で1000～1万件検索されており、日本のユーザーも多いプラグインであると考えられます。
今回発見した脆弱性の詳細
JVN#98946408・CVE-2023-40068 の詳細についてご紹介します。
これは蓄積型 XSS の脆弱性であり、編集者以上の権限でログインしているユーザーのブラウザ上で、任意のスクリプトを実行される可能性があります。
今回 XSS に繋がった原因は、エスケープ処理が適切に行われていなかったためです。
PHP で開発されている WordPress プラグインでは度々見かけますが、echo 関数を使用して変数を出力する際に esc_html のようなエスケープ関数を使用していない場合があります。
今回報告した脆弱性を例に挙げると、「フィールドラベル」、「フィールド名」に入力した値がエスケープ処理されていません。そのため、JavaScript コードを実行することができてしまいます。
JVN/CVE が発行されるまでの流れ
今回発見した脆弱性の報告は「ソフトウェア製品」の脆弱性として IPA に届け出を行いました。
脆弱性の報告から公表されるまでのプロセスは以下の図の通りです。
今回の報告から公表までにかかった期間は以下の通りです。
今回は、IPA を通して脆弱性報告を行いましたが、ほかにも各ベンダーの脆弱性窓口や、バグバウンティプラットフォームを通して報告を行う手段もあります。注意事項として、バグバウンティ制度を利用する際には、きちんと提示されているルールを守って調査を行わなければなりません。
届け出に必要な情報・注意点
IPA に対して届け出を行ううえで、脆弱性を確認したソフトウェアの情報、脆弱性により発生する脅威などを記入する必要があります。
- 例
-
- パッチレベル
- 製品開発者の連絡先
- 機密性、完全性、可用性に対する影響
- 脆弱性が再現した証跡
さらに詳しく知りたい場合は、届け出様式の閲覧をお勧めします。
https://www.ipa.go.jp/security/todokede/vuln/ug65p90000019gda-att/form_web.txt
また、注意点としては、セッションがすぐに切れてしまい、時間内に入力を終え、送信しないと再度入力し直しということになりますので、届け出に必要な記入内容をメモに残しておくことも併せてお勧めします。
脆弱性探しの環境・探し方
環境
私が普段、脆弱性検証に使用している環境をご紹介します。
- OS: Parrot OS 5.2 Security Edition
- WordPress: Ver. 6.3.2
- Apache2: Ver. 2.4.56
- MySQL: Ver. 15.1
これらを仮想環境で動かしています。また、WordPress は Local 環境で構築しています。
探し方
私は JVN/CVE を取得するため、まず既知の脆弱性の検証を行うことから始めました。
闇雲に世に出ているプラグインの未知の脆弱性を探すよりも、まずは情報が出揃っている既知の脆弱性を理解することをお勧めします。そうすることで、脆弱性が発生しやすい箇所やプラグインの傾向など、製品理解につながると思います。
過去の脆弱性報告の探し方としましては、JVNDBで過去の脆弱性報告を洗い出します。
詳細検索でキーワード、公表日、CWE（※3）などから絞り込みを行うことをお勧めします。経験上、あまり古すぎる報告は互換性の問題により検証が難しい場合が多いので、遡っても2,3年前くらいが良いです。
脆弱性の検証を行う対象が決まったら、早速検証に移ります。
検証方法としましては、対象のプラグインの JVNDB に記載してある CVE から、PoC（脆弱性の実証方法やコード）を探します。
WordPress プラグインの脆弱性に限っては、WPScanを使用すると比較的容易に PoC を探すことができます。（稀に PoC が存在しない場合があるので注意です。）
WPScan を使用して分かることは PoC だけではなく、脆弱性を確認できるプラグインのバージョン、その脆弱性が修正されているかどうかの情報なども掲載されています。
これにより、検証する際に脆弱なバージョンをすぐに特定することができ、修正情報から脆弱性の原因となるコードを参照することができます。
PoC が確認できたら、次は前述した、Parrot OS 5.2 Security Edition 上で動作させている WordPress Ver.6.3.2 に検証対象のプラグインをインストールした環境にて検証を行います。
私が普段プラグインをインストールする方法は
- プラグインが公開されている場合
- プラグインが非公開になっている場合
の2種類に分けられます。
プラグインが公開されている場合
この場合のインストールは非常に簡単です。
WordPress でプラグインを検索してインストールします。
プラグインが非公開になっている場合
SVN（※4）からリポジトリから対象のプラグインにチェックアウト、リビジョンを指定して ZIP ファイルに圧縮して WordPress に直接アップロード・インストールします。
Advanced Custom fields を例にすると
$cd wp-advanced-custom-fields/ //チェックアウトしたディレクトリに移動
$svn up -r 2947268 //リビジョンを指定
$mv trunk wp-advanced-custom-fields //trunkフォルダを分かりやすく改名
$zip -r wp-advanced-custom-fields.zip wp-advanced-custom-fields/ //ZIPに圧縮
リビジョンに関しては、プラグインの開発ログから参照できます。
以上の手順で検証を行う環境が整いました。
なお、脆弱性が存在するバージョンをインストールしていない場合は別途ロールバックという古いバージョンへと戻す作業を行う必要があります。SVN リポジトリから直接アップロードする場合はリビジョン指定しているので、ロールバックを行う必要はありません。
脆弱性を再現する手順に関しましては、プラグインによりけりなので、WPScan の PoC を参考にしながら行います。
脆弱性検証をある程度行い、攻撃方法のナレッジが蓄積されてきたら、脆弱性の検証と並行して、現行のバージョンにほかの脆弱性がないか調査してみることをお勧めします。
地道な方法ですが、普段私が脆弱性を探す方法となります。
最後に、開発ログから修正されたコードとの差分を確認することもお勧めします。
攻撃の成功を確認して終わるのではなく、どのようにコードが修正されたのかを確認することで、なぜ攻撃が成立してしまうのか理解することができます。これは今後新しい脆弱性を探していくうえで非常に重要な行為だと思います。
また、自分が開発する側となった際にセキュアなコーディングを行う知識も身につけることができます。
まとめ
本記事では、今回発見した脆弱性、脆弱性報告の流れ、脆弱性の探し方についてご紹介しました。
脆弱性報告は、JVN/CVE を取得できるだけではなく、その過程でセキュリティの知見を深めることができます。
セキュリティ技術の研鑽として、よく CTF が挙げられますが、過去の脆弱性を検証し、新たな脆弱性を探す活動も効果的です。
また、普段自分が使用している製品の脆弱性を調査・検証することで、より深くその製品を理解することができます。
加えて、脆弱性を発見し、開発者に感謝された際にはとてもやりがいを感じます。
世に出ている製品のセキュリティを向上させる行為はとても意義があるものだと感じています。
本記事が脆弱性報告活動の一助になれば幸いです。
また、セキュリティに興味のある方はぜひ SBテクノロジーに！一緒に最強を目指しましょう！
※1：WordPress 用プラグイン Advanced Custom Fields におけるクロスサイトスクリプティングの脆弱性
※2：CVE-2023-40068
※3：Common Weakness Enumeration の略。日本語では「共通脆弱性タイプ」と訳され、ソフトウェアおよびハードウェアにおける脆弱性タイプをリスト化したもの。非営利団体MITRE が中心となり運営されている。（https://www.ipa.go.jp/security/vuln/scap/cwe.html）
※4：Subversionの略。オープンソースのバージョン管理システム。
