For nogle dage siden GitHub afslørede to hændelser i NPM-pakkelagerets infrastruktur, hvoraf den beskriver, at den 2. november fandt tredjeparts sikkerhedsforskere som en del af Bug Bounty-programmet en sårbarhed i NPM-lageret som gør det muligt at udgive en ny version af enhver pakke, selvom den ikke er autoriseret at udføre sådanne opdateringer.
Sårbarheden var forårsaget af forkerte autorisationstjek i mikroservicekoden denne procesanmodninger til NPM. Autorisationstjenesten udførte en tilladelseskontrol på pakkerne 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 i selve pakken angive oplysninger om en anden pakke, som til sidst ville blive opdateret.
I de sidste par måneder har npm-teamet investeret i infrastruktur- og sikkerhedsforbedringer for at automatisere overvågningen og analysen af nyligt udgivne pakkeversioner for at identificere malware og anden ondsindet kode i realtid.
Der er to hovedkategorier af malware-postbegivenheder, der forekommer i npm-økosystemet: malware, der er postet på grund af kontokapring, og malware, som angribere sender via deres egne konti. Selvom kontoerhvervelser med stor effekt er relativt sjældne, sammenlignet med direkte malware indsendt af angribere, der bruger deres egne konti, kan kontoanskaffelser være vidtrækkende, når de retter sig mod populære pakkevedligeholdere. Mens vores detektion og responstid på anskaffelser af populære pakker har været så lav som 10 minutter i de seneste hændelser, fortsætter vi med at udvikle vores malware-detektionsfunktioner og notifikationsstrategier hen imod en mere proaktiv responsmodel.
Problemet den blev rettet 6 timer efter, at sårbarheden blev rapporteret, men sårbarheden var til stede i NPM længere end hvad telemetrilogs dækker over. GitHub oplyser, at der ikke har været spor efter angreb ved hjælp af 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. I løbet af det tekniske arbejde med replicant.npmjs.com servicedatabasen, det blev afsløret, at der var fortrolige data i databasen til rådighed for ekstern høring, der afslører oplysninger om navnene på de interne pakker, der blev nævnt i ændringsloggen.
Oplysninger om disse navne kan bruges til at udføre afhængighedsangreb på interne projekter (I februar tillod et sådant angreb kode at køre på serverne hos PayPal, Microsoft, Apple, Netflix, Uber og 30 andre virksomheder.)
Derudover i forhold til den stigende forekomst af beslaglæggelse af depoter af store projekter og promovering af ondsindet kode gennem kompromittering af udviklerkonti, GitHub besluttede at indføre obligatorisk to-faktor-autentificering. Ændringen træder i kraft i første kvartal af 2022 og vil gælde for vedligeholdere og administratorer af de pakker, der er inkluderet på listen over de mest populære. Derudover gives der information om moderniseringen af infrastrukturen, hvor den automatiske overvågning og analyse af nye pakkeversioner vil blive introduceret til tidlig detektering af ondsindede ændringer.
Husk på, at ifølge en undersøgelse udført i 2020, bruger kun 9.27 % af pakkeadministratorerne tofaktorautentificering 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 vises i kendte adgangskoder .
Under kontrol af styrken af de anvendte adgangskoder blev 12 % af konti i NPM (13 % af pakkerne) tilgået på grund af brugen af forudsigelige og trivielle adgangskoder såsom "123456". Blandt problemerne var 4 brugerkonti af de 20 mest populære pakker, 13 konti, hvis pakker blev downloadet mere end 50 millioner gange om måneden, 40 - mere end 10 millioner downloads om måneden og 282 med mere end 1 million downloads om måneden. I betragtning af modulbelastningen langs kæden af afhængigheder kan kompromittering af upålidelige konti påvirke op til 52 % af alle moduler i NPM i alt.
Endelig hvis du er interesseret i at vide mere om det du kan kontrollere detaljerne I det følgende link.