7周年を迎えたGitHubセキュリティバグ報奨金プログラム

ギットハブ・ジャパン合同会社
2021年07月15日
18：09

オープンソースプロジェクトおよびビジネスユースを含む、ソフトウェアの開発プラットフォームを提供するGitHub, Inc.（本社：米国サンフランシスコ）は、6月25日（米国現地時間）に7周年を迎えたGitHubセキュリティバグ報奨金プログラムのハイライトおよび今後の展望を公開しました。

セキュリティは、GitHubが掲げるミッションの中核を成すものです。GitHubのProduct Security Engineeringチームは、GitHubを使って安全なソフトウェアを開発する方法の継続的な改善に取り組んでいます。GitHubが取り組むセキュリティの開発ライフサイクルにおいて重要な要素の1つが、GitHubセキュリティバグ報奨金プログラム（https://bounty.github.com/）を通じたセキュリティ研究者やバグ報奨金コミュニティとのパートナーシップです。2014年のプログラム開始以来、このプログラムと研究者たちの貢献によって、GitHubはより安全な製品を提供することができるようになりました。これらは、GitHubのチームだけでは実現が難しいものです。今年で7年目となるバグ報奨金プログラムは、GitHubによる製品セキュリティの継続的な向上を可能にする、成熟した信頼できる要素となっています。

セキュリティバグ報奨金プログラムによって軽減された興味深い脆弱性の詳細や来年に向けた展望を紹介します。拡大を続けるバグ報奨金プログラムへのコミュニティの皆さまのご参加を心よりお待ちしています。

2020年のハイライト
2020年はこれまでで最も忙しい年となり、同年2月から2021年2月までの間に、過去最多のセキュリティバグ報告に対応しました。本プログラムが拡大を続ける中、バグ報告への最初の返信、トリアージ、支払いまでの時間について、挑戦的な基準を維持してきたことはGitHubの誇りとなっています。昨年のハイライトを以下にご紹介します。

GitHubの製品やサービスで見つかった203件の脆弱性に対し、524,250米ドルの報奨金が支払われました。その結果、2016年にHackerOneに移行してからのプログラム全体の報奨金は1,552,004米ドルとなりました。
公開プログラムと非公開プログラム全体で、1,066件の報告がありました。
回答時間は2019年から4時間の改善に成功し、最初の回答までが平均13時間となりました。
報告されたものは、平均24時間以内に社内で検証され、パートナーチームにトリアージされました。
報奨金は、対象となる報告が行われてから平均24日後に支払われました。
GitHubのプログラムが、HackerOneのトッププログラム（https://www.hackerone.com/resources/e-book/top-10-bounty-programs-2020）の1つにランク付けされました。

バグ報奨金プログラムへの報告は、GitHub、GitHubの製品、開発者コミュニティ、ならびにGitHubのお客様のセキュリティを高度化させる機会に貢献します。オープンソースコミュニティの方々のスキルをお借りして、すべての人にとってGitHubをより良いものにしていくための継続的なコラボレーションに期待が寄せられています。本プログラムへの参加にご興味のある方は、プログラムの対象範囲、規則、報奨金などの詳細はウェブサイト（https://bounty.github.com/）をご確認ください。

2020年にGitHubで話題となったバグ
GitHubの報奨金プログラムに寄せられるバグ報告の創造性と深い技術的才能には、当社はいつも感心させられています。その一例として、特に興味深かったものについて詳しくご紹介します。

ユニバーサルオープンリダイレクト (Universal open redirect)
オープンリダイレクト単独では通常、ソーシャルエンジニアリング攻撃の足掛かりにしかならないため、オープンリダイレクトの脆弱性が、アプリケーションに深刻な影響やリスクをもたらすことは稀です。しかし、William Bowling氏(@vakzz)（https://hackerone.com/vakzz?type=user）は、GitHub.comのオープンリダイレクトの脆弱性を利用して、GistユーザーのOAuthフローを侵害する方法を示すことに成功しました。

William氏は、GitHub.comの多数のコントローラで使われているメソッドが、Ruby on Railsの”url_for”ルーティングメソッドに、リンクやリダイレクト先を生成する安全ではないユーザー制御の引数を与えていることを発見しました。JavaScriptプロトコルハンドラーを与えると、クロスサイトスクリプティング(XSS)が生じる可能性がありましたが、GitHub.comには強力なコンテンツセキュリティポリシー（https://github.blog/2016-04-12-githubs-csp-journey/#content-security-policy）があるため、潜在的なXSSのリスクは軽減されます。ただし、この生成されたURLはリダイレクト先として使われていたため、攻撃者が選択した場所にユーザーをリダイレクトする目的で使われる可能性がありました。リスクはかなり低いのですが、この脆弱性を利用して、提供したGitHub.comへのリンクから最終的には攻撃者が指示するサイトにリダイレクトさせることで、ソーシャルエンジニアリング攻撃を容易にすることができました。

William氏は、GitHubのリクエストハンドラーでこの脆弱なメソッドが広く使われていることを考慮し、このバグの影響をさらに踏み込んで調査しました。このリダイレクトを、GitHub.comがGitHub Gistの認証を実行するOAuthフローと組み合わせて利用することにより、OAuth認証が成功した後でユーザーをリダイレクトし、ユーザーのOAuthコードを攻撃者が決めた場所に流出させることができました。その結果、攻撃者は、悪意のあるリンクに騙されたユーザーのGitHub Gistにログインできるようになります。

GitHubでは、内部的に”safe_url_for”および”safe_redirect_to”というヘルパーメソッドが用意されているため、信頼できないリダイレクト先やプロトコル、その他の危険な引数をフィルタリングすることで、このような種類の脆弱性を防いでいます。オープンリダイレクトの脆弱性を軽減するために、脆弱性のあるコードをリファクタリングし、安全なバリアントを使用して、”url_for”に対する特定の引数をユーザーが制御できないようにしました。さらに、継続的に実行しているスタティック分析ツールにチェック機能を追加し、ユーザー制御の引数を持つ新しいコードに”url_for”が追加されたことが検出できるようにしました。このように、この種の脆弱性を捕捉する安全策を講じることにより、コードベース全体でこのクラスの脆弱性の排除を進めました。

この報告には1万米ドルの報奨金が支払われました。オープンリダイレクトが他の機能と連係した場合の影響を実証するために調査を続けたWilliamさんの粘り強さに感謝しています。この脆弱性の詳細については、William氏のブログ（https://devcraft.io/2020/10/19/github-gist-account-takeover.html）をご覧ください。

CVEの発行
昨年のバグ報奨金プログラム6周年ニュースリリース（https://digitalpr.jp/r/38378）でお伝えしたとおり、2020年にGitHubはMITREのCVE採番機関(CNA)となり、GitHub Enterprise Serverの脆弱性に対するCVEの発行を開始（https://github.blog/changelog/2020-03-11-github-enterprise-server-issuing-cves/）しました。CNAになったことで、製品で修正された問題を明確かつ一貫してお客様に伝えることができるようになり、お客様は古くなったGitHub Enterprise Serverインスタンスを適切に識別し、アップグレードの優先順位を決められるようになりました。さらに、バグ報奨金プログラムに報告されたGitHub Enterprise Serverの脆弱性はそのCVEの研究者の功績となるため、GitHubのプログラムに参加している研究者の評価をさらに高めることができます。

このプロセスを支援するため、GitHubはCVE発行の社内ワークフローを形式化しました。脆弱性をGitHubの問題として社内で追跡する手段と連動する自動化を行い、CVEの詳細が明確で一貫したものになるよう、以下のように手順を標準化しました。

chat-opを実行し、GitHub製品のすべての脆弱性に対して発行される社内の脆弱性追跡番号に基づき、新しいPull Requestを作成します。
Product Security Engineeringチームのメンバーが、説明、カテゴリー、重大度、修正バージョンなどのすべての詳細情報を、Markdownテンプレートに入力します。
Product Security Engineeringチームの他のメンバーやエンジニアリングチームがこれをレビューし、Pull Request内でフィードバックを提供します。
公開の準備が整ったら、GitHub ActionsによってこれをMITREが使用するJSON形式に変換し、”CVEProject/cvelist”（https://github.com/CVEProject/cvelist/）リポジトリに追加できるようにします。

昨年、GitHubはこのワークフローとツールの改良を続け、GitHub Enterprise ServerのCVEを3件公開しました。2021年に入ってからもこのワークフローは効果的に機能していることから、7件の追加アドバイザリのCVEプロセスを迅速に完了させることができました。より多くのCVEと製品の修正に役立つ詳細を提供できれば、GitHub Enterprise Serverのお客様にアップグレードの優先度をより簡単に伝えることができます。

非公開のバグ報奨金
2020年、GitHubは公開されているバグ報奨金プログラムに加えて、ベータ版などのプレリリース製品を対象とした非公開のバグ報奨金プログラムの取り組みを開始しました。非公開の報奨金プログラムは、新製品や新機能のソフトウェア開発ライフサイクルの早い段階で問題を特定し、開発の後半になってからでは困難となるアーキテクチャや設計の変更をより容易に展開できるようにします。

GitHub Pagesの非公開表示
2020年の非公開バグ報奨金プログラムでは、GitHub Pagesの表示制限（https://docs.github.com/ja/pages/getting-started-with-github-pages/changing-the-visibility-of-your-github-pages-site）に焦点が当て取り組みました。従来は、GitHub Pagesを公開すると、インターネット上に公開されていましたが、このたびの新機能では、基盤となるリポジトリにアクセスできるGitHubユーザーのみにアクセスを制限できます。これは社内ドキュメントサイトやポータルを作成できる素晴らしい機能ですが、GitHub Pagesを実装するために複雑なアーキテクチャの変更を必要としていました。このような複雑さにはリスクが付き物であるため、Product Security EngineeringチームはGitHubのエンジニアと協力し、GitHub Pagesの認証プロセスを設計し、社内のセキュリティテストとコードレビューを通じて実装を検証しました。

また、さらなる保証のために、この機能を非公開のバグ報奨金プログラムの対象とし、2020年5月から参加ている研究者に、開発中のこの機能への早期アクセスを許可しました。Robert Chen氏(@notdeghost)とPhilip Papurt氏(@ginkoid)の2人の研究者は、XSSとその他いくつかの脆弱性を組み合わせることで、GitHub Pageの表示設定を回避（https://robertchen.cc/blog/2021/04/03/github-pages-xss）できることを特定しました。この2人の研究者には、特定した脆弱性に対してだけでなく、報奨金の一部として設定した旗取り合戦(Flag Challenge)を成功させたことに対して、35,000米ドルの報奨金が支払われました。GitHubは、この機能をリリースする前に特定された問題を修正し、今後同様の脆弱性に対してもこのサービスがより強固なものになるよう、アーキテクチャを強化することができました。

GitHub Enterprise Server 2.22
2020年にはまた、非公開のバグ報奨金プログラムの研究者にGitHub Enterprise Server 2.22（https://docs.github.com/ja/enterprise-server@2.22/admin/release-notes#2.22.0）を早期公開しました。これは、コンテナベースの新しいアーキテクチャを採用した初めてのGitHub Enterprise Serverのリリースであり、GitHub Actions、GitHub Packages、GitHub Advanced Securityに含まれるCode Scanningをベータ機能として追加した初めてのリリースでもありました。こうした新機能に加えて新たなアーキテクチャを採用したため、GitHubはセキュリティ開発ライフサイクルにこの特別なレビューステップを追加したいと考えたのです。

GitHub Codespaces
今年は、新機能や新製品の早期リリースを確実にするため、非公開プログラムの拡充に引き続き力を入れています。6月には、GitHub Codespaces（https://github.com/features/codespaces）を対象とした新しい非公開の報奨金プログラムを開始しました。GitHub Codespacesは、クラウド上に完全な開発環境を提供するだけでなく、独自のアーキテクチャとセキュリティ対策が施されています。この非公開のバグ報奨金プログラムでは、このサービスを安全な方法で設計、実装する内部作業を検証するために、研究者の参加を認めています。現在、この非公開プログラムに参加してくださっている皆さまの多大なる貢献に感謝しています。

今後の展望
2021年にはGitHubのセキュリティプログラムへの大きな投資と発展（https://github.blog/jp/2021-03-02-hello-from-githubs-new-chief-security-officer/）がありました。6月には、バグ報奨金プログラムの実施と発展を専門とする、新しい社内チームが発足しました。GitHubのプログラムに参加している皆さまは、セキュリティバグの報告の向こう側にいる新たなメンバーにぜひ期待してください！このチームは、トリアージプロセスと回答プロセスをさらに加速させ、改良にも取り組み、ライブハッキングイベントやさらなる非公開のバグ報奨金プログラムなど、新たな展開を拡大していきます。

バグ報奨金プログラムのアニバーサリーを迎えるにあたり、プログラムに参加してくださっている研究者の皆さまに改めて感謝の意を表すと共に、次の1年の活動に期待を寄せています。セキュリティへの継続的な投資の一環として、GitHubはProduct Security Engineeringチームとより広範なGitHubのセキュリティ組織を拡大しています。GitHubがバグ報奨金プログラムや開発ライフサイクルを通じて行っている、製品やサービスのセキュリティ対策に興味をお持ちの方は、https://github.com/about/careers で募集中の職種をご確認ください。

GitHub Blog
英語 https://github.blog/2021-06-25-seven-years-github-security-bug-bounty-program/
日本語
https://github.blog/jp/2021-07-15-seven-years-github-security-bug-bounty-program/

GitHubに関する情報は、こちらからもご覧いただけます。
Blog： (英語) https://github.blog (日本語) https://github.blog/jp
Twitter： (英語) @github( https://twitter.com/github )　　　
(日本語) @GitHubJapan( https://twitter.com/githubjapan )

【GitHub について】https://github.co.jp
GitHub（ギットハブ）は世界で5,600万人にのぼる開発者および300万の組織に利用される開発プラットフォームです。プログラミング環境にオープンな会話と協調を重んじるコミュニケーションによって、コラボレーションを促進する開発環境を提供しています。これらの開発を実現するワークフローで必要となるコードレビュー、プロジェクトおよびチームマネージメント、ソーシャルコーディング、ドキュメント管理などに、これまで以上の効率性と透明性をもたらし、より高速かつ品質の高いソフトウェア開発を支援しています。
GitHubは多様なユースケースに適した開発プラットフォームを用意しており、オープンソースジェクトから企業における機密性の高いソフトウェア開発までに対応できます。無料で利用できるパブリックリポジトリは、オープンソースプロジェクトにて多く利用されています。プライベートリポジトリが利用できる有償サービスとして GitHub Enterprise や GitHub One などのプランも提供しています。2008年に米国サンフランシスコで創業したGitHub, Inc.は、初の海外支社として、2015年に日本支社を開設しました。

【製品／サービスに関するお問い合わせ先】
ギットハブ・ジャパン営業およびサポート窓口　
Email: jp-sales@github.com