It turns out that cyber threat actors can do quite a bit of damage with nothing more than an email address.
New research from Aikido Security published today examines how an incoming GitLab email address acts as a highly privileged access token that grants broad user rights to an organization’s public and private projects. GitLab Automatically assigns each user of the DevOps platform a private email address to create issues in their software projects; If a user emails the address, a new issue will appear in a project created by that user.
Creating project issues through emails sent to automated unique addresses is not an uncommon capability, Aikido noted in the report. For example, project management platforms like Trello, Todoist, and Monday.com have similar features.
But each of GitLab’s email addresses contains a non-expiring token that provides broad access to an organization’s resources, and not just the project an individual user is working on. And if that address is exposed publicly, an attacker could abuse it to supply chain attacks without needing real access to the account.
“Any mailbox on the Internet can send to that address and GitLab processes the message as the owner of the token.” the report fixed. “If you have the address, you have both authentication and authorization.”
The Aikido research team maintains that many GitLab users are likely unaware of the risks associated with these addresses, as evidenced by the number of addresses intentionally exposed on the public Internet.
What is your GitLab address?
Aikido researcher Joe Leon tells Dark Reading that what started as a simple feature in GitLab for creating project issues has expanded over the years to include more features, such as pushing merger requests and patch files, with privileged access. And while the capabilities are documented, Leon says the risks are underestimated, especially in GitLab’s user interface (UI).
“It wasn’t clearly communicated that there is something sensitive there that can not only create problems but also submit code. And by submitting code, you can potentially submit code to the front page.” [the main branch] or run a CI/CD work,” he says.
The GitLab UI describes the email address as a tool for adding work items, such as issues, to a particular project and specifically states that it “cannot be used to access any other data.” But according to Aikido, this is demonstrably false.
“The credential incorporated into the address can be reused in all public and private projects,” says León.
Leon discovered that email addresses contain what’s called a glimt- (GitLab Incoming Mail Token) prefix string, and that each user’s token string is the same for all public and private projects they have access to. If an email address for a public project is exposed, an attacker could modify the project path and project ID in the email to reach other private projects (the Aikido report noted that the IDs are guessable, but an attacker would need the project name to be leaked).
“They present it as an email address to create an issue on a particular project. And if you’re working on a public project, you can distribute it; that makes sense,” León says. “But I didn’t realize that [with] the credential, just by adjusting the email address, anyone could also send code to my private projects. “That blew me away.”
Additionally, Leon discovered that he could bypass IP address restrictions with GitLab email addresses. Restricted a private project to a single random IP address that it did not own. GitLab’s restriction prevented you from cloning the project or accessing it through a web browser, but emails with merge requests crossed that security boundary.
Exposed GitLab Email Addresses Pose Significant Risk
As part of the research project, Leon conducted a “very non-exhaustive search” of the Internet that lasted a couple of hours, during which he easily found a dozen incoming email addresses that had been intentionally exposed in readme and supporting files. Some of the exposed addresses belong to popular open source projects, Leon says.
“I’m sure there are many more out there,” he says. “This was the low-hanging fruit.”
Leon also says it could be difficult to determine whether an attacker had abused an incoming email address to, for example, poison a project with malicious code via a merge request. “It is not obvious that it was done by email,” he adds. “You would need access to GitLab’s servers, assuming they collect this data.”
Aikido reported their findings to GitLab via hackerone in May, although GitLab closed the report as expected behavior. The cybersecurity vendor then followed up in June with a sensitive issue in the GitLab repository. GitLab finally changed its UI to reflect that the email address can be used for merge requests and removed the “Cannot be used to access any other data” statement.
GitLab also updated its documentation to inform users that email addresses are not subject to IP address restrictions.
Leon says the best mitigation he would like to see is a requirement that the sender address match that of the GitLab account; This would create a major obstacle to attacks, as threat actors would have to compromise the user’s email account instead of simply trusting the GitLab address.
“This basically eliminates the vast majority of the problem here,” he says.
Leon says GitLab is considering this change.
Dark Reading reached out to GitLab for comment, but the company did not respond at the time of this publication.
In the meantime, Aikido recommended that organizations reduce their attack surfaces by preemptively rotating access tokens in their GitLab email addresses and scanning these addresses in their development environments and repositories like any other. other secrets.
