本記事は駆け出しの Web 診断員が、アセスメントサービス部が誇る二人のWeb診断員、年間数十件の CVE を取得している猛者たちに、何がきっかけで CVE 取得につながる脆弱性調査(以下、脆弱性調査)を始めたのか、普段どのように脆弱性調査を行って脆弱性を報告しているのか、どうしたらそんなにたくさんの CVE を取得できるようになるのか、将来的に何を目指しているのか…？ などについてインタビューした内容を記載しています。
前編は猛者たちが脆弱性調査を始めたきっかけ、脆弱性調査にあたってのモチベーションや脆弱性調査のアプローチ方法、今までに報告した印象深い脆弱性について、後編では開発・実装にあたってのアドバイス、CVE 取得（Responsible Disclosure）プロセスに関する裏話、今後のキャリア目標について記載しています。
● 開発・実装にあたってのアドバイス
―報告した CVE の中で、共通していた設計ミスや実装パターンはありましたか。開発者の方向けへのアドバイスはありますか？
石井さん：私はよくルーターなどを調査対象にするのですが、ルーターなどの Web 管理画面は一般的によく使われているようなフレームワークなどを使わず、独自で実装されていそうなことが多いんですよね。
なので、CSRF 対策なども独自の実装になっていて、認証されていないユーザーがアクセスできる画面の CSRF トークンを管理者に使わせられるなど、レガシーになりつつある攻撃手法が有効なケースが何度かありました。認証も Basic 認証を使っていたりして、Web ブラウザのセキュリティ機構の恩恵を受けられないパターンも多いです。
診断員 A：確かに現行の Web ブラウザでは SameSite 属性がデフォルトで Lax になっていて、そもそも CSRF の攻撃が成立しにくくなっていますよね。Web ブラウザのセキュリティ機能が充実してきてブラウザ側で攻撃を止めてくれるようになってきていますが、よく使われているフレームワークを正しく利用した方がフレームワーク側で脆弱性への対策を取ってくれているので、よりセキュアな実装になりそうです。
ルーターなどは独自開発しているのもあってよりレガシーな攻撃でも刺さりやすい…というのは、傾向としてありそうですね。
川根さん：私はあまり思いつかないですね。ただ、結局基本的な対策ができていないが故に脆弱性になっていることがまだまだ多いのかなという感触です。SQL や OS コマンドを実行する前にそのエスケープ処理が適切にできていなくてインジェクションできてしまうというような典型的な脆弱性はよく見かけますし、そのような基本的な対策が取られていない製品は、更に深掘りすると認証バイパスやファイルアップロードなど、他にも様々な脆弱性が埋まっている…というのは感覚としてあります。
診断員 A：開発にあたっては、なるべく独自開発をせず既存のフレームワークを使用する、基本的なエスケープ処理をきちんと行うことが重要ですね。
● CVE 取得（Responsible Disclosure）プロセスの裏話
―脆弱性報告にあたって、ベンダーと連絡を取るときに気をつけていることはありますか？
川根さん：これは主に開示タイミングの話になるんですけど、いつ公開するのかという調整は必ずするようにしています。特に FortiWeb という WAF 製品で私が発見した脆弱性については、CVE のアドバイザリーが公開されてから1週間足らずぐらいで実際に悪用までされてしまって、KEV（Known Exploited Vulnerabilities Catalog）というアメリカの CISA が公開している脆弱性が実際に悪用されたリストみたいなのに載ってしまったんですよ。PoC や詳細情報が完全に公開されたことから、この前の Blog 記事も予定より公開を早めたのですが、本来これは1ヶ月くらい期間を空けて公開しようと思っていました。
石井さん：私は以前は脆弱性を見つけたら直接ベンダーと連絡をとっていた時期があったのですが、その最初の連絡に特に気を使っていました。脆弱性を見つけました、だけ伝えると伝え方によっては脅迫にも捉えられかねないので、こういう脆弱性が見つかったのでこんな風に修正した方が安全ですよ、という感じで脆弱性の修正手順までをきちんと連携するようにしていました。
ただ、やはりいきなり脆弱性報告の連絡を一個人から貰うとびっくりしてしまう企業も多いと思うので、最近は直接ベンダーとやり取りはせず、全部 IPA 経由で脆弱性報告するようにしています。
―川根さんの場合は脆弱性報告するときはどこに報告することが多いですか？
川根さん：私は結構色々です。その脆弱性に関する Blog 記事を書きたいようなときは、開示タイミングの調整などを直でやりとりできるのでベンダーに報告しています。あとベンダーによってはそのベンダーの中に、PSIRT という自社で開発している製品のインシデント対応を行うチームがあるので、そのチームに対応していただいています。
―CVE 番号が発行されるまでにはどれくらい時間がかかりますか？
石井さん：私は IPA 経由で報告することがほとんどですが、全体的に半年から1年くらいかかっていますね。
―脆弱性を見つけて報告したものの、他の人に先に報告されていた経験はありますか？
石井さん：JVN 経由で報告すると大体バッティングしても連名という形で報告者名が載りますし、見つけた脆弱性は全部報告できています。
川根さん：自分は直接ベンダーに報告することが多いので、その結果、報告が被って別の研究者の方がクレジットされちゃうみたいなケースがたまにあります。一抹の悲しみはありつつ、それはそれで消化して別の脆弱性を探しに行っています。
―このような脆弱性報告の活動は自分自身にとってどんな意味を持っていますか？
石井さん：私の場合はルーターなど一般家庭で使われてるような製品の脆弱性を報告することが多いので、報告した弱性が修正されると、一般家庭の人たちを守れたような気がしてちょっと嬉しいな、と思っています。
● これまでの経験と今後のキャリア目標について
―今までのどんなご経験が今の力に繋がっていると思いますか？
石井さん：私は Web に関する脆弱性をメインで探すことが多いので、普段の Web 診断業務での経験が役に立っていたり、逆に脆弱性調査の経験が普段の Web 診断業務に役に立ったりしていますね。
普段 Web 診断をやって色んなシステムに触れていると、こういう機能やこういう操作部分に XSS ありそうだな、などの感覚が身についてくるので、その経験が脆弱性調査にあたって活きているなと思います。
川根さん：私の場合は色んな経験が絡み合っていて特にこれだというものはないのですが、前職が SOC だったというのもあって、WAF や IPS のような製品をよく触っていたので、自分が報告している脆弱性も WAF や IPS に関するものが多いです。元々そういう製品の知識があるというのは結構アドバンテージになっているかもしれません。
―SOC の業務ではどのようなことをメインに取り組まれていたのでしょうか。あまり SOC の業務内容がピンと来なくて
川根さん：自分の場合はネットワーク製品の検証を主にやっていました。アップデートがあると新しい機能が増えるので、その機能が今のサービスにどう活かせるのかなどを調査します。IPS とかだとネットワーク経路上に設置されていたりするので、アップデート作業時にネットワークが遮断されてしまうんですね。アップデートによる停止の影響がどれくらいあるのかなどを検証していました。
診断員 A：ネットワーク製品について、実際に手を動かして調査・検証されていたご経験が役に立っているんですね。
川根さん：そうですね、単純に監視対象のトラフィックを監視して、攻撃を検知する作業というよりは、ネットワーク製品の実機を触っての検証・構築作業をよくやっていました。
診断員 A：ちなみにイエラエにも SOC がありますが、また SOC の業務をやりたい気持ちはありますか？
川根さん：元々バグバウンティをやっていたこともあり、どちらかというと Web 診断や攻撃に関する業務の方が性に合っているなと感じているので今のところは戻る気持ちはないです。ただ、海外の SOC の動向などを見ていると、ゼロデイの分析をかなり重点的にやっているところがあって。1 day 分析といって、パッチが公開された瞬間にその差分を取ってシグネチャに組み込むという取り組みをしているのですが、そういう業務はちょっと面白そうだな、と思っています。
―今後はどんな仕事をやってみたいですか？
石井さん：まだまだ修行が必要なので暫く Web 診断の業務経験を積みつつ、いずれ Web ペネトレーションテストをやってみたい気持ちはあります。普段の Web 診断だと脆弱性を見つけるところまでで終わりですが、見つけた脆弱性を組み合わせてより脅威になる攻撃ができないか…ということなどを試してみたいですね。
診断員 A：どんな技術を身につけたら Web ペネトレーションテストに取り組めそうですか？
石井さん：うーん。難しいですが、脆弱性を見つけた後に、具体的にどう攻撃に持っていくかの知識が重要だと思っていて。例えば SSRF の脆弱性があったときに、単に外部サーバにリクエストが送信できますだけではなく、クラウドなどでよくある公開されていてはいけないエンドポイントについてなどを理解している必要があるのかなと。
診断員Ａ：確かに脆弱性診断はどうしてもその性質上、お客様のビジネスへの影響や、具体的にどういう損害が出るか、金銭的にどれだけ被害を被る可能性があるか…などを考慮はするものの複数の脆弱性を組み合わせて特定のゴールを達成するところまでは行わないので、現実的にどうダメージを与えられるかみたいな知識は追加で必要そうな気がしますね。
石井さん：そういえば、川根さんも Web ペネトレーションテストの方向に興味があると聞いたことがありますがどうですか？
川根さん：私はソースコードの解析をするなどのホワイトボックス的な視点で脆弱性を探すようなこともやれるといいなと思っています。
―お二人とも Web ペネトレーションテストやソースコード解析にご興味があるんですね。今我々の所属するアセスメントサービス部と、Web ペネトレーションテストやソースコード解析を担当している高度診断部高度診断課では、共同の取り組みとしてタスクフォースチームが発足していますがお二人は参加されていますか？
川根さん：私は Web 診断時に使うメールサーバなどの環境構築を行うタスクフォースチームに所属しています。
石井さん：私はアセスメントサービス部と高度診断課のタスクフォースチームに所属していて、その活動の一環で LLM（大規模言語モデル）セキュリティ診断のライトプランを担当しています。
―LLM 診断というと、GPT などにプロンプトインジェクションなどの攻撃を行ってリスク評価するサービスですね。取り組んでみた感想はどうですか？
石井さん：まだ実際に案件をやってみた数は少ないのですが、普段担当している Web 診断とは全然考え方が違って、リフレッシュというか、いい気分転換になっています。ただ、最近は AI の口がだいぶ堅くなってきていて、うまくいかないこともありますね。
診断員 A：そういえば何ヶ月か前のことですが、Hack The Box CTF でも AI 分野の問題が何件か出題されていて、私もその時に色々プロンプトインジェクションを試してみたんですけれども、簡単なインジェクションは全然通りませんでしたね…。
石井さん：そうですね、回避する手法はどんどん出てくるものの、すぐに追いつかれてどんどん使えなくなっていくという。なので今後攻撃の難易度は上がっていきそうですが、いかに攻撃を通すかを地道に試行錯誤して頑張っています。
―あとこれは私の上司さんからぜひ聞いてきてほしいと言われているのですが、脆弱性調査を行うにあたって、イエラエに入社してよかったこと・イエラエだからできたことはありますか？
石井さん：やはり CVE 報奨金制度ですかね。前職にも同様の制度はありましたが、イエラエの方が金額が高いのでそこは嬉しいですよね。
川根さん：そうですね。私も CVE 報奨金制度はとても活用していて、やはり10件、20件と報告すると中々まとまった良い金額になるのでありがたいなと思っています。
あとは、毎月社内の全社会議で、CTF での活動報告や CVE 取得状況について共有されるタイミングがあるじゃないですか。そういう情報共有の場が定期的にあると、社内にたくさん凄い人たちがいるんだな、自分ももっと頑張ろう…という風に技術的なモチベーションが上がりますね。脆弱性を探しているのが自分だけではないと可視化されるのは良いことだなと。
今回のインタビューも、私のことを知ってくださっていなかったら、そもそも私にお声掛けいただくこともなかったと思いますし。今回こうしてインタビューが実現しているのも、エンジニアが CTF に出場したり、CVE を取得したりする活動を会社が全力で応援して、力を入れてくれている…というのが現れていて良いなと思っています。
● 脆弱性調査に興味がある方へ
―最後に、脆弱性調査に興味がある方へ向けて一言お願いいたします！
石井さん： CVE 取得と聞くと、ハードルが高いと思われている方も多いかもしれません。私も最初はそうでした。ただ、実際に手を動かしてやってみると、CVE の対象になる脆弱性は意外と見つかるものだと思います。勿論、世界中で使われているようなソフトウェアの脆弱性を見つけることにこだわる場合は、また話が違ってきますが、興味のある方はまず手を動かして実践してみて欲しいです。
よくどうやって脆弱性調査をやっているのかと聞かれることが多いのですが、少なくとも脆弱性診断に従事したことがある人であれば、対象次第で何かしら脆弱性を見つけられると私は思っているので、とにかくまずは調査対象を決めて始めてみて欲しいな、と思っています。
診断員 A：CVE 取得について、私も最初は常人離れした猛者たちがやることというイメージを持っていたのですが、お二人の話を聞いてみて、特に川根さんが仰っていた通り日常というか息をするようできるもので、決して非日常のものではないんだなということが少し分かってきて面白かったです。私もお二人のように脆弱性調査・CVE 取得を通して、世の中の脆弱性を一つでも減らすために精進します。
この度はインタビューにご協力いただき、ありがとうございました！
（本記事は2025年9月4日にGMO サイバーセキュリティ by イエラエ セキュリティブログに掲載された記事を転載しました）
