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

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

• Githubのblogによると、HerokuだけでなくTravis CIも影響を受けているようです。過去にTravis CIとGithub連携をしている場合も同じように状況を確認する必要がありそうです。
• BlogやTwitterを見る限り、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 の皆さんはいかがでしょうか？

@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/* のプライベートリポジトリにはアクセスできないという状態になります。

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

• About OAuth App access restrictions - GitHub Docs

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