Virksomheden Truffle Security har offentliggjort angrebsscenarier for flere typiske metoder til at arbejde med repositorys på GitHub, som muliggør udtrækning af data fra fjernrepositorys, der har offentlige forks eller som er oprettet som forks.
Muligheden for adgang til commits via hash i alle relaterede forks til repositoryet skyldes, at GitHub, for optimering og for at undgå dubletter, gemmer alle objekter fra hovedrepositoryet og forks sammen, blot logisk adskilt efter ejerforholdet af commits. Denne opbevaringsmetode tillader at se enhver commit fra enhver fork i hovedrepositoryet ved tydeligt at angive dens hash i URL'en. For eksempel kan en bruger oprette en fork af repositoryet "/torvalds/linux" og tilføje enhver kode, hvorefter denne kode vil være tilgængelig via et direkte hash-link i repositoryet "/torvalds/linux". I tilfælde af at repositoryet slettes, forbliver data fra det fjernede repository tilgængelige via commit-hashen, hvis der er mindst én offentlig fork.
Der foreslås tre scenarier, der udgør en sikkerhedstrussel:
- Det første scenarie vedrører situationer, hvor udviklere opretter forks af offentlige repositorys, tilføjer ændringer til dem, eksperimenterer, og derefter sletter dem. Udover lækage af kode, der ikke er beregnet til offentliggørelse, udgør situationen en fare, når eksperimenterne i kodefiler med eksempler indeholder aktive API-adgangsnøgler. I dette tilfælde kan angriberen få adgang til ændringerne via commit-hashen, der er adresseret efter sletningen af forken gennem hovedrepositoryet. For eksempel formåede forskere at identificere 30 aktive API-adgangsnøgler ved at undersøge tre maskinlæringsrelaterede repositorys med et stort antal forks.
- Det andet scenarie omhandler muligheden for at få adgang til data efter sletning af det primære repository, hvis der er blevet lavet forks af dette repository. Et eksempel er et tilfælde, hvor fortrolige nøgler fra en ansat ved en virksomheds offentlige repository blev offentliggjort ved en fejl, hvilket gav fuld adgang til alle virksomhedens repositories på GitHub. Virksomheden slettede det repository, hvorigennem lækagen skete, men nøglerne forblev tilgængelige for udtræk gennem anmodninger om commit-hash i repositories med forks.
- Det tredje scenarie relaterer sig til udviklingsmodellen for projekter, der udvikler en grundlæggende åben version i et offentligt repository og en udvidet proprietær version i et privat. Hvis virksomheden oprindeligt udviklede projektet i et privat repository, og derefter efter åbningen af koden til projektet flyttede det til offentlig status, men fortsatte udviklingen af en lukket intern eller udvidet version i en privat fork, er der mulighed for adgang til ændringer tilføjet til den private fork via commit-hashes gennem det offentlige repository. Adgang er dog kun mulig til de ændringer, der blev tilføjet til den private fork før overførslen af hovedrepositoryet til offentlig status (opbevaringspladserne for private og offentlige repositories er adskilt, men når to repositories var private, blev commits opbevaret sammen, og derfor forblev de i repositoryet efter dets overførsel til offentlig status).
Tricket, der muliggør adgang til commits i forks af repositoryet gennem et link til det primære repository, har været kendt i mange år og anvendes periodisk til forskellige vittigheder og for at forlede udviklere (for eksempel skaber spasmagerer periodisk på denne måde en illusion om indsatser af backdoors i repositoryet for Linux-kernen på GitHub). Som en foranstaltning til at modvirke sådanne vittigheder har GitHub tilføjet en advarsel om, at den anmodede commit ikke tilhører grenene i det aktuelle repository og muligvis tilhører en fork. Selve muligheden for at få adgang til commits efter hash i alle relaterede forks af repositoryet blev betragtet som harmløs, da viden om commit-hashen er nødvendig for at få adgang til data i fjerne og private forks.
At finde en commit-hash, der er genereret på baggrund af SHA-1 algoritmen og indeholder 32 tegn, er umuligt, men det viste sig, at det slet ikke er nødvendigt. GitHub understøtter en forkortet form for henvisning til commits, der gør det muligt at adressere ændringer med de første tegn i hashen, så længe der ikke er overlap med andre commits. Det minimale antal tegn for en forkortet hash-adresse er 4, hvilket svarer til at afprøve i alt 65.000 kombinationer (16^4). Samtidig kan det være, at en afprøvning slet ikke er nødvendig, da GitHub's API giver mulighed for at tilslutte håndtagere, der kan opsnappe begivenheder, som bruges af tredjepartsprojekter, der fører et arkiv med en komplet log over alle operationer, hvor oplysninger om commit-hashes forbliver selv efter sletning af repositories.
Kilde: opennet.ru
