GitHub het twee voorvalle in sy NPM-pakketbewaarinfrastruktuur bekend gemaak. Op 2 November het derdeparty-sekuriteitsnavorsers (Kajetan Grzybowski en Maciej Piechota), as deel van die Bug Bounty-program, die teenwoordigheid van 'n kwesbaarheid in die NPM-bewaarplek gerapporteer wat jou toelaat om 'n nuwe weergawe van enige pakket met jou rekening te publiseer, wat nie gemagtig is om sulke opdaterings uit te voer nie.
Die kwesbaarheid is veroorsaak deur verkeerde toestemmingskontroles in die kode van mikrodienste wat versoeke aan NPM verwerk. Die magtigingsdiens het pakkettoestemmingkontroles uitgevoer op grond van die data wat in die versoek geslaag is, maar 'n ander diens wat die opdatering na die bewaarplek opgelaai het, het bepaal dat die pakket gepubliseer moet word op grond van die metadata-inhoud van die opgelaaide pakket. Dus kan 'n aanvaller die publikasie van 'n opdatering vir sy pakket, waartoe hy toegang het, versoek, maar in die pakket self inligting spesifiseer oor 'n ander pakket, wat uiteindelik opgedateer sal word.
Die probleem is opgelos 6 uur nadat die kwesbaarheid aangemeld is, maar die kwesbaarheid was langer in NPM teenwoordig as wat telemetrielogboeke dek. GitHub beweer dat daar sedert September 2020 geen spore was van aanvalle wat hierdie kwesbaarheid gebruik nie, maar daar is geen waarborg dat die probleem nie voorheen uitgebuit is nie.
Die tweede voorval het op 26 Oktober plaasgevind. Tydens tegniese werk met die databasis van die replicate.npmjs.com-diens is die teenwoordigheid van vertroulike data in die databasis wat toeganklik is vir eksterne versoeke aan die lig gebring, wat inligting openbaar oor die name van interne pakkette wat in die veranderingslogboek genoem is. Inligting oor sulke name kan gebruik word om afhanklikheidsaanvalle op interne projekte uit te voer (in Februarie het 'n soortgelyke aanval toegelaat dat kode op die bedieners van PayPal, Microsoft, Apple, Netflix, Uber en 30 ander maatskappye uitgevoer word).
Boonop, as gevolg van die toenemende aantal gevalle van bewaarplekke van groot projekte wat gekaap word en kwaadwillige kode wat deur ontwikkelaarrekeninge in die gedrang kom, het GitHub besluit om verpligte twee-faktor-verifikasie in te stel. Die verandering sal in die eerste kwartaal van 2022 in werking tree en sal van toepassing wees op instandhouers en administrateurs van pakkette wat in die gewildste lys ingesluit is. Daarbenewens word berig oor die modernisering van die infrastruktuur, waarin outomatiese monitering en ontleding van nuwe weergawes van pakkette bekendgestel sal word vir vroeë opsporing van kwaadwillige veranderinge.
Kom ons onthou dat, volgens 'n studie wat in 2020 gedoen is, slegs 9.27% van pakketonderhouers twee-faktor-verifikasie gebruik om toegang te beskerm, en in 13.37% van gevalle, wanneer nuwe rekeninge geregistreer is, het ontwikkelaars probeer om gekompromitteerde wagwoorde wat in verskyn het, te hergebruik. bekende wagwoordlekkasies. Tydens 'n wagwoordsekuriteitoorsig is toegang tot 12% van NPM-rekeninge (13% van pakkette) verkry as gevolg van die gebruik van voorspelbare en onbenullige wagwoorde soos "123456." Onder die problematiese was 4 gebruikersrekeninge van die Top 20 gewildste pakkette, 13 rekeninge met pakkette wat meer as 50 miljoen keer per maand afgelaai is, 40 met meer as 10 miljoen aflaaie per maand, en 282 met meer as 1 miljoen aflaaie per maand. Met inagneming van die laai van modules langs 'n ketting van afhanklikhede, kan kompromie van onbetroubare rekeninge tot 52% van alle modules in NPM raak.
Bron: opennet.ru