• Attackers simply won't relent and find new ingenious ways to infiltrate our personal space.
• Security experts exposed another GitLab vulnerability that is actively exploited in the wild.
• This was possible because this version of GitLab CE actually allows user registration by default.
• Third parties can abuse the upload functionality and remotely execute arbitrary OS commands.

It seems that no matter at what lengths companies are willing to go to secure their products, attackers are always one step ahead and find ingenious ways to bypass all protection.

In this everchanging online world, keeping your sensitive data secured is getting increasingly difficult and we’re here to tell you about another vulnerability that’s actively being exploited in the wild.

Another GitLab vulnerability actively exploited in the wild

According to HN Security, two suspicious user accounts with admin rights were found on the Internet-exposed GitLab CE server.

Apparently, these two users were registered between June and July 2021, with random-looking usernames. This was possible because this version of GitLab CE allows user registration by default.

Furthermore, the email address provided during registration isn’t verified by default. This means that the newly created user is automatically logged on without any further steps.

To make matters more complicated, absolutely no notifications are sent to the administrators.

One of the uploaded attachments caught the experts’ attention, so they set up their own GitLab server and actually attempted to replicate what they observed in the wild.

A recently released exploit for CVE-2021-22205 abuses the upload functionality in order to remotely execute arbitrary OS commands.

The above-mentioned vulnerability resides in ExifTool, an open-source tool used to remove metadata from images, which fails in parsing certain metadata embedded in the uploaded image.

GitLab is composed of multiple elements, such as Redis and Nginx. The one that handles uploads is called gitlab-workhorse, which in turn calls ExifTool before passing the final attachment to Rails.

Digging deeper into the logs a little uncovered evidence of two failed uploads within the Workhorse logs.

This payload used by the public exploit can execute a reverse shell, whereas the one used against our customer simply escalated the rights of the two previously registered users to admin.

echo 'user = User.find_by(username: "czxvcxbxcvbnvcxvbxv");user.admin="true";user.save!' | gitlab-rails console /usr/bin/echo dXNlciA9IFVzZXIuZmluZF9ieSh1c2VybmFtZTogImN6eHZjeGJ4Y3ZibnZjeHZieHYiKTt1c2VyLmFkbWluPSJ0cnVlIjt1c2VyLnNhdmUh | base64 -d | /usr/bin/gitlab-rails console

So, basically, what appeared to be a privilege escalation vulnerability actually turned out to be an RCE vulnerability.

As security experts explained the whole exploiting process boils down to just two requests.

On a default GitLab installation (up until version 13.10.2) there’s no need to abuse the API to find a valid project, no need to open an issue, and most importantly no need to authenticate.

All the vulnerabilities described in the article (ExifTool, API abuse, User registration, etc.) are not present in the latest GitLab CE version at the time of writing.

However, we strongly advise caution when dealing with anything that involves you being online so that you don’t have any unfortunate experiences.

What’s your take on this situation? Share your opinion with us in the comments section below.

ncG1vNJzZmivmaOxsMPSq5ypp6Kpe6S7zGieoqyclq9usdeina2nn6F6t8HLp5yrmZKeuarA2Gg%3D