研究者たちは、GitHubの公開APIと「ゴーストアカウント」を利用し、通常の開発者活動に紛れ込みながら企業のソフトウェア環境をプロファイリングする持続的な攻撃キャンペーンを発見しました。
GitHubはソフトウェアサプライチェーンの中心に位置し、攻撃者が渇望する3つの要素——ソースコード、シークレット情報、そして悪用可能な自動化パイプライン——を提供することから、依然として攻撃者にとって極めて魅力的な標的であり続けています。
Datadog Security Researchは、組織とそのメンバーをマッピングしようとする「持続的なパターン」のGitHub API悪用を、過去数カ月にわたって追跡してきました。個々のリクエストは「特に目立たない」ものですが、それが数週間にわたって複数の環境をまたいで行われ、さらには本格的なクローン作成にまで進展すると、危険性を帯びてきます。最大の課題は、こうした行為が通常のAPI利用パターンに紛れ込んでしまう点です。
Beauceron SecurityのDavid Shipley氏によれば、多くの開発ライフサイクルが安全性に欠けているため、GitHubは組織への侵入を狙う犯罪者にとって「金鉱」になっているといいます。一般的に、脅威アクターが狙っているのはAPIキーやクラウドのシークレット情報です。
「今や誰もが、AIエージェントによるコーディングを含め、より速く、より多くの成果を出すよう迫られています。それに伴い、眠っているシークレット情報の宝の山もおそらくさらに大きくなっているでしょう」と同氏は述べています。「かつてのアナログ時代のゴールドラッシュの言葉を借りるなら、まさに『あの丘には金がある』という状況です」
セキュリティ・コンプライアンス企業DataBeeのCTOであるScott Miserendino氏も同意見です。「GitHubはオープンソース・企業プロジェクトの双方において最も人気のあるソースコードリポジトリです」と同氏は述べています。「膨大な数のプロジェクトを抱え、最も人気があり広く使われているソフトウェアの一部もホストしていることから、標的になりやすいのです」
同氏はさらに、プライベートリポジトリの無断クローン作成のような知的財産の窃取が、独自技術のソフトウェアの不正利用や、悪用可能な脆弱性の発見に使われる可能性があると指摘しています。
もう一つよく見られる攻撃手法は、人気ソフトウェアのデフォルト認証情報を含むリポジトリを検索するというものです。攻撃者はこれらの認証情報を使って、実運用環境に存在するアカウントや、特定のアプライアンスにデフォルトでインストールされているアカウントに対する攻撃を開発・テストする可能性があります。
また、DatadogのシニアセキュリティエンジニアであるJulie Agnes Sparks氏はブログ記事で、「この活動は単一の攻撃者によるものではありません。むしろ、カスタムの自動スキャナーツール、流出した認証情報の日和見的悪用、そして使い捨て（ゴースト）アカウントの連携ネットワークが混在したものです」と述べています。
GitHubユーザーをマッピングするシンプルかつ効果的な手法
Sparks氏は、GitHubのAPIサーフェスの「大部分」は認証なしでアクセスでき、これは設計上公開されているものだと説明しています。これらのAPIへのリクエストは通常、標準的なHTTP 200レスポンスを返します。
つまり、脅威アクターは組織やその公開リポジトリ、メンバー、フォロー先、スター付きリポジトリ、関与しているプロジェクトについて詳細なマップを作成できるということです。このトラフィックは通常のAPI利用に紛れ込むため、不審に見えないと同氏は述べています。
さらに、GitHubが位置情報データを収集するのは、ユーザーがプライベートリポジトリを操作した場合に限られます。その際には、誰が、どのアクセストークンを使ったかが記録されますが、外部リソースを操作した場合には記録されません。これにより、位置情報やVPN・プロキシに基づく攻撃者の特定は難しくなっています。
脅威アクターは通常、カスタムまたは正規のもののように見えるユーザーエージェントを使って自動スクレイピングを行い、GitHubの「ゴースト」アカウント——2年から5年前に作成され、その後放置されていたプロフィール——を利用しています。
Sparks氏によれば、これは有効な手口だといいます。「数年分の履歴を持つアカウントは、スクレイピングを開始したその週に登録されたばかりのアカウントよりも、はるかに正規のもののように見えます」
通常、これらのアカウントは1週間から3週間の「短期集中」で、一度に多数の企業を横断して使われた後、利用が止まります。研究者たちは、複数のユーザーエージェントにまたがる50件以上のゴーストアカウントを特定し、それらはuser432023、user412023、kobalt*といった名前を持つグループに分類されました。
一部のキャンペーンでは、OAuthトークンや個人アクセストークン（PAT）を誤って公開してしまった、あるいはエンドポイントが侵害・露出していたGitHubユーザーの正規アカウントが悪用されるケースも確認されています。
攻撃者はGitHub-Company-Scraper、GitHub-Scraper-Tool/1.0、GitHubAnalytics/1.5といった名称のデータ流出用エージェントを組み合わせて使用しており、これらは通常のデータ分析トラフィックに紛れ込むよう設計されています。リクエストの大半はオープンソースのクエリ言語である/graphqlを標的としており、Sparks氏によれば、これは企業・ユーザー・リポジトリを横断した一括クエリに「適している」とのことです。組織のマッピングには通常のRESTエンドポイントが使われます。
これらのキャンペーンの狙いは「狭く、一貫していた」とSparks氏は述べ、懸念すべき点は「積み重なった全体像にある」と指摘しています。単体で見れば、リクエストは認証なしで公開リポジトリを標的としており、成功レスポンスを返します。これだけでは、企業のリポジトリへの「実質的なアクセス」にはめったに至りません。
しかし、共有のGitHubアカウント群にまたがり、バージョン管理されたカスタムツールを使いながら、数週間にわたって同期して動くアカウント群となると、話ははるかに深刻で組織立った行動を意味します。同氏は、それぞれ独立した正規の（ただし侵害された）GitHubユーザーアカウント数十件が、わずか数分のうちに単一の組織に対してAPIリクエストを行った事例を挙げています。もっとも、このケースではプライベートリポジトリのコミット経路が標的とされたため、攻撃自体は失敗に終わりました。
企業がGitHub環境を守るためにできること
Sparks氏は、ユーザーエージェント、トークンの種類、自律システム番号（ASN）、試みられた操作といった「適切な項目を監視していれば」、こうした挙動は検知・特定が可能だと指摘しています。
「ユーザーエージェント、イベント活動、アクター名は、環境内の不正な活動を見抜く重要な手がかりです」とSparks氏は強調します。同氏は、GitHubの監査ログ全体、特にプラットフォームがIPアドレス・アクター名・プログラムによるアクセスの種類も記録するプライベートリポジトリへのアクセスについて、不審なユーザーエージェントの挙動を確認するよう勧めています。
企業はまた、GitHubの監査ログのストリーミングを有効にし、ユーザーエージェントのベースラインを設定し、能動的な脅威ハンティングを実施すべきです。最も重要なのは、自社のGitHub組織に特化した検知ルールを開発することだと同氏は述べ、「自分たちの環境における『通常の状態』が何かを把握しておくことが重要です」と付け加えています。
Miserendino氏は、要するに企業はセキュリティのベストプラクティスに従うべきだと述べています。具体的には、全アカウントでの多要素認証（MFA）の有効化、定期的なユーザーアクセスレビューの実施、使われていない・不要なアカウントの削除、そしてシークレットストアではなく平文で保存された認証情報がないかのリポジトリスキャンなどが挙げられます。
この記事はもともとInfoWorldに掲載されたものです。
