GitHub har afsløret to hændelser i sin NPM-pakkeopbevaringsinfrastruktur. Den 2. november rapporterede tredjeparts sikkerhedsforskere (Kajetan Grzybowski og Maciej Piechota), som en del af Bug Bounty-programmet, tilstedeværelsen af en sårbarhed i NPM-lageret, der giver dig mulighed for at udgive en ny version af enhver pakke ved hjælp af din konto, som ikke er autoriseret til at udføre sådanne opdateringer.
Sårbarheden var forårsaget af forkerte tilladelsestjek i koden for mikrotjenester, der behandler anmodninger til NPM. Autorisationstjenesten udførte pakketilladelsestjek baseret på de data, der blev sendt i anmodningen, men en anden tjeneste, der uploadede opdateringen til lageret, bestemte, at pakken skulle udgives baseret på metadataindholdet i den uploadede pakke. En angriber kan således anmode om offentliggørelse af en opdatering til sin pakke, som han har adgang til, men angive i selve pakken information om en anden pakke, som til sidst ville blive opdateret.
Problemet blev rettet 6 timer efter, at sårbarheden blev rapporteret, men sårbarheden var til stede i NPM længere end telemetrilogfiler dækker. GitHub hævder, at der ikke har været spor af angreb med denne sårbarhed siden september 2020, men der er ingen garanti for, at problemet ikke er blevet udnyttet før.
Den anden hændelse fandt sted den 26. oktober. Under teknisk arbejde med databasen for replicate.npmjs.com-tjenesten blev tilstedeværelsen af fortrolige data i databasen, der er tilgængelige for eksterne anmodninger, afsløret, hvilket afslørede oplysninger om navnene på interne pakker, der blev nævnt i ændringsloggen. Oplysninger om sådanne navne kan bruges til at udføre afhængighedsangreb på interne projekter (i februar tillod et lignende angreb at udføre kode på serverne hos PayPal, Microsoft, Apple, Netflix, Uber og 30 andre virksomheder).
På grund af det stigende antal tilfælde af arkiver af store projekter, der er blevet kapret, og ondsindet kode fremmes gennem kompromitterende udviklerkonti, har GitHub desuden besluttet at indføre obligatorisk to-faktor-godkendelse. Ændringen træder i kraft i første kvartal af 2022 og vil gælde for vedligeholdere og administratorer af pakker, der er inkluderet på den mest populære liste. Derudover rapporteres det om moderniseringen af infrastrukturen, hvor automatiseret overvågning og analyse af nye versioner af pakker vil blive introduceret til tidlig detektering af ondsindede ændringer.
Lad os huske, at ifølge en undersøgelse udført i 2020, bruger kun 9.27 % af pakkevedligeholdere to-faktor-autentificering til at beskytte adgangen, og i 13.37 % af tilfældene, når de registrerede nye konti, forsøgte udviklere at genbruge kompromitterede adgangskoder, der dukkede op i kendte password-lækage. Under en adgangskodesikkerhedsgennemgang blev 12 % af NPM-konti (13 % af pakkerne) tilgået på grund af brugen af forudsigelige og trivielle adgangskoder såsom "123456." Blandt de problematiske var 4 brugerkonti fra de 20 mest populære pakker, 13 konti med pakker downloadet mere end 50 millioner gange om måneden, 40 med mere end 10 millioner downloads om måneden og 282 med mere end 1 million downloads om måneden. Tager man hensyn til indlæsningen af moduler langs en kæde af afhængigheder, kan kompromittering af upålidelige konti påvirke op til 52 % af alle moduler i NPM.
Kilde: opennet.ru