blog of morioka12

morioka12のブログ (Security Blog)

バグハント入門 (OSS編)

BugBounty・BugHunt Web Security

1. 始めに

こんにちは、morioka12 です。

本稿では、バグハントの入門として、主に Web アプリケーションの OSS に焦点をおき、脆弱性の発見・報告・CVE ID の取得について紹介します。

[更新 2025/12/31] お知らせ

Zenn Book にて、『30日でCVE取得! OSSバグハント入門』をリリースしました。

zenn.dev

免責事項

本稿の内容は、セキュリティに関する知見を広く共有する目的で執筆されており、悪用行為を推奨するものではありません。

想定読者

  • セキュリティ初学者・学生
    • 特に Web Security の学習をしている方
  • リアルワールドで脆弱性を発見したい方
  • 初めて CVE ID を取得したい方
  • (OSS の開発に携わっている方)

筆者のバックグラウンド

簡単な筆者のバックグラウンドは以下になります。

  • Web Security や Cloud Security などのセキュリティ分野について学習している学生 (24新卒)
  • バグバウンティプラットフォームにて脆弱性の報告・認定実績あり
  • 2023年6~7月で9件の CVE ID を取得
    • GitHub Star 56k 以上の CMS「Strapi」などで脆弱性の報告・認定


2. CVE とは

CVE (Common Vulnerabilities and Exposures: 共通脆弱性識別子)とは、ソフトウェアや OSS (Open Source Software) などのプログラム上で発見された脆弱性に一意の番号を付与される識別子です。

そして、各脆弱性に付与された一意の CVE 識別番号を「CVE ID」といいます。

注意点として、CVE ID はソフトウェアや OSS などの脆弱性に対するものに採択されるため、基本的に Web サイトの脆弱性には採択されません。

IPA (情報処理推進機構)では、CVE を以下のように表記しています。

共通脆弱性識別子CVEでは、『プログラム上のセキュリティ問題』を一意に識別するために、脆弱性に対してCVE識別番号を付与します。

このCVE識別番号は「CVE-西暦-連番」と構成されており、セキュリティベンダや製品開発ベンダ、研究者などのセキュリティ専門家で構成されるCVE Editorial Boardと呼ぶ機関が、報告のあった脆弱性を評価し割り当て作業を行っています。

www.ipa.go.jp

JVN (Japan Vulnerability Notes)

JVN (Japan Vulnerability Notes)とは、日本で使用されているソフトウェアなどの脆弱性関連情報とその対策情報を提供し、情報セキュリティ対策に資することを目的とする脆弱性対策情報ポータルサイトのことです。

また、IPA の「脆弱性関連情報の届出受付」で報告を受け付けて脆弱性認定されたものは、JVN iPedia に登録されます。

jvn.jp

jvndb.jvn.jp


3. 探す対象の選び方

ターゲットとなる OSS はいくらでもあるため、脆弱性を探す対象選びが難しかったりします。

そのため、いくつかのポイントで対象を選んでみることをお勧めします。

ポイント

  • 気になる OSS や使ったことのある OSS を選ぶ
  • GitHub の Topics から気になるタイプの OSS を選ぶ
  • 過去に CVE ID が発行されたことのある OSS を選ぶ
  • 得意なプログラミング言語で作られている OSS を選ぶ
  • その他
    • GitHub の検索機能から特定のライブラリや関数を使っているものを列挙し、その中から OSS を選ぶ
    • 過去の CVE ID から特定の脆弱性で絞って OSS を選び、その修正された脆弱性を回避(bypass)できないか検証する
    • WordPress のプラグイン一覧から OSS を選ぶ
    • (バグバウンティのプログラムに含まれる OSS を選ぶ)


OSS Topic (Type)

脆弱性の探しやすいさとして、まずは以下のタイプの Web アプリケーションをお勧めします。

これらは、Web アプリケーションとして程よく機能や権限周りなどが実装されていて、脆弱性を探しやすかったりします。


特定の条件で絞る

特定のライブラリや関数で絞る場合

GitHub の検索機能などを活用して、特定のライブラリや関数に焦点を当てて OSS を探します。

例えば、PHP の unserialize() による「安全でないデシリアライゼーション(Insecure Deserialization)」を探そうとした場合、検索欄に「language:PHP unserialize($_GET」のように入力して検索することで、GET リクエストで外部から指定されたパラメーターの中身を直接デシリアライズしているコードを列挙したりすることができます。 (このままでは誤検知ややられアプリ等も含まれます)

このようにして、特定の言語で危険な関数やライブラリを使用している OSS を列挙して脆弱性を探すことで、特定の脆弱性を探しやすかったりします。

特定の機能や脆弱性で絞る場合

JVN iPedia の「脆弱性対策情報データベース検索」などを活用して、特定の機能や脆弱性のあった OSS を探します。

例えば、PHP のファイルアップロード機能における 「RCE (Remote Code Execution) 」のあった OSS を探そうとした場合、検索欄に「PHP file」と入力して検索することで、過去の CVE ID で条件にあった脆弱性を列挙することができます。

検索のキーワードとしては、以下のようなキーワードで絞って検索すると良いと思います。

  • プログラミング言語
  • 機能名
  • 脆弱性名
  • 脆弱性の CWE の番号

jvndb.jvn.jp


バグバウンティの OSS

バグバウンティのプログラムにも OSS を対象としたものがあり、脆弱性を報告して報酬金を貰うことができます。

HackerOne

Asset type で「Source code」を選択して検索することで、対象のプログラムを選ぶことができます。

hackerone.com

また、huntr.dev で Boosted Projects に指定された OSS で脆弱性を探して報告することで、認定されれば多少の報酬金を貰えたりします。

huntr - The world’s first bug bounty platform for AI/ML


4. 脆弱性の検証方法

OSS を対象に脆弱性を検証する場合、基本的には「ローカル環境」で Web アプリケーションなどを起動して動作を見ていきます。

僕の場合は、主に Docker でローカル環境にコンテナを立てて検証を行なっていました。

もし OSS のファイルに Dockerfile や docker-compose.yml などがない場合は、自分で必要なファイルを書いたり、Docker Image から引っ張ってきたりして検証をしていました。

また、OSS のドキュメントに「Getting Started」として丁寧に起動方法が記載している場合もあるため、その手順通りにローカル環境で起動させます。


アプローチ方法

OSS を対象に脆弱性を探す際のアプローチ方法として、主に動的解析と静的解析があります。

動的解析(Dynamic Analysis)

動的解析とは、プログラムやソフトウェアが実行される際の挙動や性能を評価するための手法のことです。

Web アプリケーションの場合は、Burp Suite などのローカルプロキシを用いて通信(リクエスト・レスポンス)を観測して、挙動を確認したりします。

その際は、主に認証認可や外部からの入力を受け付けるパラメーター、ファイルアップロード機能などの特定の機能に着目して脆弱性がないかを確認していきます。

確認する観点の例としては、「OWASP Top 10」や「OWASP API Security Top 10」がわかりやすいと思います。

owasp.org

owasp.org

静的解析(Static Analysis)

静的解析とは、ソースコードやバイナリコードを実行せずにコードベースで解析する手法のことです。

OSS の場合は、ソースコードを入手することが可能なため、CodeQL や Semgrep などを SAST (Static Application Security Testing)のツールを使ったりしてコードベースにセキュリティ問題の発見の手助けになる可能性があります。

また「Secure Code Review」に関して、ここではあまり触れませんが例として以下のような点を追って確認していきます。

  • 認証などの重要な機能
  • ユーザーの入力を受け付ける箇所 (HTTP リクエストパラメーターやファイルアップロードなど)
  • ハードコーディングされたクレデンシャルやシークレットな情報
  • ライブラリなどの古い依存関係の使用 (既知の脆弱性の利用)
  • 非表示のデバッグ機能やエンドポイント
  • 弱い暗号やハッシュアルゴリズム

Code Review については、OWASP もドキュメント「OWASP Secure Code Review Guide」を公開しているため、こちらをご覧ください。

https://owasp.org/www-project-code-review-guide/assets/OWASP_Code_Review_Guide_v2.pdf

OWASP の「OWASP Cheat Sheet Series」も参考になるかと思います。

cheatsheetseries.owasp.org


5. 脆弱性の報告先

CVE ID を発行してくれる報告先は、MITRE によって許可された組織である「CNA (CVE Numbering Authorities)」という CVE 採番機関である必要があります。

日本で外部からの脆弱性報告を受け付けている CNA は、IPA (情報処理推進機構)があります。

IPA は「脆弱性関連情報の届出受付」という窓口があり、以下のフォームから発見した脆弱性を報告することができます。

OSS の脆弱性を報告する場合は、「ソフトウェア製品脆弱性関連情報の届出」に該当します。

isec-vul-form.ipa.go.jp

ちなみに、IPA で報告する場合は、以下のような条件に合う OSS でなければなりません。

  • 日本国内で利用されているソフトウェア製品に関わる脆弱性である
  • 本脆弱性に起因する影響が不特定または多数の人々におよぶおそれがある

また、IPA 以外にも huntr.dev や GitHub Security Advisories などを通して脆弱性を報告して CVE ID を発行してもらうことも可能です。

huntr.dev

docs.github.com

(個人的には、GitHub の Security タブから GitHub Security Advisories を通して脆弱性の報告・対応・CVE ID の発行が諸々やりやすくて好んでいます。)


6. 報告書の書き方

OSS に対して脆弱性を報告する場合、主に以下の点を記載します。

  • 脆弱性のタイトル
  • 脆弱性の概要
  • 脆弱性の検証方法/再現方法/PoC (Proof of Concept)
  • (脆弱性の再現動画)
  • 脆弱性の原因となっているコードの行/関数
  • 脆弱性の脅威
  • (脆弱性の修正案)
  • 脆弱性のある対象のバージョン
  • 脆弱性の CVSS スコア
  • 脆弱性の CWE
  • (脆弱性の参考文献)

注意点として、脆弱性の報告書を読む人は OSS の開発者のため、セキュリティ(脆弱性)に詳しい人とは限りません。

そのため、開発者でも分かるように脆弱性の検証方法や脆弱性の具体的な脅威、信頼性のある文献(OWASP など)を丁寧に書くことをお勧めします。

また、GitHub Security Advisories を通して脆弱性を報告する場合、以下のような画面で報告書を記載します。

参考までに、僕が報告した脆弱性のレポートは以下で公開されています。

github.com


CVSS

CVSS (Common Vulnerability Scoring System: 共通脆弱性評価システム)とは、情報システムの脆弱性に対するオープンで汎用的な評価手法、および指標を指します。

CVSS は、FIRST (Forum of Incident Respones and Security Teams) 内に設置された CVSS-SIG (Special Interest Group) によって策定され、2023年9月現在の最新バージョンは3.1となっています。(2023年10月を目途にバージョン4.0の正式な公開が予定されています)

CVE ID の脆弱性に対しても、同一の基準に則った定量的な深刻度として評価します。

CVSS のスコアや脆弱性を評価する項目は、以下のようになっています。

深刻度 スコア
緊急 (Critical) 9.0 ~ 10.0
重要 (Important) 7.0 ~ 8.9
警告 (Warning) 4.0 ~ 6.9
注意 (Attention) 0.1 ~ 3.9
なし (None) 0.0

基本評価基準 (Base Metrics)

  • 攻撃の難易度を評価する項目
    • 攻撃元区分 (AV：Attack Vector)
    • 攻撃条件の複雑さ (AC：Attack Complexity)
    • 必要な特権レベル (PR：Privileges Required)
    • ユーザ関与レベル (UI：User Interaction)
  • 攻撃の影響度を評価する項目
    • 機密性への影響/情報漏えいの可能性 (C：Confidentiality Impact)
    • 完全性への影響/情報改ざんの可能性 (I：Integrity Impact)
    • 可用性への影響/業務停止の可能性 (A：Availability Impact)
  • 影響範囲の拡大の有無を評価する項目
    • スコープ (S：Scope)

www.ipa.go.jp

また、CVSS v3 のスコアを計算するツールは、以下のようにオンライン上にあったりします。

jvndb.jvn.jp


CWE

CWE (Common Weakness Enumeration: 共通脆弱性タイプ一覧)とは、脆弱性の種類を識別するための共通の基準となるものです。

報告された脆弱性の CVE ID には、どれも CWE が示されていて、簡単に脆弱性の種類を把握することができます。

www.ipa.go.jp

ちなみに、MITER が公開している「2023 CWE Top 25 Most Dangerous Software Weaknesses」というランキングもあり、最も危険なソフトウェアの脆弱性を一覧にしたものがあります。

ランキングは、2021年と2022年に CVE ID が付与された4万3996件の脆弱性について、共通脆弱性評価システム「CVSS」で分類された CWE をもとに分析され、ランキングとして取りまとめたものだそうです。

cwe.mitre.org


7. 脆弱性発見から CVE ID の取得までの流れ

脆弱性を発見してから CVE ID の取得までは、主に以下のような流れになります。

  1. 脆弱性を発見する
  2. IPA などの CVE 採番機関に報告する
  3. 報告した機関が実際に開発者に脆弱性に関する連絡をする
  4. 発見者と開発者で脆弱性の質問や修正案の連絡を数回取る
  5. 開発者が修正を完了する & 新バージョンをリリースする & 公開する
  6. 脆弱性に CVE ID が発行される

ちなみに、IPA の場合は、脆弱性を受理してから JVN が公開されるまで「45 日以内は 29%」と公表されてます。

www.ipa.go.jp

また、僕の場合は最近 huntr.dev や GitHub Security Advisories で報告していて、早いものだと報告して次の日に脆弱性が修正・公開・CVE ID の発行がされたこともあり、開発者が早い段階で対応してもらえれば、その分早く CVE ID が発行されます。 だいたいは3日~4週間くらいで修正してもらえたと思います。

ただし、企業が開発している OSS やクラウド版のサービスがある OSS などは、リリースまでの手順が長かったりして公開や CVE ID の発行が遅くなったものもありました。


注意点

OSS の脆弱性を報告することに関して、いくつか注意点があります。

  • 脆弱性を報告しても修正されない場合がある
    • 開発者が仕様内としたり、事実上の脅威がないと判断する場合がある
  • 脆弱性を報告して修正されても、CVE ID の発行まで申請してもらえない場合がある
  • 脆弱性を報告してから修正されるまで長期間待たされる場合がある
    • 脆弱性の脅威(リスク)が低い場合だと修正を後回しにされる可能性がある
  • 現在あまり使われていない OSS や開発が盛んでない OSS の場合、修正以前に脆弱性の対応がされない可能性がある

これらの懸念点を回避するには、以下のような点を気にすると良いと思います。

  • GitHub の Star が一定数多い OSS を選ぶ
  • 現在も開発が定期的に行われていそうな OSS を選ぶ
  • 過去に脆弱性が修正されて CVE ID が発行された OSS を選ぶ
  • 脆弱性の報告書を適正に脆弱性の原因や脅威を記載するようにする

また、もし脆弱性を報告して修正されたはずなのに CVE ID の発行まで申請してもらえなかった場合は、MITRE の「Submit a CVE Request」から自ら申請することで、直接 CVE ID を発行してもらえる可能性があります。

cveform.mitre.org


8. バグハント前のスキル準備

まずは、脆弱性の種類やテスト方法を習得しましょう。

それには、過去の CVE ID やレポート、検証コード(PoC)などをひたすら見て、どういう機能にどういった脆弱性が実際に報告されているかを知っていくのが手っ取り早いと思います。

過去の CVE ID やレポート


Web Security の場合

初めに Web Security に関する知見を得るには、以下のような書籍やコンテンツから学ぶことをお勧めします。

書籍

学習コンテンツ

GitHub コンテンツ


9. その他

その後のチャレンジ

その後のチャレンジとして、以下のような点をあげておきます。

  • 有名なソフトウェアを対象に脆弱性を探してみる
  • ライブラリ・モジュール・プログラミング言語・ブラウザ・OS などを対象に脆弱性を探してみる
  • バグバウンティの対象になっている OSS で脆弱性を探してみる
  • OSS でなく、バグバウンティのプログラムに含まれる Web アプリケーションを対象に脆弱性を探してみる


バグバウンティ入門

バグバウンティのプログラムに含まれる対象に対して脆弱性を探す場合、バグバウンティは報酬金(Bounty)が貰えるため OSS で脆弱性を探すより遥かにライバル(他のバグハンター)がいるためハードルが少し上がると思われます。

また、バグバウンティで脆弱性を報告して報酬金を貰うには、基本的に脆弱性の「第一報告者」にしか支払われません。脆弱性の認定も同様です。

そのため、他のバグハンターとは異なるアプローチや思想、探究心を持って脆弱性を探す必要があったりします。

ちなみに、バグバウンティの入門も別途ブログで公開しているため、よければこちらもご覧ください。

scgajge12.hatenablog.com


セキュリティエンジニアを目指す就活生の方へ

セキュリティベンダーなどの企業でセキュリティエンジニアとして働きたい学生・就活生は、一つでも CVE ID の取得にチャレンジしてみることをお勧めします。

なぜなら、セキュリティエンジニア(特に脆弱性診断などの業務を行うエンジニア)の募集欄にある「望ましい経験」に 「CVE の取得経験」と記載している企業もあるため、良いアピール？になるかもしれません。

そのため、脆弱性診断などの業務を行うセキュリティエンジニアを志望する場合、OSS で脆弱性を探したり、バグバウンティで脆弱性を報告して報酬金を貰ってみたり、既知の脆弱性を検証して理解を深めて更に検証したり、リアルワールドの脆弱性を探してみることをお勧めします。

個人的には、同じ学生でバグバウンティに取り組んでいる日本人が増えてワイワイできると嬉しいです。


OSS の開発者の方へ

OSS の開発に携わっている方は、ぜひリポジトリの Security タブから「GitHub Security Advisories」を有効に活用してもらえればと思います。

活用することで、OSS の開発者(メンテナー)が非公開スペースで脆弱性の修正を行ったり、報告者とやり取りを行うことが可能となるため、脆弱性の報告者(バグハンター)は圧倒的に脆弱性報告がしやすくなります。

その結果、OSS のセキュリティ向上にも繋がって、より良い開発物になると思います。

詳しくは、以下をご覧ください。

docs.github.com

github.nih.gov


10. 終わりに

本稿では、バグハントの入門として、主に Web アプリケーションの OSS に焦点をおき、脆弱性の発見・報告・CVE ID の取得について紹介しました。

少しでも OSS を対象とした脆弱性の発見・報告・修正・CVE ID の取得について参考になれば幸いです。

また、今回はあまり脆弱性の発見方法や Secure Code Review 、バグバウンティについて深く紹介しませんでした。

もし興味のある方や気になる方がいれば、ぜひ DM にてご連絡ください。

ここまでお読みいただきありがとうございました。