「Email work item」機能のプロジェクトメールアドレスに埋め込まれている、GitLabの有効期限のない受信メールトークンが悪用されると、攻撃者は任意のコードを送信したり、マージリクエストを作成したり、トークン所有者の権限でCI/CDパイプラインを実行させたりできることが分かりました。
この問題は、GitLabのIP制限を回避する手段にもなり得ます。受信メールはこうしたIP制限の対象から明示的に除外されているためです。
セキュリティ研究者のJoe Leon氏（Aikido Security所属）は、ユーザーがメール経由でイシューを作成できるようにするためのGitLabの非公開メールアドレスに、プロジェクト単位のメールアドレスというよりも、アカウント全体に及ぶきめ細かなアクセストークンに近い形で機能する認証情報が含まれていると報告しました。
Websitesecurity audit
このトークンには有効期限がなく、非公開リポジトリを含め、そのアカウントがアクセスできるすべてのプロジェクトで使い回されています。
GitLabのメールトークンの欠陥
GitLabは「Email work item to this project」というオプションを通じて非公開のメールアドレスを公開しています。このアドレスは通常、次のような形式になっています。
`incoming+project-id-glimt-<token>[email protected]`これまでこのインターフェースでは、このアドレスをプロジェクトのワークアイテムを作成するための手段だと説明していましたが、そこに埋め込まれたglimt-incomingメールトークンは、実際にはアカウント所有者としてリクエストを認証する働きを持っています。
GitLabの公式ドキュメントでも、この受信メールトークンには有効期限がなく、これを入手した者は誰でも関連付けられたユーザーとしてイシューやマージリクエストを作成できることが確認されています。
Aikidoの調査によると、あるユーザーが複数のリポジトリからプロジェクトのメールアドレスを取得しても、トークンの部分は常に同一のまま変わりませんでした。つまり、あるパブリックプロジェクトのREADMEやサポートページ、ドキュメント、イシューテンプレートからトークンが流出した場合、そのトークンが同一アカウントがアクセスできる他のプロジェクトに対しても悪用されかねないということです。
報告された攻撃手法は、GitLabのメール経由でマージリクエストを作成するワークフローを悪用するものです。標的のメールアドレスを知っている攻撃者は、末尾の「-issue」を「-merge-request」に書き換え、細工したメールを送信し、Gitのパッチファイルを添付することができます。
メールの件名では、対象のソースブランチを指定できます。GitLabは被害者の権限を使って、指定されたパッチをそのブランチに適用し、そのブランチが存在しなければ新規に作成します。侵害されたアカウントが保護対象ブランチへのプッシュ権限を持っていれば、攻撃者はmainブランチに直接コミットできてしまう可能性があります。
パッチが`.gitlab-ci.yml`ファイルを改変する場合、リスクは大幅に高まります。被害者のロールとパイプライン設定によっては、GitLabは攻撃者が定義したCI/CDジョブを対象プロジェクト内で実行してしまう可能性があります。
このジョブは、リポジトリの内容へのアクセス、CI/CD変数の取得、シークレットの抽出、あるいはGitLab環境内でさらにアクセス範囲を広げるためのCI_JOB_TOKENの悪用などに利用される恐れがあります。
Aikidoは、自分たちのIPアドレスを除外するIP許可リストが設定された非公開プロジェクトに対してこの挙動を検証しました。GitLabはブラウザ経由のアクセスとGitのクローン試行はブロックしましたが、マージリクエストのメールは受理してしまい、結果としてそのコミットはmainブランチに反映されてしまいました。
GitLabの公式ドキュメントでは現在、受信メールはIP制限の対象外であるため、ユーザーはメール経由でイシューとマージリクエストの両方を作成できると明記されています。したがって、各組織はGitLabのIP許可リストを、リポジトリの変更操作全般に対する包括的な対策とみなすべきではありません。
ただし、この攻撃には限界もあります。メールトークンは対象ユーザーが元々持っている権限をそのまま引き継ぐため、権限の低いアカウントであれば影響も小さく、MaintainerやOwnerのアカウントほどの影響力は持ちません。
さらに、攻撃者は対象プロジェクトのプロジェクトパスやIDといったルーティング情報を事前に知っておく必要があります。パブリックプロジェクトであればこうした情報の入手は容易ですが、非公開プロジェクトの場合は追加の情報漏えいが必要になる場合があります。
各組織は、GitLabの受信メールアドレスを機密情報として扱うべきであり、通常の連絡先アドレスと同列に扱うべきではありません。
- アドレスが漏えい・公開された、あるいはその疑いがある場合は、直ちに受信メールトークンをリセットすること。GitLabではユーザープロフィール設定およびパーソナルアクセストークンの画面からトークンをリセットでき、リセットすると関連する受信メールアドレスも無効化される。
- ソースリポジトリ、ドキュメント、Wikiページ、イシューテンプレート、公開Webサイトを対象に、glimtトークンやGitLabの受信メールアドレスのパターンが含まれていないか検索すること。
- Maintainer、Owner、および保護対象ブランチへのプッシュ権限を持つユーザーを洗い出すこと。こうしたユーザーのトークンが流出した場合、影響が特に大きくなる。
- 過度に広範なシークレットアクセス、無制限のパイプライン、過大なCI_JOB_TOKEN権限がないか、CI/CD設定を監査すること。
- IP許可リストは多層防御の一要素として扱い、受信メール経由のワークフローに対する十分な防御策とは見なさないこと。
- GitLabの監査イベント、マージリクエスト、ブランチ作成、パイプライン実行、`.gitlab-ci.yml`への変更を監視し、メール起点の不審な活動がないか確認すること。
GitLabはこの問題の公表を受けて、ユーザーインターフェースとドキュメントを更新し、受信メールアドレスからイシューとマージリクエストの両方を作成できることを明確にしました。
また、GitLabはトークンが他のデータにアクセスできないと示唆していた記述も削除しました。しかし、根本的な仕組み自体は変わっておらず、GitLabのドキュメントには依然として、このトークンには有効期限がなく機密として厳重に管理する必要があると記載されています。
SOCにおけるアラート調査の時間を1件あたり21分短縮。即座にIOCのコンテキストを把握し、迅速な対応を実現するSOC支援ツール: TI Lookupを自社のSOCに統合する
翻訳元: https://gbhackers.com/gitlab-email-token/
