A long-lived token embedded in GitLab’s issue-creating email address means anyone with the address, not just the project owner, can push code and trigger CI/CD jobs subject to the account’s existing permissions.
It was meant to make life simpler: a secret email address to which developers can send a message and create an issue in their GitLab project. But poor security defaults and a long-lived token embedded in the address mean that anyone who knows the address can potentially modify protected repositories. If project owners publish or leak these addresses, as some have, then they become vulnerable.
The project-scoped email address supplied by GitLab in the form of a button that says “Email work item to this project” can unlock account-wide access on private as well as public projects, in addition to its intended function, Aikido Security has found. The feature is turned on for every account on GitLab.com, and cannot be turned off; it may also be turned on for self-hosted instances of GitLab.
“Anyone holding that address can push code and run CI/CD jobs in every project your account can reach,” the application security company said in a blog post describing its findings.
“The biggest challenge with the existing design is anyone with an email account can email to that address and act as that GitLab user,” Joseph Leon, security researcher at Aikido told CSO. “If GitLab required the ‘from’ address of the account sending the email to match the GitLab user’s email address, most of the risk would be mitigated.”
IP restrictions ignored
GitLab does allow users to set restrictions on which IP addresses may access their account — but those restrictions do not apply to emails. “GitLab blocked our browser and rejected git clone. It accepted the email, and the commit landed on main,” Aikido said.
The behavior is intended, and not a vulnerability, according to GitLab. Aikido questions that assessment, arguing that “GitLab built a credential that reaches every project in the account and bypasses IP restrictions, then presented it as an email address.”
Vulnerable addresses have the form incoming+project-id-glimt-XXXXXXXXXXXXXX-issue@incoming.gitlab.com
The culprit is the personal access token (PAT) prefixed by “glimt-“ embedded in the email address that GitLab wants to be kept private. “Keep this token secret. Anyone who has it can create issues as if they were you,” GitLab warns through a UI description for the token.
Aikido said the description adds that the token “cannot be used to access any other data,” a claim it finds untrue. Five different projects belonging to the same account provide five different private email addresses, but the “token embedded in each one is identical,” it said. The same token is used for the entire account, making a compromise reachable to every public or private project within that account.
The token could be used to do more than create a GitLab issue such as reporting a bug or requesting a feature. By simply changing a suffix to the token, GitLab could be tricked into opening a merge request.
Doing this would allow the attacker to submit a crafted patch, a file with a set of code changes, and have GitLab execute attacker-controlled code within the project’s CI/CD environment.
And merge requests
After Aikido reported that to GitLab, the company changed the UI description to reflect that the token allows creating issues “and merge requests.”
The token does not give an attacker unlimited access to GitLab: What they can do remains tied to the permissions of the account to which the secret email address is linked.
“The organizational impact depends entirely on the user’s existing permissions,” Leon said. “If they can push code to main or run CI/CD pipeline jobs on a particular project, the email address inherits those rights, and the impact can be quite severe.”
Targeting other projects in the account faces a limitation, too. The attacker needs to provide the path and ID of the target project. Both are public for public projects, while targeting a private project requires its path to be leaked; its ID, however, can be guessed.
Leon added that the likelihood of these email addresses being leaked is high. “I found a dozen or so exposed online after looking for just a couple of hours. Some belonged to popular open source projects like wget2,” he said.
Aikido’s recommendation is to treat these email addresses as credentials rather than ordinary email endpoints. Organizations should look for exposed addresses in public repositories and documentation and, if exposure is suspected, reset the email token to invalidate the existing address.
This article first appeared on InfoWorld.