ユーザーがメール経由でワークアイテムを作成できるGitLabの機能が、アカウントレベルのコード配信手段として悪用される恐れがあることが分かりました。受信専用のプライベートメールアドレスが漏洩した場合、攻撃者が保護ブランチへコミットをプッシュし、CI/CDパイプラインを実行できる可能性があります。
Aikido Securityのセキュリティ研究者Joe Leon氏は、GitLabの「Email work item to this project」オプションが、長期間有効な受信メールトークンを含むアドレスを生成することを発見しました。
GitLabはこのアドレスをプロジェクト固有のイシュー作成手段として提示していますが、実際には埋め込まれた認証情報が、該当ユーザーがアクセス可能なすべてのプロジェクトに適用されてしまいます。
このアドレスはincoming+project-id-glimt-<token>[email protected]に似た形式になっています。glimt-の値は認証トークンとして機能し、デフォルトでは有効期限がありません。
Aikidoの調査によると、同一のトークンが複数のプロジェクト向けに生成されたメールアドレスに出現し、プライベートリポジトリを含むことも確認されています。つまりこのトークンは、プロジェクト単位ではなくアカウント単位のスコープを持つ認証情報だということです。
被害者の受信用メールアドレスを入手した攻撃者は、アドレスの接尾辞を-issueから-merge-requestに変更し、Gitパッチを添付ファイルとして送信できるとされています。
メールの件名にソースブランチを指定することで、攻撃者はGitLabに既存ブランチへパッチを適用させたり、被害者のアイデンティティで新規ブランチを作成させたりすることが可能です。
対象アカウントが保護ブランチへのプッシュ権限を持っている場合、攻撃者はmainのようなブランチへ直接コミットできてしまう可能性があります。さらに、送信されたパッチが.gitlab-ci.ymlを変更する内容であれば、攻撃者が制御するパイプラインジョブが被害者のプロジェクトコンテキスト内で実行されることになり、影響はより深刻化します。
プロジェクトのCI/CD設定次第では、そのジョブがソースコード、CI/CD変数、シークレット、そして実行中のジョブが利用できるCI_JOB_TOKENにアクセスできてしまいます。
今回報告された問題は、GitLabのIP許可リストに関する前提も揺るがすものです。Aikidoが検証したところ、単一IPアドレスに制限したプライベートプロジェクトでもこの手法が通用することが確認されました。
GitLabは研究者のネットワークからのブラウザアクセスやGitのクローン操作はブロックした一方で、受信されたマージリクエストのメールは受け付け、添付されたパッチを処理してしまいました。
現在のGitLabのドキュメントでは、イシューおよびマージリクエストの作成における受信メールはIP制限の対象外であることが明記されています。
悪用が成立するかどうかは、侵害されたアカウントの権限にも左右されます。Guestアカウントに紐づくアドレスが漏洩しても得られる価値は限定的ですが、Maintainer権限を持つアカウントであれば、保護ブランチへの到達、CI設定の改ざん、機密性の高いパイプラインデータへのアクセスも可能になる恐れがあります。
また、攻撃者は対象プロジェクトのパスと数値のプロジェクトIDを把握している必要があります。これらの情報は公開リポジトリであれば容易に入手できますが、プライベートプロジェクトを標的にする場合は、通常さらなる情報漏洩が必要になります。
GitLabは開示を受けてインターフェースを更新し、このメールアドレスがイシューとマージリクエストの両方を作成できる旨を明確にするとともに、「このトークンは他のデータにアクセスできない」とする記述を削除したとされています。
しかし、根本的な挙動は変わっていません。トークンには有効期限がなく、GitLabは送信者がアカウント所有者の認証済みメールアドレスと一致することを要求せず、ユーザーはこの機能を個別に無効化することもできません。GitLabは送信元アドレスの検証機能を検討しているとしています。
組織は、GitLabの受信用メールアドレスすべてを機密性の高い認証情報として扱うべきです。セキュリティチームは、リポジトリ、README、サポートページ、イシューテンプレート、ドキュメント、ログの中にglimt-トークンや旧形式の受信メールアドレスが含まれていないか検索する必要があります。
漏洩が確認されたトークンは、GitLabの個人アクセストークン設定から直ちにリセットすべきです。ただし、リセットを行うと関連するすべてのプロジェクトのメールアドレスが無効化される点には注意が必要です。
加えて、チームは保護ブランチの権限設定、CI/CD変数の露出状況、パイプラインのログ、直近のコミットについても、悪用の痕跡がないか確認しておくべきです。
16,000以上のSOCチームがANY.RUNを活用し、脅威調査の効率化と手作業の削減を実現しています。貴チーム向けの詳細はこちら
