Why Attackers Target GitHub, and How You Can Secure It
2022/12/28 DarkReading — 先週に Okta は、GitHub でホストされている同社のソースコードに、攻撃者がアクセスするというセキュリティ侵害について発表した。ただし、それは、GitHub に保存される企業のソースコードに対する、不正なアクセスを仕掛ける攻撃の、最新の事例に過ぎない。以前には、Dropbox／Gentoo Linux／Microsoft なども、GitHub のアカウントが狙われたことがあるのだ。
GitHub は 9000 万人のアクティブ・ユーザーを持ち、オープンソースと企業のプライベート・コード・リポジトリにおいて、最も人気のあるソースコード管理ツールである。GitHub は、基本的なインフラの主要な部分であり、世界で最も機密性の高い資産／データの管理者でもある。
攻撃者がソースコードを狙うケースが増加するのは当然のことだ。その中には、Okta を狙った攻撃者のように、ソースコードへのアクセスを試みるケースもあるだろう。そして、多くの場合において攻撃者は、後続の攻撃に使用する機密情報を狙っている。
プライベートなソースコードにアクセスできる攻撃者は、そのソースコードの脆弱性を調査し、その脆弱性を後続の攻撃で悪用する。また、GitHub に保存されている可能性のある、ハードコードされたキー／パスワード／認証情報などを窃取した攻撃者は、AWS／Azure／GCP でホストされているクラウドサービスやデータベースへのアクセスが可能になる。盗まれたリポジトリから、すぐにでも悪用できるソフトウェアの脆弱性リストや、有効な認証情報、知的財産などが得られるのだ。
驚異グループである Shiny Hunters は、GitHub のプライベート・リポジトリを特に狙うことで知られているが、この手法で数十社の企業に侵入し、そのデータをさまざまなダークウェブ・マーケットプレイスで販売している。
組織における GitHub 環境のセキュリティ確保
GitHub が組織のインフラの重要な部分であることは間違いないが、それをロックすることは、複雑で困難な ID セキュリティの問題を生じる。GitHub モデルの良さは、自由なコラボレーションを可能にすることだ。しかし、それは同時に、現代の IT セキュリティにおける最大の頭痛の種の一つを生み出すことでもある。
考えてみてほしい。2022年にリモートで技術的な仕事をしている人なら、誰でも GitHub のアカウントを持っている。そして、GitHub のアカウントは、あらゆることに使用できる。たった一つの ID を、個人的なサイド・プロジェクトやオープンソースへのコントリビュート、そして最終的には、雇用主が所有するパブリック／プライベートなコード・リポジトリにおける自分の仕事などに使うことができるのだ。
また、Sign in with GitHub 機能を使えば、GitHub 以外の Web サイトやサービスでも、GitHub の ID を使用できる。さらに、GitHub のユニークな点は、単に Web サイトにサインインするだけでなく、HTTPS／SSH 経由の git 操作によって、GitHub のサーバと個人のローカルマシンの間で、コードのプル／プッシュ／クローンを可能にする。
2021年に GitHub は、git 操作におけるユーザー名／パスワードの非推奨を発表したが、これは正しい方向への一歩と言えるだろう。
GitHub のセキュリティを確保するための７つのヒント
GitHub は環境をロックするためのツールを提供しているが、その使い方については、組織として知っておく必要があるだろう。残念ながら、最も重要なセキュリティ機能の中には、GitHub Enterprise が必要なものもある。それであっても、紹介しておきたいのは、GitHub のセキュリティを向上させるための７つの原則である。
- 仕事用の個人アカウントは許可しない：企業には公開リポジトリがいくつかあるため、たとえば就職の面接で、そこでのコントリビューションが有効性を持つのはわかる。GitHub の個人アカウントは、ユーザーのブランドの一部なのだ。しかし残念ながら、個人アカウントを仕事に使うことを厳しく規制していないことが、GitHub を使う組織における最大の弱点のひとつとなる。魅力的ではあるが、個人アカウントは仕事に使うべきではない。GitHub の個人アカウント作成に使った Gmail アドレスに、誰がアクセスできるのかを管理する方法がないのだ。
- 会社の SSO を使った認証を義務付ける：残念ながら、GitHub は SSO Wall of Shame に大きく引っかかっている。SSO を導入するには追加料金が必要なのだ。GitHub Enterprise を導入すれば、Okta／Azure AD／Google Workspace などの企業の SSO に GitHub を接続し、SSO での認証のみを許可するよう組織をロックできる。
- すべてのアカウントで 2FA を必須とする：SSO で二要素認証 (2FA／MFA) を導入し、SSO での認証を必須としている場合でも、組織内のすべての GitHub ユーザーに対して、2FA を適用することが最も安全な方法だ。SSO プロバイダーの免責グループやポリシー例外により、SSO の MFA は簡単に回避されてしまう。
- git の操作には SSH キーを使う：GitHub は Personal Access Tokens (PAT) による、きめ細かな権限制御を導入している。しかし、これらのトークンは平文でコピーされることが多いため、フィッシングの影響を受けやすいことに変わりはない。git 操作の認証に SSH 鍵を使用し、SSH 鍵のプロビジョニング方法を管理する思慮深い PKI を使用し、これを企業のデバイス管理と独自の認証局 (CA：Certificate Authority) に結び付けることもできる。
- ロールでリポジトリ・メンバーの特権を制限する：GitHub が提供するものに、最小特権の原則に基づいて割り当てられる、いくつかの異なるリポジトリ・ロールがある。基本的な権限は、組織レベルで制御できる。全員を管理者にするのはやめ、常に、メンバーが生産的に働くために必要な、最小特権のロールを割り当てるように留意する。
- 外部の協力者を認めないこと：大規模なソフトウェア・プロジェクトを管理する上で、外部の協力者と一緒に仕事をすることは当前のことだ。しかし、GitHub の外部協力者を取り巻くガバナンスは、組織の安全を守るには不十分だ。その代わりに、外部の協力者に対しては、企業の SSO で認証させるようにし、リポジトリ管理者によるダイレクトな招待を行わせないようにする。
- 監査、分析、そしてまた監査：完璧な組織など存在しない。どんなに優れた方針を掲げていても、隙間から漏れてしまうアカウントやミスはあるものだ。GitHub をロックする前に、定期的な監査プロセスを実施し、アクセス権を使用していない休眠アカウントを探し、リポジトリ内の特権的ロールの数を制限する。環境をロックダウンした後は、SSO 以外の認証を行っているユーザーや、2FA を使用していないユーザーなどの、ポリシー違反に目を光らせること。
Okta の GitHub リポジトリへの侵入は、企業における ID の保護がいかに困難であるかを示す強力な例ではあるが、特別なものではない。私たちは毎日、従業員のアカウントが乗っ取られる状況を目撃している。認証の脆弱性／個人のＥメールアカウントに関するポリシーの甘さ／拡大し続ける ID といった、攻撃対象がもたらす影響を目の当たりにしているのだ。
今回の Okta のインシデントは、残念ながら、2023年に注意すべき ID 関連の侵害が増加していくという傾向の、一端に過ぎない。
この記事で取り上げられている、Okta – GitHub のインシデントについては、2022年12月21日の「Okta の GitHub リポジトリが侵害：３月に発生した Lapsus$ との関連性は不明」を、ご参照ください。この記事からも、そして、今日の記事からも、これから起こり得ることが特定できないという、もどかしさが伝わってきます。2023年のセキュリティを予測するという点において、このコード・リポジトリ認証の問題は、大きな要素になっていくのでしょう。この年末にポストされた、以下の記事も、よろしければ、ご参照ください。
12月16日：APT と地政学的な背景：2022年に猛威を奮った脅威 Top-5 を分析
12月23日：2023年の脅威を予測する：サイバー戦争から 不正な Bitcoin 採掘まで
12月27日：2023年以降の Internet AppSec：依然として脆弱 継続的な対策が必要
IoT OT Security News 
You must be logged in to post a comment.