【ITニュース解説】The Ghost in the Machine: Unraveling Persistent Git Compromises Beyond Your Control

システムエンジニアを目指す初心者の皆さんへ、現代のソフトウェア開発におけるセキュリティの複雑な問題について解説する。自分のパソコンが電源オフになっているにもかかわらず、GitHubのリポジトリに不正な変更（「force-push」と呼ばれる強制的な上書き）が勝手に加えられるという恐ろしい状況が、実際に報告されている。個人的にパスワードを変更し、二段階認証を設定し、認証に使われるトークンをすべて無効化し、さらに感染の疑いがあるローカルのコードも削除したにもかかわらず、この不正な操作が再発するという事態だ。これはまるでSF映画のような話だが、私たちのセキュリティ対策に潜む盲点を浮き彫りにしている。

この問題の根源は、悪意のあるソフトウェアが仕込まれたパッケージをインストールしたことにあると推測されている。この種の攻撃で特に重要な点は、もし個人で徹底的なセキュリティ対策を行っても不正なGit操作が続く場合、攻撃者が単に古い認証情報を使い回しているわけではないということだ。代わりに、何らかの方法で新しい認証情報を生み出しているか、あるいはこれまで見落とされてきたアクセス経路を悪用している可能性が高い。つまり、個人のパソコンやアカウントだけでなく、プロジェクト全体のセキュリティ体制に目を向ける必要がある。

この「パソコンがオフなのに」という状況が、事態の深刻さを示している。これは、攻撃が個人のパスワードやSSHキーといった単純な認証情報の窃盗にとどまらず、より広範囲に及んでいることを意味する。攻撃者は一度システムに侵入すると、元の侵入経路や個人の作業セッションに依存しない、持続的な足がかりを確立することがよくある。

その主な原因としては、以下のような経路が考えられる。一つ目は、「Gitの作成者なりすましと横展開の侵害」だ。Gitでは、コミット（変更履歴）の作成者と、実際にそのコミットをサーバーにプッシュ（アップロード）した人が別々に記録される。攻撃者があなたのチームメイトのアカウントを乗っ取った場合、そのアカウントからあなたのメールアドレスを使ってコミットを作成し、悪意のあるコードをプッシュできる。これでは、あたかもあなたが変更を行ったかのように見えてしまう。もしチーム内の別の開発者が、不正に感染したリポジトリを自身の環境にコピーし、ビルド（プログラムを動かす準備）を行った場合、その人の環境も感染し、そこから攻撃者に認証情報を盗まれて不正なプッシュに使われる可能性がある。

二つ目は、「悪意のあるデプロイキー」の利用だ。デプロイキーとは、リポジトリへのアクセスを許可するための鍵で、特定のユーザーアカウントではなく、リポジトリ自体に紐付けられる。攻撃者がリポジトリの管理者権限を奪うと、このデプロイキーを密かに設定し、書き込み権限を与えることができる。こうなると、あなたが個人的にパスワードを変更したりトークンを無効化したりしても、デプロイキーの有効性には何の影響も及ぼさないため、攻撃は止められない。

三つ目は、「CI/CDパイプラインの汚染」だ。CI/CDとは、コードのテストやデプロイ（公開）を自動化する仕組みを指す。注入された悪意のあるコードが、プロジェクトのビルド設定ファイル（例えば、ウェブサイトの見た目を調整するファイルなど）を標的にする。もし組織がGitHub Actionsのような自動化ツールを使っている場合、そのビルド実行環境がマルウェアを実行してしまう。攻撃者はこの実行環境が持つ認証情報や環境変数（プログラムが利用する設定情報）を悪用し、不正なコードをリポジリに強制的にプッシュし返すことができる。これは、あなたの自動化システムが攻撃者に利用されている状態だ。

これらの組織的な問題が見当たらない場合でも、攻撃者がさらに巧妙で持続的なアクセス方法を確立している可能性もある。これらはしばしば見過ごされがちだ。

一つは、「OAuthアプリとGitHubアプリ」の存在だ。個人用の認証情報（個人アクセス・トークンやSSHキー）を無効化しても、あなたが過去に許可したOAuthアプリやGitHubアプリのアクセス権は残ってしまう場合がある。もし悪意のあるOAuthアプリにリポジトリへのアクセス権を与えていた場合、パスワードを変更しても、二段階認証を有効にしても、個人アクセス・トークンを無効化しても、そのアプリはアクセスを継続できてしまう。

次に、「認証情報ヘルパーとキャッシュされたセッション」の問題がある。あなたのパソコンのGit設定には、「credential.helper」という機能があり、これはOSが提供する認証情報管理機能（Windowsの資格情報マネージャーやmacOSのキーチェーンなど）にパスワードやトークンを保存している場合がある。攻撃者はこれらのシステムに保存された有効なトークンを悪用するか、あるいはGitの設定ファイル自体を改ざんして、不正なスクリプトを仕込むことも可能だ。

さらに深刻なのが、「システムレベルの永続性」だ。悪意のあるプログラムは、パソコンのより深い部分に侵入し、認証トークンを保存する設定ファイルや、シェル（コマンドを入力する画面）の起動時に実行されるファイル（/.bashrcや/.zshrcなど）を改ざんすることがある。また、定期的に特定のプログラムを自動実行する「cronジョブ」や「Windowsのタスクスケジューラ」などを設定して、パソコンが再起動しても攻撃を継続できるようにすることもできる。GitHubトークンやNPMトークンのような環境変数がシェル設定ファイルに保存されていれば、それらを盗み出して再起動後も利用され続ける危険性がある。

このような高度な攻撃に対しては、個人レベルの対策だけでは不十分で、組織全体での対応が不可欠だ。これは開発者だけの問題ではなく、プロジェクトのコードの整合性を守るための、リーダーシップと体系的なアプローチが求められる重大なセキュリティインシデントと捉える必要がある。

まず、「迅速なインシデント対応と確認」が重要だ。GitHubの画面で、不正な強制プッシュに「Verified」（検証済み）の緑色のバッジがあるかどうかを確認する。もしバッジがなければ、作成者が偽装されている可能性が高い。次に、組織のリポジトリ設定にすぐにアクセスし、覚えのないデプロイキー、GitHubアプリ、Webhook（外部サービスとの連携設定）がないか徹底的に調べ、不要なものはすべて削除する。そして、攻撃者が何をしたかったのか、その意図を分析することも重要だ。例えば、ビットコインなどの仮想通貨に関わる情報が狙われている場合もある。

次に、「監査ログの活用」が非常に有効だ。GitHubには、個人アカウントのセキュリティログと、組織の監査ログがある。組織の監査ログは決定的な情報源であり、組織の管理者に依頼して、いつ、誰が、どのIPアドレスから、どのような認証情報（個人アクセス・トークン、OAuthアプリ、デプロイキー、SSHキーなど）を使って強制プッシュを行ったかを確認してもらう。これは、セキュリティインシデントの正確な報告書を作成するために不可欠な情報となる。

さらに、「より広範なエコシステムの保護」も欠かせない。あなたが承認したOAuthアプリや、組織にインストールされているGitHubアプリを確認し、身に覚えのないものや疑わしいものはすべてアクセス権を取り消す。そして、攻撃の影響を受けた可能性のあるチーム全体を対象に、すべての開発者が自身の認証情報をリセットし、ローカル環境を徹底的に検査するべきだ。

最終手段として、「オペレーティングシステムの完全な再インストールと予防策」も考慮する必要がある。もし個人的な対策を徹底してもなお再発する場合、パソコンのオペレーティングシステムを完全に消去し、クリーンな状態で再インストールすることは、しばしば必要かつ有効な手段となる。カスタマイズされたマルウェアに対しては、一般的なウイルス対策ソフトでは検出が難しい場合が多いからだ。OSをクリーンにした後、新しく安全な別のデバイスからすべての認証情報を再設定することで、すでに感染しているかもしれないパソコンから新しい認証情報が盗まれるリスクを防ぐ。また、もし悪意のあるパッケージを発見した場合は、他の人を守るために、関係機関に報告することも忘れてはならない。

結論として、パソコンが電源オフの状態でも不正な操作が行われるという事例は、現代のセキュリティ脅威が多面的であることを強く示している。脅威は個人のアカウントだけでなく、組織全体のアクセス経路、自動化されたシステム、そしてパソコンの奥深くに潜む持続的なメカニズムにまで及ぶ。個人の認証情報のリセットだけに頼るセキュリティ対策では、もはや不十分だ。詳細な活動履歴（Gitレポート）を活用し、組織のアクセスポイントを徹底的に監査し、開発エコシステム全体に対して継続的な警戒を怠らないことで、チームの生産性を高め、最も巧妙な攻撃者からもコードベースを守ることができる。