Summary
- An RCE was discovered in GitLab server and assigned CVE-2022-2185
- Exploit requires a valid account, but the default behavior of the server allows for new account creation with approval by the administrator.
- Censys users can find GitLab servers with the following Censys Search query
- Check out our GitLab Dashboard, which is updated every 24 hours.
Introduction
On July 1st, 2022, CVE-2022-2185, a critical issue in the GitLab server, was made public, allowing an authenticated user to craft a request that results in remote code execution (RCE). The following versions of GitLab are affected:
- 14.0 (fixed in v14.10.5)
- 15.0 (fixed in v15.0.4)
- 15.1 (fixed in v15.1.1)
It is important to understand that for this exploit to be successful, an attacker must have a valid login to the GitLab service. The default service allows users to sign up and create an account using their credentials. Additionally, an admin must explicitly disable the “Require admin approval for new sign-ups” setting for the user to obtain an account without approval from an administrator first.
While it may sound implausible that an attacker could trick an administrator into approving such a request, it is feasible. A remote user can still leverage the attack on systems where the credentials have been cracked, stolen, leaked, or obtained legally. A user can obtain shell-level access to the underlying host running the GitLab service if the attack is successful, allowing more permissive movement inside victim resources.
Identifying GitLab Instances
Using the same methods to identify GitLab versions for CVE-2021-22205, we determined that certain filenames found in the HTTP response body could be associated with specific versions of GitLab Server. In short, whenever a new build is tagged, along with many other events, GitLab’s Continuous Integration (CI) system will kick off a job that compiles static assets. This job results in some files having a unique file extension that can loosely map the running software to the original version.
For example, the file “public/assets/application.css” seems to have a uniquely generated filename for every minor release of the software, which includes a 64-byte ASCII-HEX encoded string appended to the end of the filename.
In our analysis of this specific vulnerability, we have found the following filenames in the HTTP response body that can map to a particular major and minor version of GitLab Server:
Filename (found in the HTTP response body)
|
Mapped Version |
application-90abf7746df5cb82bca9949de6f512de7cb10bec97d3f5103299a9ce38d5b159.css |
14.0.* |
application-5cd37ee959b5338b5fb48eafc6c7290ca1fa60e653292304102cc19a16cc25e4.css |
14.1.* |
application-4f233d907f30a050ca7e40fbd91742d444d28e50691c51b742714df8181bf4e7.css |
14.2.[0-5] |
application-57e83f1a3cf7c0fe3cf2357802306688dab60cf6a30d00e14e67826070db92de.css |
14.2.[6-7] |
application-a8bf3d1210afa873d9b9af583e944bdbf5ac7c8a63f6eccc3d6795802bd380d2.css |
14.3.[0-3] |
application-ba74062de4171df6109c4c96da1ebe2b538bb6cc7cd55867cbdfba44777700e1.css |
14.3.[4-6] |
application-50d9206410f00bb00cc8f95865ab291c718e7a026e7fdc1fc9db0480586c4bc9.css |
14.4.0 |
application-775f130d36e9eb14cb67c6a63551511b87f78944cebcf6cdddb78292030341df.css |
14.4.[1-5] |
application-1832611738f1e31dd00a8293bbf90fce9811b3eea5b21798a63890dbc51769c8.css |
14.5.[0-4] |
application-8b78708916f28aa9e54dacf9c9c08d720837ce78d8260c36c0f828612567d353.css |
14.6.[0-3] |
application-cfa6748598b5e507db0e53906a7639e2c197a53cb57da58b0a20ed087cc0b9d5.css |
14.7.[0-7] |
application-1d840f0c4634c8813d3056f26cbab7a685d544050360a611a9df0b42371f4d98.css |
14.8.[0-6] |
application-003236d7e2c5f1f035dc8b67026d7583ee198b568932acd8faeac18cec673dfa.css |
14.9.[0-4] |
application-739a920f5840de93f944ec86c5a181d0205f1d9e679a4df1b9bf5b0882ab848a.css |
14.10.* |
application-1062bbba2e9b04e360569154a8df8705a75d9e17de1a3a9acd5bd20f000fec8b.css |
15.0.[0-1] |
application-a743f974bacea01ccc609dcb79247598bd2896f64377ce4a9f9d0333ab7b274e.css |
15.0.[2-4] |
application-7d0792b17e1d2ccac7c6820dda1b54020b294006d7867b7d78a05060220a0213.css |
15.1.* |
There are some overlaps in what we can identify and what is and is not vulnerable; for example, the file associated with v14.10.1 (a vulnerable version of GitLab) and v.14.10.5 (the fixed version) have the same filename. This overlap is also the case for v15.0.2 and v15.0.3, which have the same filename as the fixed version v15.0.4. And finally, version 15.1.0 has the same filename as the fixed version (v15.1.1).
At the time of writing (July 24th, 2022), Censys has observed 17,828 hosts with an associated version that may be vulnerable to this attack (excluding v14.10 hosts due to the version overlap). Of those hosts, only 6,759 have new account creation enabled. Unfortunately, Censys cannot validate whether these hosts require admin approval for new sign-ups. Still, given that this setting is the default, there is a high likelihood that approval is required.
Country |
Hosts |
China |
3,646 |
United States |
452 |
South Korea |
447 |
Germany |
391 |
Russia |
280 |
Geographically, most hosts running a matching version of GitLab with account creation enabled are in China, with 3,646 hosts. The United States is trailing with 452 hosts, closely followed by South Korea with only 447 hosts.
To help the general community monitor these vulnerabilities, Censys has created a public GitLab-specific interactive dashboard tracking both CVE-2022-2185 and CVE-2021-22205, updated every 24 hours. With this, users can filter various fields related to GitLab (including whether to display statistics on GitLab servers with open account creation). Censys will add new features and statistics in the upcoming days.
Vulnerability Details
For more details about the actual vulnerability, a researcher at Star Labs has written a very extensive analysis of this particular bug which references some of the original work done by a bounty hunter named Vakzz on Hackerone.
What do I do about it?
- Upgrade to GitLab v14.10.5, v15.0.4, or v15.1.1.
- Censys ASM customers now have access to a new risk that identifies potentially vulnerable GitLab services.
- At the very least, an administrator should disable the new account creation feature under the administration UI -> Settings -> General -> “Sign-up restrictions” and unselect the option “Sign-up enabled.”