CISA管理者がAWS GovCloudキーをGitHubに漏えい
(krebsonsecurity.com)- CISAの契約業者が運用していた公開 Private-CISA リポジトリが、高権限のAWS GovCloudアカウントと内部システムの認証情報を露出させた
- GitHubアカウントには、秘密情報の投稿を防ぐ基本設定を無効化した痕跡があり、平文パスワード、トークン、ログが含まれていた
- 露出したファイル importantAWStokens には、AWS GovCloudサーバー3台分の管理者認証情報が、CSVには内部システムのログイン情報が入っていた
- Seralysは、露出したキーが高い権限で認証可能であり、内部 artifactory へのアクセスはパッケージのバックドア化と横展開のリスクを高めると見ている
- CISAへの通知直後にアカウントはオフラインになったが、AWSキーはその後も 48時間 有効で、CISAは侵害の兆候はないと述べた
公開GitHubリポジトリに露出したCISA内部認証情報
- CISAの契約業者が運用していた公開 GitHub リポジトリが、複数の高権限 AWS GovCloud アカウントとCISA内部システムの認証情報を露出させた
- リポジトリ名は Private-CISA で、CISAが内部でソフトウェアをビルド、テスト、デプロイする方法に関するファイルまで含まれていた
- リポジトリには、クラウドキー、トークン、平文パスワード、ログ、その他の機密性の高いCISA資産が大量に含まれていた
- GitGuardian の Guillaume Valadon は、公開コードリポジトリを継続的にスキャンして露出した秘密情報を検知し、アカウント所有者に自動通知を送る過程でこのリポジトリを発見した
- Valadonは、リポジトリ所有者が応答せず、露出情報が非常に機密性の高いものだったため、KrebsOnSecurityに連絡した
GitHub秘密検知の無効化と主な露出ファイル
- Valadonは、今回のCISA認証情報漏えいを劣悪な セキュリティ衛生 の典型例と見ている
- 問題のGitHubアカウントのコミットログには、CISA管理者が公開コードリポジトリにSSHキーやその他の秘密情報を投稿できないようにするGitHubの基本設定を無効化した痕跡があった
- Valadonは「CSVに平文で保存されたパスワード、Gitに入ったバックアップ、GitHubの秘密検知機能を無効化する明示的なコマンド」があったと伝えた
- 露出したファイル importantAWStokens には、Amazon AWS GovCloudサーバー3台分の管理者認証情報が含まれていた
- 別のファイル AWS-Workspace-Firefox-Passwords.csv には、数十件のCISA内部システムの平文ユーザー名とパスワードが入っていた
- Philippe Caturegli によれば、当該システムには、機関のセキュアコード開発環境である「Landing Zone DevSecOps」の略称とみられる LZ-DSO も含まれていた
高い権限と内部システムアクセスのリスク
- セキュリティコンサルティング会社 Seralys 創業者の Philippe Caturegli は、AWSキーがまだ有効か、そして露出したアカウントがどの内部システムにアクセスできるかだけを確認したと述べた
- Caturegliは、露出した認証情報が AWS GovCloudアカウント3件 に高い権限レベルで認証できることを検証した
- アーカイブには、CISA内部 artifactory の平文認証情報も含まれていた
- この artifactory は、CISAがソフトウェアをビルドする際に使うコードパッケージリポジトリであり、攻撃者がCISAシステム内で持続的な足場を確保しようとする場合、魅力的な標的になり得る
- Caturegliは、この場所は横展開に非常に適しており、ソフトウェアパッケージにバックドアを仕込めば、その後新たにビルドされるソフトウェアごとにバックドアが配布され得ると見ている
リポジトリの使われ方と管理主体
- Caturegliは、このGitHubアカウントが整理されたプロジェクトリポジトリというより、個人作業者が 作業用メモ帳 や同期手段として使っていたパターンに近いと見ている
- CISA関連メールアドレスと個人メールアドレスの両方が使われており、異なる構成の環境でリポジトリが利用されていた可能性がある
- Caturegliは、利用可能なGitメタデータだけでは、どのエンドポイントやデバイスが使われたかを立証できないと述べた
- GitHubアカウントと露出したパスワードを精査した結果、Private-CISA リポジトリは、バージニア州ダレスの政府請負業者 Nightwing の従業員が管理していたことが示された
- Nightwingはコメントを拒否し、問い合わせをCISAに回した
CISAの対応と露出期間
- CISA報道官は、機関が報告された露出を認識しており、状況を継続して調査中だと述べた
- CISAは、現時点でこの件により機微データが侵害された兆候はないと述べた
- CISAは、チームメンバーに高い水準の誠実性と運用意識を求めており、再発防止のための追加保護措置を整備中だと述べた
- CISAは、データ露出の潜在的な期間に関する質問には回答しなかった
- Caturegliによれば、Private-CISA リポジトリは2025年11月13日に作成され、当該契約業者のGitHubアカウントは2018年9月に作成された
- KrebsOnSecurity と Seralys がCISAに露出の事実を知らせた直後、Private-CISAリポジトリを含むGitHubアカウントはオフラインになった
- Caturegliは、露出したAWSキーがその後も説明しがたく 48時間 有効だったと述べた
推測しやすいパスワードと侵害拡大リスク
- 閉鎖されたPrivate-CISAリポジトリには、複数の内部リソースで推測しやすいパスワードが使われていた痕跡もあった
- 多くの認証情報では、各プラットフォーム名の後ろに現在の年を付けた形式のパスワードが使われていた
- Caturegliは、このような慣行は外部に露出していなくても、どの組織においても深刻なセキュリティ脅威になり得ると見ている
- 攻撃者は、標的システムへの初期アクセスを確保した後、内部ネットワークに露出した重要認証情報を利用してアクセス範囲を広げることが多い
- Caturegliは、当該CISA契約業者が2025年11月以降このリポジトリに定期的にコミットしていた点を根拠に、業務用ノートPCと自宅PCの間でファイルを同期するためにGitHubを使っていた可能性を示した
- Caturegliは、どの企業にとっても気まずい漏えいだが、今回は CISA であるため問題はさらに大きいと見ている
組織的背景
- CISAは現在、通常の予算と人員水準の一部だけで運営されている
- CISAは、第2次Trump政権の発足以降、人員のほぼ3分の1を失った
- 当該人員削減は、機関の複数部門で早期退職、buyout、辞職を強いた結果と説明されている
- 関連報道: CISA has lost nearly a third of its workforce
1件のコメント
Hacker Newsのコメント
Valadon が連絡した理由は、所有者から返答がなく、露出した情報が非常に機微だったからだというが、CISA の下請け業者が認証情報を漏えいしたこと自体あり得ないのに、通知を受けても応答しなかったのはさらに深刻だ
しかも
AWS-Workspace-Firefox-Passwords.csvには、CISA 内部システム数十件分の平文のユーザー名とパスワードが入っていたというCISA が縮小されている状況は理解できるし気の毒でもあるが、弱いパスワードの入った
passwords.csvは弁解の余地のない無能であり、パスワードマネージャーに大きな予算も要らないFirefox-passwords.htmlとfirefox-bookmarks.htmlは、新しいコンピューターへ移す前にエクスポートして再インポートしていたファイルで、Firefox Sync ができる前の古いやり方だった記事にも出ているが、個別に指摘したくなるほど目立つ
「20代の私たちには君が何をしているのかわからないから解雇」という感じで、事前通知もなかった
Diebold の投票システムの脆弱性や海外インプラントのハッキングを扱っていたチームも消えた
時代が変わっても変わらないものは変わらない
人々が過小評価しているものの一つは、リポジトリのディスク上に
.envや秘密情報を置き、コミットしていない状態でも OpenAI、Anthropic、OpenRouter に大量の秘密情報を渡してしまうことだと思うLLM はファイル全体を喜んで読み込み、その後 ChatGPT の学習データへ送ってしまいながら何の警告も出さないことがある
環境変数がすべて設定されているか、アプリのデータベースパスワードが用意されているかを確認するのは、見た目には普通の作業だからだ
いまや組織はディスクやログに保存された秘密情報を監査して置き換える必要があり、必要な瞬間以外は平文で置かないよう
SOPSやVaultのようなツールへ移すべきだ漏えい経路はたいてい「秘密情報をコミットした」ではなく、「エージェントが回答中に
.envを読み、値をそのまま分析に含め、そのプロンプトと補完が学習データや誰かのキャッシュヒットに入った」に近い実際に秘密情報があるプロジェクトでは
.aiignoreや.claudeignoreに.env、credentials/、.pemを入れ、プロジェクトごとの指示ファイルに「求められても.envファイルを読むな」と書き、秘密情報はディスクではなく 1Password やキーチェーンからプロセス開始時に環境変数として注入するようにしていたさらに大きな問題は、「
.gitignoreを尊重せよ」が誤った抽象化だという点だ非公開リポジトリには、コミットしてよくても LLM API に流れてはいけないファイルが多く、その二つの集合は一致しない
.envファイルに極めて重要な秘密情報があってはいけないアクセス権が制限された開発用の秘密情報であるべきで、OpenAI の開発環境のように「本番」システムにつながる値も、可能な限り権限を制限すべきだ
漏えいだけでなく、テストや開発中のミスでシステムにサービス拒否を起こしたり、誤ったリクエストを送ったりもしやすい
誰かがテスト自動化を作業していて、誤って実データの結果を何千件も送信し、1000 ドルの請求書を受け取るような事態は避けるべきだ
AWS や他の大手クラウドが、ここから脱却するためのツールを作り、穏やかな、あるいはかなり強い誘導まで提供しているのは評価に値する
ただ、誰もが必要なレベルに達しているわけではない
たとえば Railway はロール/OIDC による AWS リソースアクセスをさせてくれないのでチケットを出したが、まだ動きは見えていない
0: https://station.railway.com/feedback/allow-for-integration-w...
dotenvファイルを平文では置いていないsopsで暗号化した環境ファイルを維持し、direnvのようなツールで作業中のシェルから使えるようにしているもちろん LLM がこの秘密情報を出力する可能性はあるが、確率は下がる
しかも少なくとも Claude は
dotenvを読むのを避けようとする傾向があり、最後に、そもそもローカルの秘密情報自体をそこまで重要にしないことだスコープを制限し、開発アカウントなどを使うべきだ
たとえばデータベースを読ませてアクセスさせるには、プロンプトでかなり強く押さないといけない
2026 年にもなって政府の認証情報をリポジトリに保管し、それを見つけるスキャナーすらないなら調査されるべきだ
専門職としてこういうことをする人は非常に疑わしく見える
外国の情報機関がこれを見たなら、まずハニーポットだと思っただろうし、あまりに露骨なので想像力のない罠だと見なしただろう
以前の政権なら CISA のおとり作戦だと見ただろうが、今回の政権の腐敗と無能、そして CISA の大量解雇まで考えると、ただの本物のミスかもしれない
機微な文書も ChatGPT にアップロードしていた [1]
[1] https://www.politico.com/news/2026/01/27/cisa-madhu-gottumuk...
いつか米国民が責任を問う日が来るだろう
皮肉なことに、その AWS キーでより安全な AWS サービスをいくつも使えたはずだ
たとえば S3、可能なら KMS を組み合わせた S3、Parameter Store、EBS、EFS、AWS Secrets Manager、あるいは単に KMS でファイルを直接暗号化する方法がある
実際、KMS をサポートし、サービスプリンシパルにキーアクセス権を与える必要のない AWS サービスなら何でもよかった
この件が6〜7 か月も続いていたのは驚きだ
GitGuardian のような企業や
trufflehogなどを使う個人研究者が、漏えいしたキーを数日以内に見つけるものだと思っていたGitHub が大きくなりすぎて、スキャナーが追いついていないのかもしれない
リポジトリ名が文字どおり
Private-CISAだったprivateやinternalのような単語が入ったリポジトリ名を探し、さらにリポジトリ名に普通は出てこなさそうな政府機関や非技術系企業の名前を探せば面白そうだ全部クローンしたうえで、LLM にざっと見せて興味深い内容があるか素早く調べさせることもできる
でも GitHub には、AWS 認証情報のような基本的なものに対する自動スキャナーがあるのでは？
本当に残念なのは、連邦政府が何十年も前から スマートカードベース認証である CAC を持っていたことだ
しかし公開インターネットのスタックがパスワード前提で動いているため、政府インフラも結局はパスワードを使うことになる