GitLabのメールアドレスがサプライチェーン攻撃に悪用される恐れ

サイバー脅威アクターは、メールアドレスひとつあれば相当な被害をもたらせることが明らかになりました。

Aikido Securityが本日公開した新たな調査では、GitLabの受信用メールアドレスが実質的に高権限のアクセストークンとして機能し、組織の公開・非公開プロジェクトに対して広範なユーザー権限を付与してしまう問題が指摘されています。GitLabは、このDevOpsプラットフォームの各ユーザーに対し、ソフトウェアプロジェクトでイシューを作成するための専用メールアドレスを自動的に割り当てています。ユーザーがこのアドレス宛にメールを送信すると、そのユーザー名義で新しいイシューがプロジェクトに作成される仕組みです。

自動生成された固有アドレス宛のメールでプロジェクトのイシューを作成できる機能自体は、珍しいものではないとAikidoは報告書の中で指摘しています。例えば、Trello、Todoist、Monday.comといったプロジェクト管理プラットフォームにも同様の機能があります。

しかしGitLabのメールアドレスには、それぞれ有効期限のないトークンが含まれており、個々のユーザーが作業しているプロジェクトだけでなく、組織のリソース全体に対して広範なアクセスを許してしまいます。しかも、このアドレスが外部に公開されてしまった場合、攻撃者はアカウント自体へのアクセス権を持たなくても、サプライチェーン攻撃に悪用できる可能性があります。

「インターネット上のどのメールボックスからでもそのアドレス宛にメールを送信でき、GitLabはそのメッセージをトークンの所有者からのものとして処理します」と報告書は述べています。「そのアドレスさえ手に入れば、認証と認可の両方を手にしたことになるのです」

Aikidoの研究チームは、公開インターネット上で意図的に晒されているアドレスの数を見る限り、多くのGitLabユーザーがこうしたアドレスに伴うリスクに気づいていないだろうと指摘しています。

あなたのGitLabアドレスは何を明かしているか

Aikidoの研究者Joe Leon氏はDark Readingの取材に対し、もともとはプロジェクトのイシュー作成という単純な機能だったものが、年月を経てマージリクエストやパッチファイルの送信といった、より権限の強い機能にまで拡張されてきたと説明しています。これらの機能自体はドキュメント化されているものの、Leon氏は特にGitLabのユーザーインターフェース(UI)において、そのリスクが過小評価されていると指摘します。

「そこにイシューを作成できるだけでなく、コードをプッシュできるという、極めて機微な機能が備わっていることが明確に伝えられていませんでした。しかもコードのプッシュ先はmain(メインブランチ)である可能性もあり、CI/CDジョブを実行できてしまう可能性すらあります」と同氏は述べています。

GitLabのUIでは、このメールアドレスについて特定のプロジェクトにイシューなどの作業項目を追加するためのツールだと説明されており、「これを使って他のデータにアクセスすることはできません」と明記されています。しかしAikidoによれば、これは事実と異なることが実証されています。

「アドレスに埋め込まれている認証情報は、アクセス可能なすべての公開・非公開プロジェクトで使い回すことができます」とLeon氏は述べています。

Leon氏は、これらのメールアドレスにはglimt-(GitLab Incoming Mail Token)という接頭辞文字列が含まれており、各ユーザーのトークン文字列はそのユーザーがアクセスできるすべての公開・非公開プロジェクトで共通であることを突き止めました。ある公開プロジェクトのメールアドレスが漏洩した場合、攻撃者はメール内のプロジェクトパスのスラッグとプロジェクトIDを書き換えることで、他の非公開プロジェクトにも到達できてしまいます(AikidoのレポートによればIDは推測可能ですが、攻撃者はプロジェクト名が漏洩している必要があります)。

「彼らはこれを、特定のプロジェクトにイシューを作成するためのメールアドレスとして提示しています。公開プロジェクトで作業しているのであれば、それを配布するのは理にかなっています」とLeon氏は言います。「しかし、単にメールアドレスを少し調整するだけで、その認証情報を使って誰でも私の非公開プロジェクトにもコードをプッシュできてしまうとは思いもよりませんでした。これには本当に驚かされました」

さらにLeon氏は、GitLabのメールアドレスを使えばIPアドレス制限を回避できることも発見しました。同氏は、自分が所有していないランダムな単一のIPアドレスに非公開プロジェクトへのアクセスを制限しました。GitLabの制限機能により、プロジェクトのクローン作成やWebブラウザ経由でのアクセスはブロックされましたが、マージリクエストを含むメールメッセージはこのセキュリティ境界を突破してしまいました。

公開されたGitLabメールアドレスがもたらす重大なリスク

この調査の一環として、Leon氏は数時間ほどかけて「決して網羅的とは言えない」インターネット検索を行っただけで、ReadMeやサポートファイル内で意図的に公開されていた受信用メールアドレスを十数件、たやすく見つけ出しました。公開されていたアドレスの中には、人気のオープンソースプロジェクトに属するものも含まれていたとLeon氏は述べています。

「他にもまだ多く存在しているはずです」と同氏は言います。「これは、いわば簡単に見つかる部分にすぎません」

Leon氏はまた、例えば攻撃者がマージリクエストを介して受信用メールアドレスを悪用し、プロジェクトに悪意あるコードを混入させた場合、それを特定するのは困難だろうと指摘しています。「メール経由で行われたことが一目で分かるわけではありません」と同氏は付け加えます。「GitLabのサーバーがこのデータを収集していると仮定した上で、そのサーバーへのアクセスが必要になるでしょう」

Aikidoは5月、HackerOneを通じてこの調査結果をGitLabに報告しましたが、GitLabはこれを意図された仕様であるとして報告をクローズしました。このセキュリティベンダーはその後6月、GitLabのリポジトリ上で非公開のイシューとしてこの件をフォローアップしました。最終的にGitLabはUIを変更し、このメールアドレスがマージリクエストにも使用できる旨を反映するとともに、「これを使って他のデータにアクセスすることはできません」という記述を削除しました。

GitLabはまた、このメールアドレスがIPアドレス制限の対象外であることをユーザーに周知するため、ドキュメントも更新しました。

Leon氏が最も望ましいと考える対策は、送信元アドレスがGitLabアカウントに登録されたアドレスと一致することを必須要件にすることだといいます。これにより、攻撃者はGitLabのアドレスに頼るだけでなく、ユーザーのメールアカウント自体を侵害する必要が生じるため、攻撃の大きな障壁になるとしています。

「これだけで、この問題の大部分はほぼ解消されるはずです」と同氏は述べています。

Leon氏によれば、GitLabはこの変更の実施を検討しているとのことです。

Dark ReadingはGitLabにコメントを求めましたが、記事執筆時点で同社からの回答はありませんでした。

それまでの間の対策として、Aikidoは各組織に対し、GitLabのメールアドレスに含まれるアクセストークンを予防的にローテーションし、開発環境やリポジトリ内でこうしたアドレスが他の機密情報と同様に漏洩していないかスキャンして攻撃対象領域を縮小するよう推奨しています。