Brother
Professional
- Messages
- 2,590
- Reaction score
- 533
- Points
- 113
Why are administrators slow to update, risking the protection of their networks?
The critical Zero-click vulnerability CVE-2023-7028 (CVSS score 10.0), which we already reported last week, was discovered by researchers in more than 5,300 GitLab instances accessible from the Internet. Despite the fact that the problem was fixed in the latest versions of GitLab, not all users managed to update their software.
This vulnerability allows attackers to hijack accounts without the need for user interaction. Hackers send password reset emails to an email address they control, which allows them to change the password and hijack the account.
Although the vulnerability does not provide a way to bypass two-factor authentication (2FA), for accounts that are not protected by this additional security mechanism, it poses a huge risk.
The issue affects the following GitLab Community and Enterprise editions:
The corresponding fixes were released on January 11. Two weeks later, the ShadowServer threat monitoring service reports 5,379 vulnerable GitLab instances accessible from the Internet.
Based on the role of GitLab as a platform for software development and project planning, as well as the nature of the vulnerability, these servers are at risk of supply chain attacks, proprietary code disclosure, API key leaks, and other malicious activity.
According to Shadowserver, the majority of affected servers are located in the United States (964), followed by Germany (730), Russia (721), China (503), France (298), the United Kingdom (122), India (117) and Canada (99).
Those who have not yet installed patches may already be compromised, so it is extremely important to use the GitLab Incident Response Guide and check for signs of compromise.
GitLab previously shared the following detection tips for information security professionals:
Administrators who discover compromised instances should change all credentials, API tokens, certificates, and other secrets, in addition to activating 2FA on all accounts and installing a security update.
After securing the servers, administrators should check for changes to the development environment, including source code and potentially tampered files.
To date, there have been no confirmed cases of active exploitation of the CVE-2023-7028 vulnerability, but this should not be considered as a reason to delay taking action.
The critical Zero-click vulnerability CVE-2023-7028 (CVSS score 10.0), which we already reported last week, was discovered by researchers in more than 5,300 GitLab instances accessible from the Internet. Despite the fact that the problem was fixed in the latest versions of GitLab, not all users managed to update their software.
This vulnerability allows attackers to hijack accounts without the need for user interaction. Hackers send password reset emails to an email address they control, which allows them to change the password and hijack the account.
Although the vulnerability does not provide a way to bypass two-factor authentication (2FA), for accounts that are not protected by this additional security mechanism, it poses a huge risk.
The issue affects the following GitLab Community and Enterprise editions:
- 16.1 to version 16.1.5;
- 16.2 to version 16.2.8;
- 16.3 to version 16.3.6;
- 16.4 to version 16.4.4;
- 16.5 to version 16.5.6;
- 16.6 to version 16.6.4;
- 16.7 to version 16.7.2.
The corresponding fixes were released on January 11. Two weeks later, the ShadowServer threat monitoring service reports 5,379 vulnerable GitLab instances accessible from the Internet.
Based on the role of GitLab as a platform for software development and project planning, as well as the nature of the vulnerability, these servers are at risk of supply chain attacks, proprietary code disclosure, API key leaks, and other malicious activity.
According to Shadowserver, the majority of affected servers are located in the United States (964), followed by Germany (730), Russia (721), China (503), France (298), the United Kingdom (122), India (117) and Canada (99).
Those who have not yet installed patches may already be compromised, so it is extremely important to use the GitLab Incident Response Guide and check for signs of compromise.
GitLab previously shared the following detection tips for information security professionals:
- check gitlab-rails/production_json. log for HTTP requests to the /users/password path with params. value. email consisting of a JSON array with multiple email addresses;
- check gitlab-rails/audit_json. log for entries with meta.caller.id PasswordsController#create and target_details, consisting of a JSON array with multiple email addresses.
Administrators who discover compromised instances should change all credentials, API tokens, certificates, and other secrets, in addition to activating 2FA on all accounts and installing a security update.
After securing the servers, administrators should check for changes to the development environment, including source code and potentially tampered files.
To date, there have been no confirmed cases of active exploitation of the CVE-2023-7028 vulnerability, but this should not be considered as a reason to delay taking action.
