Openbare GitLab-e-mailadressen laten aanvallers code pushen

Sommige ontwikkelaars zetten privé-e-mailadressen van GitLab in README's, bijdragerichtlijnen en supportpagina's om bugmeldingen binnen te krijgen. Volgens onderzoekers van applicatiebeveiligingsbedrijf Aikido bevatten die adressen een inloggegeven waarmee aanvallers op GitLab kunnen optreden als de ontwikkelaar aan wie het adres toebehoort.

De adressen komen van een ingebouwde GitLab-functie die "Email work item to this project" heet. GitLab maakt ze automatisch aan. Stuurt iemand een bericht naar zo'n adres, dan zet GitLab de e-mail om in een issue of taak binnen het project.

Het probleem is dat elk adres een token bevat dat lang geldig blijft en aan het account van de ontwikkelaar gekoppeld is. Die tekenreeks dient als inloggegeven om per e-mail werkitems aan te maken.

Een token verstopt in het adres

Elk privéadres van dit type bevat een "glimt-"-reeks die toegang geeft tot het project. Diezelfde reeks wordt gebruikt in alle vergelijkbare adressen die voor dat project worden aangemaakt.

Aikido ontdekte dat het adres niet beperkt blijft tot issues. "Verander het achtervoegsel -issue in het e-mailadres in -merge-request, en GitLab opent een merge request", aldus de onderzoekers.

GitLab controleert bovendien niet wie het bericht verstuurt. "In principe zou een controle of het afzenderadres overeenkomt met het e-mailadres van de tokeneigenaar een extra verdedigingslaag opleveren, maar GitLab doet dat niet (al overwegen ze het nu)", legden de onderzoekers uit. "Elke mailbox op internet kan naar dat adres sturen, en GitLab verwerkt het bericht als de eigenaar van het token."

Uit de tests van Aikido bleek ook dat de techniek IP-adresbeperkingen omzeilt.

Wat een aanvaller kan doen, hangt af van de rechten van het account achter het token. Volgens Aikido kan een gecompromitteerd account worden gebruikt om:

• code te pushen naar beschermde branches van privérepository's
• broncode te stelen
• geheimen te verzamelen die in CI/CD-variabelen zijn opgeslagen
• vertrouwelijke issues te lezen

De rechten van het account zijn niet te omzeilen. Een aanvaller heeft daarnaast het pad en de ID van het doelproject nodig. Bij openbare projecten zijn die allebei makkelijk te vinden. Bij privéprojecten kan de ID met brute force worden achterhaald, maar het pad zou dan moeten zijn uitgelekt.

Adressen bewust gepubliceerd

Op één middag vond Aikido een tiental actieve inkomende e-mailadressen van GitLab in openbare documentatie. Volgens de onderzoekers hadden beheerders die er bewust neergezet, zodat gebruikers bugmeldingen konden insturen.

Een aantal van die adressen hoorde bij populaire opensourceprojecten. "Een paar waren van zeer populaire opensourceprojecten", merkten de onderzoekers op. Bij projecten met een groot gebruikersbestand levert dat een risico voor de toeleveringsketen op.

De eigen documentatie van GitLab zegt dat de adressen privé zijn en "speciaal voor jou aangemaakt". Er staat ook een waarschuwing bij: "Houd het voor jezelf, want iedereen die het kent, kan issues of merge requests aanmaken alsof hij jou is. Vermoed je dat dit privé-e-mailadres is uitgelekt, reset het token dan onmiddellijk."

De reactie van GitLab

Aikido meldde het probleem in mei bij GitLab via bugbountyplatform HackerOne. GitLab sloot de melding af als "bedoeld gedrag".

In juni stuurde Aikido een tweede melding. Daarna voerde GitLab een aantal wijzigingen door:

• de gebruikersinterface noemt nu ook merge requests
• onjuiste uitspraken over welke gegevens het token kan benaderen zijn verwijderd
• de documentatie vermeldt nu dat inkomende e-mail IP-beperkingen omzeilt

De onderzoekers raden beheerders aan om deze adressen niet langer in openbare documentatie te zetten. Wie dat in het verleden wel heeft gedaan, moet de tokens voor de betreffende projecten resetten.

Onze analyse

Deze zaak draait minder om een klassieke softwarebug en meer om een gemaksfunctie waarvan de risico's makkelijk over het hoofd werden gezien. GitLab waarschuwde gebruikers de adressen privé te houden, maar beheerders publiceerden ze toch, kennelijk in de veronderstelling dat het gewone supportinboxen waren. Dat hetzelfde adres ook merge requests kon openen, stond pas duidelijk gedocumenteerd nadat Aikido er voor de tweede keer aan de bel had getrokken.

Het past in een breder patroon waarin openbare ontwikkelaarsdocumentatie een toegangspoort voor aanvallen wordt. Geheimen die in CI/CD-pipelines zijn opgeslagen, zijn waardevol voor aanvallers, zoals eerdere zaken lieten zien, bijvoorbeeld het TeamCity-lek dat door ransomwarebendes werd misbruikt. Een token dat via een e-mailadres zulke toegang geeft, verdient dezelfde zorg als een API-sleutel.

Voor lezers die projecten op GitLab beheren, is de praktische stap om README's, bijdragerichtlijnen en supportpagina's na te lopen op inkomende e-mailadressen en blootgestelde tokens te resetten. Het is de moeite waard om in de gaten te houden of GitLab daadwerkelijk het afzenderadres gaat controleren. Volgens Aikido overweegt het bedrijf dat, en daarmee zou het meest voor de hand liggende gat gedicht zijn. Tot die tijd kun je er het veiligst van uitgaan dat elk gepubliceerd adres van dit type al gevonden is.