Aikido-Forscher Joe Leon erklärt gegenüber Dark Reading, was als simple Funktion zum Anlegen von Issues begann, sei über die Jahre um privilegierte Fähigkeiten erweitert worden – etwa das Einreichen von Merge Requests und Patch-Dateien. Dokumentiert sei das zwar, die Risiken würden aber untertrieben dargestellt, insbesondere in der Benutzeroberfläche.
„Es wurde nicht klar kommuniziert, dass dort etwas Sensibles steckt, das nicht nur Issues erstellen, sondern auch Code einspielen kann. Und beim Einspielen von Code kann dieser potenziell in den Hauptzweig gelangen oder einen CI/CD-Job ausführen“, sagt Leon.
In der GitLab-Oberfläche wurde die Adresse als Werkzeug beschrieben, um Arbeitselemente wie Issues zu einem bestimmten Projekt hinzuzufügen – mit dem ausdrücklichen Hinweis, sie könne „nicht genutzt werden, um auf andere Daten zuzugreifen“. Das sei nachweislich falsch, so Aikido. „Die in der Adresse eingebettete Zugangsinformation lässt sich über alle öffentlichen und privaten Projekte hinweg wiederverwenden“, sagt Leon.
Technisch enthalten die Adressen eine Zeichenkette mit dem Präfix „glimt-“ (GitLab Incoming Mail Token). Das Token eines Nutzers ist für sämtliche öffentlichen und privaten Projekte identisch, auf die er Zugriff hat. Ist die Adresse eines öffentlichen Projekts bekannt, kann ein Angreifer den Projektpfad und die Projekt-ID in der Adresse abändern und so andere, private Projekte erreichen. IDs seien erratbar, merkt der Bericht an, allerdings müsse ein Projektname durchgesickert sein.
„Aber mir war nicht klar, dass mit dieser Zugangsinformation und einer bloßen Anpassung der E-Mail-Adresse jeder auch Code in meine privaten Projekte schieben kann. Das hat mich umgehauen“, sagt Leon.
Als zweiten Befund umging Leon IP-Beschränkungen: Er begrenzte ein privates Projekt auf eine einzelne, zufällige IP-Adresse, die ihm nicht gehörte. Das Klonen und der Zugriff über den Browser wurden daraufhin blockiert – E-Mails mit Merge Requests durchbrachen die Grenze dagegen problemlos.
Wie wenig Nutzern die Tragweite bewusst sein dürfte, zeigt eine „sehr unvollständige“ Suche über wenige Stunden: Leon fand ein Dutzend Eingangsadressen, die absichtlich in ReadMe- und Support-Dateien veröffentlicht worden waren, einige davon aus bekannten Open-Source-Projekten. „Ich bin sicher, es gibt viele weitere. Das waren die tief hängenden Früchte.“ Ein Missbrauch wäre zudem schwer nachweisbar: „Es ist nicht offensichtlich, dass es per E-Mail geschah. Man bräuchte Zugriff auf GitLabs Server – vorausgesetzt, diese Daten werden überhaupt erhoben.“
Aikido meldete die Ergebnisse über HackerOne an GitLab, das den Report als beabsichtigtes Verhalten schloss. Nach einer vertraulichen Nachfrage im GitLab-Repository passte das Unternehmen die Oberfläche an: Sie weist nun auf die Nutzung für Merge Requests hin, der Satz zum angeblich ausgeschlossenen Datenzugriff wurde entfernt. Auch die Dokumentation vermerkt inzwischen, dass die Adressen keinen IP-Beschränkungen unterliegen.
Leon wünscht sich als wirksamste Gegenmaßnahme, dass die Absenderadresse mit der des GitLab-Kontos übereinstimmen muss – Angreifer müssten dann das Postfach kompromittieren. „Das beseitigt im Grunde den allergrößten Teil des Problems.“ GitLab ziehe diese Änderung in Erwägung. Bis dahin rät Aikido Organisationen, die Tokens in ihren GitLab-E-Mail-Adressen vorsorglich zu rotieren und Entwicklungsumgebungen sowie Repositories wie bei anderen Geheimnissen nach solchen Adressen zu durchsuchen. Dark Reading bat GitLab um eine Stellungnahme; das Unternehmen antwortete bis Redaktionsschluss nicht.