Gitlab OmniAuth Static Passwords and stored XSS

Hello everyone! In this episode, let’s take a look at the latest vulnerabilities in Gitlab. On March 31, the Critical Security Release for GitLab Community Edition (CE) and Enterprise Edition (EE) was released. GitLab recommends that all installations running a version affected by the issues described in the bulletin are upgraded to the latest version as soon as possible.

Alternative video link (for Russia): https://vk.com/video-149273431_456239079

Unfortunately, Gitlab, as well as some other Western companies, is currently hostile to the country where I live and work. So their calls to immediately install updates now have additional connotations. If Gitlab is so clearly politically motivated that even the logo on their site has been recolored in a certain way, then what else can be expected from their updates? Backdoors? Malicious functionality that wipes data? Quite possible. IMHO, when companies are so willing to mix geopolitical messages and business, it exposes them as unreliable vendors that should be avoided.

But let’s get back to vulnerabilities. There are 17 CVEs in the bulletin. We will start with the most critical one.

CVE-2022-1162: Static passwords inadvertently set during OmniAuth-based registration

This is a critical level vulnerability with a CVSS Base Score 9.1.

“A hard-coded password was set for accounts registered using an OmniAuth provider (e.g. OAuth, LDAP, SAML) in GitLab CE/EE versions 14.7 prior to 14.7.7, 14.8 prior to 14.8.5, and 14.9 prior to 14.9.2 allowing attackers to potentially take over accounts”

OmniAuth is a library that standardizes multi-provider authentication for web applications. During the account registration process, the password is set with a predictable pattern, which makes it relatively easy for an attacker to brute force the registered user’s password based on the pattern. The exploit is not yet publicly available.

Gitlab.com was also affected by this vulnerability, but it was fixed and some passwords were reset. A script is available in the bulletin which can be used by self-managed instance admins to identify user accounts potentially impacted by CVE-2022-1162. There is a warning “use at your own risk”.

To fix, you need to update Gitlab to the latest version. Versions less than 14.7 are not vulnerable.

Stored XSS in Notes (CVE-2022-1175) and on Multi-word milestone reference (CVE-2022-1190)

Both vulnerabilities have a CVSS Base Score 8.7, High.

Improper handling of user input in GitLab CE/EE allowed an attacker to exploit XSS by injecting HTML in notes and allowed an attacker to exploit a stored XSS by abusing multi-word milestone references in issue descriptions, comments, etc.

It seems that this can be successfully used in phishing.

For a complete list of vulnerable versions for these vulnerabilities, see the bulletin. Note that the second stored XSS has been around since version 8.3. Patch releases only include bug fixes for the current stable released version of GitLab (currently 14).

The remaining vulnerabilities are not critical enough, so it makes no sense to review them separately. But perhaps the most interesting of them are those related to DoS: Denial of service caused by a specially crafted RDoc file (CVE-2022-1185), regular expression denial of service in release asset link (CVE-2022-1100) and client DoS through rendering crafted comments (CVE-2022-1174).

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.