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

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

本ブログでは、7年目を迎えたバグ報奨金プログラムの成果に関する説明に加え、このプログラムで軽減された興味深い脆弱性の詳細や来年に向けた展望をご紹介します。拡大を続けるバグ報奨金プログラムへの、コミュニティの皆さんのご参加を心よりお待ちしています。

2020年のハイライト

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

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

バグ報奨金プログラムへの報告は、GitHub、GitHubの製品、開発者コミュニティ、そしてGitHubのお客様のセキュリティをさらに高める絶好のチャンスになります。皆さんのスキルをお借りして、すべての人にとってGitHubをより良いものにしていく、継続的なコラボレーションに期待しています。参加にご興味のある方は、プログラムの対象範囲、規則、報奨金などの詳細はウェブサイトをご確認ください。

2020年にGitHubで話題となったバグ

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

ユニバーサルオープンリダイレクト (Universal open redirect)

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

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

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

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

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

CVEの発行

昨年のバグ報奨金プログラムの記念ブログでお伝えしたとおり、2020年にGitHubはMITREのCVE採番機関(CNA)となり、GitHub Enterprise Serverの脆弱性に対するCVEの発行を開始しました。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形式に変換し、<code>CVEProject/cvelist</code>リポジトリに追加できるようにします。

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

非公開のバグ報奨金

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

GitHub Pagesの非公開表示

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

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

GitHub Enterprise Server 2.22

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

GitHub Codespaces

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

今後の展望

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

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