Het bedrijf Truffle Security heeft aanvalsscenario's gepubliceerd voor verschillende standaardmethoden van werken met repositories op GitHub, waarmee gegevens kunnen worden geëxtraheerd uit externe repositories die openbare forks hebben of die zijn gemaakt als forks.
De mogelijkheid om commits op basis van een hash te benaderen in alle gerelateerde forks van de repository is te wijten aan het feit dat GitHub, ter optimalisatie en om duplicaten te voorkomen, alle objecten van de hoofdrepository en forks samen opslaat, terwijl de toewijzing van commits alleen logisch wordt gescheiden. Deze opslag maakt het mogelijk om elke commit van een fork te bekijken in de hoofdrepository, door de hash expliciet in de URL op te geven. Bijvoorbeeld, een gebruiker kan een fork maken van de repository '/torvalds/linux' en daar enige code aan toevoegen, waarna deze code beschikbaar wordt via een directe hash-link in de repository '/torvalds/linux'. In het geval dat de repository wordt verwijderd, blijven de gegevens uit de verwijderde repository toegankelijk op basis van de commit hash, zolang er ten minste één openbare fork is.
Er worden drie scenario's gepresenteerd die een beveiligingsrisico vormen:
- Het eerste scenario betreft situaties waarin ontwikkelaars forks van openbare repositories maken, daarin wijzigingen aanbrengen, experimenteren en deze vervolgens verwijderen. Naast het uitlekken van code die niet bedoeld is voor publicatie, vormt de situatie waarin werkende API-toegangssleutels in de voorbeeldbestanden van experimenten worden toegevoegd een gevaar. In dit geval kan de aanvaller toegang krijgen tot de wijziging op basis van de commit hash, die na verwijdering van de fork via de hoofdrepository kan worden aangesproken. Bijvoorbeeld, op deze manier konden onderzoekers 30 werkende API-toegangssleutels identificeren door drie gerelateerde repositories met machine learning te bestuderen die veel forks hadden.
- Het tweede scenario betreft de mogelijkheid om toegang te krijgen tot gegevens na het verwijderen van de primaire repository, als er forks van die repository zijn gemaakt. Ter illustratie wordt een geval aangehaald waarin in een openbare repository van een bedrijf per ongeluk de privésleutels van een van de medewerkers zijn gepubliceerd, waarmee volledige toegang tot alle repositories van dat bedrijf op GitHub verkregen kon worden. Het bedrijf heeft de repository verwijderd waardoor de lek plaatsvond, maar de sleutels zijn nog steeds toegankelijk voor extractie via verzoeken op de commit-hash in de repositories met forks.
- Het derde scenario is gerelateerd aan het model voor projectontwikkeling, waarbij een basisversie in een openbare repository wordt ontwikkeld en een uitgebreide propriëtaire versie in een private. Als een bedrijf aanvankelijk een project in een private repository ontwikkelde en vervolgens na het openstellen van de projectcode deze omzette naar een publieke status, maar ook de ontwikkeling van een interne of uitgebreide versie in een private fork voortzette, bestaat er een mogelijkheid om toegang te krijgen tot de wijzigingen die aan de private fork zijn toegevoegd via de commit-hashes via de openbare repository. Hierbij is toegang alleen mogelijk tot de wijzigingen die aan de private fork zijn toegevoegd vóór de omzetting van de hoofdrepository naar een publieke status (de opslagplaatsen van private en openbare repositories zijn gescheiden, maar wanneer twee repositories private waren, werden de commits samen opgeslagen, zodat ze in de repository bleven na de omzetting naar een publieke status).
De truc waarmee toegang kan worden verkregen tot commits in de forks van een repository via een link naar de hoofdrepository is al vele jaren bekend en wordt af en toe gebruikt voor verschillende grappen en om ontwikkelaars te misleiden (bijvoorbeeld, grappenmakers creëren af en toe op deze manier de schijn van backdoor-invoegingen in de kernelrepository van Linux op GitHub). Als maatregel om dergelijke grappen tegen te gaan heeft GitHub een waarschuwing toegevoegd dat de aangevraagde commit niet behoort tot de takken in de huidige repository en mogelijk toebehoort aan een fork. Daarbij werd de mogelijkheid om toegang te krijgen tot commits via de hash in enige gerelateerde forks van de repository als onschuldig beschouwd, aangezien toegang tot gegevens in externe en private forks vereist dat de commit-hash bekend is.
Het vinden van een commit-hash die is gebaseerd op het SHA-1-algoritme en 32 tekens bevat, is niet mogelijk, maar het blijkt dat dit niet nodig is. GitHub ondersteunt een verkorte vorm van verwijzing naar commits, waarmee wijzigingen kunnen worden aangesproken op basis van een aantal eerste tekens van de hash, mits er geen overlappingen zijn met andere commits. Het minimale aantal tekens voor verkorte hash-verwijzing is 4, wat overeenkomt met het doorlopen van in totaal 65.000 combinaties (16^4). Het doorlopen hoeft echter niet eens nodig te zijn, aangezien de GitHub API het mogelijk maakt om handlers aan te sluiten voor het onderscheppen van gebeurtenissen, die gebruikt worden door externe projecten die een archief bijhouden met een volledige log van alle bewerkingen, waarin informatie over commit-hashes behouden blijft, ook nadat repositories zijn verwijderd.
Bron: opennet.ru
