GitLab, the popular web-based Git repository manager, fixed a vulnerability recently that could have exposed its users to session hijacking attacks.
Daniel Svartman, a security researcher with Imperva, discovered the issue in May but couldn’t disclose it until Wednesday, after GitLab was able to patch the issue and confirm it had been fixed.
If an attacker had exploited the vulnerability they could have carried out a laundry list of nefarious activities, Svartman told Threatpost on Thursday.
“If an attacker successfully brute-forced an account, the attacker would be able to manage the account, dump the code, perform updates to it, and of course steal potentially sensitive information, such as new versions of software unreleased to the public,” Svartman said, “Also, in other scenarios, by performing updates to the code, the attacker would be able to embed any kind of malware into it.”
The researcher said in a disclosure he knew something was up when he saw his session token in his URL. All he had to do was copy and paste the token around to secure access to GitLab dashboard, account information, individual projects, and even website code.
While having a session token out in the open like that, visible in a URL, is concerning enough, more alarming was Svartman’s second discovery: GitLab uses persistent private session tokens that never expire. If an attacker secured access to a user’s session token it wouldn’t expire, something that could let them stage an attack weeks or months after they stole it, with the victim left none the wiser.
The tokens were also only 20 characters long, something that left them susceptible to brute-forcing, according to the researcher.
“Given their persistent nature and the admin level access they granted, this added up to a real security concern,” Svartman wrote.
It’s unknown how long the vulnerability lingered until it was fixed, but Svartman notes that he wasn’t the first to point it out to GitLab; he also saw it mentioned on the company’s support forums.
When reached Thursday, GitLab told Threatpost there was no indication the vulnerability had been used to compromise an account.
Brian Neel, Security Lead at GitLab stressed that on its own the fact GitLab uses private tokens isn’t a problem.
According to Neel:
“This isn’t something that can be exploited directly. The existence of private tokens only becomes a problem when combined with a cross-site scripting or other vulnerability. Generally speaking, an account with a private token is at no more risk of compromise than if the tokens didn’t exist, unless another vulnerability is leveraged to steal the token. Most modern web services support the concept of a private token: AWS has access/secret keys, GitHub has access tokens, Digital Ocean has tokens, etc. The only real difference between their tokens and our private tokens is that they are limited to the API and typically encrypted. We support both of these options with personal access tokens. GitLab is currently phasing out private tokens in favor of personal access tokens.”
GitLab told Threatpost Friday that it has moved away from using private tokens to fetch RSS feeds and now uses a read-only RSS token that if exposed would only disclose RSS feed data. The company reiterated that it has plans to deprecate the use of private tokens and contests that the use of private tokens should be considered a vulnerability.
“There is no reason to think that private tokens had leaked due to the prior implementation. GitLab was being proactive by moving to a safer implementation,” Neel said.
“The private token has been part of GitLab for years. Its existence should not be considered a vulnerability. Improvements have been made to how this feature is implemented but users should not feel at risk simply because they run a version of GitLab that allows private tokens.”
GitLab fixed a similarly nasty command execution vulnerability in the repository last November, albeit in days, not months. The critical vulnerability could have let an authenticated user gain access to sensitive application files, tokens, or secrets. HackerOne cofounder Jobert Abma found the bug in late October and GitLab issued a fix a week later, on November 2.
*This article was updated at 2:30 p.m. to include clarifications from GitLab
