Have you ever thought the most popular CI/CD platform – GitLab – may have security issues? In fact, it is inevitable with such a massive infrastructure. Don’t worry! The platform is still reasonably secure: it scores [well over 700 on BitSight](), monitors alerts in real-time, and addresses them instantly.
But vulnerabilities still arise, and it’s good to know their types, severity, and how they are addressed. We carefully analyzed GitLab’s security reports from the last six months, January—June 2022, to provide you with some insights on the matter.
![Vulnerabilities found in GitLab](https://i0.wp.com/lab.wallarm.com/wp-content/uploads/2022/08/Vulnerabilities-found-in-GitLab.jpeg?resize=770%2C372&ssl=1)Vulnerabilities found in GitLab over the past six months
Before diving in, here is some great news: on June 30, GitLab issued a [monthly critical security release](). Along with other vulnerabilities, it fixes the critical remote code execution vulnerability [CVE-2022-2185](). Before that, an unauthorized user could execute malicious code on the server using the project import feature. The vulnerability was assigned a CVSS score of 9.9 (Critical severity). Having it resolved is a relief.
## How Often Do Severe Problems Arise?
GitLab is a highly secure platform. It keeps its finger on the pulse of vulnerabilities and consistently updates its repositories. You can rest easy knowing that your code is in safe hands. That said, what vulnerabilities were tracked and addressed in the last six months? Let’s proceed to the details.
* **Uncontrolled Resource Consumption** is the most encountered vulnerability type in the past six months. Researchers have identified nearly 25 cases affecting GitLab’s production environment. The vulnerability allows an attacker to initiate DoS attacks. One of the prominent examples for this class is [CVE-2022-0151](). Improper handling of package deleting functionality enables DoS attacks under certain conditions. The vulnerability was disclosed by GitLab on January 16, 2022, and was assigned a CVSS score of 6.4 (Medium severity).
* 13 cases of **Improper Authorization** were identified in the production. Authorization vulnerabilities can be critical, as it is with [CVE-2022-1680](). Due to misconfiguration in the SCIM feature available on Premium+ subscriptions, this bug allowed ATO attacks on any GitLab account. How? An owner of a Premium group invites a user by their username and email and then changes the email to an attacker-controlled one via the SCIM feature. GitLab team discovered CVE-2022-1680 and assigned it a CVSS score of 9.9 (Critical severity).
* **Improper Access Control** is also typical for GitLab. One example is [CVE-2022-1423](). If an attacker has sufficient privileges to push code and run the pipeline on any branch, they can poison the cache in a protected context and execute malicious code. Deployment tokens, authorization keys and other sensitive information about the project can also leak. In addition, an attacker could backdoor the final pipeline by altering the build process. The vulnerability was published on May 19, and its CVSS score is 6.5 (Medium severity).
* **Information exposure vulnerabilities** come next in the chart. What happens when you expose something that you shouldn’t? In the past, GitLab made this mistake. The [CVE-2022-0244]() issue is connected to the Bulk Imports API. The symlinks were not removed when untarring the uploaded tar.gz file. So, arbitrary files could be read and uploaded when importing a group. An independent security researcher discovered this flaw. It was assigned a CVSS score of 8.5 (High severity).
![Vulnerable code snippet](https://i0.wp.com/lab.wallarm.com/wp-content/uploads/2022/08/Vulnerable-code-snippet.jpeg?resize=770%2C439&ssl=1)Vulnerable code snippet
**Comment:** If a GitLab group has uploaded files, a tar.gz file will be downloaded and extracted via the extract function. Any symlinks extracted from the file will be added to the list of file paths. When the load function gets called, the symlinks are used for the content of the new file. An attacker could use this vulnerability to read sensitive information.
* **Improper Neutralization vulnerabilities **are a thing for GitLab. Abusing multi-word milestone references in issue descriptions and comments allows for stored XSS vulnerability, as in [CVE-2022-1190](). Notably, a restriction was missing in the string-based multi-word milestone regex. The vulnerability was found by an independent security researcher and reported through the HackerOne platform. It was published on April 4 and assigned a CVSS score of 8.7 (High severity).
![Vulnerable code snippet 2](https://i0.wp.com/lab.wallarm.com/wp-content/uploads/2022/08/Vulnerable-code-snippet-2.jpeg?resize=770%2C459&ssl=1)Vulnerable code snippet
**Comment:** As you can see, no regular expression is in place to restrict malicious code. The code snippet is subject to [Cross-Site Scripting]() (XSS) and other input-based vulnerabilities.
* **Memory corruption bugs** are old school but continue to thrive. Since January, six memory corruption bugs have been discovered in GitLab. Most of the time, they don’t pose a real risk to GitLab’s production environment.
* So far in 2022, three **Improper Input Validation** bugs were discovered in GitLab’s production environment. [CVE-2022-1406]() is the most critical one among them. It was possible to read protected group or CI/CD variables by importing a malicious project. It was assigned a CVSS score of 6.4 (Medium severity).
* **Improper Authentication bugs **are not typical for GitLab. Only one vulnerability was discovered thus far in 2022, a low-risk finding. Due to an incorrect authorization mechanism, a user could get authenticated without a personal access token. [CVE-2022-1426]() was published by GitLab.
* The use of **Hard-coded Credentials** should not be as common as it is. It’s drilled into developers’ heads to _not_ hard-code sensitive data since malicious actors will use it against them. So far in 2022, only one such vulnerability was discovered in GitLab. [CVE-2022-1162]() was assigned a CVSS score of 9.1 (Critical severity). A hard-coded password set for accounts registered using an OmniAuth provider (e.g., OAuth, LDAP, SAML) in GitLab CE/EE allows an attacker to take over any account.
## Advice for Better API Security
Users must be careful when using GitLab to avoid the exploitation of vulnerabilities and malicious attacks. An awareness of the risks in your environment, and the measures you have taken to minimize them, will help mitigate any potential attack. Here are some suggestions for managing your GitLab environment vulnerabilities.
1. First of all, gain a thorough understanding of your API portfolio. Establish how many APIs you have and their types (e.g., internal, partner, external) and usage. Thus you will find any shadow or zombie APIs. Next, check if there are deviations from the design schema to verify that the original intent matches with actual usage. Finally, determine the sort of sensitive data, like passwords, tokens, and PII, to ensure you meet your security and compliance requirements.
2. Get a grip on the frequency, severity, and impact of any API vulnerabilities in your environment. For instance, even if your APIs don’t have the CVE-2022-1162 vulnerability, they still may contain other vulnerabilities associated with hardcoded credentials ([CWE-798]()). This is especially important if any of such vulnerabilities are external-facing.
3. Explore the mitigation approaches available to you. They should fix the root cause and immediately push the update into production. But what about zero-day vulnerabilities, the ones you don’t yet know? In addition to the “shift left” philosophy, you need a “shield right” approach for run-time [protection of your APIs](). This “defense in depth” approach is nothing new — we’ve been using it in compiled code for decades. So it’s time to bring it into the modern API world.
There are dedicated automated tools for most of those tasks. To avoid future vulnerabilities, regularly conduct a full [API Discovery]() and leverage [automated threat detection scanners]().
## Bottom Line
The analysis of GitLab vulnerabilities over the first six months of 2022 suggests that the platform has seen a fair number of issues and has been pretty responsive in addressing them. The most severe frequent issue was CVE-2022-1680 (Improper Authorization), which allows ATO attacks against any account on GitLab.
It’s essential to stay on top of developments in the API vulnerability space. You can join over 1,500 peers in the [LinkedIn API Security Community]() for up-to-date information on impactful API vulnerabilities.
In addition, we invite you to [subscribe to our blog]() and peruse our [API Security Learning Center]().
To explore how the Wallarm API Security platform can protect your API portfolio against vulnerabilities, you can [book a quick demo]() with one of our API security experts.
The post [GitLab Security Issues: Six Months of Vulnerabilities]() appeared first on [Wallarm]().Read More
Back to Main