Een aanval op NPM waarmee u de aanwezigheid van pakketten in privérepository's kunt bepalen

Er is een fout ontdekt in NPM waarmee u het bestaan ​​van pakketten in gesloten opslagplaatsen kunt detecteren. Het probleem wordt veroorzaakt door verschillende reactietijden bij het aanvragen van een bestaand en niet-bestaand pakket bij een derde partij die geen toegang heeft tot de repository. Als er geen toegang is voor pakketten in privérepository's, retourneert de register.npmjs.org-server een fout met de code "404", maar als er een pakket met de gevraagde naam bestaat, wordt de fout met een merkbare vertraging afgegeven. Een aanvaller kan deze functie gebruiken om de aanwezigheid van een pakket vast te stellen door pakketnamen te doorzoeken met behulp van woordenboeken.

Het bepalen van pakketnamen in privéopslagplaatsen kan nodig zijn om een ​​afhankelijkheidsmengaanval uit te voeren die de kruising van afhankelijkheidsnamen in openbare en interne opslagplaatsen manipuleert. Als een aanvaller weet welke interne NPM-pakketten aanwezig zijn in bedrijfsrepository's, kan hij pakketten met dezelfde namen en nieuwere versienummers in de openbare NPM-repository plaatsen. Als tijdens de montage de interne bibliotheken niet expliciet aan hun repository zijn gekoppeld in de instellingen, zal de npm-pakketbeheerder de openbare repository als een hogere prioriteit beschouwen en het door de aanvaller voorbereide pakket downloaden.

GitHub werd in maart op de hoogte gebracht van het probleem, maar weigerde bescherming tegen de aanval toe te voegen, onder verwijzing naar architecturale beperkingen. Bedrijven die privéopslagplaatsen gebruiken, wordt aanbevolen om periodiek te controleren of er overlappende namen in de openbare opslagplaats voorkomen, of namens hen stubs te maken met namen die de namen van pakketten in privéopslagplaatsen herhalen, zodat aanvallers hun pakketten met overlappende namen niet kunnen plaatsen.

Bron: opennet.ru

Voeg een reactie