Kwetsbaarheid die het mogelijk maakte om een update voor elk pakket in de NPM-repository uit te brengen

GitHub heeft informatie vrijgegeven over twee incidenten in de infrastructuur van het NPM-pakketrepository. Op 2 november meldden externe beveiligingsonderzoekers (Kajetan Grzybowski en Maciej Piechota) in het kader van het Bug Bounty-programma een kwetsbaarheid in het NPM-repository, die het mogelijk maakte om een nieuwe versie van elk pakket te publiceren met behulp van hun account, dat niet bevoegd was voor dergelijke updates.

De kwetsbaarheid werd veroorzaakt door een onjuiste autorisatiecontrole in de code van microservices die verzoeken aan NPM verwerken. De autorisatieservice controleerde de toegangsrechten tot pakketten op basis van gegevens die in het verzoek werden verzonden, maar een andere service, die de update in het repository uploadde, bepaalde het te publiceren pakket op basis van de metadata-inhoud in het geüploade pakket. Hierdoor kon een aanvaller een verzoek doen om een update voor zijn pakket, waartoe hij toegang had, te publiceren, maar in het pakket informatie over een ander pakket opgeven dat uiteindelijk zou worden bijgewerkt.

Het probleem werd opgelost zes uur nadat de kwetsbaarheid aan het licht kwam, maar de kwetsbaarheid was langer in NPM aanwezig dan de telemetrie-logboeken dekken. GitHub beweert dat er sinds september 2020 geen aanwijzingen zijn voor aanvallen die gebruikmaakten van deze kwetsbaarheid, maar er zijn geen garanties dat het probleem niet eerder is uitgebaat.

Het tweede incident vond plaats op 26 oktober. Tijdens technische werkzaamheden met de database van de service replicate.npmjs.com werd vastgesteld dat vertrouwelijke gegevens beschikbaar waren in de externe database, die informatie onthult over interne pakketnamen die in het changelog werden genoemd. Informatie over dergelijke namen kan worden gebruikt voor aanvallen op afhankelijkheden in interne projecten (in februari maakte een vergelijkbare aanval het mogelijk om code uit te voeren op servers PayPal, Microsoft, Apple, Netflix, Uber en nog eens 30 bedrijven).

Bovendien, gezien de toenemende incidenten van repositoryovername van grote projecten en de verspreiding van schadelijke code door het compromitteren van ontwikkelaarsaccounts, heeft GitHub besloten om verplichte tweefactorauthenticatie in te voeren. Deze wijziging gaat in in het eerste kwartaal van 2022 en zal van toepassing zijn op onderhouders en beheerders van pakketten die op de lijst van de meest populaire pakketten staan. Daarnaast is er nieuws over de modernisering van de infrastructuur, waarin een geautomatiseerd systeem voor monitoring en analyse van nieuwe versies van pakketten zal worden geĆÆmplementeerd voor vroegtijdige detectie van schadelijke wijzigingen.

Ter herinnering, volgens een onderzoek dat in 2020 is uitgevoerd, gebruikt slechts 9,27% van de onderhouders van pakketten tweefactorauthenticatie voor toegangbeveiliging, en in 13,37% van de gevallen probeerden ontwikkelaars bij het registreren van nieuwe accounts opnieuw gecompromitteerde wachtwoorden te gebruiken die in bekende datalekken zijn verschenen. Bij de controle van de betrouwbaarheid van de gebruikte wachtwoorden kon in 12% van de accounts in NPM (13% van de pakketten) toegang worden verkregen vanwege het gebruik van voorspelbare en triviale wachtwoorden, zoals '123456'. Onder de problematische accounts waren 4 accounts van Top20 van de meest populaire pakketten, 13 accounts waarvan de pakketten meer dan 50 miljoen keer per maand zijn gedownload, 40 met meer dan 10 miljoen downloads per maand en 282 met meer dan 1 miljoen downloads per maand. Gezien de laadtijd van modules via afhankelijkheidsketens kon de compromittering van onbetrouwbare accounts tot maar liefst 52% van alle modules in NPM treffen.

Bron: opennet.ru

Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers šŸ”„ Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers | ProHoster