GitLab-Passwort-Reset-Bug bringt mehr als 5.300 Server in Gefahr

 (scmagazine.com)
1 Punkte von GN⁺ 2024-01-29 | 1 Kommentare | Auf WhatsApp teilen

Ungepatchte Server mit der GitLab-Sicherheitslücke CVE-2023-7028

  • Die schwerwiegende GitLab-Sicherheitslücke CVE-2023-7028 war Stand Dienstag auf mehr als 5.300 Servern noch nicht gepatcht, wodurch eine Remote-Übernahme von Konten von Softwareentwicklern möglich ist.
  • Der Bug erhielt den maximalen CVSS-Score von 10 und wurde von GitLab am 11. Januar erstmals offengelegt und gepatcht.
  • Aufgrund einer Schwachstelle im GitLab-Login-System können Angreifer Passwort-Reset-Links ohne Interaktion des Opfers an nicht authentifizierte E-Mail-Adressen senden.

Patch-Informationen und Ergebnisse von Schwachstellentests

  • Sicherheitsupdates wurden für die GitLab-Versionen 16.5.6, 16.6.4 und 16.7.2 veröffentlicht und außerdem auf die Versionen 16.1.6, 16.2.9, 16.3.7 und 16.4.5 zurückportiert.
  • Ein Forscher testete den Bug auf GitLab Community Edition Version 16.6.1 und teilte AttackerKB mit, er sei „sehr effektiv und leicht auszunutzen“.

Erkennung verwundbarer Instanzen und rückläufiger Trend

  • Fast zwei Wochen nachdem Patches verfügbar wurden, erkannte die Shadowserver Foundation weltweit 5.379 verwundbare GitLab-Instanzen.
  • Die USA und Deutschland hatten mit 964 beziehungsweise 730 die meisten verwundbaren Instanzen.
  • Das Dashboard-Tool von Shadowserver zeigte am 24. Januar, dass die Zahl verwundbarer Instanzen auf 4.652 gesunken war.
  • Ein Sprecher von Shadowserver erklärte gegenüber SC Media, dass der Rückgang verwundbarer Instanzen zwar eine positive Entwicklung sei, aber mehr Zeit nötig sei, um zu beurteilen, ob es sich um einen Trend oder nur um eine Schwankung handelt.

Kompromittierungsindikatoren für GitLab CVE-2023-7028

  • GitLab-Kunden mit selbstverwalteten Instanzen von GitLab Community Edition und GitLab Enterprise Edition sollten ihre Logs prüfen, um festzustellen, ob CVE-2023-7028 ausgenutzt wurde.
  • In gitlab-rails/production_json.log sollten HTTP-Anfragen an den Pfad /users/password überprüft werden, insbesondere ob params.value.email als JSON-Array mit mehreren E-Mail-Adressen aufgebaut ist.
  • In gitlabs-rails/audit_json.log sollten Einträge geprüft werden, bei denen meta.caller.id den Wert PasswordsController#create hat und target_Details als JSON-Array mit mehreren E-Mail-Adressen aufgebaut ist.
  • Auf GitLab.com oder dedizierten GitLab-Instanzen wurde keine Ausnutzung dieses Bugs festgestellt.
  • GitLab empfiehlt außerdem, die Zwei-Faktor-Authentifizierung (2FA) zu aktivieren. Diese verhindert zwar Kontoübernahmen über CVE-2023-7028, aber Nutzer ungepatchter Instanzen laufen weiterhin Gefahr, aus ihren Konten ausgesperrt zu werden, wenn Angreifer die Schwachstelle zum Zurücksetzen des Passworts ausnutzen.

Meinung von GN⁺

  • Dieser Artikel liefert wichtige Informationen zu einer schwerwiegenden Sicherheitslücke in GitLab. CVE-2023-7028 kann eine direkte Bedrohung für die Sicherheit von Konten von Softwareentwicklern darstellen und erfordert angemessene Maßnahmen.
  • Obwohl ein Patch bereitgestellt wurde, sind weltweit noch viele Server verwundbar, was die Bedeutung von Sicherheitsbewusstsein und zeitnahen Updates unterstreicht.
  • Die Bedeutung der Zwei-Faktor-Authentifizierung (2FA) wird hervorgehoben, indem Nutzern empfohlen wird, zusätzliche Sicherheitsmaßnahmen zu nutzen, was das Bewusstsein für IT-Sicherheit stärkt.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-01-29
Hacker-News-Kommentare

  • "Ich möchte auf die Gefahren der Funktion hinweisen, die in kontobasierten Web-Apps eine E-Mail-Adresse mit einem Konto verknüpft. Das ist eines der Dinge, die Pentester sofort zu manipulieren versuchen, und es gibt seit den frühen 2000er-Jahren bekannte Schwachstellen in diesem Bereich. Bei GitLab ist so ein Problem erneut aufgetreten. GitLab hat ein hervorragendes Security-Team, aber solche Bugs scheinen schwer zu vermeiden zu sein. Wenn sich normale Hacker-News-Leser für dieses Thema interessieren, sollten sie ihre eigene Passwort-Zurücksetzen-Funktion prüfen, insbesondere die Logik zur E-Mail-Verknüpfung."

  • "Ich teile den Commit-Link, in dem diese Schwachstelle im Rails-Codebestand gefunden wurde: GitLab-Commit-Link"

  • "Ich war von diesem Bug betroffen. Für den Angriff muss man die E-Mail-Adresse des Benutzers kennen, aber es gibt versteckte E-Mail-Adressen, die mit der GitLab-Benutzer-ID verknüpft sind, also Zahlen, die ab 1 hochzählen. ID 1 oder 2 ist wahrscheinlich ein Administrator und damit ein gutes Ziel. Das E-Mail-Format sieht so aus: '1-user@mail.noreply.<gitlabhost>'. Es sah nach einem automatisierten Angriff aus, und 2FA hat uns gerettet."

  • "Das Zurücksetzen von Passwörtern per E-Mail ist selbst bei korrekter Implementierung ein Security-Albtraum. Bei den meisten Diensten kann man diese Funktion nicht deaktivieren, und die Alternative ist oft nur Enterprise-SSO. Bei manchen Diensten kann man eine Telefonnummer für SMS-Tokens hinterlegen, aber ich habe noch nie eine Option gesehen, bei der sowohl E-Mail als auch SMS-Token erforderlich sind."

  • "Ich habe einmal einen Bug gefunden, mit dem man ein Konto per Brute Force angreifen konnte, indem man im Login-Formular ein Passwort-Array eingab. Es war eine primitive Web-Oberfläche für eine Spam-Appliance, und ich bin mir nicht sicher, ob das beabsichtigt war oder ob ein PHP-Anfänger den Code geschrieben hatte. Entdeckt wurde es von einem Benutzer, der damals ein Passwort mit Sonderzeichen verwendete."

  • "Das erinnert daran, dass interne Dienste wie GitLab am besten hinter einem VPN betrieben werden sollten, auf das nur vertrauenswürdige Benutzer zugreifen können."

  • "GitLab-Updates zu automatisieren ist sehr einfach. Man kann GitLab mit Docker+Compose betreiben und es über Watchtower oder Ähnliches täglich aktualisieren. Ich betreibe seit mehr als sieben Jahren auf diese Weise GitLab-Server und hatte keine Probleme. Wenn man sich umschaut, sieht man viele GitLabs mit veralteten Versionen — was machen die Administratoren eigentlich?"

  • "Ich habe den Grundsatz, keinerlei interne Server dem öffentlichen Internet auszusetzen. Sie sind nur über VPN erreichbar, wodurch eine zweite Verteidigungslinie entsteht."

  • "Noch eine Erinnerung daran, immer SSO zu verwenden und 2FA nicht zu vergessen."

  • "Wir sollten uns von der Vorstellung verabschieden, dass Ruby/Rails eine geeignete Wahl für Software ist, die sicher sein muss. Ich verstehe, dass GitLab damit arbeiten muss, aber wir sollten künftig anerkennen, dass etwas Einfacheres besser ist als Sprachen und Frameworks, die intelligente und versteckte Kontrollflüsse bevorzugen. Ich arbeite an einem produktiven Ruby-Codebestand und kann klar sehen, wie ähnliche Probleme entstehen können, wenn jemand glaubt, mehrere Abstraktionsebenen hätten den Code besonders gut erweiterbar gemacht."