GitLab-Passwort-Reset-Bug gefährdet mehr als 5.300 Server

 (scmagazine.com)
1 Punkte von GN⁺ 2024-01-29 | 1 Kommentare | Auf WhatsApp teilen
  • Die GitLab-Schwachstelle CVE-2023-7028 ist rund zwei Wochen nach Veröffentlichung des Patches weltweit noch auf 5.379 Servern vorhanden und könnte zur Übernahme von Entwicklerkonten aus der Ferne führen
  • Das Problem liegt im Passwort-Reset-Ablauf des Login-Systems: Angreifer können bewirken, dass ein Reset-Link ohne Interaktion des Opfers an ihre eigene nicht verifizierte E-Mail-Adresse gesendet wird
  • GitLab veröffentlichte die Schwachstelle mit CVSS-Wert 10 am 11. Januar 2024 und stellte Sicherheitsupdates für 16.5.6, 16.6.4, 16.7.2 sowie die Backport-Versionen 16.1.6 bis 16.4.5 bereit
  • Die Shadowserver Foundation entdeckte am 23. Januar 5.379 verwundbare Instanzen; die meisten davon befanden sich in den USA (964) und Deutschland (730). Am 24. Januar sank die Zahl auf 4.652
  • Betreiber von self-managed GitLab Community Edition und Enterprise Edition sollten ihre Logs auf Reset-Anfragen in Form von Arrays mit mehreren E-Mail-Adressen prüfen und 2FA aktivieren, um das Risiko einer Kontoübernahme zu senken

Risiko von CVE-2023-7028

  • CVE-2023-7028 ist eine Schwachstelle im GitLab-Login-System, die auf ungepatchten GitLab-Servern zur Übernahme von Konten aus der Ferne führen kann
  • GitLab hat die Schwachstelle am 11. Januar 2024 erstmals offengelegt und gepatcht
  • Der CVSS-Wert der Schwachstelle beträgt 10 und entspricht damit der höchsten Kritikalität
  • Angreifer können mit speziell präparierten HTTP-Anfragen ohne Interaktion des Opfers eine E-Mail zum Zurücksetzen des Passworts an ihre eigene nicht verifizierte E-Mail-Adresse senden lassen
  • Ein Forscher, der mit GitLab Community Edition 16.6.1 testete, bewertete CVE-2023-7028 auf AttackerKB als „sehr effektiv und leicht auszunutzen“

Betroffene Versionen und Patches

  • GitLab stellte für die folgenden Versionen Sicherheitsupdates bereit
    • 16.5.6
    • 16.6.4
    • 16.7.2
  • Die Patches wurden auch auf die folgenden Versionen zurückportiert
    • 16.1.6
    • 16.2.9
    • 16.3.7
    • 16.4.5

Ergebnisse der Shadowserver-Erkennung

  • Die Shadowserver Foundation entdeckte am 23. Januar, rund zwei Wochen nach Veröffentlichung des Patches, weltweit 5.379 verwundbare GitLab-Instanzen
  • Nach Ländern gab es die meisten verwundbaren Instanzen in den USA und Deutschland
    • USA: 964
    • Deutschland: 730
  • Am 24. Januar sank die Zahl der verwundbaren Instanzen im Shadowserver-Dashboard auf 4.652
  • Shadowserver bestätigte, dass der Rückgang an sich positiv sei, aber mehr Zeit nötig sei, um zu beurteilen, ob es sich um einen tatsächlichen Trend oder um eine vorübergehende Schwankung beim Scannen handelt

So prüft man auf Indicators of Compromise

  • Kunden mit self-managed GitLab Community Edition und GitLab Enterprise Edition sollten ihre Logs auf Spuren einer Ausnutzung von CVE-2023-7028 prüfen
  • Die zu prüfenden Logs und Bedingungen sind folgende
    • gitlab-rails/production_json.log: HTTP-Anfragen an den Pfad /users/password, bei denen params.value.email ein JSON-Array mit mehreren E-Mail-Adressen ist
    • gitlabs-rails/audit_json.log: Fälle, in denen meta.caller.id PasswordsController#create ist und target_Details ein JSON-Array mit mehreren E-Mail-Adressen ist

Auswirkungen auf GitLab.com, GitLab Dedicated und 2FA

  • GitLab erklärte, keine Fälle entdeckt zu haben, in denen dieser Bug auf GitLab.com- oder GitLab Dedicated-Instanzen ausgenutzt wurde
  • Kunden wird empfohlen, 2FA zu aktivieren
  • 2FA verhindert zwar eine Kontoübernahme über CVE-2023-7028, auf ungepatchten Instanzen können Angreifer jedoch weiterhin das Passwort zurücksetzen und Nutzer aus ihren Konten aussperren

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-01-29
Meinungen auf Hacker News

  • Die Funktion, in Account-basierten Webapps E-Mail-Adressen mit einem Konto zu verknüpfen, finde ich wirklich beängstigend.
    Ich kenne die Vorgeschichte dieses Bugs nicht, aber das ist ein Bereich, den Pentester sofort anfassen, und es ist eine alte Fehlerklasse, die bis zu Schwachstellen in Standard-Unix-MTA-Implementierungen aus den frühen 2000ern zurückreicht, bei denen man Passwort-Reset-Mails an mehrere Adressen schicken lassen konnte.
    Bei GitLab sieht es so aus, als hätte ein funktionsreiches Web-Framework diese Angriffsfläche wiederbelebt. Normale HN-Leser, die neugierig geworden sind, sollten sich die Passwort-Reset-Funktion unbedingt ansehen, insbesondere die Logik zur E-Mail-Verknüpfung.
    Dass so ein Bug aufgetreten ist, obwohl das GitLab-Sicherheitsteam meines Wissens ziemlich gut ist, zeigt, wie schwer diese Bug-Klasse zu vermeiden ist.

    • Nach dem Verhalten, das in einem anderen Kommentar beschrieben wurde, wirkt dieser Bug sehr leicht vermeidbar.
      Mit einer statisch typisierten Sprache wäre er kaum entstanden, es sei denn, man hätte es absichtlich so gebaut, und im Code-Review wäre es so auffällig gewesen, dass man sich gefragt hätte, ob ein Kollege eine Backdoor einbauen will.
    • Ich finde nicht, dass man das GitLab-Sicherheitsteam als hervorragend bezeichnen kann.
      Die Funktion zum Verknüpfen sekundärer E-Mail-Adressen wurde erst vor Kurzem hinzugefügt und war keine schon immer vorhandene Funktion. Es wirkt also, als hätte man bei einer neuen Funktion mit Bezug zur Account-Sicherheit eine Abkürzung genommen, statt sie ordentlich auf Missbrauch zu testen.
      Außerdem gab es offenbar auch eine CVSS-9.6-CVE, bei der eine Integrationsfunktion Befehle mit den Rechten anderer Nutzer ausführen konnte.
      Von außen betrachtet scheint das Tempo der Feature-Auslieferung höher zu sein als das Tempo, in dem man sicher testen kann; vielleicht liegt das auch daran, dass die Monetarisierung schwierig ist.
      Aus Business-Sicht kann man das ein Stück weit verstehen, aber wenn der Kern einer selbst gehosteten Git-Lösung im Grunde Account-Management ist, können solche Sicherheitsprobleme das Geschäft selbst zum Einsturz bringen.
    • Das ist eine merkwürdige Sichtweise.
      Woran sollte man es denn koppeln, wenn nicht an E-Mail? Ich habe über 20 Jahre lang Sites mit großer Nutzerbasis betrieben; anfangs haben wir Benutzernamen verwendet, und das war eine Katastrophe.
      Jeder kannte die Benutzernamen der anderen, wodurch Brute-Force-Angriffe auf Passwörter oder Reset-Versuche einfach waren.
      Das Problem ist nicht die Verwendung von E-Mail an sich, sondern dass man die Login- und Passwort-Wiederherstellungslogik übermäßig kompliziert macht, mit Abstraktionen um sich wirft, over-engineert und Code in sicherheitskritische Bereiche schiebt, ohne ihn ordentlich zu prüfen.
      Man sollte sich auch GitLabs Sicherheitsbilanz ansehen. Mehrmals im Jahr gab es kritische Exploits, wegen derer GitLab-Deployments dringend aktualisiert werden mussten; unter Sicherheitsgesichtspunkten war GitLab das schlechteste Produkt, das ich je verwendet habe.
    • Jedes Mal, wenn ich eine fehlgeleitete Passwort-Reset-Mail bekomme, mache ich mir Sorgen, ob jemand heimlich eine Recovery-E-Mail-Adresse außerhalb meiner Kontrolle zu meinem Konto hinzugefügt hat, um es zu übernehmen.
      Mir ist das bisher noch nicht passiert, aber wie dieser Fall zeigt, ist es leider absolut möglich.
    • Wie funktioniert dieser Exploit? Falls es einen gut zusammengefassten Artikel dazu gibt, wäre ich interessiert.

  • Wenn man den Teil der Rails-Codebasis sehen möchte, der zu diesem Exploit geführt hat: Der Fix-Commit ist hier:
    https://gitlab.com/gitlab-org/gitlab/-/commit/c571840ba2f0e9...

    • Das sieht eher nach anschließendem Refactoring aus als nach dem eigentlichen Fix.
      Der Fix scheint hier zu sein: https://gitlab.com/gitlab-org/gitlab/-/commit/abe79e4ec43798...
      recoverable.send_reset_password_instructions(to: email) if recoverable&.persisted? wurde zu recoverable.send_reset_password_instructions if recoverable&.persisted? geändert.
    • # Concern that overrides the Devise methods / # to send reset password instructions to any verified user email / module RecoverableByAnyEmail — heißt das, das war eine Funktion?
      Aber selbst in der korrigierten Version heißt es immer noch RecoverableByAnyEmail. Lesen Leute den Code um ihre Änderung herum nicht?
    • Ich kenne Ruby nicht gut; kann jemand erklären, wo der Fehler liegt?

  • Wir wurden ebenfalls von diesem Angriff getroffen und haben gesehen, dass er zusammen mit einem zweiten „Feature“ genutzt wurde, das die Exponierung noch vergrößert hat.
    Grundsätzlich muss man für diesen Angriff die E-Mail-Adresse des Nutzers kennen, dessen Passwort zurückgesetzt werden soll; es gibt aber eine versteckte E-Mail-Adresse, die an die GitLab-User-ID gebunden ist. Diese ID ist eine ab 1 hochzählende Zahl.
    ID 1 oder 2 ist mit hoher Wahrscheinlichkeit ein Admin und damit ein gutes Ziel; die E-Mail hat eine Form wie 1-user@mail.noreply...
    Das war wirklich übel und sah automatisiert aus. Bei uns hat 2FA gerettet.

  • Passwort-Reset per E-Mail ist selbst bei korrekter Implementierung ein Sicherheitsalbtraum.
    Noch schlimmer ist, dass man ihn bei den meisten Diensten nicht abschalten kann und die Umgehung normalerweise nur über Enterprise-SSO möglich ist.
    Manche Dienste erlauben das Hinterlegen einer Telefonnummer für SMS-Tokens, aber ich habe noch nie gesehen, dass sowohl E-Mail als auch SMS-Token verlangt werden.

    • Inwiefern hältst du das für einen Sicherheitsalbtraum?

  • Das erinnert mich an einen Bug, bei dem man Konten per Brute Force angreifen konnte, wenn man im Login-Formular ein Array von Passwörtern übergab.
    Es war ausgerechnet das schlampige Web-Interface eines Spam-Geräts, und ich weiß nicht, ob das Absicht war oder Code von einem PHP-Anfänger.
    Entdeckt hat es damals ein Nutzer, dessen Passwort Sonderzeichen enthielt, was zu der Zeit selten war.

    • Ruby on Rails behandelt ein Array als Parameter von .where(...) im ORM als OR-Bedingung zwischen den Array-Werten.
      Wenn der Code also etwa User.where(name: name, password: password) lautete, scheint mir gut möglich, dass so etwas passieren konnte.

  • Eine gute Erinnerung daran, interne Dienste wie GitLab hinter ein VPN zu stellen, sodass nur vertrauenswürdige Nutzer Zugriff haben

    • Ich verstehe wirklich nicht, warum man interne Versionsverwaltung und CI/CD ins öffentliche Internet stellt
      Genau für solche Zwecke gibt es VPNs
    • Stimmt, dadurch sind wir auch davongekommen, und es gab noch ein paar andere Schutzmaßnahmen
      Ich arbeite bei einem großen staatlichen Telekommunikationsanbieter, und die Netzwerkleute sind wirklich hervorragend. Sie sorgen dafür, dass die Serverleute keine Grenzen überschreiten
      Für bestimmte externe Projekte und Consultants haben wir GitLab zwar in gewissem Maße exponiert, aber frei aus dem Internet erreichbar ist es trotzdem nicht
      Die Nutzer werden außerdem im AD verwaltet, sodass es gar keine SMTP-Anbindung für Passwort-Zurücksetzungen gibt
      Allerdings müssen wir die 2FA-Pflicht noch verschärfen. Derzeit lassen wir jedes Projekt seine eigenen 2FA-Regeln festlegen

  • Ehrlich gesagt würde ich keinen internen Server ins öffentliche Internet stellen
    Es ist besser, den Zugriff nur per VPN zu erlauben und damit eine zweite Verteidigungslinie zu haben

    • Gerade etwas wie GitLab kann stark von externen Integrationen profitieren, die die GitLab-API aufrufen müssen
      Man könnte zwar genau diese Requests auf eine Allowlist setzen, aber das kann ziemlich mühsam werden
    • GitLab ist meine bevorzugte Wahl, um eine Code-Forge zu betreiben: git.drk.sc
      In Hochsicherheitsumgebungen stimme ich defensiveren Taktiken zu, aber ich finde, Software sollte so konzipiert sein, dass sie auch im öffentlichen Web bestehen kann
    • Stimmt, besonders wenn ein Unternehmen selbst gehostetes GitLab nutzt, sollte es immer hinter dem Firmen-VPN stehen

  • GitLab-Updates zu automatisieren ist wirklich einfach
    Schon eine Variante: Wenn man GitLab mit Docker+Compose betreibt, läuft es sehr stabil, und Tools wie Watchtower können tägliche Updates übernehmen
    Ich betreibe seit über 7 Jahren zwei GitLab-Server auf diese Weise und hatte keinerlei Probleme
    Wenn ich mich so umsehe, gibt es viel zu viele veraltete GitLab-Installationen; ich frage mich, was die Admins eigentlich machen

  • Wir sollten aufhören, so zu tun, als sei Ruby/Rails eine gute Wahl für Software, die sicher sein muss
    Ich verstehe, dass GitLab nun einmal so gebaut ist und man damit leben muss, aber künftig sollten wir nicht mehr so tun, als seien Sprachen und Frameworks, die Cleverness und versteckten Kontrollfluss priorisieren, besser als langweiligere Alternativen
    Falls ich übermäßig genervt klinge: Das liegt daran, dass ich mit einer Ruby-Codebasis im Produktivbetrieb arbeiten muss
    Weil jemand dachte, 17 Schichten Abstraktion würden den Code enorm erweiterbar machen, sehe ich genug Szenarien, in denen ähnliche Probleme nur darauf warten, ausgenutzt zu werden

    • Ich halte es für besser, Sprachen oder Frameworks zu meiden, die es dem Aufrufer erlauben, bestimmte Parameter als String oder als Array von Strings anzugeben
      Die Kosten dieses einen Fehlers dürften wahrscheinlich höher sein als der gesamte Nutzen, den man durch diese Funktion gewonnen hat

  • Noch eine Erinnerung daran, immer SSO und 2FA zu verwenden