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

[画像1]https://digitalpr.jp/simg/1306/38378/700_345_202004061715265e8ae51eaf058.pngオープンソースプロジェクトおよびビジネスユースを含む、ソフトウェアの開発プラットフォームを提供するGitHub, Inc.（本社：米国サンフランシスコ、以下ギットハブ）は、3月25日（米国現地時間）に6周年を迎えたGitHubセキュリティバグ報奨金プログラムのハイライト及び今後のプランを公開いたしました。2020年2月、GitHubのセキュリティバグ報奨金プログラム( https://bounty.github.com/ ) が重要な節目の月を迎え、GitHubがセキュリティに関する問題報告の受付を開始してから6周年を迎えました。この6年間、GitHubはライブイベントやプライベートバグ報奨金プログラム、フィーチャープレビューなどを立ち上げ、さらには、現金による報奨金の支払いなど、バグ報奨金コミュニティに投資してきました。インターネット経由でサービスを提供する企業が抱える深刻な脆弱性の撲滅のために、ソフトウェアセキュリティ研究者は重要な役割を担っています。GitHubは、これらの研究者に敬意を払うとともに、セキュリティバグ報奨金プログラム( https://bounty.github.com/ ) のもと、重大な脆弱性の報告に対して3万USドル以上の報酬を提供しています。2016年にプログラムをHackerOneに移管してから、研究者に支払われた報奨金の合計額が100万USドルを超えました。昨年だけでその半額以上が支給され、全プログラムの総報奨額は59万USドル近くに達しました。また、サブミッション件数が増加し続けているなか、大量の案件にも速やかに回答できており、平均回答時間17時間を維持できています。昨年以降、報告件数が40%の増加を記録しているにもかかわらず、このような数字を達成することができました。昨年のハイライトと、今後のプランについてご紹介いたします。2019年のハイライト素晴らしいバグ報告コミュニティからの素晴らしい報告を日々興味深く検討しています。レベルの高い報告の多くに共通していることは、バグを発見したエンジニアはGitHubやそのテクノロジーについて、GitHubのエンジニアリングチームに匹敵するほどの理解をしている点です。非常に魅力的な報奨金を提示しているため、このような才能ある方々がGitHubのコードベースを深く掘り下げることに意欲を持っていただけています。2019年もGitHubのコミュニティはすばらしい活躍をしてくれました。クロスサイト HEAD リクエストを使ったOAuthフローのバイパス@not-an-ardvark ( https://github.com/not-an-aardvark ) 氏からは、このプログラムに多くの素晴らしい案件を報告していただいていますが、その中でも特にこのバグは重大でした。@not-an-ardvark氏のブログ( https://blog.teddykatz.com/2019/11/05/github-oauth-bypass.html ) に詳しく説明されていますが、その概要を以下にまとめます。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にパッチを展開させました( https://enterprise.github.com/releases/2.17.3/notes ) 。脆弱性の深刻度や、バグ報告の詳述レベルに基づき、GitHubは@not-an-aardvark氏に2万5千USドルの報奨金を提供しました。このバグは、セキュリティ全般における研究者の役割の重要性を示しています。報奨金プログラムを通して問題が発見されたことで、パッチを適用できる他、過去に悪用されていないことを確認するなどの対応を講じ、ユーザーを守ることができました。コマンドインジェクションによるGitHub.comのリモートコード実行@ajxchapman( https://github.com/ajxchapman ) 氏は、Mercurialのインポート機能でコマンドインジェクションをトリガーし、GitHub.comでリモートコード実行を行うことに成功しました。インポートロジックがブランチ名を適切にサニタイズしないため、不正に作成されたブランチ名がGitHubサーバーでコードを実行できるようになっていました。このインポート機能は非常に複雑なため、インポートコードは、当初より本番ネットワークから隔離された専用サーバー上のサンドボックスで実行されていました。このような隔離によって、この脆弱性の影響は抑えられ、GitHub.comに素早く修正をリリースし、GitHub Enterprise Serverユーザーに修正をバックポートすることを可能にしました。また、インポートロジックに同様の問題がないか監査を行い、記録システムからも、この脆弱性が悪用されていないことを確認できました。このバグで特に興味深いのがその根本原因です。最終的に、このバグは古い依存性によって引き起こされていたことがわかりました。このバグはコードをインポート処理する依存性に存在していましたが、以前にアップストリームでは修正されていました。ところが、依存性が最新版にアップデートされておらず、結果として、この脆弱性が発生しやすい状態になっていました。このバグは、セキュリティプログラムにおいてコードの依存関係を管理することがいかに重要かを浮き彫りにしました。GitHubは、GitHubやお客様のセキュリティを維持するため、依存関係管理ツール( https://github.blog/2019-12-11-behind-the-scenes-github-vulnerability-alerts/ ) に継続的な投資を行います。この問題におけるアレックス氏の貢献については、彼の個人ブログ( https://ajxchapman.github.io/ ) をご覧ください。報奨金対象範囲の拡大GitHubは2019年、多くの新機能をセキュリティバグ報奨金プログラムの対象に追加しました。Pull Reminders：https://github.blog/jp/2019-06-26-github-acquires-pull-panda/ エンジニアの確認が必要なPull Requestがあった場合、エンジニアに通知される機能が追加されました。GitHubの主要アプリケーションや既存のSlackインテグレーションに、このソリューションを統合しました。自動セキュリティアップデート https://help.github.com/en/github/managing-security-vulnerabilities/configuring-automated-security-updates（旧Dependabot）：新規のセキュリティ修正コードが発見されると新しいPull Requestを自動的に開き、依存関係を更新するため、依存関係に関わる脆弱性を防止します。GitHub for mobile：https://github.blog/2020-03-17-github-for-mobile-is-now-available/ App Storeから初めて登場したGitHubアプリです。このアプリ提供開始により、新たなAPI要件やセキュリティ上注意しなければいけない点が発生しました。このアプリにはGitHub.comと同等のセキュリティや機能性が提供されています。GitHub Actions https://github.blog/2019-08-08-github-actions-now-supports-ci-cd/：GitHub ActionsはPull Request以来の大きな新機能です。ユーザーがGitHub.comで直接コードを実行できるようにしました。SemmleのLGTMツールhttps://lgtm.com/：GitHubのセキュリティ機能に追加された、重要なセキュリティツールです。LGTMを使うことで、Pull Request発生時にコード内に潜在的なセキュリティ問題がないかスキャンできます。一部の極めて重要なバグ報告が、これらの製品の開発に大きく役立ちました。これらの新しい対象製品の脆弱性に関して、2万USドル以上の報奨金が支払われました。今後もGitHubの成長に伴い、バグ報奨金プログラムの対象範囲を拡大していきたいと思います。H1-7022019年8月、第2回H1-702 ( https://www.hackerone.com/resources/youtube-h1-702-2019-live-hacking-event/githubs-greg-ose-on-record-breaking-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 ( https://github.blog/changelog/2019-05-23-maintainer-security-advisories/ ) やGitHub Package Registry ( https://github.blog/jp/2019-05-17-introducing-github-package-registry/ ) にフラグを隠し、各フラグにボーナスを設定しました。研究者の一部から、このCTFに高い評価をいただきました。今後のイベントでもCTFを開催する予定です。全体として、一晩で15万5千USドル以上の報奨金が、研究者に支給されました。その半額は、深刻度が高い、あるいは極めて危険なバグに対する報奨金です。GitHubのバグ報奨金プログラムにおいて、H1-702のようなライブハッキングイベントは、言葉で言い表すことができないほど重要なイベントです。将来的には、ライブハッキングイベントだけでなく、コミュニティと交流できる斬新な方法をさらに増やしていきたいと思います。非公開のバグ報奨金さまざまな公開プログラムに加え、新機能を一般向けに提供する前に、研究者だけに対して招待制の非公開プログラムも実施しました。このような非公開プログラムは、多くのユーザーに影響を与えることなく、少人数のメンバーと密接に協力することでバグを発見できる機会です。今年、非公開プログラムを通して3万7千USドル以上の報奨金が支払われました。発見されたバグの多くは、新機能が多数のユーザー向けに公開される前に修正されました。GitHub ActionsのCI/CD機能（継続的インテグレーション／継続的デリバリー）https://help.github.com/ja/actions/building-and-testing-code-with-continuous-integration/about-continuous-integrationGitHub Actionsを対象に行われた初の非公開バグ報奨金プログラムの成功を受け、同製品の最新版を対象に、2回目の非公開プログラムを実施しました。同様の問題から製品を守るため、初回プログラムで得た教訓を活かしました。コミュニティはこの挑戦に挑み、第2版からも新たなバグが発見されました。自動セキュリティアップデート（旧Dependabot）https://help.github.com/ja/github/managing-security-vulnerabilities/configuring-automated-security-updates複雑な2つのシステムを統合する場合には必ず課題が発生するものですが、Dependabotの買収時も、異なる2つのアーキテクチャを統合するため、GitHubのセキュリティチームは独自の問題に対処する必要がありました。非公開のバグ報奨金プログラムを利用し、この新サービスに独自の追加セキュリティレビューを実施しました。この非公開プログラムを通して、DependabotとGitHub.comの統合方法について、非常に多くの所見を得ることができました。また、新サービスを展開させる前に、いくつかの問題を発見することができました。Pull Remindershttps://help.github.com/ja/github/setting-up-and-managing-organizations-and-teams/managing-scheduled-reminders-for-pull-requestsDependabotと同様、買収したPull ReminderをGitHubに安全に統合するために大きな注意を払いました。また、Slackと連結されたことで、Pull Remindersがより複雑化しました。GitHub独自のSlackインテグレーションがこの機能のベースとなっていましたが、これら2つの機能を統合するために、アーキテクチャの大幅修正や開発が必要でした。ここでも、バグ報奨金プログラムを利用し、コミュニティでのPull Remimdersのインテグレーションテストを経て、大勢のユーザー向けに機能をリリースしました。2020年の取り組み2020年には、さまざまなイニシアティブを予定しています。今後の予定をご紹介します。セキュリティラボ報奨金プログラムあらゆるオープンソースソフトウェア（OSS）のセキュリティにご協力いただくため、GitHubセキュリティラボ報奨金プログラム( https://securitylab.github.com/bounties ) を開始しました。この新プログラムでは、すべての脆弱性クラスを検知できるCodeQLクエリを記述したコミュニティメンバーに報奨金を支給することで、すべてのコミュニティメンバーがこれらのクエリを自身のプロジェクトで実行可能にするというものです。これによって、大規模に脆弱性( http://securitylab.github.com/research/CERT-CVE-2020-8597-automated-remediation-scale ) を取り除くことができます。このプログラムに協力することで、世界的なソフトウェアセキュリティに影響を与えられるだけでなく、将来的に同様の脆弱性を防止することができます。これまでのGitHubバグ報奨金プログラムに、アレンジを加えたプログラムとなります。現在までに20件が報告され、2万1千USドル近くの報奨金が支給されています。その直接的な結果として、OSSエコシステム全体で数百件の脆弱性が修正されました。CVEとバグの開示今年から、GitHub Enterprise Serverに影響するバグの報告に共通脆弱性識別子（CVE）を割り当て( https://github.blog/changelog/2020-03-11-github-enterprise-server-issuing-cves/ ) ます。CVEを割り当てることでGitHubユーザーにGitHub Eneterprise Serverのセキュリティ最新情報を随時通知できるようになります。研究者にとってはGitHub Enterprise Serverに潜む脆弱性を探し、賞金を獲得する新しい手段です。報奨金プログラム参加のお願いGitHubが追加した新たなプログラムに興味を持っていただき、より多くの方々の参加をお待ちしております。対象製品、参加規約、報奨金については、GitHubセキュリティバグ報奨金ページ( https://bounty.github.com/ ) をご覧ください。皆さんからバグを報告していただくことで、すべての人のためにGitHubを強化していきたいと思います。GitHubセキュリティバグ報奨金プログラムについて詳しく読む ( https://bounty.github.com/ )GitHub Blog英語https://github.blog/2020-03-25-six-years-of-the-github-security-bug-bounty-program/日本語https://github.blog/jp/2020-04-06-six-years-of-the-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 )【ギットハブについて】https://github.co.jpGitHubは世界で4,000万人にのぼる開発者および210万の組織に利用される開発プラットフォームです。プログラミング環境にオープンな会話と協調を重んじるコミュニケーションによって、コラボレーションを促進する開発環境を提供しています。これらの開発を実現するワークフローで必要となるコードレビュー、プロジェクトおよびチームマネージメント、ソーシャルコーディング、ドキュメント管理などに、これまで以上の効率性と透明性をもたらし、より高速かつ品質の高いソフトウェア開発を支援しています。GitHubは多様なユースケースに適した開発プラットフォームを用意しており、オープンソースジェクトから企業における機密性の高いソフトウェア開発までに対応できます。無料で利用できるパブリックリポジトリはオープンソースプロジェクトにて多く利用されていますが、プライベートリポジトリが利用できる有償サービス、GitHub EnterpriseやBusiness on GitHub.comなども提供しています。2008年に米国サンフランシスコで創業したGitHub, Inc.は、初の海外支社として、2015年に日本支社を開設しました。本件に関するお問合わせ先【製品／サービスに関するお問い合わせ先】ギットハブ・ジャパン営業およびサポート窓口 Email：jp-sales@github.com【報道関係者からのお問い合わせ先】 ギットハブ・ジャパンPR事務局（プラップジャパン内）担当：牟田 / 西田Email：GitHub@prap.co.jp

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

トピックス

リリースニュースランキング

このカテゴリーについて