Attackers that were aiming to exploit users through session hijacking attacks on GitLab – the modern web-based Git repository manager have been stopped in their tracks as company fixes the bug.
Hijacking Bug and Potential Damages for GitLab and Users
“If there was a successful exploit on behalf of the attacker, the vulnerability within the system could have initiated an extensive list of damaging activities,” said Daniel Svartman who discovered the bug back in May this year. However, he could not disclose the information until this week after GitLab patched the bug and reassured their users the issue was fixed.
If an attacker was successful in their attempt to brute-force an account, they would grant themselves the ability to manage the account, dump the code, perform updates to the accounts as well as the noteworthy potential of stealing your personal information and sensitive data in the likes of new versions of software that are unreleased to the public. There are other possibilities whereby executing updates to the code could enable the attacker to embed any malware into it.
Svartman had noticed something was not quite right when he discovered that his session token was in his URL. Thus, all he had to do was to copy and paste the token several times and around the website to secure access to the GitLab’s dashboard, account information, other individual and ongoing company projects and even the site’s code.
This was not the only worrying factor that suggested something was up with the site. Having session tokens exposed so openly, being visible in the URL, is concerning enough, more so vividly exposing the bug itself. However, it was Svartman’s second discovery that confirmed his initial observation: GitLab lab makes use of persistent private session tokens that do not expire. What this means is that if an attacker were able to secure access to a user’s session token, it would not expire. This is specifically beneficial to an attacker as such a technique could let them stage an attack weeks or months after they have stolen the information, leaving the victim unaware and clueless of the intrusion.
Another suspicious feature that spiked Svartman’s interest was that the tokens were only 20 characters long, leaving the susceptible to brute-forcing. Given the token’s persistent nature and the admin level access the granted to users, there was no doubt that this was a looming security hole.
GitLab Fixes Hijacking Bug
It is not yet known how long the vulnerability had remained exposed to users before it was finally fixed. However, the researcher points out that he was not the first individual to highlight and bring up the issue to GitLab having seen users discussing the same issue on the company’s support forums.
Security Lead at GitLab, Brian Neel, highlighted that the company’s use of private tokens is not the main issue here and neither is it a problem on its own. He went on to elaborate:
“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, on the other hand, has also started to replace private tokens with custom RSS tokens for fetching RSS feeds. This initiative has been put in place to ensure that no session IDs are being leaked. Personal access tokens are also being increasingly employed by GitLab which would offer role-based access controls, thus boosting security measures as well.
