Aanvallers die zijn gericht op gebruikers door middel van het kapen van sessies aanslagen op GitLab uitbuiten - de moderne web-based Git repository manager zijn gestopt in hun sporen als een bedrijf herstelt de bug.
Hijacking Bug en potentiële schade voor GitLab en gebruikers
“Als er was een succesvol exploiteren namens de aanvaller, de kwetsbaarheid in het systeem zou zijn begonnen een uitgebreide lijst met schadelijke activiteiten,” zegt Daniel Svartman die de bug in mei van dit jaar ontdekte terug. Echter, hij kon de informatie tot deze week niet bekendmaken na GitLab gepatcht de bug en gerustgesteld hun gebruikers het probleem is opgelost.
Als een aanvaller succesvol in hun poging om brute-force een account was, ze zouden zelf de mogelijkheid om het account te beheren verlenen, dump de code, het uitvoeren van updates van de jaarrekening, alsmede de opmerkelijke mogelijkheden van het stelen van uw persoonlijke informatie en gevoelige gegevens in de wil van nieuwe versies van software die unreleased zijn voor het publiek. Er zijn andere mogelijkheden, waardoor het uitvoeren van updates van de code kan de aanvaller in staat stellen om alle malware insluiten erin.
Svartman had gemerkt iets niet helemaal gelijk toen hij ontdekt dat zijn sessietoken was in zijn URL. Zo, alles wat hij moest doen was om Kopieer en plak de token meerdere malen en rond de website de toegang tot het dashboard van de GitLab veilig te stellen, Account Informatie, andere individuele en lopende projecten van de onderneming en zelfs code van de site.
Dit was niet de enige zorgwekkende factor dat er iets suggereerde was met de site. Na sessietokens blootgesteld zo openlijk, zichtbaar in de URL, is zorgwekkend genoeg, meer zo levendig het blootstellen van de bug zelf. Echter, Het was de tweede ontdekking Svartman dat zijn eerste waarneming bevestigd: GitLab lab maakt gebruik van persistente privé-sessie tokens die niet vervallen. Wat dit betekent is dat als een aanvaller in staat waren om beveiligde toegang tot sessietoken van een gebruiker, het zou niet vervallen. Dit is met name gunstig voor een aanvaller als een dergelijke techniek zou laten een aanval weken of maanden het podium na de informatie te hebben gestolen, het verlaten van het slachtoffer zich niet bewust en geen idee van de inbraak.
Een andere verdachte eigenschap die belangstelling Svartman's spiked was dat de tokens alleen waren 20 karakters lang, het verlaten van de vatbaar voor brute-forcing. Gezien de token aanhoudende aard en de toegang admin niveau van de aan gebruikers, was er geen twijfel over bestaan dat dit een dreigende gat in de beveiliging.
GitLab Fixes Hijacking Bug
Het is nog niet bekend hoe lang de kwetsbaarheid was gebleven blootgesteld aan gebruikers voordat het uiteindelijk werd vastgesteld. Echter, de onderzoeker wijst erop dat hij was niet de eerste persoon om te markeren en te GitLab gezien te hebben gebruikers de bespreking van de zelfde kwestie op de steun van het bedrijf forums brengen de kwestie.
Veiligheid Lead bij GitLab, Brian Neel, benadrukt dat het gebruik van privé-tokens van het bedrijf is niet het belangrijkste probleem hier en het is evenmin een probleem op zijn eigen. Hij ging over te kunnen uitweiden:
“Dit is niet iets dat direct kan worden benut. Het bestaan van private tokens wordt pas een probleem wanneer het wordt gecombineerd met een cross-site scripting of andere kwetsbaarheid. Over het algemeen, een rekening bij een privé-token is op geen enkel risico meer compromis dan wanneer de tokens niet bestond, tenzij een andere kwetsbaarheid wordt benut om de token te stelen. De meeste moderne web services ondersteunen het concept van een privé-token: AWS heeft toegang / geheime sleutels, GitHub heeft toegangstokens, Digital Ocean heeft tokens, etc. Het enige echte verschil tussen hun tokens en onze prive-tokens is dat ze worden beperkt tot de API en typisch gecodeerd. Wij ondersteunen beide opties met persoonlijke toegangstokens. GitLab is momenteel uitfaseren private tokens in het voordeel van persoonlijke toegangstokens.”
GitLab, anderzijds, is ook begonnen met een eigen tokens met aangepaste RSS-tokens te vervangen voor het ophalen van RSS feeds. Dit initiatief is in het leven geroepen om ervoor te zorgen dat er geen sessie-id's worden gelekt. Persoonlijke toegang tokens worden ook steeds meer in dienst van GitLab die rolgebaseerde toegangscontrole zou aanbieden, dus veiligheidsmaatregelen stimuleren alsook.
