学生向けバグバウンティイベント P3NFEST にプログラムを提供しました!

こんにちは、菊地(@_tinoji)です。GW終わっちゃいましたね・・・。

この度、IssueHunt社主催の 学生のためのサイバーセキュリティカンファレンス P3NFEST Conf 2024 に参加し、同時開催された学生限定バグバウンティイベント P3NFEST Bug Bounty 2024Park Directをプログラム提供させていただきました!

※オフラインのカンファレンスイベントに加え、同時開催でオンラインのバグバウンティイベントがあるという形式でした。カンファレンスでバグバウンティイベントについて紹介するパートがあったので、カンファレンスにも参加させてもらいました。

issuehunt.jp

学生さん向けイベントの参加も初、バグバウンティを実施するのも初、と何から何まで初めてづくしでしたが本当に有意義な経験となりました。

目次のとおり長くなってしまいそうですが、記憶の新しいうちにレポートしておこうと思います。バグバウンティの導入を検討する方の一助になれば幸いです。

バグバウンティ導入を心に決めるまで

セキュリティ対策の状況

Park Directは2019年にローンチしたサービスですが、個人情報をお預かりしていますし決済機能もあるアプリケーションなため、かなり早くから外部の企業に脆弱性診断をお願いしていました。また、コンテナイメージやTerraformファイルのスキャンもCIに導入していました。

そのため 診断/スキャン→トリアージ→対策 というプロセスは実施できていたのですが、一方で「攻撃者視点での対策」ができているかというと・・・、社内にホワイトハッカーがいるわけでもないですし、あまり現実的ではありませんでした。ペネトレーションテストも一度検討したことがあったのですが、紆余曲折あって実施には至りませんでした。

「一定やれているけど、実際攻撃の標的になった場合にどうなんだ??」というのは、プロダクトを開発している人ならば一度は考えたことがあるのではないでしょうか。

IssueHuntとの出会い

もちろんバグバウンティという選択肢は考えたことはあったのですが、バグバウンティのプラットフォームは海外で活発なイメージが強く、日本国内対象のPark Directを登録してもなぁ、と思いながら過ごしていました。

そんなある日、東洋経済オンラインのすごいベンチャー100という記事を何気なく見ていたら、「バグバウンティサービス展開」の文字が!!!

それがIssueHuntさんでした。一緒に見ていたメンバーがその日のうちに資料請求をしていたことを覚えています(笑)

一度打ち合わせで仕組みやコストについて説明していただき、導入はかなり現実的だと感じました。ただ、当然ながらその年の予算計画になかったので、2024年度の導入を目指してとりあえず予算確保に動き始めました。

イベント参加に至るまで

無事予算が取れそうではあったのですが、1つ大きな心配事として「めっちゃ報告来て運用回らなかったらどうしよう」というものがありました。

まぁ腹を決めてやるしかないか〜と思っていたのですが、IssueHunt Loungeというコミュニティイベントに参加した際に、代表の横溝さんに学生向けイベントの提案をしていただきました。

招待制イベントで参加者が限られているため一般公開するよりも報告数は少なくなる、ということでトライアルに最適だと思い、参加を決めました。

参加を決めて社内で調整を始めてからそれなりに苦労した点もあったのですが、それは振り返りイベントでお話しさせていただいたので後述します。

カンファレンス当日

コロナでオフラインイベントが少なくなって以降あまり大人数のイベントに参加していなかったのですが、会場参加もオンライン参加もそれぞれ150人以上という大盛況ぶりで、とても懐かしい気持ちになりました。基調講演とパネルディスカッションも拝聴させてもらい、「すげー!本物の徳丸先生だ!」と学生さんよりも興奮していました。 boost.connpass.com

バグバウンティプログラムの紹介パートもあったので自分も登壇させてもらったのですが、他の企業さんと比べて会社・サービスともに知名度が圧倒的に低く、もっと頑張らねばと思いました・・・!

IssueHunt代表の横溝さんと記念撮影

バグバウンティ期間中の話

バグバウンティは2/19(月)からスタートしたのですが、なんと最初の週から複数件の報告がありました・・・!

↓最初の報告をしていただいた学生さんの記事。お互い初めてのことでしたが、IssueHuntのプロセスに沿って進めればよく、スムーズに報奨金支払いまで行けました。 l3ickey.github.io

自分は以下のような流れで対応していました。

  1. 報告を受ける。
    1. 脆弱性の種類、再現手順、CVSSスコアから想定される報奨金の額などが記載されます。
    2. 内容を確認したら一旦「これから調査します〜」と返信。※返信日数の目安を設定可能です。
  2. 再現検証と既知調査を行い有効かどうか判定する。
    1. 記載された手順で再現し実際に攻撃が可能、過去の脆弱性診断で報告がない、CVSSスコアが基準以上、の3点で判断。
    2. 決まりはないですが、1週間以内を目安に判定していました。
  3. 報奨金を支払う。
    1. 報告者が設定したCVSSスコアとは別に、ホスト側でも算出する機能があるので項目を埋めて確認。
    2. 目安の金額が出力されるので、それをベースにお支払いする。
  4. 対応期日を決めて開発チームに修正を依頼。
    1. CVSSスコアによって対応期日の目安を設定して、チケットを開発チームにアサイン。
    2. ※ということをやりたかったのですが、結局期間中に運用に乗せられず・・・。緊急度の高いもの以外は一度貯める感じになってしまいました。

全体的な流れはスムーズだった一方、トリアージや報告者への対応にはいくつか反省点も残りました。こちらも振り返りイベントで話したので後述します。

その後もコンスタントに報告をいただき、最終的に7件の報告があり、全て有効認定とし報奨金をお支払いしました。

振り返りイベントでの登壇

バグバウンティ期間が3月末で終わり、4月にカンファレンスとバグバウンティについて振り返るイベントが開催されました。自分も他の企業さんのバグバウンティについて知りたいと思っていたので、振り返りがあるのは非常に助かりました。 boost.connpass.com

自分は「バグバウンティイベント振り返り」のパートで登壇させていただき、いくつかの質問に回答したので、加筆修正しつつ簡単にまとめておきます。

左: 日本経済新聞社 藤田さん、中央: 自分、右: Sansan 黒澤さん

本イベントを社内に提案した際、どのような反応だったか、どのように社内を説得したか

基本的にウェルカムで、「やるのかどうか」ではなく、「やる前提で懸念を潰していこう」という方向で早い段階で議論を進められました。

ニーリーの場合、CTOだけでなくCEOとCISOもエンジニア出身なのでこういった説得に全く苦労しないというチートがあってズルいのですが(笑)、事前にコスト面や利用規約について詳しく把握しておいたのでスムーズでした。 特にIssueHuntはプログラムごとに予算額を設定してそれを超過したら停止できるので、従量課金ではありつつも上限を決めて「これ以上は行かないので!」という説得がしやすいと思います。

もちろん頭を悩ませたポイントもあり、以下の2点は何度も議論しました。

  • ①実施環境をどうするのか?
    • 検証だとしても攻撃が成功して個人情報が見えてしまうのは避けたい。
    • DEV/STGを使っても環境差分はほぼないので、診断に影響はないのでは?
    • → DEV環境を使うことに決定!
  • ②toCだけでなくtoBのアプリケーションも対象にするのか?
    • toCの画面だけでなく、不動産管理会社が利用するtoB用の管理画面も存在する。
    • サインアップはできずアカウントは個別に発行するため、期間中は共有アカウントを作ってプログラム説明欄にID/パスワードを記載する必要がある。
    • DEV環境、身分が保証された招待制イベント、期間が終わればアカウントを停止すればOK、という3点でリスクは低い。
    • → toBも対象にすることに決定!

余談ですが、自分もCTOもIssueHunt社が提供しているBoost Noteというアプリの元ヘビーユーザーで、それで会社への信用度が上がったという寄与が若干あるかもしれません(笑)

どのような類の脆弱性報告を受け取ったか

すでに修正対応済みで話せるものを1つ紹介します。とあるAPIのパラメータに適当なIDを入れると、権限確認の処理が抜けていて自分のアカウントが所有していないものが取れてしまうという、非常に初歩的なアクセス制御のミスがありました。

こういったものはかなり気をつけており過去にも網羅的に確認していたのですが、(詳しくは書きませんが)確かに気づきづらい理由がありました。脆弱性診断でも報告は上がっていませんでした。

こういった「簡単だけど気付けないもの」に対してバグバウンティは非常に有効な手段だと感じています。

印象に残っている報告や、その他エピソードなど

具体的にどういう脆弱性かは割愛しますが、とある報告に対して「toB画面から自分のアカウントに対してしか実行できず、外部からの攻撃はできないので脆弱性として扱いません」というような回答をしたケースがありました。しかし、その後詳しく調べてみると外部からの攻撃が通ることが分かり、回答を撤回して追加の報奨金をお支払いしました。

今振り返ると、再現検証のフローが曖昧だったという反省になります・・・。初めてではあったものの、どこまで検証してどうなれば有効判定にするかについては事前に決めておくべきでした。複数人で対応可能なら、判定や報奨金額に対するクロスチェック or レビューも効果的だと思います。

次回のイベントにて、プログラム提供を悩んでいる企業様に対し、背中を押すコメント

費用対効果が非常に高いと感じました。今回7件の有効報告がありましたが、トータルの費用は10万円未満でした。そこまで重大な脆弱性が見つからなかったというのはもちろんありますが、それでも全て未知の脆弱性でトリアージ対象になるものもあったので、かなりお得だったと思っています。

これから

もともとは今回のイベントが終わったらすぐ一般公開のプログラムに変更しようと思っていたのですが、実際にやってみて、まだ自分たちは一般公開した場合の報告数に耐えられる体制ではないなと感じました。報告後すぐに再現検証の時間が取れなかったり、修正対応を開発チームに差し込むのが難しかったりと、課題が多く見つかりました。また、一般公開の場合は海外のユーザーも多いので、英語でのコミュニケーションで若干対応コストが増えることも念頭に置く必要があります。

セキュリティチームやPSIRTという訳ではないですが、バグバウンティの運用も守備範囲にする新しいチームを現在立ち上げ中で、最近メンバーも増えたので、あと何回か期間限定のプログラムでチームの練度を上げて、一般公開に向けてステップアップしていこうと考えています。夏にもP3NFESTが開催される予定とのことなので、またお世話になろうと思っています!

また、VDPとバグバウンティを組み合わせて運用している企業の事例をお聞きして、一般公開プログラムにしなくても間口を広げる方法があることも知り、そちらも候補に挙がっています。あらゆる手段を活用してPark Directをよりセキュアにしていきます!!