Dette er den tredje episode i en række artikler om den mest udbredte form for softwareforsyningskædeangreb: dem, der misbruger et offentligt register over open source softwarekomponenter. Efter at have analyseret i den forrige episode “Anatomien af skadelige pakker: Hvad er tendenserne?"hvordan de ondsindede aktører injicerer ondsindet adfærd i nye eller eksisterende publicerede komponenter, er vi klar til at tage vores brandbekæmpelsesveste på og undersøge, hvordan vi med succes kan blokere skadelig software, der leveres på denne måde, eller alternativt håndtere en potentielt alvorlig cyberhændelse, fordi vi har valgt den forkerte fremgangsmåde."
De fleste sikkerhedsbevidste fagfolk har ideer til, hvordan man håndterer denne trussel. Vi har hørt sikkerhedschefer sige uden tøven, at SCA Værktøjer fortæller dig allerede, hvornår en pakkeversion er malware. Eller at de er afhængige af velkendte, velrenommerede softwarekomponenter, hvor enhver malware straks ville blive opdaget og fjernet. De bruger åbne mindre/patch-versioner til automatisk at få rettelser til sårbarheder, og det er den korrekte, anbefalede måde at mindske risikoen for open source-afhængigheder, i henhold til "lapp tidligt, lapp ofte”-Princippet.
I denne episode vil vi gennemgå, hvorfor disse ideer er forkerte, og hvordan sådanne misforståelser bidrager til populariteten af denne angrebsmekanisme og til en overvældende risiko, som organisationer oplever. Vi vil afslutte med, hvad der virker, og hvilket er den involverede indsats og de involverede ressourcer.
Almindelige misforståelser
Under vores rejse med softwaresikkerhed så vi angrebsteknikkerne udvikle sig og en bred vifte af ideer fra sikkerhedsbevidste personer. Organisationer misforstår ofte, hvad der virker mod denne trussel, så først vil vi undersøge, hvad der ikke virker, samlet i den følgende, ikke udtømmende, liste over misforståelser.
Misforståelse nr.1: SCA Værktøjer rapporterer allerede skadelige komponenter
Ja! Men efter det faktum... Når det sandsynligvis er for sent, hvis elementet blev brugt i en softwareudvikling, og de ondsindede aktører allerede har fået fodfæste hos en udvikler eller CI/CD vært. Hemmeligheder kan være blevet eksfiltreret, yderligere malware kan være downloadet og installeret, og måske har modstanderen bevæget sig sidelæns og allerede fået adgang et andet sted.
Analyse af softwarekomposition (SCA)-værktøjer blev designet til at identificere potentielle kendte sårbarheder. Moderne værktøjer gør et fantastisk stykke arbejde ved at forstærke signal-støj-forholdet og afgøre, om sårbarheden rent faktisk er tilgængelig eller udnyttelig. Men de er ubrugelige mod ny malware. Tænk på en ondsindet komponent som en zero-day-sårbarhed: Først når dens ondsindede adfærd registreres, rapporteres komponenten til det registrerede register, som efter en gennemgang af et sikkerhedsteam bekræftes som ondsindet og fjernes fra registret. [1].
På det tidspunkt var verden (inklusive SCAs) ved, at det ikke er en god ting at installere eller bruge komponenten (eller en eller flere versioner af en eksisterende komponent). Men dette er tilfældet, når komponenten ikke er tilgængelig fra registreringsdatabasen.Det er godt at vide, at jeg har sårbarheder i tredjepartskomponenter, eller endda komponenter, der er blevet kategoriseret som skadelige af registreringsdatabasen, men desværre SCA eller almindelige revisionsværktøjer hjælper ikke i denne sammenhæng. Medmindre SCA/audit-værktøjet kan virkelig vide på forhånd, at en komponent er skadelig, før den bruges i din organisation.
Husk, at enhver løsning mod ondsindede open source-komponenter skal opdage dem. på farten, mellem det tidspunkt, hvor komponenten publiceres i registreringsdatabasen, og det tidspunkt, hvor komponenten (versionen) bruges første gang i din organisation. Og det inkluderer transitive komponenter.
Misforståelse nr. 2: Kontrol af installationsscripts under byggetid forhindrer ondsindet adfærd fra open source-komponenter
Forskellige pakkehåndteringsprogrammer tilbyder muligheden for at køre scripts (inkluderet i komponenten tarball [2]), af legitime årsager, såsom at kompilere nødvendige elementer på forskellige platforme, generere kode eller køre tests, og vi bør alle vide, at de kan misbruges af ondsindede aktører, hvis ondsindede scripts er inkluderet i tarballen, eller hvis angriberen kan få et ondsindet script til at køre i stedet for det gode.
Med dette i tankerne kan vi konfigurere pakkehåndteringen til at ignorere scripts. For eksempel med NPM –Ignorér-scripts flag (eller en konfigurationsegenskab i .npmrc fil) springer scripts over under installationen. Dette kan give nogle problemer, fordi det er almindeligt at køre scripts i mange økosystemer: Nogle pakkeadministratorer tillader ikke engang deaktivering af scriptkørsel (hint: prompt "Hvilke pakkeadministratorer tillader ikke deaktivering af udførelsen af installationsscripts?" i din foretrukne AI). Men dette beskytter ikke generelt (vi er nødt til at håndhæve, at konfigurationen for deaktivering af spring over er overalt).
Og når den ondsindede adfærd ikke findes i installationsscripts, men i softwaren, der skal udføres under kørsel, beskytter denne mulighed os ikke alene.
Misforståelse nr. 3: Versionsfastgørelse forhindrer installation af skadelige komponenter
Der er en afvejning mellem at patche tidligt og ofte med åbne versioner (lader pakkehåndteringen automatisk installere nye opdateringer, når de er tilgængelige for sikkerhedsrettelser) og versionsfastgørelse (har alle de direkte og transitive afhængigheder for software i en fast version). Sikkerhedsprincipperne er stædige og til tider modstridende, som det sker med "patch tidligt, patch ofte" og "Opgradering bør ikke tages let på"Nogle pakkeadministratorer foretager automatiske opdateringer med serverintervaller på den anbefalede måde. Fantastisk, hvis du også vil modtage de skadelige opdateringer! Ja, komponenter skal opdateres for at modtage sikkerhedsrettelser, der lukker sårbarheder så hurtigt som muligt, men ... lad aldrig pakkeadministratoren gøre dette automatisk.
Misforståelse nr. 4: Det er sikkert at bruge betroede komponenter. Enhver skadelig version vil straks blive fundet, afsløret og fjernet.
Hvorfor er en komponent betroet? Muligvis fordi den er meget populær, med mange øjne, der leder efter sårbarheder, et stort antal bidragydere til vedligeholdelse, med flere kernevedligeholdere, der omhyggeligt gennemgår alle pull requestsVirkeligheden er en helt anden. Nogle essentielle komponenter vedligeholdes af en enkelt, ulønnet udvikler. Udbredte frameworks har et par faste bidragydere, med et hurtigt faldende antal commits pr. vedligeholder (populære projekter har en lang hale af bidragydere, der udfører nogle drive-by commit og aldrig komme tilbage). Og populære projekter med en enkelt vedligeholder findes i overflod.
Forestil dig selv at sige "Åh, vi bruger Spring Boot / Angular / React / PyTorch / officielle Docker-base-images, så den risiko, du taler om, er ret lav." Måske er det sandt, vi sikkerhedsleverandører, der skræmmer os hele tiden og blander os i udviklingsteams for at afbøde en diskutabel risiko, er nonsens. Du kan blive fristet til at hoppe til afsnittet om risikoaccept (i næste afsnit) og være færdig. Desværre er de mest populære komponenter mål for ondsindede aktører, og for eksempel de populære PyTorch-biblioteket blev angrebet tidligere.
"Omgående fundet, afsløret og fjernet". Det tager dage for en ny skadelig komponent at blive fjernet fra det offentlige register. Registre er forsigtige med at fjerne en komponentversion, for at gøre det bedre. Vores erfaring er, at når den først er rapporteret fra vores side, er den gennemsnitlige tid for registret at fjerne den berørte version 39 timer, mere end halvanden dag. Der er skadelige komponenter, der fjernes en uge efter vores første rapportering i registret. Og i nogle tilfælde fjernes komponenten først, efter at et offer eller et incident response-firma rapporterer en hændelse, der involverer komponenten.
Hvad virker IKKE mod skadelige komponenter
Enhver uspecifik tilgang vil mislykkes fatalt. Det er helt sikkert, at du ikke sørger for effektive modforanstaltninger mod den risiko, der er forbundet med denne trussel.
Traditionel SCA Værktøjer fortæller dig om kendt malware, men har et stort eksponeringsvindue. Medmindre de proaktivt udfører malwaredetektion med tvungen blokering af ondsindede komponenter, virker de ikke mod denne trussel.
Deaktivering af installationsscripts kan hjælpe, men det skal håndhæves overalt, hvor en komponent skal installeres. Det samme gælder versionsfastlåsning, da versioner ikke kan fastlåses fra en sikker starttilstand for evigt.
At antage, at populære komponenter får nok opmærksomhed til, at de ikke kan injiceres med utilsigtet adfærd i et forsyningskædeangreb uden en næsten øjeblikkelig detektion for at forhindre skade, er naivt og risikabelt. Du vil vel ikke leve på kanten?
Hvis du stopper på dette tidspunkt, så risikoaccept er det eneste, du kan gøre: Dette er en decision, der skal dokumenteres i din trusselsmodel/risikovurdering, herunder begrundelsen for at acceptere risikoen og dens potentielle konsekvenser. Øg bevidstheden ved at kommunikere den til ledelsen og andre relevante parter. Nogle uforudsete kunne planlægges, når en skadelig komponent installeres eller inkluderes i din software, men dette er vanskeligt, fordi angribere har mange veje at følge. Detaljerne i et forsyningskædeangreb baseret på brugen af en skadelig komponent vil drastisk ændre den offentlige offentliggørelse af hændelsen, hvilket sandsynligvis er obligatorisk i henhold til din organisations lovgivningsmæssige rammer. Du kan også adressere kompenserende kontroller or overførselsrisiko fx med forsikring.
Der er dog kontrolforanstaltninger, der adresserer truslen, og som bør overvejes, hvis du ikke er tilfreds med risikoaccepten. Læs videre.
Hvad virker mod angreb med ondsindede komponenter
Håndtering af Solid-version
Versionsfastlåsning med kontrollerede og informerede versionsbumps er vejen frem for at afbalancere behovet for at fjerne sårbarheder uden at modtage malware. Men husk misforståelse nr. 3: Versionsfastlåsning alene er ikke tilstrækkeligt til at blokere ondsindet kode fra nye versioner, fordi du i fremtiden bliver nødt til at opdatere versioner i enhver direkte eller indirekte afhængighed. På det tidspunkt har du brug for stærke beviser for, at alle ændrede versioner ikke indeholder malware.
Tidlig advarsel
En tilgang til problemet med skadelige komponenter er et tidligt varslingssystem (her kaldet Tidlig advarsel om malware eller MEW), hvor nye udgivede versioner (for nye eller eksisterende komponenter) analyseres af en detektionsmotor, som, når der findes tilstrækkeligt bevismateriale, kan klassificere den nye version som potentielt skadelig.
Automatisering er afgørende her, da det er umuligt manuelt at gennemgå alle de nye komponenter med den nuværende publiceringshastighed. Så detektionsmotoren skal kombinere en række forskellige teknikker, måske inklusive statisk, dynamisk og funktionsanalyse, brugeromdømme og beviser fra uoverensstemmelser mellem komponentmetadataene og tarball-indholdet, eller mellem tarball og kildearkivet, hvor komponenten angiveligt kommer fra.
Der er en mørk zone mellem udgivelsestidspunktet og hvornår motoren analyserer komponentindholdet, men det bør ikke overstige et par minutter. Skemaet kan ændres, for eksempel ved at vente på, at nye komponenter analyseres, før de tillades at blive installeret og brugt i softwareopbygningen. pipelines, eller analyser dem efter behov. En komponent i en given version er uforanderlig [3], så den behøver kun at blive analyseret én gang.
Fuld automatisering er ikke mulig, og en sikkerhedsgennemgang for potentielt skadelige komponenter er nødvendig. Pas på fortalere for digitale universalmidlerAI og maskinlæring er ikke udviklede nok til at få det sidste ord, når det kommer til at bekræfte, om en mistænkelig komponent indeholder malware. Maskinlæring spiller selvfølgelig en nøglerolle i detektionsmotoren ved at klassificere inputkomponenten ud fra de rå beviser, der er indsamlet, men når komponenten er "sat i karantæne", er det sidste ord ved den manuelle gennemgang foretaget af et sikkerhedsteam med erfaring i ondsindede komponenter. Dette bekræfter enhver potentiel malware eller omklassificerer den som sikker. Og tidsperioden er i timernes intervaller.
Registreringsdatabasen rapporterer om den skadelige version/komponent; registreringsdatabasen udfører derefter sin gennemgang for at bekræfte og fortsætter med offentliggørelse og fjernelse fra registret. Nogle registre opbevarer en sikkerhedspakke. Tidsintervallet her er dagene eller ugerne siden offentliggørelsen, hvilket er 'opholdstid'eller'eksponeringsvindue' for de fleste ondsindede komponenter.
Er det muligt at vide, om en komponentversion er skadelig?
Så for at kunne give tidlig varsling er vi nødt til at give et tilfredsstillende svar på dette spørgsmål: Hvordan kan jeg vide, at et bibliotek eller en pakke er (ikke) skadelig? Hvordan indsamler jeg nok beviser for ondsindet adfærd? Muligt, men vanskeligt, da modstanderne bruger meget opfindsomhed for at undgå opdagelse. Der er forskellige tilgange, hver med fordele og ulemper.
Statisk analyse kan undersøge alle udførelsesstier, kontrollere for teknikker brugt af angribere uden at køre komponenten og udføre forbehandlingsopgaver som de-obfuskation eller dechifrering. Når angribere forsøger at skjule deres ondskab, er obfuskationsforsøg faktisk bevis på malware (men bemærk, at legitime komponenter tilslører kode for at bevare intellektuel ejendom, hvilket modsiger "open source”). Kun et mindretal af meget sofistikerede angreb med stærk obfuskation behøver sandboxing, men sådan stærk obfuskation er et afslørende tegn på ondsindethed. Bemærk venligst, at konventionelle SAST Værktøjer blev designet til utilsigtede sårbarheder, ikke til ondsindede hensigter som bagdøre.
Dynamisk analyse kører komponenten og undersøger responsen ved at instrumentere runtime, typisk ved at tilbyde et sandkassemiljø. Ondsindet adfærd, der udløses under visse betingelser, kan gå ubemærket hen: Bemærk venligst, at malware kan bruge undvigelsesteknikker som Virtualisering/Sandbox Evasion kun at aktivere, når den ikke er under opsyn, og også et afslørende tegn på ondsindet aktivitet for enhver statisk analysemaskine.
Kompetenceanalyse overvejer, hvad komponenten gør: hvor den opretter forbindelse til, hvilke filer den tilgår, hvilke kommandoer eller programmer der køres, hvilken terminal- eller enheds-I/O der udføres, eller hvilke systemkald der påkaldes. Denne fingeraftryksanalyse af adfærd kan sammenlignes (for en eksisterende komponent) på tværs af versioner, så når uventet adfærd registreres, kan dette bevis give anledning til mistanke om potentiel ondsindet aktivitet, der er injiceret i den nye version. Denne tilgang følger de triagetrin, som sikkerhedsanalytikere følger, når de står over for potentiel malware: en inspektion ved hjælp af strygere eller lignende værktøjer. Denne tilgang registrerer ondsindet adfærd uanset udløsende betingelser og fungerer, når der ikke er kildekode tilgængelig.
Kontekstanalyse indsamler oplysninger om, hvordan komponenten blev udgivet, og af hvem. Kampagner fra ondsindede aktører bruger ofte en eller flere nye brugerkonti, der ikke er underlagt nogen streng godkendelsesproces. Sporing af tidligere aktivitet kan give indsigt i den underliggende bruger, primært for anomalier, der kan antyde en potentiel kompromittering. Omdømme er så svært at opbygge og så let at miste! En bruger uden tidligere aktivitet er neutral, men karma forfølger de ondsindede. Hacktivister eller normale brugere, der får deres udgivelsesoplysninger stjålet, bør spores omhyggeligt.
En anden kontekstuel information er enhver uoverensstemmelse mellem kildearkivet, der angiveligt bruges til at oprette komponent-tarballen, og indholdet af selve tarballen. Og også at følge god praksis, såsom at oprette tags eller udgivelser i kildearkivet, der matcher de versioner af komponenten, der er offentliggjort i det offentlige register. Når kildearkivet på et bestemt commit er tagget med udgivelse, og så pludselig én version ikke følger den, er det alene stærkt bevis på, at komponenten kan være inficeret: den ondsindede aktør har muligvis kompromitteret den konto, der bruges til at udgive komponenten, men har ingen skrivetilladelser i kildekodearkivet). Mange angreb detekteres rutinemæssigt ved hjælp af disse regler: for eksempel Ledger-angreb kunne let opdages på denne måde. Kontekstanalyse identificerer derfor sådanne anomalier i udgivelsesprocessen.
Afhængighedsfirewalling
En anden tilgang er at have en omfattende hvidliste over komponenter til alle afhængighedsgrafer, der bruges i din software, så i ethvert build pipeline I din organisation kan kun godkendte komponentversioner installeres og bruges.firewall"håndhæves ved hjælp af et internt register, hvor tar-filer for de tilladte komponentversioner serveres (cachelagret eller via proxy). Bemærk venligst, at enhver hvidliste ikke vil fungere, medmindre du har teknologien til at klassificere enhver ny version som rimelig sikker, så den kan føjes til hvidlisten.
Bemærk venligst, at tidlig advarsel (hurtig detektion så hurtigt som muligt efter udgivelsen af den nye version) skal kombineres med en måde at bruge disse oplysninger proaktivt til at blokere den komponent, der påvirker buildet. pipelines eller udviklernes maskiner [4]Vi kalder dette “afhængighedsfirewalling": en karantænemekanisme til at beskytte automatiserede builds mod ondsindede pakker. Interne pakker og billedregistre er gode til at isolere organisationer fra ydre ondskab, men stærk nok bevismateriale er nødvendigt for at gøre karantænen effektiv.
Runtime-sandboxing
En alternativ tilgang til detektion på udgivelsestidspunktet er at analysere adfærd under kørsel. Ideen er at registrere den forventede adfærd fra softwaren og detektere (eller blokere) eventuelle fundne anomalier. Denne fremgangsmåde har problemet med at skulle instrumentere kørselstiden til overvågning eller blokering, og det er en lovende idé, der vil blive føjet til arsenalet af beskyttelsesmekanismer mod skadelige komponenter.
Fastlæggelse af en omfattende strategi
Den anbefalede strategi skal kombinere forskellige teknikker i softwareudviklingsprocessen og tage kontrol over versionsopdateringer for at blokere indgående skadelige komponenter. Vi skal imødekomme versionslåsning for at undgå automatisk infektion med opdateringer af versioner for at få rettelser til de sårbarheder, der er vigtige; en hurtig og effektiv vurdering af direkte og indirekte afhængigheder under versionsopdateringer for at have tilstrækkeligt bevis for, at de ikke er malware-inficerede. Softwareversioner, der er afhængige af kendte skadelige komponenter, skal blokeres. Og alt skal håndhæves.
Brug versionsfastgørelse, når det er muligt, da det gør builds mere reproducerbare. Versionsfastgørelse med kontrollerede, manuelt godkendte versionsbumpsog assisteret af hjælpeteknologi, bør vurdere, om opdateringen medfører malware eller ødelægger softwaren, og forene opdatering til udbedring af sårbarheder med at undgå malwareinfektion. Værktøjer kan hjælpe her ved (1) at prioritere, hvilke sårbarheder der virkelig betyder noget (tilgængelige og udnyttelige, med en høj risiko for at blive mål for angribere), (2) at vælge de målversioner, der er kompatible med den nuværende komponentanvendelse og ikke ødelægger softwaren, (3) at vælge målversioner, der ikke indeholder ondsindet adfærd, og (4) at gøre versionsopdateringen for direkte og indirekte afhængigheder til en leg ved at foreslå ændringer i manifestfilerne, der hurtigt kan godkendes. Trin (3) har brug for specifikke oplysninger om ondsindede komponenter så tæt på deres udgivelsestidspunkt som muligt.
Denne proces med at opdatere afhængigheder skal være håndhæves og verificeres på alle steder. Processen skal dokumenteres, og alle involverede parter bør trænes, da udvikling og softwareopbygning/implementering ofte eksternaliseres. CI/CD pipelines bør ændres i overensstemmelse hermed, så automatisering ikke tillader en ondsindet indirekte afhængighed at glide ind i buildet: guardrails At blokere buildet, hvis der er tilstrækkeligt bevis for potentiel malware i en afhængighed, er den anbefalede fremgangsmåde.
Hvis din organisation har et internt register, der fungerer som en sikkerhedsproxy for at indeholde de tilladte komponentversioner, skal du indhente oplysninger om skadelige komponenter (ud over andre kriterier) for at kunne godkende en anmodet komponent, før du tilføjer den til listen over tilladte versioner.
Det er ikke nemt at bruge open source-software på en sikker måde, og malware-faktoren skal tages fuldt ud i betragtning, og der skal lægges en tilsvarende indsats i håndteringen af sårbarheder.
En sidste note: Kildens oprindelse, i form af softwareattestationer, genereret på komponentens byggetidspunkt, er et andet vigtigt element i bestræbelserne på at spore artefakten (komponent-tarball) med kilderne og byggeprocessen, der producerede den. Bemærk, at denne forbindelse mellem kilde-snapshottet + byggemiljøet og den tilhørende softwareartefakt (signeret af det betroede byggesystem) ikke i sig selv forhindrer, at komponenten ikke indeholder ondsindet adfærd, men gør det sværere for de onde at injicere malware. Og det vil tage lang tid at gøre proveniensvalidering til et almindeligt krav for at forbruge open source-komponenter, og kun ... for nylig tilføjet til NPMAt gøre disse betroede build- og implementeringssystemer manipulationssikre, eller at muliggøre detektering af manipulation i buildet, er en anden historie, der ligger uden for dette indlægs rammer.
Yderligere læsning
Den næste episode Open Source-skadelige pakker: Xygeni-tilgangen vil præsentere den strategi, vi følger hos Xygeni for vores Tidlig advarsel om malware (MEW) system. Nye pakkeversioner i de offentlige pakke- og billedregistre scannes, og bevismateriale indhentes ved hjælp af en kombination af statisk, dynamisk, funktions- og kontekstuel analyse. Bevismaterialet, kombineret med brugeromdømme og historikken over ændringer i kildekodelagre, muliggør en fuldt automatiseret klassificering af en komponent i højrisiko- og sandsynligvis skadelige kategorier. Systemet lærer af tidligere bevismateriale indsamlet fra pakker for at reducere falske positiver til et minimum.
Abonnenter modtager en advarsel om komponenter, de bruger, direkte eller indirekte, når en skadelig version kategoriseres. Derefter udfører vores analytikere en manuel analyse, som bekræfter eller afviser klassificeringen. For bekræftet malware underrettes det offentlige register, så det kan udføre sin egen analyse og typisk fjerne den skadelige version eller foretage yderligere handlinger, såsom at blokere eller fjerne den pågældende brugerkonto.
Vi vil forklare, hvordan vi hjælper NPM, PyPI, GitHub og andre vigtige infrastrukturer i open source-økosystemet med at reducere den tid, en ny, skadelig komponent, der udgives, forbliver aktiv, indtil den er bekræftet som malware og fjernet fra registreringsdatabasen. Og hvordan organisationer kan drage fordel af MEW-systemet for at få en langt bedre beskyttelse mod angreb i softwareforsyningskæden, der involverer open source-komponenter.
- [1] Under alle omstændigheder skal brugere af komponenten kontrollere, om komponentens tar-fil er cachelagret eller registreret et sted, for eksempel i et internt register, så sygdommen udryddes.
- [2] Den pakkede komponent indeholder et manifest, der deklarerer dens indhold og metadata, kildekode eller kompileret kode, installationsscripts og yderligere elementer såsom testpakker, i henhold til et pakkeformat og typisk i komprimeret form. Dette kaldes "komponent-tarball".
- [3] Selv hvis den ondsindede aktør kan ændre en publiceret komponent på grund af et brud i selve registreringsdatabasen, kan en almindelig kryptografisk digest registrere enhver ændring i tar-filen, efter at analysen er udført.
- [4] Husk at nogle ondsindede komponenter kører under installationen, så det kan påvirke udviklerknuder, der uforvarende kører "npm install X" med X som en ondsindet komponent.
