🔖

HerokuのOAuthトークン流出で、やっておくといいことリスト(コメント大歓迎)

2022/04/16に公開約9,600字14件のコメント

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のトークンをダウンロード 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トークンを無効化している報告がツイッターに上げられる Twitter
2022-04-16 SalesforceのBotがHeroku Dasuboardの全てのOAuthトークンの無効化を始めたと思われる報告がツイッターに上げられる Twitter
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トークンの無効化
  • 攻撃を受けたどうかの確認
  • 関係者への連絡

Organizationのオーナーがやったほうがいいこと

  1. GitHub/Heroku/Travis-CIからのメールの確認
  2. Third-party application access policyの確認
  3. (まだの場合)Heroku Dashboard/Travis-CIのOAuthトークンの無効化
  4. Audit logの調査
  5. 関係者への連絡

1. GitHub/Heroku/Travis-CIからのメールの確認

自身が攻撃対象であったか、必要なアクションなどの連絡が来ている場合、確認して従いましょう。

2. Third-party application access policyの確認

以下URL(org_idを自身のOrganizationで置換)にアクセスし、Third-party application access policyAccess 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_approvedaction:repo.download_zip 以外でも、重要なイベントは確認すると良さそうです。

その他のactionはこちらからご覧いただけます。

5. 関係者への連絡

攻撃の証拠を見つけた場合、Herokuであればサポートに問い合わせるよう案内が出ています

個人がやったほうがいいこと

  1. GitHub/Heroku/Travis-CIからのメールの確認
  2. (まだの場合)Heroku Dashboard/Travis-CIのOAuthトークンの無効化
  3. Security logの調査
  4. 関係者への連絡

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に所属している方は、必要に応じて以下を管理者に報告すると良いと思います。

  1. Heroku Dashboard/Travis-CIのアクセスが許可されていたか
  2. Heroku Dashboard/Travis-CIのアクセスが許可されていた場合、対象のOrganizationへのアクセスは許可されていたか
  3. Heroku Dashboard/Travis-CIのアクセスが許可されていた場合、アクセスを取り消したか
  4. 過去にHeroku Dashboard/Travis-CIにアクセスを許可したり、削除した履歴があるか(ある場合はその期間)

また、攻撃の証拠を見つけた場合、Herokuであればサポートに問い合わせるよう案内が出ています

まとめ

GitHubのOrganizationのオーナーと個人向けに、今回のインシデントで行うべきことをまとめました。
繰り返しますが、筆者は専門家ではなく単なるWebアプリケーション開発者です。よりよい知見をお持ちの方のコメントをお待ちしております。

参考

GitHubで編集を提案

Discussion

情報共有ありがとうございます。弊社ソニックガーデンでもほぼ同じ対応をしていました。
この記事に付け加えるとすれば、以下の点も認識しておいた方がいいかもしれません。

  • Githubのblogによると、HerokuだけでなくTravis CIも影響を受けているようです。過去にTravis CIとGithub連携をしている場合も同じように状況を確認する必要がありそうです。
  • BlogTwitterを見る限り、Travis CIからは現時点では公式な声明は出ていません。ただし、Travis CIでも運営者らしきアカウントが強制的にトークンを取り消すようなアクションが見られるようです(参考)。
  • Github blogの"What GitHub customers and organizations need to know"の項には、不正アクセスの被害に遭った組織には72時間以内に連絡が行く、というような話も書いてあります。このブログは日本時間の4/16 7:53am頃に公開されたようなので(参考)、文字通り受け取るともし被害に遭っていた場合は4/19の朝8時頃までに何らかの連絡が来るかもしれません。

あと、細かいTipsですが、Githubから監査ログのCSVをダウンロードするとcreated_atがエポックミリ秒になっています。ExcelやGoogle Sheetsなどでは以下の式(と表示形式の変更)を使うと日本時間に変換できます。

=DATE(1970,1,1)+[対象のセル]/86400000+9/24

以上ご参考までに。

情報共有ありがとうございます!

今回のインシデント発生日である2022/04/09以降で不審なアクティビティがないか見てみてもよいのではないでしょうか。

インシデント発生日ではなく、インシデント発覚日なんですかね?↓

https://status.heroku.com/incidents/2413

We're actively investigating a report received on April 13, 2022, from GitHub that a subset of Heroku’s GitHub private repositories, including some source code, were downloaded by a threat actor on April 9, 2022.

Organization の監査ログを確認したところ、不自然な repo.download_zip action が非常に気になりました。インシデント発生日はもっと前の可能性があります。ちょっと濁しますが、去年末とか。

他の 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点だけですね。

  • GitHubが調査開始したのは2022/04/12
  • Herokuの顧客は少なくとも2022/04/09 には影響を受けている

いつから、というのを削除いたしました。

不自然な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リポジトリに不正にアクセスした結果、世界的なセキュリティインシデントが二次被害、三次被害的に発生した、なんてことも起きうるかもしれません。
そうなると、我々エンジニアは「監査ログをチェックしましたが、異常ありませんでした。めでたしめでたし」、で終われなくなります。

上のような話はすべて僕の杞憂に終わればいいんですが、今後しばらく状況を注視せざるを得なくなりそうです。

Organization の監査ログを確認したところ、不自然な repo.download_zip action が非常に気になりました。

詳細な仕様は分かりませんが、Githubのリポジトリ上で「.」押してVSCodeを起動して全検索したときにも、監査ログにrepo.download_zipが記録されるようです。

たとえば、「弊社ではHerokuはまったく使っていません!」という場合でも、社員がプライベートでHeroku連携しているリポジトリを持っている場合、その社員のOAuth認証を使って攻撃者が社内のprivateリポジトリにアクセスする可能性があります

これについてですが、OAuthアプリがOrganizationのprivateリポジトリにアクセスするためには、次の条件を両方満たす必要があります。

  1. OAuthアプリが、OrganizationのThird-party application access policyでApproveされている
  2. OAuthアプリを認証したMemberが、その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していない状態)、Member userAがOAuthアプリを認証しているという状態の場合では、
OAuthアプリはuserA/* のリポジトリにはアクセスできるが、Organization orgX/* のプライベートリポジトリにはアクセスできないという状態になります。

詳細は次のドキュメントを参照してください。

詳しい説明ありがとうございます!
なるほど、それであればリスクはそこまで高くないかもしれませんね。
上の僕のコメントも訂正しておきました。

Security alert: Attack campaign involving stolen OAuth user tokens issued to two third-party integrators | The GitHub Blog

As of 9:30 PM UTC on April 18, 2022, we’ve notified victims of this campaign whom we have identified as having repository contents downloaded by an unauthorized party through abuse of third-party OAuth user tokens maintained by Heroku and Travis CI.

OAuth token 不正利用の被害者に対して、GitHub がお知らせを開始したそうです。

If you do not receive a notification email from us, that means GitHub has not identified your account as impacted by the current incident.

もし、GitHub からの通知メールが届かない場合は、GitHubが今回のインシデントの影響対象として認識していないことを意味するとのこと。

https://status.heroku.com/incidents/2413

5/5 に具体的な更新がありました。「Heroku データベースに不正アクセス」まで踏み込んだ言及は初めてかもしれません。ところで何のトークンだろう?

  • 攻撃者は 4/7 に Heroku データベースに不正アクセスし、ユーザーの GitHub OAuth token を盗み出して、ユーザーのリポジトリをダウンロードしたらしい。不正アクセスは漏洩したトークンを使ったとのこと。そのため Salesforce は 4/16 に全ての GitHub OAuth token を失効させた
  • さらに攻撃者は同様に漏洩したトークンを使ってデータベースに不正アクセスし、ユーザーのハッシュ化およびソルト化されたパスワードを流出させたらしい。そのため Salesforce はすべての Heroku ユーザーのパスワードをリセットし、API Key を失効させた
  • トークン漏洩の原因は引き続き調査中とのこと

さらに、5/7 に Heroku ゼネラルマネージャーで Salesforce 副社長の Bob Wise 氏が「We've Heard Your Feedback」を投稿していました。

  • 4/14 以降、攻撃者がユーザーのアカウントにアクセスした証拠も、ユーザーの環境変数を解読した証拠も含めて、Heroku への不正アクセスの証拠は見つかっていない
  • 「現在取り組んでいます」という投稿を減らして欲しいと、ユーザーからフィードバックがあった。透明性とのバランスを取るのは難しいが、今後は共有すべき新たな情報がある場合だけ、情報を公開する
  • Heroku の GitHub Integration が未だに使えない不満が来ている。今後数週間のうちに復活させたいと考えている

Heroku Review Apps と Heroku CI の Config vars(環境変数)が漏洩した可能性があると、メールが来てましたね。5/16 (Mon) に明らかになったとのこと。Config vars のローテーションをした方が良い。

OAuth token 以外の漏洩は、今回初めての判明ですね...。本番環境もローテーションしてなければ、やった方が良いと思います。

ログインするとコメントできます