Maximum-Severity GitLab Flaw Allowing Account Hijacking Under Active Exploitation (arstechnica.com) 17
Dan Goodin reports via Ars Technica: A maximum severity vulnerability that allows hackers to hijack GitLab accounts with no user interaction required is now under active exploitation, federal government officials warned as data showed that thousands of users had yet to install a patch released in January. A change GitLab implemented in May 2023 made it possible for users to initiate password changes through links sent to secondary email addresses. The move was designed to permit resets when users didn't have access to the email address used to establish the account. In January, GitLab disclosed that the feature allowed attackers to send reset emails to accounts they controlled and from there click on the embedded link and take over the account.
While exploits required no user interaction, hijackings worked only against accounts that weren't configured to use multi-factor authentication. Even with MFA, accounts remained vulnerable to password resets. The vulnerability, tracked as CVE-2023-7028, carries a severity rating of 10 out of a possible 10. The vulnerability, classified as an improper access control flaw, could pose a grave threat. GitLab software typically has access to multiple development environments belonging to users. With the ability to access them and surreptitiously introduce changes, attackers could sabotage projects or plant backdoors that could infect anyone using software built in the compromised environment. An example of a similar supply chain attack is the one that hit SolarWinds in 2021, infecting more than 18,000 of its customers. Other recent examples of supply chain attacks are here, here, and here. These sorts of attacks are powerful. By hacking a single, carefully selected target, attackers gain the means to infect thousands of downstream users, often without requiring them to take any action at all. According to Internet scans performed by security organization Shadowserver, more than 2,100 IP addresses showed they were hosting one or more vulnerable GitLab instances. In order to protect your system, you should enable MFA and install the latest patch. "GitLab users should also remember that patching does nothing to secure systems that have already been breached through exploits," notes Goodin.
While exploits required no user interaction, hijackings worked only against accounts that weren't configured to use multi-factor authentication. Even with MFA, accounts remained vulnerable to password resets. The vulnerability, tracked as CVE-2023-7028, carries a severity rating of 10 out of a possible 10. The vulnerability, classified as an improper access control flaw, could pose a grave threat. GitLab software typically has access to multiple development environments belonging to users. With the ability to access them and surreptitiously introduce changes, attackers could sabotage projects or plant backdoors that could infect anyone using software built in the compromised environment. An example of a similar supply chain attack is the one that hit SolarWinds in 2021, infecting more than 18,000 of its customers. Other recent examples of supply chain attacks are here, here, and here. These sorts of attacks are powerful. By hacking a single, carefully selected target, attackers gain the means to infect thousands of downstream users, often without requiring them to take any action at all. According to Internet scans performed by security organization Shadowserver, more than 2,100 IP addresses showed they were hosting one or more vulnerable GitLab instances. In order to protect your system, you should enable MFA and install the latest patch. "GitLab users should also remember that patching does nothing to secure systems that have already been breached through exploits," notes Goodin.
Subject is here, here and here (Score:2, Troll)
Editing, do you do it?
Re: (Score:1)
Repo (Score:2)
I had some problem with a gitlab-ce install some months back where an update failed to install and then new updates filled the disk with the apt cache on it.
I used their docs to clear the problem and get current but there was nothing inherently wrong, just an upgrade error.
This may have preceded the security patch; if it's a common problem people who thought they were OK with automatic updates might be in for quite a surprise.
I am glad gitlab exists but goodness it's up to about 20GB for a half dozen very s
How does this work? (Score:3)
"Even with MFA, accounts remained vulnerable to password resets."
Since the exploit is a password reset, which the summary indicates is prevented by MFA, Isn't a password reset prevented by MFA?
Re: (Score:2)
"Even with MFA, accounts remained vulnerable to password resets."
Since the exploit is a password reset, which the summary indicates is prevented by MFA, Isn't a password reset prevented by MFA?
That part of the announcement is confusing.
What happens is that an attacker can successfully reset a user's password without any authentication. This locks the user out. However, MFA still keeps the attacker from fully logging in.
(Assuming your company isn't using something dumb like SMS 2FA.)
Re: (Score:2)
Re: (Score:2)
This was gitlab, not github.
Re: (Score:3)
MS still hasn't figured out their own MFA - it's fairly often I see accounts 'protected' by Microsoft Authenticator suddenly have new, mysterious rules re-rerouting inbound mail to various mailbox folders and have a sudden increase in outbound mail flow.
You'd think eastern Europe or China or something but wherever the attackers actually are physically, they usually register in the 365 logs as coming from within the US. I suspect this is to make geoblocking less effective.
I'm guessing it's not terribly diff
Are you starting your supply chain audits now? (Score:2)
So unless you've been enforcing 100% 2FA or 100% SSO, your unpatched GitLab instance (and any hosted software projects) have been vulnerable to anyone sending a password reset request. Auditing software and machine changes since GitLab 16.1 on May 1, 2023 is going to be a lot of work. Don't forget to check your upstreams and dependencies too.
Only 4 comments posted so far. We've given up on companies having any real security process.
Re: (Score:2)
I'm amazed at how many companies tolerate working with years old versions of services and libraries which are putting them at risk. This is especially true of any stack that will be reachable on the public internet like many of these self hosted GitLab instances here.
In my own org I try to keep our software development stack as fresh as possible because it is the best way to ensure you have least amount of vulnerabilities, the best long term compatibility, especially when working with SaaS, and have access
Re: (Score:2)
The short and sweet of it is this: All of the assurances / attestations / signatures / etc. are worthless if you have to constantly change what they validate.
It's effectively security theater because none of that actually prevents code exploitation. It just prevents you from executing code that was
Re: (Score:2)
Relying on a firewall is not sufficient to secure internal services. There is a long list of security breaches that were caused by an employee getting their laptop breached, for whatever reason, and then the bad actors roamed around the private network and exploiting known, patchable, vulnerabilities.
Of course the urgency to update is not the same for publicly accessible services as it is for services on the internal network, but running a 5y old server without updates when there is a long list of critical
Re: (Score:2)
Re: (Score:3)
So unless you've been enforcing 100% 2FA or 100% SSO, your unpatched GitLab instance (and any hosted software projects) have been vulnerable to anyone sending a password reset request.
The way I read TF (needs revision badly) S was that because gitlab made a modification to allow password resets on non-primary accounts, their reset process got bugged up to allow resets to be sent to any email address. (As registering a new secondary account would require login.) According to the bug report [gitlab.com] this assumption was correct. It's allowing an attacker to intercept and change the reset email list. (Why is this being sent to the unauthenticated end user!? Let alone actually being used directly ins
Re: (Score:2)
"Gitlab has yet another severe security vulnerability" is barely "news" at this point, it happens so often.
Gitlab is one of those software that puts a reasably nice looking "box" around dubious chunks of code vaguely duct taped toogether. You can do an easy deployment that nicely seems to work, but if you look a little harder, you can see a bunch of complex hard to debug interactions that you just have to hope never goes wrong.
With predictable implications for security, where vulnerabilities love overly co
Bad timing (Score:1)
And that's after a recent migration of the Tor Project to their instance of GitLab.
https://blog.torproject.org/gi... [torproject.org]