Das Anwendungssicherheitsunternehmen Aikido stellte fest, dass die E-Mail-Adressen der GitLab-Funktion Email work item to this project gelegentlich in README-Dateien, Beitragsleitfäden und öffentlichen Supportseiten erscheinen. Diese Adressen enthalten ein langlebiges Token, das mit dem Konto des Entwicklers verknüpft ist. Ihre Veröffentlichung kommt daher eher der Offenlegung von Zugangsdaten gleich als der Veröffentlichung eines gewöhnlichen Kanals zum Empfang von Fehlerberichten.
Die Funktion ermöglicht es jeder Stelle, die eine Nachricht an die Adresse sendet, ein Issue oder eine Aufgabe in einem GitLab-Projekt zu erstellen. Die von Aikido durchgeführten Tests zeigten jedoch, dass ein Angreifer das Suffix -issue in der Adresse in -merge-request ändern kann, woraufhin GitLab die Nachricht akzeptiert und einen Merge Request im Projekt erstellt.
Was kann praktisch geschehen?
Das Ausmaß der Auswirkungen hängt von den Berechtigungen des mit dem Token verknüpften Kontos ab. Zu den möglichen Folgen gehören das Einbringen von Codeänderungen, das Ausführen von CI/CD-Jobs, der Zugriff auf private Repositories oder das Auslesen von in CI/CD-Variablen gespeicherten Geheimnissen sowie der Einblick in vertrauliche Issues. In Open-Source-Projekten könnten offengelegte Adressen zu einer Gefahr für die Lieferkette werden, wenn sie genutzt werden, um Änderungen in Projekte einzubringen, von denen eine große Zahl von Nutzern abhängig ist.
Die Aikido-Forscher fanden innerhalb eines einzigen Nachmittags etwa 12 aktive Adressen, die in öffentlichen Dokumenten veröffentlicht waren, und erklärten, dass einige davon zu weit verbreiteten Open-Source-Projekten gehörten. Der Angreifer muss die E-Mail-Adresse des Token-Inhabers nicht fälschen; GitLab verarbeitet die Nachricht so, als stamme sie vom Token-Inhaber. Außerdem zeigten die Tests, dass Beschränkungen von IP-Adressen umgangen werden konnten.
Grenzen der Ausnutzung und Verantwortung der Administratoren
Die Offenlegung der Adresse bedeutet nicht, dass die Berechtigungen des Kontos umgangen werden; die Benutzerberechtigungen bleiben eine grundlegende Einschränkung. Außerdem muss der Angreifer den Pfad und die Kennung des Projekts kennen. Diese Informationen sind bei öffentlichen Projekten verfügbar, während für den Angriff auf ein privates Projekt der Pfad durchgesickert sein muss, selbst wenn die Kennung durch Brute-Force erraten werden kann.
Die GitLab-Dokumentation selbst warnt davor, diese Adressen weiterzugeben, und beschreibt sie als privat und für den jeweiligen Benutzer generiert. Sie weist darauf hin, dass jeder, der sie kennt, Issues oder Merge Requests so erstellen kann, als wäre er der Inhaber. Die Plattform empfiehlt, das Token sofort zurückzusetzen, wenn der Verdacht besteht, dass es durchgesickert ist.
Was bedeutet das für Projekte?
Aikido meldete das Problem im Mai über HackerOne an GitLab, doch der Bericht wurde mit der Begründung geschlossen, das Verhalten sei beabsichtigt. Nach einer zweiten Meldung im Juni aktualisierte GitLab seine Oberfläche, um auf die Möglichkeit der Erstellung von Merge Requests hinzuweisen, entfernte ungenaue Aussagen über den Zugriff auf Tokendaten und dokumentierte, dass der Empfang von Nachrichten per E-Mail IP-Beschränkungen umgeht.
Der wichtigste praktische Schritt liegt bei den Projektadministratoren: Sie sollten diese Adressen aus öffentlichen Dokumenten entfernen und die Tokens von Projekten zurücksetzen, die zuvor veröffentlicht wurden. Offene Fragen betreffen, in welchem Umfang GitLab künftig die Übereinstimmung der Absenderadresse mit der E-Mail-Adresse des Token-Inhabers als zusätzliche Schutzschicht nutzen wird. Laut Aikido prüft die Plattform diesen Mechanismus derzeit.