Dit is die eerste episode in 'n reeks artikels oor die mees algemene soort sagteware-voorsieningskettingaanvalle: dié wat 'n openbare register van sagtewarekomponente (mis)bruik, bedoel vir oopbronprojekte om artefakte op te laai wat met ander gebruikers gedeel kan word. Wanneer die slegte ouens kwaadwillige sagteware daar publiseer en die register as 'n voertuig vir die verspreiding van wanware gebruik, het ons 'n voorsieningskettingaanval wanneer die slagofferorganisasies die besmette sagtewarekomponent installeer of uitvoer.
Om die bespreking te vereenvoudig, sal ons praat oor sagtewarepakkette:, komponente in 'n verpakte vorm wat deur derde partye vervaardig word. Dit sluit nie net komponente in wat deur pakketbestuurders soos NPM of Poetry gebruik word nie, maar ook bedryfstelselkomponente insluitend biblioteke en uitvoerbare binêre lêers, houerbeelde, en virtuele masjiene, of gereedskapuitbreidings vir ontwikkelings-, bou- en ontplooiingsinstrumente. Ons het oral kwaadwillige pakkette gesien. Kubermisdadigers gee nie om nie: hulle is verheug oor die alternatiewe wat deur moderne sagteware-infrastrukture gebied word en gebruik die register en die instrument wat die beste by hul voorneme pas. Onthou dus asseblief dat sagtewarepakkette 'n afkorting is vir houerbeelde, binêre pakkette, oopbron-bewaarplekke en uitbreidings of inproppe van alle soorte (IDE's, CI/CD stelsels, bougereedskap). Almal word gereeld aangeval.
Die reeks sal 5 episodes hê:
- Wat is die probleem met oopbronpakkette? Dit is die tema van hierdie plasing. Waarom publiseer misdadigers van alle soorte kwaadwillige pakkette? Waarom moet ek bekommerd wees?
- Anatomie van Kwaadwillige Pakkette: Wat is die Tendense? In hierdie episode fokus ons op die bedreiging wat ons dag na dag met ons MEW-stelsel monitor. Met 'n groot agtergrondgeraas as gevolg van 'n groot aantal kwaadwillige pakkette wat typosquatting of afhanklikheidsverwarring gebruik, is 'n kleiner persentasie aanvalle baie meer verraderlik en hou 'n groter risiko in. Hoe het die slegte akteurs se gedrag rakende OS in die onlangse verlede verander? Wat is die syfers? Wat is die taktieke, tegnieke en prosedures wat gebruik word, en die skadelike aksies wat gesien word?
- Beskerming teen oopbron-kwaadwillige pakkette: Wat werk (nie) nieDie meeste sekuriteitsbewuste professionele persone het idees oor hoe om hierdie bedreiging te hanteer. Ons het sekuriteitsbestuurders sonder aarseling hoor sê dat SCA gereedskap vertel jou reeds wanneer 'n pakketweergawe wanware is. Of dat hulle staatmaak op bekende, hoogs geëvalueerde sagtewarekomponente, waar enige wanware vinnig opgespoor en verwyder sal word. Hulle gebruik oop klein/pleisterweergawes om outomaties kwesbaarheidsoplossings te kry, en dat dit die korrekte, aanbevole manier is om die risiko op oopbronafhanklikhede te verlaag, volgens die "pleister vroeg, pleister gereeld"-beginsel. In hierdie episode sal ons hersien waarom hierdie idees verkeerd is, en hoe sulke wanopvattings bydra tot die gewildheid van hierdie aanvalsmeganisme, en tot 'n oorweldigende risiko wat organisasies ervaar. Ons sal eindig met wat wel werk, en wat die moeite en hulpbronne is wat betrokke is.
- Oopbron Kwaadwillige Pakkette: Die Xygeni-benaderingIn hierdie episode bied ons aan watter strategie ons by Xygeni volg vir ons Malware Early Warning (MEW)-stelsel. Hoe werk hierdie meerfase-stelsel intyds wanneer 'n nuwe pakketweergawe gepubliseer word, hoe bewyse uit verskillende bronne versamel word, hoe triage gedoen word, watter klassifikasiekriteria volg ons, en waarom 'n mate van handmatige analise nog nodig is om die aard van 'n kwaadwillige pakketkandidaat te bevestig? Hoe die terugvoer van ons interne en registerspanne die stelsel help om te leer uit vorige bewyse wat versamel is om vals positiewe tot 'n minimum te verminder. Ons sal ook verduidelik hoe ons NPM, GitHub, PyPI en ander sleutelinfrastrukture in die oopbron-oopbron-ekosisteme help om verblyftyd te verminder..
- Die benutting van oopbron: Wat om van die slegte ouens te verwagDie reeks eindig met 'n fokus op die nuutste aksies wat die teenstanders aanneem om die aanvalle meer onopvallend, moeiliker op te spoor, meer gerig op spesifieke nywerhede te maak, en meer voordeel uit hierdie klas aanvalle te trek. Sal losprysware-aanvalle met behulp van hierdie voertuig uitgevoer word? Hoe benut die slegte ouens KI-instrumente om meer gesofistikeerde kwaadwillige pakkette te lewer? Is top gewilde projekte in gevaar? Dit is om lesers 'n gevoel te gee oor hierdie wapenwedloop, en wat om te verwag op kort termyn (tweede helfte van 2024) en medium termyn (2025). Ons sal leer hoe aanvalle soos die onlangse... XZ-Utils Agterdeur, of die leef-van-die-land-aanval op elektronbouer in MaartMaart 2024 wys dat ons waaksaam moet bly oor hoe die teenstanders ontwikkel.
Kom ons open die verhoog met die eerste episode: Wat gaan aan met kwaadwillige oopbron-oopbronpakkette?
Wat is die probleem met oopbronpakkette?
In onlangse jare het oortreders van alle soorte oopbron-sagtewareregisters gebruik om kwaadwillige gedrag te lewer. Hierdie aktiwiteite is so oud soos oopbron, maar hul frekwensie het in die afgelope drie jaar ontplof.
Publisering van kwaadwillige komponente in openbare registers (afhanklikheidsgebaseerde aanvalle) is asimmetriese guerrilla-oorlogvoering wat bedreigingsakteurs gebruik om wanware te versprei, wat die vertroue wat organisasies in oopbronkomponente van onbekende ontwikkelaars plaas, benut (onthou die afhanklikheid xkcd strokiesprent?). Omdat jy pakkette vertrou en nie omgee om die pakketinhoud en hul afhanklikhede handmatig na te gaan nie, is hierdie aanvalle buitengewoon effektief. En die asimmetrie kom omdat hulle grootliks outomaties kan word en die slegte ouens nie direk met die slagoffer hoef te kommunikeer nie. Hulle laai die pakket eenvoudig op in die openbare register en laat dit gaan.
Kwaadwillige pakkette met 'n 6x-faktor gestyg in 2022, en het in 2023 met 'n 2.5x-faktor bly groei. Verlede jaar is 'n yslike 245 000 kwaadwillige pakkette gesien, 'n syfer wat die totale aantal van vorige jare saam meer as verdubbel. Dit is eksponensiële groei! Van pakketverwydering tot bevestigde wanware in die honderde gedurende 2021 en in die duisende gedurende 2022, het ons baie meer agtergrond-"geraas" gedurende 2023 gesien, met 'n soortgelyke tempo vir hierdie jaar. En versteek in daardie agtergrond, veroorsaak deur ongesofistikeerde kubermisdadigers wat die "pad van die minste weerstand" volg, het 'n minderheid van hoëprofiel-aanvalle selfs in die algemene media opslae gemaak.
Waarom is dit 'n probleem van so 'n omvang? Daar is 'n oormaat vertroue oor die hele ketting. Oopbronsagteware word met sy bronkode versprei en onder 'n gegewe lisensie vrygestel. Ja, enigiemand kan die bronkode inspekteer; maar wie doen dit oor die algemeen? Wie, nadat hy inspekteer het dat die sagteware geen wanware bevat nie, bou die sagteware vanaf die bronne? Wie, voordat hy die verpakte komponent (ook bekend as 'n pakket) stroomaf na die pakketbestuurder of die bou-instrument, maak seker dat die pakket nie met wanware besaai is nie en ooreenstem met die veronderstelde bronkode waaruit dit moet kom?
Waarom laat die infrastruktuur sulke maklike aanvalle toe?
Pakketregisters is oop, wat dikwels minimale verifikasie van die identiteit van die uitgewer vereis. "Enigeen is welkom om hul sagteware hier te publiseer!" Die standaard vir aanvallers is laag gestel: hulle gebruik weggooibare e-posadresse en weggooibare GitHubgithub-rekeninge om honderde kwaadwillige pakkette in kort, phishing-agtige veldtogte te skep. Slegs vir geteikende pakkette is 'n hoër gesofistikeerdheid nodig: Ons het selfs gesien hoe 'n geloofwaardige GitHub-bronbewaarplek met baie sterre en commits van verskeie vals bydraers en ander maatstawwe van gewildheid en onderhoud. Om te kry sterrekykers en reputasie van vals bydraes is nie moeilik om te outomatiseer nie. Ons het misbruik op oop sagteware-infrastrukture van alle soorte gesien, nie net wanware nie, soos die tee-protokol-insident.
Pakketbestuurders is ontwerp vir gebruiksgemak en nie vir sekuriteit nie.Hulle kan voor- en na-installasie skripte uitvoer (soms is die saamstel van oorspronklike kode vir 'n biblioteek nodig). Ook, Pakketbestuurders installeer pakkette van verskeie bronne, en soms is die verstekwaarde om publieke registers te gebruik. Hulle het nie gekontroleer vir 'n wanverhouding tussen die metadata in die publiseerversoek en die metadata in die pakket self nie.
Afhanklikhede word geneste en vorm 'n grafiek. In sekere ekosisteme soos Node (JavaScript), versamel kleinkorrel-afhanklikhede in die honderde of duisende. Een ding is om streng beheer te hê oor direkte afhanklikhede wat deur my sagtewareprojekte verklaar word, maar oorganklike afhanklikhede is moeiliker om te beheer. Oopbron het gevolg "die vriende van my vriende is my vriende". Broederskap is die norm in die wilde Verre Ooste! Bedreigingsakteurs weet dit en versteek die kwaadwillige gedrag diep in obskure afhanklikhede wat dikwels onbekend is. Dit was die geval met die gebeurtenisstroom voorval wat gemik is op die Copay-beursie.
Só het oopbronsagteware sedert sy ontstaan gewerk. Dit sal nie veel verander nie. Sommige pakketregisters vereis op sy beste tweefaktor-verifikasie, en dikwels net vir die gewildste pakkette. Sommige registers bied omvang, 'n naamruimte wat deur 'n geverifieerde organisasie besit word, maar tragies ander ondersteun dit nie (PyPI) of maak dit opsioneel (NPM). Dit is interessant om daarop te let dat selfs 'n eenvoudige siftingskema (gebaseer op beheer van die DNS- of GitHub-bewaarplek/organisasie wat ooreenstem met die groep-ID) en maak PGP-handtekeninge verpligtend vir alle artefakte behalwe kontrolesomme verwyder die meeste van die "geraas", typosquatting-agtige kwaadwillige pakkette, en beperk baie van afhanklikheidsverwarringGesofistikeerde aanvalle is moontlik, maar baie moeiliker, met slegs 'n paar soos die com.github.koderingenkodering:maven-samesteller-inprop bekend vir Maven Central. En nie alle Maven-registers volg dieselfde praktyke nie!
Sekuriteitsbeheermaatreëls op pakketbestuurders kan afhanklikheidsaanvalle belas, maar dit belemmer nie. Die probleem met multifaktor-verifikasie is dat afgeleide geloofsbriewe soos toegangstokens of APIapi-sleutels vir outomatisering gegenereer word vir rekeninge wat gebruik kan word in APIapi-oproepe wat vanaf outomatiseringsskripte gemaak word, sonder dat 'n ondersteunende interaktiewe gebruiker 'n tweede faktor verskaf. MFA is goed om gebruikersrekeninge teen wagwoordlekkasies te beskerm, maar die gegenereerde toegangstokens of APIapi-sleutels moet beskerm word terwyl hulle aktief is, anders sal hul eienaar deur die teenstanders nageboots word. 'n Groot deel van pakketgebaseerde voorsieningskettingveldtogte begin met 'n gelekte sleutel/token. Onthou net voorvalle soos grootboek, 3CX, en vele meer, waar nie-interaktiewe geloofsbriewe eers in 'n voorlopige inbraak gesteel is vir die loodsing van die voorsieningskettingaanval.
Die reaksie op hierdie bedreiging was nie robuust genoeg nie. In die derde episode sal ons fokus op wat gewerk het en wat jammerlik misluk het. Die bedryf moet gesamentlik saamwerk aan die standards, prosesse, opleiding en gereedskap om risiko's vir globale voorsieningskettings te verminder. Dit is nie 'n probleem wat 'n enkele organisasie op sy eie kan oplos nie.
Om hierdie afdeling af te sluit, die deurslaggewende misverstand: ons praat oor kwaadwillige pakkette, nie kwesbaar Kwetsbaarhede kom van ontwerp- of koderingsfoute, wat per ongeluk ingebring word, sonder slegte bedoelings. Die kwesbaarhede kan uitgebuit word, maar baie word nie. Kwaadwillige pakkette is altyd opsetlik, en daar is 100% uitbuitbaarheid as hulle uitgevoer word. Geen vergelykbare risiko nie! Dus Dit is paradoksaal om te sien hoeveel pogings aangewend word om kwesbaarhede op te spoor en te verminder, en die gebrek aan ekwivalente maatreëls vir kwaadwillige komponente..
“Ons neem sekuriteit ernstig op”
Kom ons verbeel ons die gebruiklike Acme CorporationAcme, 'n belangrike verskaffer vir WileCoyote.com, kry die meeste van sy sagteware van derde partye, met meer as 80% van oopbron-bronprojekte. Hulle produseer sagteware vir interne gebruik, maar hulle verskaf ook sagteware vir hul vennote, verskaffers en kliënte/eindgebruikers. Acme het sagteware geskryf in Go, JavaScript, Java, C# en Python, en laat die meeste van sy sagteware op die wolk loop, onder Kuberneteskubernetes-groepe. Acme bou sy persoonlike beelde uit basisbeelde wat geneem is van Docker Hub en ander registers. En hulle deel ook 'n paar biblioteke, pakkette en houerbeelde in openbare registers.
Acme neem sekuriteit ernstig op. Hulle is redelik bewus van die probleem van open source security, en die risiko wat dit inhou. Alle ontwikkelaars, stelselbestuurders en DevOpsdevops-ingenieurs gebruik daardie oulike klein kripto-sleutels as tweede-faktor-verifikasie. Almal commits na kode-bewaarplekke word onderteken, takbeskerming word geaktiveer met verpligte kode-oorsigte, CI/CD gesluit, geheime gestoor in 'n geheime kluis, en met 'n interne register wat gedeeltelik eksterne registers weerspieël waar slegs die toegelate, witlys-komponente gestoor word. Dit word vereis dat sagteware wat deur Acme gebou is, derdeparty-afhanklikhede van hierdie register moet neem.
Waarskynlik pas die meeste organisasies in hierdie profiel. Geagte leser, joune pas beslis as jy al hier is, nie waar nie?
Toe, een ongelukkige dag, 'n belangrike frontend-ontwikkelaar by Acme gehardloop npm installeer acme-cute-lib, en vergeet dat @acme/cute-lib die regte afhanklikheid was. Die presiese fout is nie belangrik nie, baie dinge kan verkeerd loop selfs wanneer 'n mens perfekte beheer oor die sagtewarelewensiklus neem. Ons ontwikkelaar het nie geweet dat 'n APT-groep Acme geteiken het nie en het 'n kwaadwillige komponent onder daardie naam gepubliseer, op 'n slinkse manier sodat die kwaadwillige gedrag slegs aktiveer wanneer die sagteware op Acme-rekenaars geïnstalleer word. Die pakket is nie vir weke na die publikasie daarvan opgespoor nie.
'n Installasieskrip word uitgevoer wat soek na geloofsbriewe (daar was baie sappige toegangstokens in ons ontwikkelaar se skootrekenaar), wat toegang tot interne sagtewarebewaarplekke en die voorgenoemde interne bewaarplek, wat natuurlik slegs via VPN toeganklik is, toelaat. Die kwaadwillige kode het daarin geslaag om die bestaande VPN-verbinding te gebruik en 'n tweede-fase kwaadwillige komponent in die interne register te publiseer, wat 'n gemeenskaplike hulpprogramme-biblioteek beïnvloed wat deur die meeste sagteware wat deur Acme gelewer word, gedeel word.
Weke daarna het ander organisasies wat Acme se gepubliseerde gereedskap gebruik het, vreemde verkeer op hul netwerke begin sien, met verkeer wat Acme se protokol gebruik het, maar na gashere gerig is wat soos die Acme-domein lyk. Die verkeer was geïnkripteer, maar stelselmoniteringsinstrumente het toegang gevind tot onverwagte lêers en die uitvoering van prosesse wat soos stelselopdragte lyk, maar wat uiteindelik afgelaaide uitvoerbare lêers laat loop.
Die res is geskiedenis: Acme het eers ontken dat sulke gedrag aan hulle toegeskryf kon word en dat alle sekuriteitsmaatreëls in plek was. Eers nadat die kubersekmedia begin vra het waarom die bron van die opgespoorde gedrag van Acme se komponente afkomstig was, en sekuriteitsanalise geplaas het hoe deurspek daardie komponente met skelm wanware was, moes Acme die voorval herken en 'n voorvalreaksiefirma ontbied. 'n Negatiewe bemarkingsveldtog wat die welverdiende vertroue in 'n sekonde ondermyn het.Acme was een npm-installasie weg van disaster” was ’n algemene opskrif. Daarna het regsgedinge en gekanselleerde kontrakte gevolg.
Sien jy ooreenkomste met bekende vorige voorvalle? Acme het in twee fases 'n voorsieningskettingvoorval gehad, met behulp van 'n mengsel van afhanklikheidsverwarring/typosquatting Aanvalle wat 'n ontwikkelaarwerkstasie as 'n brughoof gebruik het om komponente te besmet wat in sagteware beland het wat deur derde partye gebruik word. Hoe kan dit voorkom of verminder word?
Waarom vergiftigde pakkette so gewild is
Hierdie hipotetiese voorval toon dat selfs met 'n redelike benadering tot oopbron-sekuriteit, organisasies spesifieke maatreëls benodig om te verhoed dat hulle slagoffer word van wanware in oopbron-komponente. Skematies kan die bedreigingsakteur:
- Skep 'n nuwe pakket (volgens die bekende typosquatting- of afhanklikheidsverwarringsroetes, is dit die mees deurkruiste pad deur die slegte ouens in volume);
- Probeer om 'n bestaande een te besmet, óf deur dit in bronkode in te spuit, óf deur dit as 'n bydraer te vermom via pull request, of sosiale manipulasie gebruik om 'n onderhouer te word (soos "Jao Tan" in die XZ Backdoor gedoen het of regs9ctrl GitHub-gebruiker het in die gebeurtenisstroom voorval in die herfs van 2018), of deur oopbron-bewaarplek-geloofsbriewe te verkry en die onderhouer na te boots;
- Spuit wanware in tydens die bou van die pakket, óf deur 'n kwaadwillige bouskrip uit te voer, of inmeng met pakketaflaaie met man-in-die-middel-onderskeppings (gelukkig word TLS nou altyd in die meeste registers vereis).
- Spuit die verpakte komponent direk in die register in, tipies deur die registerbewyse vas te lê (die voorkeuralternatief vir baie gesofistikeerde aanvalle soos Acme s'n, waar die gekompromitteerde werkstasie in die eerste fase die interne registertoegangstoken gehad het, bv. in die gewone .a V or ~/.m2/instellings.xml: slegte akteurs weet wel waar om vir geheime te soek). Kwetsbaarhede in die registers is ook uitgebuit.
Die vergiftiging van registers met wanware is die basis vir afhanklikheidsaanvalle. Niks nuuts onder die son nie: die voorkoms daarvan het ontplof, maar dieselfde tegnieke werk nou as vyf jaar gelede.
Bron: Rugsteker se Mesversameling.
Die kwaadwillige pakket kan tydens installasie, tydens sagtewarebou of tydens looptyd funksioneer. En die gedrag wissel van inligting-uitfiltrasie, bv. die onttrekking van geheime vir 'n tweede fase-poging, tot bronkode-onttrekking en die verwydering van bykomende wanware. In die volgende episode sal ons die kwaadwillige pakkette ontleed en hoe hulle gepubliseer word.
Verdere leeswerk
Die volgende episode Anatomie van Kwaadwillige Pakkette: Wat is die Tendense? sal fokus op werklike gevalle wat ons dag na dag monitor met ons Malware Early Warning-stelsel. Ons sal hersien watter tipes malware gesien is, en watter taktieke, tegnieke en prosedures die gunstelinge is. Ons sal verdoeseling ondersoek en hoe hulle probeer wegkruip van potensiële beoordelaars, die ontduikingstegnieke om opsporing te vermy, en hoe hulle ontwikkel met telemetrie en laterale beweging. Bly asseblief ingeskakel!
Verwysings
- Rugsteker se Knyfversameling: 'n Oorsig van Aanvalle op die Voorsieningsketting van OopbronsagtewareM. Ohm et al., Mei 2020.
- Oopbron-wanwarebeskermingWitboek van Xygeni.
- Software Supply Chain Security Terugskouing: Die vorming van 'n veiliger 2024Verslag van Xygeni.
