GitLab-E-Mail-Adressen: Angreifer können Code einschleusen

Manche Entwickler veröffentlichen private GitLab-E-Mail-Adressen in READMEs, Beitragsrichtlinien und Support-Seiten, um Fehlermeldungen zu sammeln. Nach Angaben von Forschern des Anwendungssicherheitsunternehmens Aikido enthalten diese Adressen ein Zugangsmerkmal, mit dem Angreifer auf GitLab im Namen des Entwicklers handeln können, dem die Adresse gehört.

Die Adressen stammen aus einer eingebauten GitLab-Funktion namens „Email work item to this project“. GitLab erzeugt sie automatisch. Schickt jemand eine Nachricht an eine dieser Adressen, macht GitLab aus der E-Mail ein Issue oder eine Aufgabe im Projekt.

Das Problem: Jede Adresse enthält ein langlebiges Token, das an das Konto des Entwicklers gebunden ist. Diese Zeichenfolge dient als Zugangsmerkmal, um per E-Mail Arbeitselemente anzulegen.

Ein Token, versteckt in der Adresse

Jede private Adresse dieser Art enthält eine „glimt-“-Zeichenfolge, die Zugriff auf das Projekt gewährt. Dieselbe Zeichenfolge steckt in allen vergleichbaren Adressen, die für dieses Projekt erzeugt werden.

Aikido fand heraus, dass sich die Adresse nicht auf Issues beschränkt. „Ändert man das Suffix -issue in der E-Mail-Adresse zu -merge-request, öffnet GitLab einen Merge-Request“, so die Forscher.

Außerdem prüft GitLab nicht, wer die Nachricht geschickt hat. „Grundsätzlich würde eine Prüfung, ob die Absenderadresse mit der E-Mail-Adresse des Token-Inhabers übereinstimmt, eine zusätzliche Schutzebene schaffen, aber GitLab macht das nicht (erwägt es inzwischen aber)“, erklärten die Forscher. „Jedes beliebige Postfach im Internet kann an diese Adresse schreiben, und GitLab verarbeitet die Nachricht so, als käme sie vom Inhaber des Tokens.“

Die Tests von Aikido zeigten zudem, dass die Methode Beschränkungen nach IP-Adressen umgeht.

Was ein Angreifer tun kann, hängt von den Berechtigungen des Kontos hinter dem Token ab. Laut Aikido ließe sich ein kompromittiertes Konto nutzen, um:

• Code in geschützte Branches privater Repositories zu pushen
• Quellcode zu stehlen
• in CI/CD-Variablen hinterlegte Geheimnisse abzugreifen
• vertrauliche Issues zu lesen

Die Berechtigungen des Kontos lassen sich dabei nicht umgehen. Ein Angreifer braucht außerdem Pfad und ID des Zielprojekts. Bei öffentlichen Projekten sind beide leicht zu finden. Bei privaten Projekten lässt sich die ID per Brute Force ermitteln, der Pfad müsste aber durchgesickert sein.

Absichtlich veröffentlichte Adressen

An einem einzigen Nachmittag fand Aikido ein Dutzend aktiver GitLab-Adressen für eingehende E-Mails in öffentlicher Dokumentation. Die Forscher zufolge haben die Maintainer sie bewusst dort eingetragen, damit Nutzer Fehlermeldungen schicken können.

Mehrere dieser Adressen gehörten zu beliebten Open-Source-Projekten. „Einige gehörten zu sehr beliebten Open-Source-Projekten“, stellten die Forscher fest. Bei Projekten mit großer Nutzerbasis entsteht so ein Risiko für die Lieferkette.

GitLabs eigene Dokumentation bezeichnet die Adressen als privat und „nur für Sie erzeugt“. Sie warnt: „Behalten Sie sie für sich, denn jeder, der sie kennt, kann in Ihrem Namen Issues oder Merge-Requests anlegen. Wenn Sie vermuten, dass diese private E-Mail-Adresse durchgesickert ist, setzen Sie das Token sofort zurück.“

GitLabs Reaktion

Aikido meldete das Problem im Mai über die Bug-Bounty-Plattform HackerOne an GitLab. GitLab schloss die Meldung als „beabsichtigtes Verhalten“.

Im Juni schickte Aikido eine zweite Meldung. Danach nahm GitLab mehrere Änderungen vor:

• die Benutzeroberfläche erwähnt jetzt Merge-Requests
• falsche Angaben dazu, auf welche Daten das Token zugreifen kann, wurden entfernt
• die Dokumentation weist nun darauf hin, dass eingehende E-Mails IP-Beschränkungen umgehen

Die Forscher raten Maintainern, diese Adressen nicht mehr in öffentlicher Dokumentation zu veröffentlichen. Wer das in der Vergangenheit getan hat, sollte die Tokens der betroffenen Projekte zurücksetzen.

Unsere Einschätzung

Bei diesem Fall geht es weniger um einen klassischen Softwarefehler als um eine Komfortfunktion, deren Risiken leicht zu übersehen waren. GitLab hat Nutzer zwar gewarnt, die Adressen geheim zu halten, doch Maintainer haben sie trotzdem veröffentlicht und offenbar wie gewöhnliche Support-Postfächer behandelt. Dass dieselbe Adresse auch Merge-Requests öffnen konnte, war nicht klar dokumentiert, bis Aikido das Thema ein zweites Mal ansprach.

Das passt zu einem größeren Muster, bei dem öffentliche Entwicklerdokumentation zum Einfallstor für Angriffe wird. In CI/CD-Pipelines hinterlegte Geheimnisse sind für Angreifer wertvoll, wie frühere Fälle zeigen, etwa die von Ransomware-Banden ausgenutzte TeamCity-Lücke. Ein Token, das über eine E-Mail-Adresse einen solchen Zugriff gewährt, verdient dieselbe Sorgfalt wie ein API-Schlüssel.

Für Leser, die Projekte auf GitLab betreuen, heißt der praktische Schritt: READMEs, Beitragsrichtlinien und Support-Seiten nach Adressen für eingehende E-Mails durchsuchen und alle offengelegten Tokens zurücksetzen. Es lohnt sich zu beobachten, ob GitLab die Prüfung der Absenderadresse tatsächlich umsetzt. Laut Aikido erwägt das Unternehmen dies, und es würde die offensichtlichste Lücke schließen. Bis dahin sollte man sicherheitshalber davon ausgehen, dass jede veröffentlichte Adresse dieser Art bereits gefunden wurde.