大規模なインターネットスキャンにより、AWS、OpenAI、Stripe、GitHubなどの認証情報を露出させている、外部からアクセス可能な.gitリポジトリが28,000件見つかりました。単純なWebサーバーの設定ミスが、ソースコードの履歴をクラウドへの即座のアクセスリスクに変えてしまう実態を浮き彫りにしています。
この調査はアタックサーフェス管理企業のIntruderが発表したもので、関連する可能性のあるサブドメイン4,000万件のプールから選定した350万件の稼働中HTTPホストを対象に実施されました。
Intruderによると、復元された認証情報の多くは検証時点でも有効な状態のままだったといいます。
この露出は、Webサーバーがプロジェクトの.gitディレクトリへの外部アクセスを許可している場合に発生します。
訪問者の目には通常のWebサイトしか映らない場合でも、公開状態のGitメタデータフォルダには、攻撃者がソースコードや設定ファイル、過去のコミット履歴を復元するのに十分な情報が含まれている可能性があります。
この「履歴」という要素が重要です。開発者はアプリケーションの最新版からハードコードされた秘密情報を削除することがありますが、その認証情報は古いコミットから取得できる状態のまま残っている場合があります。
削除されたブランチや書き換えられた履歴、reflogにも、プロジェクトの現在の状態では見えなくなったコミットへの参照が残っていることがあります。
Intruderは、インターネット規模での収集という課題に対応するため、オープンソースツール「gitreaper」を開発しました。
このツールは、公開されているリポジトリをすべてディスクにクローンするのではなく、Gitオブジェクトグラフをメモリ上でたどり、コミットやツリー、blobを取得して各blobを秘密情報についてスキャンし、該当しない内容は破棄します。検出がトリガーされたファイルのみが保持される仕組みです。
このアプローチにより、数メガバイトから数十ギガバイトに及ぶこともあるリポジトリ全体をダウンロードする際のストレージ負荷を回避できます。
また、組織が「削除済みの秘密情報はもう露出していない」と思い込みがちなHEAD状態を超えて、スキャンを行うことも可能になります。
今回の調査結果の中で、最も影響が大きいのはAWS関連の発見です。Intruderの報告によると、流出した鍵の中には、勤怠状況や懲戒処分情報を含む社内人事記録を保管するS3バケットへのアクセス権を持つものが含まれていました。
Intruderの研究者らによると、今回のスキャンでは400件を超えるAWSアクセスキー、107件のStripe APIキー、123件のOpenAI APIキー、80件のTelegramボットトークン、17件のGitHubパーソナルアクセストークン(PAT)が確認されたとのことです。
こうしたデータは、標的型フィッシングやなりすまし、より広範なソーシャルエンジニアリング攻撃を助長するおそれがあります。
28,000件の公開.gitリポジトリ
別のAWS認証情報も発見されており、以前にコミットされた.envファイル内に含まれ、音楽ホスティングコレクションへのアクセスを可能にしていました。
一見すると深刻度は低く見えますが、このケースは、リポジトリの流出が、開発者が「非公開」あるいは「低リスク」と考えているリソースまでも露出させかねないことを示しています。
有効なStripeのシークレットキーは、直接的な金銭的詐欺やプライバシー侵害につながる可能性があります。
付与された権限次第では、攻撃者が顧客情報を閲覧したり、取引履歴や支払い履歴を確認したり、返金を実行したり、場合によっては支払い先を不正に変更したりすることも考えられます。
Intruderによると、復元された鍵の1つは、支払いスケジュールや取引履歴、収益データ、銀行口座情報の一部へのアクセスを可能にするものだったとのことです。
GitHubのPATは、また別の種類のソフトウェアサプライチェーンリスクをもたらします。組織やリポジトリに対する権限を持つ有効なトークンがあれば、侵入者は非公開のソースコードを閲覧したり、独自情報を窃取したり、信頼されている開発ワークフローに悪意あるコミットを注入したりできる可能性があります。
今回の調査結果は、自律型AIエージェントの脅威モデルにおいて、流出した認証情報が新たな重要性を帯びつつあるタイミングで発表されました。
7月には、OpenAIとHugging Faceが、評価作業に関連するセキュリティインシデントを公表しました。このインシデントでは、AIモデルが外部の4つのアカウントに紐づく公開状態の認証情報を発見し、実際に使用していたことが明らかになっています。
OpenAIによると、1つのアカウントは送信用のリレー兼中継経路として、別の1つはデータ保管用として使用されており、残る2つは読み取り専用でアクセスされていたとのことです。
データプライバシーコンサルティング
もっとも、このインシデントがあったからといって、公開されているすべての.gitディレクトリがAIエージェントに狙われるとは限りません。
しかし、この事例は、ある重要な運用上の現実を裏付けています。攻撃者はもはや、流出した認証情報の一つひとつを手作業で発見・検証し、悪用に持ち込む必要がなくなっているのです。自動化されたシステムが、発見から悪用までの時間を大幅に短縮しています。
組織は、Webサーバーおよびネットワーク層で.gitパスへの外部アクセスを遮断し、ソース管理下に置かれた可能性のあるすべての認証情報をローテーションし、現行ブランチだけでなくGit履歴全体を監査し、コミット前・CI/CD・リポジトリホスティングの各ワークフローに自動シークレットスキャンを導入すべきです。
公開状態の.gitディレクトリは、単なる設定不備ではなく、認証情報が侵害された可能性がある事案として扱うべきです。
★どのセキュリティツールを削減すべきか?1ページで採点 – 「継承セキュリティスタック」ガイドをダウンロード
翻訳元: https://gbhackers.com/28000-exposed-git-repositories/
