GitLab Critical Vulnerability Exploited

The U.S. Cybersecurity and Infrastructure Security Agency (CISA) recently warned about a critical vulnerability discovered in GitLab’s software. This flaw, classified as CVE-2023-7028, is currently being exploited by malicious actors and has a CVSS score of 10.0, the highest possible rating for vulnerabilities.

GitLab disclosed the vulnerability earlier this year. They noted that it was inadvertently introduced during a code update in May 2023. The issue affects all authentication mechanisms in versions 16.1.0 onwards. It poses a significant risk to users, especially those without two-factor authentication. Nevertheless, despite the seriousness of the situation, CISA did not provide details about specific exploitation cases.

More About Vulnerability

Successful exploitation of CVE-2023-7028 allows attackers to send password reset email to unverified email addresses, enabling account access for third parties. Successful attacks allow TAs to take control of GitLab accounts. This can lead to pilfering sensitive data, compromising credentials, and injecting malicious code into source code repositories. As a result, this could have a cascading effect, leading to widespread supply chain attacks.

Cloud security experts from Mitiga have highlighted the potential for attackers to manipulate CI/CD pipeline configurations, inserting code designed to siphon off sensitive data like personally identifiable information or authentication tokens. Additionally, tampering with repository code could introduce system-compromising malware or unauthorized access backdoors.

Mitigation Efforts and Federal Response

GitLab has addressed the vulnerability in several versions of its software, with patches available for versions 16.5.6, 16.6.4, and 16.7.2 and backported fixes for earlier affected versions. Despite all this, CISA is yet to disclose specific details on how the vulnerability is actively exploited.

In response to the ongoing threat, CISA has mandated federal agencies to update their GitLab installations by May 22, 2024. This directive underscores the critical nature of the vulnerability and the need for immediate action to safeguard networks against potential breaches.

The post GitHub Vulnerability Exploited in the Wild, CISA Notifies appeared first on Gridinsoft Blog.

Hackers Abuse GitHub and GitLab Feature to Upload Malware to Legit Repositories

The research regarding the new spreading campaign of RedLine stealer, that McAfee released the week before, revealed a rather unusual tactic. Hackers managed to place the malware file on the GitHub repository of Microsoft, without resorting to compromising one. Instead, threat actors exploited a design flaw of the platform.

In its Issue and Pull Request menus, GitHub offers users to attach a file they need – a neat feature which makes both actions convenient for users and the developers. Thing is – all the attachments are uploaded with the path of this repository, making them look like a thing related to this repo. User does not even need to post the message, as the link will work right away, after the system processes the file. These uploads do not appear anywhere in the repository and are kept only on GitHub’s CDN servers.

This forced analysts to dig further, and they discovered that GitLab, another developer platform, is susceptible to the very same issue. At the moment when a user attaches the file to a comment, the service generates a link to it. It remains active even if the comment was never posted or deleted shortly after publication.

This boils down to a simple conclusion: that feature allows the use of trusted and well-recognized repos as a concealed file sharing service. Repository masters will never know that someone is piggybacking their repo, and will not be able to do anything about it.

How dangerous is this?

In short: this can nullify any cybersecurity features that rely on trust ratings and designed to block access to web pages thas spread malware. Malicious programs rarely arrive “as is”, without loaders or other tricks that help it to examine the environment and run without interruptions. For quite some time now hackers rely on a place where they can upload the payload, so the said loader can pull and run one.

Usually, for this online storage, adversaries use a compromised website or a file sharing service. But modern security tools are aware of it and trigger the alarm when they see this traffic. On the other hand, a link that leads to the Microsoft repository, by the looks of it, will never be a reason for alarm. There is no way to tell whether the link leads to a file that is directly in the repo or just sits on a CDN.

The worst part here is that neither GitHub nor GitLab are able to fix the issue on short notice. Researchers who did the analysis of a GitLab case say they have contacted both companies, but did not receive a response yet. And honestly, I cannot see a quick and painless remedy here. Banning CDN uploads, the most straightforward decision, will disrupt genuine uploads. Integrating a malware scanning mechanism may create issues with educational open-source malicious software, and is also time consuming. That probably explains why the services remain silent on the request from the researchers.

The post GitHub and GitLab CDNs Abused to Spread Malware appeared first on Gridinsoft Blog.

New GitLab Critical Vulnerability Discovered

A critical vulnerability identified as CVE-2024-0402, rated as high as 9.9 of 10. It allows attackers to execute arbitrary code on GitLab instances, potentially leading to data theft, unauthorized access to sensitive information, and disruption of critical development operations. This vulnerability stems from a flaw in GitLab’s handling of incoming HTTP requests, making it possible for attackers to craft malicious requests and exploit the system.

To exploit CVE-2024-0402, an attacker begins by preparing a malicious request that includes directory traversal sequences ( ‘. . /’). This is embedded within the parameters responsible for defining workspace paths. When the GitLab server processes this request, the improper input validation allows these sequences to navigate beyond the intended workspace directory.

The exploitation chain looks like this:

1. Preparation
   The attacker crafts a specially designed request, embedding directory traversal characters along with the name of the file they intend to overwrite.
2. Execution
   This request sends to the GitLab server during the workspace creation process.
3. Overwrite
   The server, failing to sanitize the input properly, processes the request, leading to the overwrite of the targeted file.
4. Post-Exploitation
   Depending on the overwritten file, the attacker can achieve various malicious objectives, including code execution, privilege escalation, data tampering, or else.

GitLab Releases Fixes to CVE-2024-0402

GitLab has released patches for the critical vulnerability. Experts strongly recommend that all installations running a version affected by the issues described are upgraded to the latest version as soon as possible. GitLab.com and GitLab Dedicated environments are already running the patched version. The fix for this security vulnerability has been backported to the following versions: 16.5.8, 16.6.6, 16.7.4 and 16.8.1.

GitLab has resolved four medium-severity vulnerabilities. Additionally these vulnerabilities could lead to regular expression denial-of-service (ReDoS), HTML injection, and the disclosure of a user’s public email address via the tags RSS feed.

Mitigation Strategies

Beyond applying the patch, organizations are advised to take further steps to enhance their security posture:

• Conduct a thorough review of system logs for any signs of exploitation or unusual activity.
• Regularly update all software components to their latest versions to mitigate vulnerabilities.
• Employ network segmentation and firewall rules to limit access to critical systems.
• Integrate EDR/XDR with other security systems for better coverage and incident response.

The post GitLab Vulnerability CVE-2024-0402 Exposes File Overwrite Risk appeared first on Gridinsoft Blog.

GitLab Zero-Click Vulnerability Allows Account Hijacking

As far as the company’s official description of the CVE-2023-7028 goes, a handful of versions contain a critical bug. Using it, a potential adversary can send the password reset email to an arbitrary email address. Therehence, hackers can effortlessly hijack accounts of any access privileges. Such ease of exploitation and severity of potential outcomes is what gives this vulnerability the CVSS score of 10/10.

By accessing the repository, attackers can effectively do whatever they want with the code stored on it. Selling corporate secrets, seeking for potential vulnerabilities in the software, injecting malicious code hoping to compromise employees’ systems or even launching a supply chain attack – pick the one you like. Patching this should not be just urgent – it must be done immediately.

As GitLab notes, the activated 2FA on the account would have saved it from hijacking. Two-factor auth is not susceptible to the bug and should still be verified in a proper way. Still, there are enough people who do not care about the security of Git repository access, meaning that CVE-2023-7028 has an enormous field of application.

GitLab 0-click Vulnerability Fixes Available

The company did not just release a security notification, but made it a part of patch note for an update that fixes all this mess. According to the information, only version 16 is vulnerable, specifically a lineup of its minor updates:

The latest versions available are 16.5.6, 16.6.4 and 16.7.2, meaning there are no options for users of versions 16.4 and below. However, GitLab also provides backports of the vulnerability to 16.1.6, 16.2.9, 16.3.7, 16.4.5, 16.5.6, 16.6.4, meaning that there is no need to update to the most recent version. As there are no mitigation options offered (and possible), updates remain the only choice.

How to protect against software vulnerabilities?

As I mentioned above, there is one way to avoid account hijacking through this vulnerability – using 2FA. Still, every specific vulnerability requires its own protection method, which makes it quite difficult to give universal advice. For this specific case, for example, a security solution is completely useless, as the hack happens completely away from the protected environment.

Nonetheless, the use of a thoroughly-engineered security software heavily reduces the chances of being hacked. Such zero-click vulnerabilities are rare occurrences, so pessimism aside – EDR/XDR will be effective against the majority of exploitation attempts. For the additional awareness and more rapid response, SOAR and SIEM systems will serve a great addition to the pack.

The post GitLab Zero-Click Account Hijack Vulnerability Revealed appeared first on Gridinsoft Blog.

What is GitLab?

GitLab is an open-source repository and collaborative software development platform. The DevOps software package allows users to develop, protect and use software used by development teams who need to manage their code remotely. It has around 30 million registered users, including one million paying customers. As you may imagine, even a slight issue or vulnerability in the product will have a terrifying scale – and that is what happened.

GitLab Vulnerability Scores Highest CVSS Rating

The company recently discovered a critical path traversal vulnerability CVE-2023-2825 with maximum severity status CVSS score of 10.0. This vulnerability allows unauthenticated attackers to read arbitrary files on the server under certain conditions. Attackers can read sensitive data from vulnerable endpoints. This data may include proprietary software code, user credentials, tokens, files, and other personal information.

The vulnerability was discovered by cybersecurity researcher “pwnie” and affected versions 16.0.0 of GitLab Community Edition (CE) and Enterprise Edition (EE). He said you must have an attachment in a public project nested in at least five groups to exploit the vulnerability. However, the excellent point is that this structure is only found in some GitHub projects. Moreover, version 16.0 is the most recent update for GitLab CE/EE, thus it simply circulates too little time to become a major issue.

Mitigation

GitLab immediately released a security update to address this vulnerability after its discovery, highlighting its quick response to such security threats. To protect their systems, GitLab CE or EE version 16.0.0 users are strongly encouraged to install the most recent update or perform a roll back.

We strongly recommend that all installations running a version affected by the issues described below are upgraded to the latest version as soon as possible. When no specific deployment type (omnibus, source code, helm chart, etc.) of a product is mentioned, this means all types are affected. – GitLab.

To update your GitLab installation, please follow these instructions.

Aside from the official guidelines, you may apply a number of other measures. They are reactive, but will most likely do their job in the case of other issues that will not receive a fix that fast.

For example, I recommend using software that supports the Zero Trust model. In two words, Zero Trust is a security strategy designed to implement security principles. It is not a product or service but rather an approach. These principles include detailed verification, the use of least privilege access, and the assumption of a breach. However, this may prevent unauthorized access.

In addition, you can follow cyber news and keep up with the latest developments. Thus, you can gain valuable insights into the latest products, emerging threats, and cybersecurity trends. Cyber news sources provide information about new vulnerabilities, data breaches, malware attacks, and hacking incidents. So, it lets you stay proactive and better equipped to protect yourself and your digital assets. By keeping up with these reports, you can learn from real-world examples and understand the tactics and techniques employed by cybercriminals. Forewarned is forearmed.

The post GitLab Releases Patch to Critical Vulnerability appeared first on Gridinsoft Blog.

A training attack conducted by the GitLab Red Team simulated a real phishing campaign, the purpose of which was to find out the credentials of GitLab employees. For this purpose, information security specialists registered the gitlab.company domain name and configured it to send phishing emails using the open source GoPhish and GSuite from Google. Phishing emails were designed in order to simulate real notifications from the IT department, allegedly informing about the need to update the laptop.

“The target users were asked to click on the link, supposedly in order to agree to the update, but in fact this link led to a fake login page on GitLab.com located on the gitlab.company domain”, — say in GitLab.

During the audit were sent 50 such emails. As a result, 17 (34%) of recipients clicked on the link in the message, going to a special phishing site. Of these, another 10 people (59% of those who went to the site, and 20% of the total tested group) continued to work and entered their credentials on a fake page. However, only 6 out of 50 recipients of phishing messages (12%) reported a phishing attempt to GitLab security staff.

It is worth saying that, according to Verizon’s report, 22% of the total number of incidents related to data disclosure usually related to phishing, and about 90% of incidents are related to social interaction. The report also states that on average, the frequency of clicks on phishing links should be much lower – 3.4% against 20% shown by GitLab employees.

Another information security company, Rapid7, wrote that the frequency of clicks on links in phishing emails varies from 7 to 45%. Another 2018 report, compiled by KnowBe4, states that the average percentage of workers vulnerable to phishing attacks in various industries is 27%.

According to the Vade Secure report, during the pandemic, the number of phishing attacks using Facebook increased by 358.8%, and using Whatsapp messenger – by 13467%.

GitLab’s vice president of security, Jonathan Hunt, told The Register that he’s generally happy with the results of the audit and is pleased to see that GitLab’s results are better than average in the enterprise.

“Initially, the [Red Team] suggested that more people would fall for this phishing bait, but this assumption turned out to be wrong. Some vendors claim that the average success rate of phishing attacks is about 30-40%, so it’s nice to see that we are staying below this level”

Considering that popularity of phishing does not think to wane, Hunt emphasizes that companies are required to train their employees in information security, regardless of whether they work remotely or not:

“This means that companies, regardless of whether they work remotely or not, must train their employees so that they maintain the proper level of vigilance when dealing with e-mail. As organizations move more and more to remote work and, potentially, can more frequently use cloud services, user identity management and multi-factor authentication become critical factors. ”

Let me remind you that Github also recently warned employees and users about the increased danger of phishing attacks.

The post GitLab checked its employees: on phishing got every fifth appeared first on Gridinsoft Blog.

Bowling exposed the vulnerability in March 2020. Then the expert noticed that an attacker could get arbitrary files from the server while moving the issue from one GitLab project to another.

“The problem was due to the lack of file name validation in the UploadsRewriter function. As a result, the specialist demonstrated in his report that an attacker could exploit this problem to read arbitrary files from the server, including configuration files, tokens, and other sensitive data”, — says William Bowling.

Studying this problem further, the expert discovered that it could also lead to the remote execution of arbitrary code. The flaw applied to both local GitLab installations and gitlab.com.

GitLab engineers note that an attacker could exploit this vulnerability by simply creating his own project or group, moving issue from one project to another.

GitLab developers fixed the vulnerability a few days after receiving a message from the researcher. As mentioned above, William Bowling was paid a reward of $20,000 for this bug.

Interestingly, this is far from the first bug bounty of Bowling. In recent months, the expert has earned more than $50,000 on GitLab problems, having found several critical and serious vulnerabilities of the platform.

At the end of 2019, GitLab reported that over the past year, it paid researchers more than $500,000 as part of its reward program for vulnerabilities discovered.

Let me remind you that recently I wrote here about the information security researcher Jacob Archuleta, known on the network under the pseudonym Nullze, who found that the Tesla Model 3 interface is vulnerable to DoS attacks. Archuleta earned at least $15,000 through the Tesla bug bounty program.

The post IS researcher discovered a critical vulnerability in GitLab appeared first on Gridinsoft Blog.