アプリケーションセキュリティ企業のAikidoは、GitLabのEmail work item to this project機能用メールアドレスが、READMEファイルやコントリビューションガイド、公開サポートページ内に表示されることがあると明らかにした。これらのアドレスには開発者アカウントに関連付けられた長期間有効なトークンが含まれており、公開することは通常のバグ報告受付手段を公開するというより、認証情報を漏えいさせることに近い。
この機能により、誰でもそのアドレス宛てにメールを送信し、GitLabプロジェクト内にイシューまたは作業項目を作成できる。しかし、Aikidoが実施したテストでは、攻撃者がアドレス内の-issueという接尾辞を-merge-requestに変更することで、GitLabがメールを受け付け、プロジェクト内にマージリクエストを作成することが示された。
実際に何が起こり得るのか？
影響範囲は、トークンに関連付けられたアカウントの権限に左右される。考えられる結果には、コードへの変更の追加、CI/CDジョブの実行、非公開リポジトリへのアクセス、CI/CD変数に保存された秘密情報の抽出に加え、機密性の高いイシューの閲覧などが含まれる。オープンソースプロジェクトでは、広く利用されているプロジェクトに変更を追加するために悪用されれば、公開されたアドレスがサプライチェーンへの脅威に変わる可能性がある。
Aikidoの研究者は、ある午後の間に、公開文書に掲載された有効なメールアドレスを約12件発見し、その一部は広く利用されているオープンソースプロジェクトのものだったと述べた。攻撃者はトークン所有者のメールアドレスを偽装する必要はない。GitLabはそのメールをトークン所有者から送信されたものとして処理し、テストではIPアドレスの制限も回避できることが示された。
悪用の制限と管理者の責任
アドレスが公開されたからといって、アカウントの権限を超えられるわけではない。ユーザーの権限は依然として基本的な制約となる。また、攻撃者はプロジェクトのパスと識別子を知る必要がある。これらの情報は公開プロジェクトでは入手可能だが、非公開プロジェクトを標的にするには、たとえ識別子を総当たりで推測できるとしても、パスの漏えいが必要になる。
GitLabの文書自体も、これらのアドレスを共有しないよう警告しており、対象ユーザー向けに生成された非公開のものだと説明している。アドレスを知る者は、所有者本人であるかのようにイシューやマージリクエストを作成できる。GitLabは、漏えいが疑われる場合には直ちにトークンをリセットするよう推奨している。
プロジェクトにとって何を意味するのか？
Aikidoは5月、HackerOneを通じてこの問題をGitLabに報告したが、報告は意図された挙動としてクローズされた。6月に2回目の通知を受けた後、GitLabはインターフェースを更新してマージリクエストを作成できる可能性を明記し、トークンデータへのアクセスに関する不正確な表現を削除するとともに、メールによるメッセージ受信がIP制限を回避することを文書化した。
最も重要な実務上の対応はプロジェクト管理者に委ねられている。公開文書からこれらのアドレスを削除し、過去に公開されたプロジェクトのトークンをリセットする必要がある。残された疑問は、GitLabが今後、追加の防御層として送信者アドレスとトークン所有者のメールアドレスの一致を利用するかどうかに関するものであり、Aikidoによれば、この仕組みは現在GitLabが検討している。