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の動向などを見ていると、ゼロデイの分析をかなり重点的にやっているところがあって。1day分析といって、パッチが公開された瞬間にその差分を取ってシグネチャに組み込むという取り組みをしているのですが、そういう業務はちょっと面白そうだな、と思っています。
―今後はどんな仕事をやってみたいですか？
石井さん：まだまだ修行が必要なので暫く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取得を通して、世の中の脆弱性を一つでも減らすために精進します。
この度はインタビューにご協力いただき、ありがとうございました！
