Vulnerable GitHub Actions Workflows Part 1: Privilege Escalation Inside Your CI/CD Pipeline
At Legit Security, we’re focused on preventing software supply chain attacks and securing the SDLC for our customers and the broader cybersecurity...
On April 1st, GitLab announced Critical Security Release CVE-2022-1162, disclosing a very bizarre vulnerability and illustrating some important lessons in securing a software supply chain. Although published on April’s Fool's Day, unfortunately, there was no prank involved. After all, a CVE with a CVSS score of 9.1 is no joke.
In this post, we’re going to analyze what happened and share the cautionary tale of misplaced trust across a software supply chain. In short, the consequences of allowing presumably trusted third-party access to your mainline code branch without sufficient code reviews and secret scanning capabilities can be potentially devastating. We’ll go into a brief forensic review, discuss the potential implications, and most importantly describe how these kinds of security risks can be prevented.
The GitLab vulnerability was in the OmniAuth-based user authentication mechanism, and was found by the GitLab security-research team. GitLab stated in their disclosure:
A hardcoded 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.
That means GitLab servers of both Community and Enterprise editions running all recent versions had a backdoor. The implication was that an adversary could take over accounts and log in as any user using any OmniAuth providers by entering the hardcoded password.
OmniAuth is a Standardized Multi-Provider Authentication library.
OmniAuth is a library that standardizes multi-provider authentication for web applications. It was created to be powerful, flexible, and do as little as possible. Any developer can create strategies for OmniAuth that can authenticate users via disparate systems.
By leveraging different strategies, application developers can easily plug-in authentication methods to enable secure login to their applications.
GitLab supports and advertises integrating different OmniAuth providers.
How did it suddenly happen? This backdoor wasn’t out there for a long time - only newer versions were affected by it.
The original commit - https://gitlab.com/gitlab-org/gitlab/-/merge_requests/76318/diffs?commit_id=5339bc9a22f6392df7615fc3ec7a608dd95d876e looks like a legitimate commit: a ton of test files changes that enhance the password strength in testing. But looking further into it, one file stands out - lib/GitLab/auth/o_auth/user.rb. Only one small change on that pull request was deployed to production code, and it was a very critical one:
Yep! Instead of the user’s authenticated hash, GitLab used a hardcoded password. How did this code get merged into the main branch? The answer is, probably, the large number of appearances of the same parameter in that commit, namely GitLab::password.test_default.
34 files were modified in this commit:
The commit title was “JH need more complex passwords”. So, what is JH? https://gitlab.cn/en/company/
GitLab licensed its technology to a new independent Chinese company, called JiHu. This independent company will help drive adoption of the GitLab complete DevOps platform in China and foster the GitLab community and open source contributions.
In China, there are some regulations concerning passwords, phone numbers storage, etc. To deal with those regulations, GitLab started an independent company named JiHu, which created a special edition tailored for China’s regulations, ensuring GitLab will be broadly usable in China.
Similar to CE/EE, JH is also based on the GitLab repository, but the JH project is not completely integrated back into GitLab. The JH repository was archived and moved to a different place 3 months ago. The repository movement occurred around the time of the “JH needs more complex passwords” commit (the last commit written to the archived project was pushed 4 days after the faulty commit).
The work was managed with the following methodology:
If you are interested in playing with the software, you can find the installation kit for Ubuntu here.
The commit’s author, @memorycancel, contributed many good commits to GitLab for the JH deployment, and is one of the biggest contributors to the GitLab JH project.
As this was the latest commit @memorycancel submitted to the JH and GitLab projects, following a long period of active contribution, we cannot be certain about the motives behind that commit. This kind of malicious activity can also happen as a result of a compromised account, among other reasons.
How could this incident be prevented? Following software security best practices can help significantly, and recently frameworks have started to emerge to address these types of risks, such as SLSA and SSDF.
A few mitigation points that relate to this case:
This incident is yet another case showing us we can never predict the next hole that will become an ominous vulnerability in our supply chain. It is also a cautionary tale about extending trust to entities with access to your supply chain, and about the limitations of human security checks and their ability to consistently detect security issues.
However, new solution approaches are available to help that leverage (a) automated discovery and security analysis across the supply chain environment, (b) detect any removal of mandatory security controls including code reviews; and (c) automated secret scanning within the code to prevent downstream vulnerabilities.
If you are interested in learning how the Legit Security platform can protect against the risks described earlier and much more, please contact us. If you’d like to learn more about other attack patterns documented by popular frameworks check out The 3 Riskiest Software Supply Chain Attack Patterns Across Frameworks.
Join the Legit Security Newsletter to stay up-to-date on the latest tips, tricks, and tech-industry news.
At Legit Security, we’re focused on preventing software supply chain attacks and securing the SDLC for our customers and the broader cybersecurity...
1 min read
Update: On November 1st the OpenSSL project maintainers released their fix for the vulnerabilities. There were two vulnerabilities discovered. After...
In this blog post, we'll discuss a new type of GitHub Actions workflow vulnerability we called "GitHub Environment Injection". We've found a couple of