HerokuのOAuthトークン流出で、やっておくといいことリスト（コメント大歓迎）
2022年4月16日(日本時間)にアナウンスがあった、Heroku/Travis-CIのOAuthトークンの流出および悪用を受けて、ユーザーとしてやっておくといいことをまとめました。
GitHubのOrganizationのオーナー向けと個人向けで分けてあります。
追記: 複数の補足のコメントを頂き、記事にも取り込んでいます。ありがとうございます！
注意
- 執筆者はGitHub, Heroku, Travis-CIの専門家ではありません。この記事は誤っている可能性があります。
- この記事は現在調査中の問題について書かれています。最新情報は必ず公式サイトをご確認ください。
インシデントの概要
GitHubがHerokuとTravis-CIのOAuthアプリケーションに発行したトークンが流出・悪用したことで、それらの連携が有効だった多くのOrganizationからプライベートリポジトリが閲覧・ダウンロードされる自体が発生しました。npmも被害に遭ったOrganizationの一つです。
時系列順にイベントをまとめました。なお、下記以外の攻撃が無かったことを保証するものではありません。
| 日付（UTC） | イベント | Source |
|---|---|---|
| 日付不明 | 攻撃者がTravis-CIのOAuthトークンを用いた攻撃を行う | |
| 2022-04-07 | 攻撃者がHerokuのデータベースにアクセスし、OAuth Appのトークン、及び一部ユーザーのConfig Varsをダウンロード | Incident 2413 | Heroku Status |
| 2022-04-08 | 攻撃者がGitHubのリポジトリに関するメタデータ（筆者注: 所属Organizationなどか？）を列挙 | Incident 2413 | Heroku Status |
| 2022-04-09 | 攻撃者がHerokuのOAuthトークンを用いてプライベートリポジトリを大量にダウンロード | Incident 2413 | Heroku Status |
| 2022-04-12 | GitHubのセキュリティチームが調査を開始 | Security alert | The GitHub Blog |
| 2022-04-13, 14 | GitHubからHeroku, Travis-CIに対して通知 | Security alert | The GitHub Blog |
| 2022-04-13~ | Herokuが攻撃に用いられたOAuthトークンを無効化 | Incident 2413 | Heroku Status |
| 2022-04-15 | GItHubのセキュリティチームがブログを公開 | Security alert | The GitHub Blog |
| 2022-04-15 | Herokuがブログを公開 | Incident 2413 | Heroku Status |
| 2022-04-15 | Travis-CIの従業員らしきユーザーがOAuthトークンを無効化している報告がツイッターに上げられる | |
| 2022-04-16 | SalesforceのBotがHeroku Dasuboardの全てのOAuthトークンの無効化を始めたと思われる報告がツイッターに上げられる | |
| 2022-04-17 | 全てのHeroku DashboardのOAuthトークンの無効化が完了 | Incident 2413 | Heroku Status |
| 2022-04-18 | Travis-CIがブログを公開 | The Travis CI Blog |
| 2022-04-18 | GitHubが被害を受けたユーザーに対しての通知を実施（日本時間の4/19 6:30AM） | Security alert | The GitHub Blog |
| 2022-04-27 | GitHubが攻撃の分析結果を発表。複数の組織を対象とした標的型攻撃という見解 | Security alert | The GitHub Blog |
| 2022-05-07 | Herokuがパスワードリセットを実施 | Incident 2413 | Heroku Status |
インシデントの影響
所属するOrganizationまたは自分自身が攻撃を受けた場合の影響
プライベートリポジトリ内にクレデンシャルなどがコミットされていた場合、悪用される恐れがあります。アカウントの無効化やクレデンシャルのローテーションなどが必要になるでしょう。
npmが攻撃を受けたことによる影響
npmのOrganizationのプライベートリポジトリにコミットされてたAWSクレデンシャルを用いた、npmのS3へのアクセスが行われました。2022-04-17時点ではパッケージの変更やユーザーアカウント・クレデンシャルへのアクセスは確認されていないそうです。また、プライベートパッケージへのアクセスの有無は調査中です。詳細はGitHubのブログを参照下さい。
OAuthトークンの無効化による影響
Heroku DashboardのGitHub統合の全てのOAuthトークンが失効させられる方針となったため、Heroku Dashboardを用いたHerokuへのアプリケーションのデプロイはできなくなります。
GitHubのリポジトリをHerokuにデプロイするための方法は他にもあるので、公式の案内を参考にしてください。
Travis-CIでも類似の影響があるかもしれません。公式の案内を参考にして下さい。
やったほうがいいこと
GitHubによる攻撃対象者への連絡とHeroku/Travis-CIによるOAuthトークンの無効化が進められていますが、私達自身でやったほうがいいこともあるのでご紹介します。
- メールの確認
- (まだの場合)Heroku Dashboard/Travis-CIのOAuthトークンの無効化
- 攻撃を受けたどうかの確認
- 関係者への連絡
- (メールで案内があった場合）HerokuのConfig Varのローテーション
Organizationのオーナーがやったほうがいいこと
- GitHub/Heroku/Travis-CIからのメールの確認
- Third-party application access policyの確認
- (まだの場合)Heroku Dashboard/Travis-CIのOAuthトークンの無効化
- Audit logの調査
- 関係者への連絡
1. GitHub/Heroku/Travis-CIからのメールの確認
自身が攻撃対象であったか、必要なアクションなどの連絡が来ている場合、確認して従いましょう。
2. Third-party application access policyの確認
以下URL(org_idを自身のOrganizationで置換)にアクセスし、Third-party application access policyが Access restricted になっていることを確認します。
https://github.com/organizations/{org_id}/settings/oauth_application_policy
Access restricted になっていない場合、組織のメンバーがインストールしたアプリが組織のプライベートリポジトリに制限なくアクセスできることを表します。この機会に制限したほうがいいかもしれません。
詳細は次のドキュメントを参考にして下さい。
About OAuth App access restrictions - GitHub Docs
@azuさんのコメントを元に加筆しました。ありがとうございました！
3. (まだの場合)Heroku Dashboard/Travis-CIのOAuthトークンの無効化
以下URL(org_idを自身のOrganizationで置換)にアクセスし、Third-party application access policy を確認します。
https://github.com/organizations/{org_id}/settings/oauth_application_policy
この中に Heroku Dashboard/Travis-CIがなければ、現時点で無効化が必要なアプリケーションはないと私は判断しています。
4. Audit logの調査
以下URL(org_idを自身のOrganizationで置換)にアクセスし、Audit log を確認します。
https://github.com/organizations/{org_id}/settings/audit-log?q=action%3Aorg.oauth_app_access_approved
github.com 上で簡単に検索した後、ログをExportして詳細な調査を行いましょう。
github.com 上で検索
注意: 経験上、github.com 上では昔のイベントが表示されない可能性があります。詳細な調査はログをExportして行いましょう。
Filter欄に action:org.oauth_app_access_approved と入力します。すると、過去にOrganizationでアクセスがApproveされたアプリケーションが表示されます。
この中にHeroku Dashboard/Travis-CIがなければ、少なくとも直近の攻撃の対象ではなさそうだ、と言えるかもしれません。
また、Filter欄に action:repo.download_zip と入力することで、リポジトリのダウンロードに関わるイベントが表示されます。このイベントは正常なアプリケーションを利用していても発生するので、以下の点に注意して不審なイベントを見極めると良いと思います。
- 国や時間、頻度
- 連携しているアプリケーション側のログと整合するか
Exportによる調査
Audit log の画面から、JSONまたはCSVとしてログをExportすることができます。
上述の通り、国や時間、頻度、連携しているアプリケーションのログとの整合性などを見ると良いと思います。action:org.oauth_app_access_approved と action:repo.download_zip 以外でも、重要なイベントは確認すると良さそうです。
その他のactionはこちらからご覧いただけます。
5. 関係者への連絡
攻撃の証拠を見つけた場合、Herokuであればサポートに問い合わせるよう案内が出ています。
個人がやったほうがいいこと
- GitHub/Heroku/Travis-CIからのメールの確認
- (まだの場合)Heroku Dashboard/Travis-CIのOAuthトークンの無効化
- Security logの調査
- 関係者への連絡
1. GitHub/Heroku/Travis-CIからのメールの確認
自身が攻撃対象であったか、必要なアクションなどの連絡が来ている場合、確認して従いましょう。
2. (まだの場合)Heroku Dashboard/Travis-CIのOAuthトークンの無効化
Applications > Authorized OAuth AppsからOAuthアプリケーションを確認します。
Heroku Dashboard/Travis-CIがあったら、クリックして開きます。
Organization Accessが許可されていた場合、Organizationのオーナーに報告しましょう。
まだアクセスがApproveされている場合 Revoke Accessから取り消すことができます。
3. Security logの調査
Security log を確認します。
github.com 上で簡単に検索した後、ログをExportして詳細な調査を行いましょう。
github.com 上で検索
注意: 経験上、github.com 上では昔のイベントが表示されない可能性があります。詳細な調査はログをExportして行いましょう。
Security Log で Filtersに action:oauth_authorization.create と入力すると、過去にアクセスを許可したOAuth Applicationが表示できます。
また、同様にSecurity Log で Filtersに action:oauth_authorization.destroy と入力すると、アクセス権限を取り消したOAuth Applicationを表示できます。
それ以外の種類のactionはこちらからご覧いただけます。
Exportによる調査
Security Logから監査ログをExportします。
国や時間、頻度などから、不審なイベントがないかを見ると良いと思います。
4. 関係者への連絡
個人の方でOrganizationに所属している方は、必要に応じて以下を管理者に報告すると良いと思います。
- Heroku Dashboard/Travis-CIのアクセスが許可されていたか
- Heroku Dashboard/Travis-CIのアクセスが許可されていた場合、対象のOrganizationへのアクセスは許可されていたか
- Heroku Dashboard/Travis-CIのアクセスが許可されていた場合、アクセスを取り消したか
- 過去にHeroku Dashboard/Travis-CIにアクセスを許可したり、削除した履歴があるか（ある場合はその期間）
また、攻撃の証拠を見つけた場合、Herokuであればサポートに問い合わせるよう案内が出ています。
HerokuのReview AppsまたはHeroku CIのConfig Varに不正アクセスされた場合にやったほうがいいこと
HerokuのReview AppsまたはHeroku CIのConfig Varに不正アクセスされたユーザーには、5/19までにHerokuから直接メールで案内がされています。案内に従い、Config Varsのローテーションなどの対応を行うと良いでしょう。
まとめ
GitHubのOrganizationのオーナーと個人向けに、今回のインシデントで行うべきことをまとめました。
繰り返しますが、筆者は専門家ではなく単なるWebアプリケーション開発者です。よりよい知見をお持ちの方のコメントをお待ちしております。
参考
- Security alert: Attack campaign involving stolen OAuth user tokens issued to two third-party integrators | The GitHub Blog
- Incident 2413 | Heroku Status
- The Travis CI Blog: SECURITY BULLETIN; Certain private customer repositories may have been accessed
- Searching the audit log for your enterprise - GitHub Docs
- セキュリティログをレビューする - GitHub Docs
Discussion
情報共有ありがとうございます。弊社ソニックガーデンでもほぼ同じ対応をしていました。
この記事に付け加えるとすれば、以下の点も認識しておいた方がいいかもしれません。
あと、細かいTipsですが、Githubから監査ログのCSVをダウンロードすると
created_atがエポックミリ秒になっています。ExcelやGoogle Sheetsなどでは以下の式（と表示形式の変更）を使うと日本時間に変換できます。以上ご参考までに。
情報共有ありがとうございます！
インシデント発生日ではなく、インシデント発覚日なんですかね？↓
Organization の監査ログを確認したところ、不自然な
repo.download_zipaction が非常に気になりました。インシデント発生日はもっと前の可能性があります。ちょっと濁しますが、去年末とか。他の Organization の皆さんはいかがでしょうか？
Organization の監査ログ (https://github.com/organizations/***/settings/audit-log) に
repo.download_zipがいっぱいありますが、herokuで普通にgithubからdeployするように設定している場合、この記録になるようです。IPアドレスは表示されず国名だけですが、見知らぬ国が無いからといって安心できないので、とりあえずheroku側のactivityと突き合わせて、一致を確認できました。おお、、そうなんですね。情報ありがとうございます！
でも個人リポジトリで「herokuで普通にgithubからdeployするように設定」しているけど、
repo.download_zip出てませんでしたね。いろいろ難しいですね。😅個人アカウントにはaudit logはなくて（代わりにsecurity logがある）、したがって、
repo.download_zipを捕捉することはできない、という理解です。こういうのは、何かが起きる前に違いを理解しておくべきなんでしょうが、なかなか網羅的に理解するのは難しいですね...@jnchito ご指摘・ご補足ありがとうございます！
おっしゃるとおりTravis-CIについて言及がなかったため、追記いたしました。また、インシデントの概要を充実させています。Tipsも多くの方のお役に立つと思われます！
@masutaka
おっしゃるとおり、現時点で2022/04/09が発生日であるとは断言できませんね。
現時点で言えるのは以下の2点だけですね。
いつから、というのを削除いたしました。
不自然な
repo.download_zipアクションがあったとのこと、とても気になります。情報のご共有もありがとうございます。追記です。
もしかしたらこんなことも起きうるかも、という話を書きます。
が、僕もセキュリティの専門家でも何でもないので信憑性は怪しいです。
内容の保証はしませんので悪しからず。
（さらに追記）明示的に許可する設定をしていない限り、攻撃者がOAuth権限を使って組織のあらゆるprivateリポジトリにアクセスすることはできないようです。なので、以下のリスクはそれほど高くないかもしれません。詳しくはazuさんのコメントを参照してください。
GithubやHerokuからは何も明言されていないのですが、Heroku Dashboardの権限を確認すると"Full control of private repositories"になっています。以下はrevoke直前に撮ったスクショです。これを素直に解釈すると、攻撃者がこの権限を悪用した場合、Herokuと連携していないprivateリポジトリであっても、自由にコードを読み書きされる恐れがあります。またこのOAuth権限は組織単位ではなく、アカウント単位で紐付いています。そのため、組織AでのみHeroku連携していたとしても、アカウントが組織Bのprivateリポジトリにアクセスできる場合、攻撃者はその権限を使って組織Bのprivateリポジトリにもアクセスできるかもしれません。なので、思いのほか攻撃者がアクセスできるリポジトリの範囲が大きくなります。たとえば、「弊社ではHerokuはまったく使っていません！」という場合でも、社員がプライベートでHeroku連携しているリポジトリを持っている場合、その社員のOAuth認証を使って攻撃者が社内のprivateリポジトリにアクセスする可能性があります（注：あります、と書きましたが、実際にそういう問題が起こりうるのかどうかは全く未確認です！あと、会社用とプライベートはGithubアカウントを分けるべきだろ、みたいなお説教はここでは考えないことにします）。また、現時点では攻撃対象としてあげられているサービスはHerokuとTravis CIしかありませんが、今後間接的に被害が大きくなる可能性もゼロではないかも、と思っています。たとえば、今回のインシデントを通じて攻撃者が別の巨大サービスのGithubリポジトリに不正にアクセスした結果、世界的なセキュリティインシデントが二次被害、三次被害的に発生した、なんてことも起きうるかもしれません。
そうなると、我々エンジニアは「監査ログをチェックしましたが、異常ありませんでした。めでたしめでたし」、で終われなくなります。
上のような話はすべて僕の杞憂に終わればいいんですが、今後しばらく状況を注視せざるを得なくなりそうです。詳細な仕様は分かりませんが、Githubのリポジトリ上で「.」押してVSCodeを起動して全検索したときにも、監査ログにrepo.download_zipが記録されるようです。
これについてですが、OAuthアプリがOrganizationのprivateリポジトリにアクセスするためには、次の条件を両方満たす必要があります。
(もう少し細かい条件は Heroku が自分の GitHub リポジトリにアクセスできないのはなぜですか? がわかりやすいと思います)
GItHub Organizationの設定で、現在のデフォルトはThird-party application access policy: Access restrictedなので、大体のOrganizationはrestrictedの設定になっていると思います。
restrictedの場合、
https://github.com/organizations/{org}/settings/oauth_application_policyこのページに Herokuアプリが存在しない or Herokuアプリが明示的にDenyされている場合は、
1の条件が満たせないので、HerokuのOAuthアプリは、Organizationのprivateリポジトリへはアクセスできないですね。
1のApproveは、OrganizationのOwner権限を持っている人が初回だけインストール時にApproveする必要があります。そのため、OrganizationのMemberが個人のアカウントで該当のOAuthアプリ使っていても、Orgnization側で該当のOAuthアプリをApproveしない限りは、そのOAuthアプリはOrganizationのprivateリポジトリへアクセスできませんね。
Organization
orgXでは該当のOAuthアプリをDenyしていて(Approveしていない状態)、MemberuserAがOAuthアプリを認証しているという状態の場合では、OAuthアプリは
userA/*のリポジトリにはアクセスできるが、OrganizationorgX/*のプライベートリポジトリにはアクセスできないという状態になります。詳細は次のドキュメントを参照してください。
詳しい説明ありがとうございます！
なるほど、それであればリスクはそこまで高くないかもしれませんね。
上の僕のコメントも訂正しておきました。
Security alert: Attack campaign involving stolen OAuth user tokens issued to two third-party integrators | The GitHub Blog
OAuth token 不正利用の被害者に対して、GitHub がお知らせを開始したそうです。
もし、GitHub からの通知メールが届かない場合は、GitHubが今回のインシデントの影響対象として認識していないことを意味するとのこと。
5/5 に具体的な更新がありました。「Heroku データベースに不正アクセス」まで踏み込んだ言及は初めてかもしれません。ところで何のトークンだろう？
さらに、5/7 に Heroku ゼネラルマネージャーで Salesforce 副社長の Bob Wise 氏が「We've Heard Your Feedback」を投稿していました。
@masutaka ありがとうございます。記事に取り込ませて頂きました🙏
feat: update timeline about heroku travis incident · xhiroga/zenn-content@374ba4a
Heroku Review Apps と Heroku CI の Config vars（環境変数）が漏洩した可能性があると、メールが来てましたね。5/16 (Mon) に明らかになったとのこと。Config vars のローテーションをした方が良い。
OAuth token 以外の漏洩は、今回初めての判明ですね...。本番環境もローテーションしてなければ、やった方が良いと思います。
@masutaka ありがとうございます。遅くなりましたが、記事に取り込ませていただきました🙏
今後のアップデートでいうと、5/30までにHeroku側の調査が完了するようです。結果が気になりますね。
feat: about heroku config vars · xhiroga/zenn-content@616f943