先月、GitHubのセキュリティバグ報奨金プログラムが重要な節目の月を迎えました。2020年2月、GitHubがセキュリティに関する問題報告の受付けを開始してから6周年を迎えました。この6年間、GitHubはライブイベントやプライベートバグ報奨金プログラム、フィーチャープレビューなどを立ち上げ、さらには、現金による報奨金の支払いなど、バグ報奨金コミュニティに投資してきました。
インターネット経由でサービスを提供する企業が抱える、深刻な脆弱性の撲滅のために、ソフトウェアセキュリティ研究者は重要な役割を担っています。GitHubは、これらの研究者に敬意を払うとともに、セキュリティバグ報奨金プログラムのもと、重大な脆弱性の報告に対して3万USドル以上の報酬を提供しています。
大変光栄なことに、2016年にプログラムをHackerOneに移管してから、研究者に支払われた報奨金の合計額が100万USドルを超えました。昨年だけでその半額以上が支給され、全プログラムの総報奨額は59万USドル近くに達しました。また、報告件数が増加し続けているなか、大量の案件にも速やかに回答できており、平均回答時間17時間を維持できています。昨年以降、サブミッション件数が40%の増加を記録しているにもかかわらず、このような数字を達成することができました。昨年のハイライトと、今後のプランについてご紹介いたします。
2019年のハイライト
素晴らしいバグ報告
コミュニティからの素晴らしい報告をいつも興味深く検討しています。レベルの高い報告の多くに共通して言えることは、バグを発見したエンジニアはGitHubやそのテクノロジーについて、GitHubのエンジニアリングチームに匹敵するほどの理解をしている点です。非常に魅力的な報奨金を提示しているため、このような才能ある方々がGitHubのコードベースを深く掘り下げることに意欲を持っていただけています。2019年もGitHubのコミュニティはすばらしい活躍をしてくれました。
クロスサイト HEAD リクエストを使ったOAuthフローのバイパス
@not-an-ardvark氏はこのプログラムに多くの素晴らしいバグ報告していますが、その中でも特にこのバグは重大でした。@not-an-ardvark氏のブログに詳しく説明されていますが、その内容を簡単にまとめます。
GitHubでは、インテグレーターがGitHubエコシステムを利用するいくつかの手段を提供しています。その1つが、OAuthアプリケーションを使って、GitHubユーザーに代わり、アプリケーション側にアクションを認める方法です。OAuthアプリケーションは、ユーザーに自身のデータへのアクセスを認める前に、GitHub.comへリダイレクトし、認証リクエストを確認した上で、明示的にアプリケーションを認証させなければなりません。@not-an-ardvark氏はこの制御を迂回し、ユーザー側からの操作を不要として、OAuthアプリケーションを認証する方法を発見しました。その方法は下記のとおりです。
GitHubは、OAuthアプリケーションの認証など、GitHub.com上で状態を変化させるリクエストを処理する際は、Ruby on RailsのCross Site Request Forgery (CSRF)保護を使用しています。POSTリクエストを受け取る際に、検証する各Form要素のDOMに特殊なトークンをインジェクトします。OAuthアプリケーションの認証フローは、POSTリクエストを使い、有効なCSRFトークンを要求します。ところが、OAuthコントローラは、誤ってPOSTリクエストとHEADリクエストの両方に認証ロジックのトリガーを認めていました。一般的に、HEADリクエストは状態を変化させるリクエストではないため、HEADリクエストを処理する際は、CSRF検証フローをスキップします。そのため、ユーザーの操作が不要な状態で不正サイトがOAuthアプリケーションを自動的に認証できる状態になっていました。
この脆弱性の深刻度から、速やかにパッチを適用することが求められました。エンジニアリングチームと密接に協力し、バグが報告されてから3時間以内にGitHubユーザーに修正を提供することができました。また、SIRTエンジニアと共に徹底的に調査を行い、この脆弱性が悪用されていないことを確認しました。さらに、サポートされる全バージョンのGitHub Enterprise Serverにパッチを展開させました。脆弱性の深刻度や、バグ報告の詳述レベルに基づき、GitHubは@not-an-aardvark氏に2万5千USドルの報奨金を提供しました。
このバグは、セキュリティ全般における研究者の役割の重要性を示しています。報奨金プログラムを通して問題が発見されたことで、パッチを適用できる他、過去に悪用されていないことを確認するなどの対応を講じ、ユーザーを守ることができました。
コマンドインジェクションによるGitHub.comのリモートコード実行
@ajxchapman氏は、Mercurialのインポート機能でコマンドインジェクションをトリガーし、GitHub.comでリモートコード実行を行うことに成功しました。インポートロジックがブランチ名を適切にサニタイズしないため、不正に作成されたブランチ名がGitHubサーバーでコードを実行できるようになっていました。このインポート機能は非常に複雑なため、インポートコードは、当初より本番ネットワークから隔離された専用サーバー上のサンドボックスで実行されていました。このような隔離によって、この脆弱性の影響は抑えられ、GitHub.comに素早く修正をリリースし、GitHub Enterprise Serverユーザーに修正をバックポートすることを可能にしました。また、インポートロジックに同様の問題がないか監査を行い、記録システムからも、この脆弱性が悪用されていないことを確認できました。
このバグで特に興味深いのがその根本原因です。最終的に、このバグは古い依存性によって引き起こされていたことがわかりました。このバグはコードをインポート処理する依存性に存在していましたが、以前にアップストリームでは修正されていました。ところが、依存性が最新版にアップデートされておらず、結果として、この脆弱性が発生しやすい状態になっていました。このバグは、セキュリティプログラムのにおいてコードの依存関係を管理することがいかに重要かを浮き彫りにしました。GitHubは、GitHubやお客様のセキュリティを維持するため、依存関係管理ツールに継続的な投資を行います。この問題におけるアレックス氏の貢献については、彼の個人ブログをご覧ください。
報奨金対象範囲の拡大
GitHubは2019年、多くの新機能をセキュリティバグ報奨金プログラムの対象に追加しました。
- Pull Reminders:エンジニアの確認が必要なPull Requestがあった場合、エンジニアに通知される機能が追加されました。GitHubの主要アプリケーションや既存のSlackインテグレーションに、このソリューションを統合しました。
- 自動セキュリティアップデート(旧Dependabot):新規のセキュリティ修正コードが発見されると新しいPull Requestを自動的に開き、依存関係を更新するため、依存関係に関わる脆弱性を防止します。
- GitHub for mobile:GitHubが初めてApp Store経由で配布するGitHubアプリです。このアプリ提供開始により、新たなAPI要件やセキュリティ上注意しなければいけない点が発生しました。このアプリにはGitHub.comと同等のセキュリティや機能が提供されています。
- GitHub Actions:GitHub ActionsはPull Request以来の大きな新機能です。ユーザーがGitHub.comで直接コードを実行できるようにしました。
- SemmleのLGTMツール:GitHubのセキュリティ機能に追加された、重要なセキュリティツールです。LGTMを使うことで、Pull Request発生時にコード内に潜在的なセキュリティ問題がないかスキャンできます。
一部の極めて重要なバグ報告が、これらの製品の開発に大きく役立ちました。これらの新しい対象製品の脆弱性に関して、2万USドル以上の報奨金が支払われました。今後もGitHubの成長に伴い、バグ報奨金プログラムの対象範囲を拡大していきたいと思います。
H1-702
2019年8月、第2回H1-702に参加するためラスベガスに行きました。このイベントでは、GitHub以外の2社と共に、HackerOneのプラットフォームから有名なハッカーを招き、3夜にわたるライブハッキングを行いました。GitHubはこのイベントを非常に楽しみにしており、研究者にGitHubアプリケーションを詳しく調査してもらうために、可能な限りの報奨金を提供しています。基本となる報奨金に加え、Best Proof of Concept(最高の概念実証)、Longest Exploit Chain(最長エクスプロイトチェーン)、Remote Code Execution(リモートからのコード実行)などに対する多数のボーナスを用意しました。また、GitHub.comでCTF(Capture the Flag, セキュリティコンテスト)を開催し、研究者が最新の攻撃対象領域に取り組めるようにしました。Maintainer Security AdvisoryやGitHub Package Registryにフラグを隠し、各フラグにボーナスを設定しました。研究者の一部から、このCTFに高い評価をいただきました。今後のイベントでもCTFを開催する予定です。
全体として、一晩で15万5千USドル以上の報奨金が、研究者に支給されました。その半額は、深刻度が高い、あるいは極めて危険なバグに対する報奨金です。GitHubのバグ報奨金プログラムにおいて、H1-702のようなライブハッキングイベントは、言葉で言い表すことができないほど重要なイベントです。将来的には、ライブハッキングイベントだけでなく、コミュニティと交流できる斬新な方法をさらに増やしていきたいと思います。
非公開のバグ報奨金
さまざまな公開プログラムに加え、新機能を一般向けに提供する前に、研究者だけに対して招待制の非公開プログラムも実施しました。このような非公開プログラムは、多くのユーザーに影響を与えることなく、少人数のメンバーと密接に協力することでバグを発見できる機会です。今年、非公開プログラムを通して3万7千USドル以上の報奨金が支払われました。発見されたバグの多くは、新機能が多数のユーザー向けに公開される前に修正されました。
GitHub ActionsのCI/CD機能(継続的インテグレーション/継続的デリバリー)
GitHub Actionsを対象に行われた最初の非公開バグ報奨金プログラムの成功を受け、同製品の最新版を対象に、2回目の非公開プログラムを実施しました。同様の問題から製品を守るため、初回プログラムで得た教訓を活かしました。コミュニティはこの挑戦に挑み、2回目のプログラムからも新たなバグが発見されました。
自動セキュリティアップデート(旧Dependabot)
複雑な2つのシステムを統合する場合には必ず課題が発生するものですが、Dependabotの買収時も、異なる2つのアーキテクチャを統合するため、GitHubのセキュリティチームは独自の問題に対処しなければなりませんでした。非公開のバグ報奨金プログラムを利用し、この新サービスに独自の追加セキュリティレビューを実施しました。この非公開プログラムを通して、DependabotとGitHub.comの統合方法について、非常に多くの所見を得ることができました。また、新サービスを展開させる前に、いくつかの問題を発見することができました。
Pull Reminders
Dependabotと同様、買収したPull ReminderをGitHubに安全に統合するために大きな注意をはらいました。さらに、Pull ReminderはSlackと連携して動くため、セキュリティチェックははより複雑でした。GitHub独自のSlackインテグレーションがこの機能のベースとなっていましたが、これら2つの機能を統合するために、アーキテクチャの大幅修正や開発が必要でした。ここでも、バグ報奨金プログラムを利用し、コミュニティでのPull Remimdersのインテグレーションテストを経て、大勢のユーザー向けに機能をリリースしました。
2020年の取り組み
2020年には、さまざまなイニシアティブを予定しています。今後の予定を少しご紹介します。
セキュリティラボ報奨金プログラム
オープンソースソフトウェア(OSS)のセキュリティ強化のために、GitHubセキュリティラボ報奨金プログラムを開始しました。この新プログラムは、すべての脆弱性クラスを検知できる、CodeQLクエリを作成したコミュニティメンバーに報奨金を支給します。誰もが使えるCodeQLクエリをコミュニティに提供し、すべてのコミュニティメンバーがこれらのクエリを自身のプロジェクトで実行することで、大規模に脆弱性を取り除くことができます。
このプログラムに協力することで、世界的なソフトウェアセキュリティに影響を与えられるだけでなく、将来的に同様の脆弱性を防止することができます。これまでのGitHubバグ報奨金プログラムにアレンジを加えたプログラムで、多くのセキュリティ研究者がCodeQLを使ってくれることを期待しています。現在までに20件が報告され、2万1千USドル近くの報奨金が支給されています。その直接的な結果として、OSSエコシステム全体で数百件の脆弱性が修正されました。
CVEとバグの開示
今年から、GitHub Enterprise Serverに影響するバグの報告に共通脆弱性識別子(CVE)を割り当てます。CVEを割り当てることでGitHubユーザーにGitHub Eneterprise Serverのセキュリティ最新情報をきちんと通知できるようになります。研究者にとってはGitHub Enterprise Serverに潜む脆弱性を探し、賞金を獲得する新しい手段です。
報奨金プログラム参加のお願い
GitHubが追加した新しいプログラムに興味を持ちましたか?皆さんの参加をお待ちしております。対象製品、参加規約、報奨金については、GitHubセキュリティバグ報奨金ページをご覧ください。皆さんからバグを報告していただくことで、すべての人のためにGitHubを強化していきたいと思います。