Angreifer können Betriebssystembefehle aus der Ferne ausführen, indem sie diese GitLab-Sicherheitslücke ausnutzen

Es scheint, dass Angreifer immer einen Schritt voraus sind und ausgeklügelte Wege finden, um jeglichen Schutz zu umgehen.

In dieser sich ständig verändernden Online-Welt wird es immer wichtiger, Ihre sensiblen Daten zu schützen schwierig und wir sind hier, um Ihnen von einer weiteren Schwachstelle zu berichten, die aktiv ausgenutzt wird das wilde.

Eine weitere GitLab-Sicherheitslücke, die in freier Wildbahn aktiv ausgenutzt wird

Laut HN Security, wurden zwei verdächtige Benutzerkonten mit Administratorrechten auf dem im Internet exponierten GitLab CE-Server gefunden.

Offenbar wurden diese beiden Nutzer zwischen Juni und Juli 2021 mit zufällig aussehenden Nutzernamen registriert. Dies war möglich, da diese Version von GitLab CE standardmäßig eine Benutzerregistrierung ermöglicht.

Außerdem wird die bei der Registrierung angegebene E-Mail-Adresse standardmäßig nicht verifiziert. Das bedeutet, dass der neu angelegte Benutzer ohne weitere Schritte automatisch angemeldet wird.

Um die Sache noch komplizierter zu machen, werden absolut keine Benachrichtigungen an die Administratoren gesendet.

Einer der hochgeladenen Anhänge erregte die Aufmerksamkeit der Experten, also richteten sie ihren eigenen GitLab-Server ein und versuchten tatsächlich, das zu replizieren, was sie in freier Wildbahn beobachteten.

Ein kürzlich veröffentlichter Exploit für CVE-2021-22205 missbraucht die Upload-Funktionalität, um beliebige Betriebssystembefehle aus der Ferne auszuführen.

Die oben erwähnte Schwachstelle liegt in ExifTool, einem Open-Source-Tool zum Entfernen von Metadaten aus Bildern, das beim Parsen bestimmter Metadaten, die in das hochgeladene Bild eingebettet sind, fehlschlägt.

GitLab besteht aus mehreren Elementen wie Redis und Nginx. Dasjenige, das Uploads verarbeitet, heißt gitlab-workhorse, das wiederum ExifTool aufruft, bevor der endgültige Anhang an Rails übergeben wird.

Wenn man tiefer in die Logs eintaucht, gibt es ein wenig aufgedeckte Beweise für zwei fehlgeschlagene Uploads in den Workhorse-Logs.

Diese vom öffentlichen Exploit verwendete Nutzlast kann eine Reverse Shell ausführen, während die gegen unseren Kunden verwendete lediglich die Rechte der beiden zuvor registrierten Benutzer auf admin eskalierte.

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

Im Grunde entpuppte sich das, was wie eine Privilegieneskalations-Schwachstelle aussah, tatsächlich als RCE-Schwachstelle.

Wie Sicherheitsexperten erklärten, läuft der gesamte Exploit-Prozess auf nur zwei Anfragen hinaus.

Bei einer standardmäßigen GitLab-Installation (bis Version 13.10.2) muss die API nicht missbraucht werden, um ein gültiges Projekt zu finden, kein Problem zu öffnen und vor allem keine Authentifizierung erforderlich.

Alle im Artikel beschriebenen Schwachstellen (ExifTool, API-Missbrauch, Benutzerregistrierung usw.) sind zum Zeitpunkt der Erstellung nicht in der neuesten GitLab CE-Version vorhanden.

Wir raten jedoch dringend zur Vorsicht, wenn Sie mit allem umgehen, bei dem Sie online sind, damit Sie keine unglücklichen Erfahrungen machen.

Wie stehst du zu dieser Situation? Teilen Sie uns Ihre Meinung im Kommentarbereich unten mit.