Die betroffenen Adressen werden von GitLab automatisch erzeugt und sind pro Projekt und Nutzer eindeutig. Die enthaltene „glimt-“-Zeichenkette bleibt über alle für dasselbe Projekt generierten Adressen hinweg gleich und wirkt damit wie ein dauerhaftes Zugangsmerkmal.
Entscheidend ist, dass GitLab die Absenderadresse nicht prüft. „Grundsätzlich würde ein Abgleich der Absenderadresse mit der E-Mail-Adresse des Token-Inhabers eine zusätzliche Verteidigungsebene schaffen, aber GitLab macht das nicht – auch wenn man es inzwischen erwägt“, erklären die Forscher. „Jedes Postfach im Internet kann an diese Adresse senden, und GitLab verarbeitet die Nachricht als der Token-Inhaber.“ In Tests von Aikido umging der Weg über die eingehende E-Mail zudem bestehende IP-Beschränkungen.
Welchen Zugriff ein Angreifer tatsächlich erlangt, hängt von den Rechten des jeweiligen Kontos ab – möglich sind Codeänderungen, das Auslösen von CI/CD-Läufen sowie Zugriff auf private Repositories und Geheimnisse. Diese Berechtigungsgrenze lässt sich laut Aikido nicht umgehen. Zusätzlich benötigt ein Angreifer den Pfad und die ID des Zielprojekts. Bei öffentlichen Projekten sind beide Angaben frei verfügbar; bei privaten Projekten lässt sich die ID durch Ausprobieren ermitteln, der Pfad müsste jedoch anderweitig bekannt werden.
GitLab selbst weist in seiner Dokumentation auf die Tragweite hin: Die Adressen seien privat und „nur für dich erzeugt“. „Behalte sie für dich, denn jeder, der sie kennt, kann Issues oder Merge Requests anlegen, als wäre er du. Wenn du vermutest, dass diese private E-Mail-Adresse durchgesickert ist, setze den Token sofort zurück“, heißt es in der Warnung.
An der Praxis ändert das wenig: Innerhalb eines einzigen Nachmittags stießen die Aikido-Forscher auf ein Dutzend aktiver GitLab-Eingangsadressen in öffentlichen READMEs, Beitragsleitfäden und Support-Seiten. Die Adressen waren dort absichtlich veröffentlicht worden, damit Nutzer Fehlerberichte an die Maintainer schicken können. „Einige gehörten zu sehr populären Open-Source-Projekten“, so die Forscher – woraus sich Risiken für die Software-Lieferkette entsprechend großer Nutzerbasen ergeben.
Aikido meldete das Problem im Mai über HackerOne an GitLab; der Bericht wurde als „beabsichtigtes Verhalten“ geschlossen. Nach einer zweiten Meldung im Juni passte GitLab immerhin die Benutzeroberfläche an: Dort werden nun auch Merge Requests erwähnt, falsche Angaben zum Zugriff auf Token-Daten wurden entfernt, und es ist dokumentiert, dass eingehende E-Mails IP-Beschränkungen umgehen.
Den Forschern zufolge sollten Projektbetreuer solche Adressen nicht länger freiwillig in öffentlicher Dokumentation veröffentlichen und die Token für Projekte zurücksetzen, die in der Vergangenheit auf diese Weise offengelegt wurden.