開発者がプロジェクトにイシューやタスクをプッシュできるようにする非公開のGitLabメールアドレスが、READMEやコントリビューションガイド、バグ報告用のサポートページに意図的に公開されているケースが見つかっています。
このアドレスは「Email work item to this project(このプロジェクトへメールでワークアイテムを送信)」というGitLab組み込み機能の一部で、開発者のアカウントに紐づく長期有効なトークンを含んでいます。
これらのアドレスは自動生成され、メール経由でワークアイテムを作成するための認証情報として機能する文字列を含んでいます。外部のクライアントがこれらのアドレス宛にメッセージを送信すると、GitLabはそれを解析してプロジェクトのイシューやタスクとして登録します。
アプリケーションセキュリティ企業のAikidoの研究者らは、公開ドキュメント内に複数の非公開GitLabアドレスが露出しているのを発見し、それに伴うリスクについて警告しています。
攻撃者はこれらのアドレスを悪用してGitLabアカウントを侵害し、非公開リポジトリの保護されたブランチにコードをプッシュしたり、ソースコードを盗んだり、CI/CD変数から機密情報を収集したり、非公開イシューにアクセスしたりする攻撃を仕掛けることが可能です。
これらの非公開GitLabアドレスにはそれぞれ「glimt-」という文字列が埋め込まれており、これがプロジェクトへのアクセス用の認証情報として機能します。この文字列は、該当プロジェクト用に生成される同種のアドレス全てで共通して使い回されます。
「メールアドレスの末尾にある『-issue』を『-merge-request』に変更するだけで、GitLabはマージリクエストを開いてしまいます」とAikidoは述べています。
そのアドレスを知っている、あるいは入手できた攻撃者は、末尾の「-issue」を「merge-request」に書き換えるだけで、GitLabはそれを受理し、当該プロジェクトにマージリクエストを作成してしまいます。
「本来であれば、送信元アドレスがトークン所有者のメールアドレスと一致するかを確認することで、もう一段の防御層を追加できるはずです。しかしGitLabはこれを行っていません(現在、対応が検討されてはいます)」と研究者らは指摘しています。
「インターネット上のどのメールボックスからでもそのアドレス宛に送信でき、GitLabはそのメッセージをトークン所有者本人からのものとして処理してしまいます」
さらに、Aikidoのテストでは、この攻撃手法はIPアドレス制限も回避できることが判明しています。
結果として得られるアクセス権限のレベルはユーザーアカウントの権限次第ですが、コードの変更、CI/CDの実行、非公開リポジトリへのアクセス、機密情報の窃取などが可能になる場合があります。
研究者らによれば、権限による制約は回避できないものの、攻撃者は対象プロジェクトのパスとIDも必要とします。
公開プロジェクトの場合、この情報は誰でも入手可能です。一方、非公開プロジェクトの場合はIDをブルートフォースで割り出すことは可能ですが、パスについては別途漏洩している必要があります。
GitLabはドキュメント内で、こうしたアドレスの公開が持つセキュリティ上のリスクについて注意喚起しており、これらは非公開のものであり「あなた専用に生成されたもの」であると説明しています。
「これは他人に教えないでください。知っている者は誰でも、あなたになりすましてイシューやマージリクエストを作成できてしまいます。この非公開メールアドレスが漏洩した疑いがある場合は、直ちにトークンをリセットしてください」とGitLabは警告しています。
公開されていた非公開メールアドレス
Aikidoの研究者らは、わずか一日の午後だけで、公開されているREADME、コントリビューションガイド、サポートページの中から、実際に使用可能な非公開GitLabの受信用メールアドレスを十数件発見しました。
研究者らによると、これらのアドレスは、メンテナーにバグ報告を送るための手段として、意図的に公開ドキュメントに記載されたものだといいます。
多くのケースで、この露出は人気のあるオープンソースプロジェクトに影響しており、多数のユーザーを抱えるプロジェクトにサプライチェーンリスクをもたらしていました。「中には非常に人気の高いオープンソースプロジェクトも含まれていました」と研究者らは述べています。
Aikidoによれば、この問題を5月にHackerOne経由でGitLabに報告したものの、GitLabは「意図された仕様」としてクローズしたとのことです。
同社は6月に2回目の報告を行い、これを受けてGitLabはUIを更新し、マージリクエストに関する説明を追加するとともに、トークンによるデータアクセスに関する誤った記述を削除し、受信メールがIP制限を回避してしまう点をドキュメントに明記しました。
プロジェクトのメンテナーは、こうした情報を公開ドキュメントに自ら記載することをやめ、過去にこの方法で露出させてしまったプロジェクトについてはトークンをリセットすべきです。
