Dette er den tredje episoden i en serie artikler om den vanligste typen angrep på programvare i forsyningskjeden: de som misbruker et offentlig register over åpen kildekode programvarekomponenter. Etter å ha analysert i forrige episode «Anatomien til skadelige pakker: Hva er trendene?«hvordan de ondsinnede aktørene injiserer ondsinnet oppførsel i nye eller eksisterende publiserte komponenter, er vi klare til å ta på oss brannvestene våre og undersøke hvordan vi kan blokkere skadelig programvare som leveres på denne måten, eller alternativt håndtere en potensielt alvorlig cyberhendelse fordi vi tok feil tilnærming.»
De fleste sikkerhetsbevisste fagfolk har ideer om hvordan de skal håndtere denne trusselen. Vi har hørt sikkerhetsledere si uten å nøle at SCA Verktøy forteller deg allerede når en pakkeversjon er skadelig programvare. Eller at de er avhengige av kjente, høyt anmeldte programvarekomponenter, der all skadelig programvare raskt ville blitt oppdaget og fjernet. De bruker åpne mindre/oppdateringsversjoner for automatisk å få sikkerhetsrettinger, og det er den riktige, anbefalte måten å redusere risikoen for avhengigheter av åpen kildekode, i henhold til «lapp tidlig, lapp ofte”Prinsippet.
I denne episoden skal vi gjennomgå hvorfor disse ideene er feil, og hvordan slike misoppfatninger bidrar til populariteten til denne angrepsmekanismen, og til en overveldende risiko som organisasjoner opplever. Vi avslutter med hva som fungerer, og hva som er innsatsen og ressursene som er involvert.
Vanlige misoppfatninger
Under vår reise med programvaresikkerhet så vi angrepsteknikkene utvikle seg og et bredt spekter av ideer fra sikkerhetsbevisste personer. Organisasjoner misforstår ofte hva som fungerer mot denne trusselen, så først skal vi undersøke hva som ikke fungerer, forkortet i den følgende, ikke uttømmende, listen over misoppfatninger.
Misforståelse #1: SCA Verktøy rapporterer allerede skadelige komponenter
Faktisk! Men etter det faktum… Når det sannsynligvis er for sent hvis elementet ble brukt i en programvarebygging, og de ondsinnede aktørene allerede har fått fotfeste hos en utvikler eller CI/CD vert. Hemmeligheter kan ha blitt eksfiltrert, ytterligere skadelig programvare kan ha blitt lastet ned og installert, og kanskje motstanderen har beveget seg sidelengs og allerede fått tilgang andre steder.
Analyse av programvarekomposisjon (SCA)-verktøy ble utviklet for å identifisere potensielle kjente sårbarheter. Moderne verktøy gjør en god jobb ved å øke signal-støy-forholdet, og avgjøre om sårbarheten faktisk er tilgjengelig eller utnyttbar. Men de er ubrukelige mot ny skadelig programvare. Tenk på en ondsinnet komponent som et nulldagssårbarhet: Først når den ondsinnede oppførselen oppdages, rapporteres komponenten til det lagrede registeret, som etter en gjennomgang av et sikkerhetsteam bekreftes som skadelig og fjernes fra registeret. [1].
På det tidspunktet, verden (inkludert SCAs) vet at det ikke er bra å installere eller bruke komponenten (eller en eller flere versjoner av en eksisterende komponent). Men dette er når komponenten ikke er tilgjengelig fra registeret.Det er bra å vite at jeg har sårbarheter i tredjepartskomponenter, eller til og med komponenter som ble kategorisert som skadelige av registeret, men dessverre SCA eller vanlige revisjonsverktøy hjelper ikke i denne sammenhengen. Med mindre SCA/audit-verktøyet kan virkelig vite på forhånd at en komponent er skadelig før den brukes i organisasjonen din..
Husk at enhver løsning mot ondsinnede komponenter med åpen kildekode må oppdage dem på farten, mellom når komponenten publiseres i registeret og når komponenten (versjonen) brukes for første gang i organisasjonen din. Og det inkluderer transitive komponenter.
Misforståelse nr. 2: Kontroll av installasjonsskript under bygging forhindrer ondsinnet oppførsel fra komponenter med åpen kildekode
Ulike pakkebehandlere tilbyr muligheten til å kjøre skript (inkludert i komponenten tarball [2]), av legitime grunner, som å kompilere nødvendige elementer på forskjellige plattformer, generere kode eller kjøre tester, og vi bør alle vite at de kan misbrukes av dårlige aktører hvis ondsinnede skript er inkludert i tarballen, eller hvis angriperen kan få et ondsinnet skript til å kjøre i stedet for det gode.
Når vi vet dette, kan vi konfigurere pakkebehandleren til å ignorere skript. For eksempel, med NPM –Ignorer-skript flagg (eller en konfigurasjonsegenskap i .npmrc file) hopper over skriptene under installasjonen. Dette kan føre til noen problemer fordi det er vanlig å kjøre skript i mange økosystemer: Noen pakkebehandlere tillater ikke engang deaktivering av skriptkjøring (hint: prompt “Hvilke pakkebehandlere tillater ikke deaktivering av kjøring av installasjonsskript?«i din favoritt-AI). Men dette beskytter ikke generelt (vi må håndheve at konfigurasjonen for deaktivering av hopp over er overalt).
Og når den ondsinnede oppførselen ikke finnes i installasjonsskript, men i programvaren som skal kjøres under kjøring, beskytter ikke dette alternativet alene oss.
Misforståelse nr. 3: Versjonslåsing forhindrer at skadelige komponenter installeres
Det er en avveining mellom å patche tidlig og ofte med åpne versjoner (la pakkebehandleren automatisk installere nye oppdateringer når de er tilgjengelige for sikkerhetsrettelser) og versjonslåsing (har alle de direkte og transitive avhengighetene for programvare i en fast versjon). Sikkerhetsprinsippene er sta og noen ganger motstridende, slik som skjer med «oppdater tidlig, oppdater ofte» og «Oppgradering bør ikke tas lett på»Noen pakkebehandlere oppdaterer automatisk med serverområder på anbefalt måte. Flott hvis du også vil motta skadelige oppdateringer! Ja, komponenter må oppdateres for å motta sikkerhetsrettinger som lukker sårbarheter så snart som mulig, men … la aldri pakkebehandleren gjøre dette automatisk.
Misforståelse nr. 4: Det er trygt å bruke pålitelige komponenter. Enhver skadelig versjon vil bli funnet, avslørt og fjernet umiddelbart.
Hvorfor er en komponent klarert? Muligens fordi den er svært populær, med mange som ser etter sårbarheter, et stort antall bidragsytere til vedlikehold, med flere kjernevedlikeholdere som nøye gjennomgår alle pull requestsRealiteten er ganske annerledes. Noen viktige komponenter vedlikeholdes av én enkelt, ulønnet utvikler. Mye brukte rammeverk har noen få faste bidragsytere, med et raskt synkende antall commits per vedlikeholder (populære prosjekter har en lang hale av bidragsytere som utfører noen drive-by-besøk) commit og aldri komme tilbake). Og populære prosjekter med én enkelt vedlikeholder florerer.
Tenk deg at du sier «Å, vi bruker Spring Boot / Angular / React / PyTorch / offisielle Docker-basebilder, så risikoen du snakker om er ganske lav.» Kanskje det er sant, vi sikkerhetsleverandører som skremselspropaganderer hele tiden, og blander oss inn i utviklingsteam for å redusere en diskutabel risiko er tull. Du kan bli fristet til å hoppe til avsnittet om risikoaksept (i neste avsnitt) og være ferdig. Dessverre er de mest populære komponentene mål for skurker, og for eksempel de populære PyTorch-biblioteket ble angrepet i det siste.
«Umiddelbart funnet, avslørt og fjernet». Det tar dager før en ny skadelig komponent fjernes fra det offentlige registeret. Registere er forsiktige med å fjerne en komponentversjon, for det bedre. Vår erfaring er at når den er rapportert fra vår side, er mediantiden for registeret å fjerne den berørte versjonen 39 timer, mer enn halvannen dag. Det finnes skadelige komponenter som fjernes én uke etter vår første rapportering i registeret. Og i noen tilfeller fjernes komponenten først etter at et offer eller et hendelsesresponsselskap rapporterer en hendelse som involverer komponenten.
Hva fungerer IKKE mot skadelige komponenter
Enhver uspesifikk tilnærming vil mislykkes fatalt. Dette er helt sikkert, du tilbyr ikke effektive mottiltak for risikoen forbundet med denne trusselen.
Tradisjonelle møbler SCA Verktøyene forteller deg om kjent skadelig programvare, men har et stort eksponeringsvindu. Med mindre de proaktivt utfører skadelig programvaredeteksjon med tvungen blokkering av skadelige komponenter, fungerer de ikke mot denne trusselen.
Deaktivering av installasjonsskript kan hjelpe, men må håndheves overalt hvor en komponent må installeres. Det samme gjelder versjonslåsing, ettersom versjoner ikke kan låses fra en sikker starttilstand for alltid.
Å anta at populære komponenter får nok oppmerksomhet til at de ikke kan injiseres med utilsiktet oppførsel i et forsyningskjedeangrep uten en nesten umiddelbar deteksjon for å forhindre skade er naivt og risikabelt. Du vil vel ikke leve på kanten?
Hvis du stopper på dette tidspunktet, da risikoaksept er det eneste du kan gjøre: Dette er en decissjon som må dokumenteres i trusselmodellen/risikovurderingen, inkludert begrunnelsen for å akseptere risikoen og dens potensielle implikasjoner. Øk bevisstheten ved å kommunisere den til ledelsen og andre relevante parter. Noen beredskap kan planlegges når en skadelig komponent installeres eller inkluderes i programvaren din, men dette er vanskelig fordi angripere har mange veier å følge. Detaljene i et forsyningskjedeangrep basert på bruk av en skadelig komponent vil drastisk endre offentliggjøringen av hendelsen, noe som sannsynligvis er obligatorisk i henhold til organisasjonens regelverk. Du kan også ta opp kompenserende kontroller or overføringsrisiko f.eks. med forsikring.
Det finnes imidlertid kontroller som håndterer trusselen, og disse bør vurderes hvis du ikke er fornøyd med risikoaksepten. Les videre.
Hva fungerer mot angrep som bruker skadelige komponenter
Håndtering av solid versjon
Versjonslåsing med kontrollerte og informerte versjonsoppdateringer er veien å gå, for å balansere behovet for å fjerne sårbarheter uten å motta skadelig programvare. Men husk misforståelse nr. 3: Versjonslåsing alene er ikke nok til å blokkere skadelig kode som kommer fra nye versjoner, fordi du i fremtiden må oppdatere versjoner i enhver direkte eller indirekte avhengighet. I det øyeblikket trenger du sterke nok bevis for at alle modifiserte versjoner ikke inneholder skadelig programvare.
Tidlig advarsel
En tilnærming til problemet med skadelige komponenter er et tidlig varslingssystem (her kalt Tidlig advarsel om skadelig programvare eller MEW), der nye publiserte versjoner (for nye eller eksisterende komponenter) analyseres av en deteksjonsmotor, som når det finnes nok bevis, kan klassifisere den nye versjonen som potensielt skadelig.
Automatisering er viktig her, ettersom det er umulig å manuelt gjennomgå alle de nye komponentene med dagens publiseringshastighet. Så deteksjonsmotoren må kombinere en rekke teknikker, kanskje inkludert statisk, dynamisk og funksjonsanalyse, brukeromdømme og bevis som kommer fra avvik mellom komponentmetadataene og tarball-innholdet, eller mellom tarball og kildearkivet der komponenten angivelig kommer fra.
Det er en mørk sone mellom publiseringstidspunktet og når motoren analyserer komponentinnholdet, men det bør ikke overstige noen få minutter. Skjemaet kan endres, for eksempel ved å vente på at nye komponenter skal analyseres før de tillates installert og brukt i programvarebyggingen. pipelines, eller analyser dem på forespørsel når det er nødvendig. En komponent i en gitt versjon er uforanderlig [3], så den trenger bare å analyseres én gang.
Full automatisering er ikke mulig, og en sikkerhetsgjennomgang for potensielt skadelige komponenter er nødvendig. Vokt dere for tilhengere av digitalt vidundermiddelAI og maskinlæring er ikke utviklet nok til å ta det siste ordet når det gjelder å bekrefte om en mistenkelig komponent har skadelig programvare. Maskinlæring spiller riktignok en nøkkelrolle i deteksjonsmotoren når det gjelder å klassifisere inndatakomponenten fra de rå bevisene som er fanget, men når komponenten er "satt i karantene", er det siste ordet på den manuelle gjennomgangen av et sikkerhetsteam med erfaring i skadelige komponenter. Dette bekrefter potensiell skadelig programvare eller klassifiserer den på nytt som sikker. Og tidsperioden er i timeområdet.
Registeret rapporterer om den skadelige versjonen/komponenten. Deretter utfører registeret sin gjennomgang for å bekrefte, og går videre til offentliggjøring og fjerning fra registeret. Noen registre har en sikkerhetspakke. Tidsintervallet her er dagene eller ukene siden publiseringen, som er 'holdetid'eller'eksponeringsvindu' for de fleste skadelige komponenter.
Er det mulig å vite om en komponentversjon er skadelig?
Så for tidlig varsling må vi gi et tilfredsstillende svar på dette spørsmålet: Hvordan kan jeg vite at et bibliotek eller en pakke er (ikke) skadelig? Hvordan samle nok bevis på ondsinnet oppførsel? Mulig, men vanskelig, ettersom motstanderne bruker mye oppfinnsomhet for å unngå oppdagelse. Det finnes forskjellige tilnærminger, hver med fordeler og ulemper.
Statisk analyse kan undersøke alle utførelsesbaner, sjekke etter teknikker som brukes av angripere uten å kjøre komponenten, og utføre forbehandlingsoppgaver som de-obfuskering eller dechiffrering. Når angripere prøver å skjule sin ugagn, er obfuskeringsforsøk faktisk bevis på skadelig programvare (men merk at legitime komponenter obfusker kode for å bevare åndsverk, i motsetning til "åpen kildekode”). Bare et mindretall av svært sofistikerte angrep med sterk obfuskasjon trenger sandkasse, men slik sterk obfuskasjon er et avslørende tegn på ondsinnethet. Vær oppmerksom på at konvensjonelle SAST Verktøyene ble designet for utilsiktede sårbarheter, ikke for ondsinnede hensikter som bakdører.
Dynamisk analyse kjører komponenten og undersøker responsen ved å instrumentere kjøretiden, vanligvis ved å tilby et sandkassemiljø. Ondsinnet oppførsel utløst under visse forhold kan gå ubemerket hen: vær oppmerksom på at skadelig programvare kan bruke unnvikelsesteknikker som Virtualisering/Sandbox Evasion å bare aktiveres når den ikke er under gransking, og også et avslørende tegn på ondsinnet aktivitet for enhver statisk analysemotor.
Kapabilitetsanalyse vurderer hva komponenten gjør: hvor den kobler seg til, hvilke filer den åpner, hvilke kommandoer eller programmer som kjøres, hvilken terminal- eller enhets-I/O som utføres, eller hvilke systemkall som påkalles. Denne fingeravtrykksanalysen av atferd kan sammenlignes (for en eksisterende komponent) på tvers av versjoner, slik at når uventet atferd oppdages, kan disse bevisene gi mistanke om potensielt ondsinnet aktivitet injisert i den nye versjonen. Denne tilnærmingen følger triage-trinnene som sikkerhetsanalytikere følger når de står overfor potensiell skadelig programvare: en inspeksjon ved hjelp av strenger eller lignende verktøy. Denne tilnærmingen oppdager ondsinnet oppførsel uavhengig av utløsende forhold og fungerer når ingen kildekode er tilgjengelig.
Kontekstanalyse samler inn informasjon om hvordan komponenten ble publisert og av hvem. Kampanjer fra ondsinnede aktører bruker ofte en ny brukerkonto(er) som ikke er underlagt noen streng kontrollprosess. Sporing av tidligere aktivitet kan gi innsikt i den underliggende brukeren, hovedsakelig for avvik som kan antyde en potensiell kompromissløshet. Omdømme er så vanskelig å opparbeide seg og så lett å miste! En bruker uten tidligere aktivitet er nøytral, men karma forfølger de ondsinnede. Hacktivister, eller vanlige brukere som får publiseringslegitimasjonen sin stjålet, bør spores nøye.
En annen kontekstuell informasjon er eventuelle avvik mellom kildearkivet som angivelig brukes til å opprette komponentens tarball og innholdet i selve tarballen. Og også å følge god praksis, som å opprette tagger eller utgivelser i kildearkivet som samsvarer med versjonene av komponenten som er publisert i det offentlige registeret. Når kildearkivet på et bestemt commit er merket med utgivelse, og så plutselig én versjon ikke følger den, er det alene sterke bevis på at komponenten kan være smittet: den ondsinnede aktøren kan ha kompromittert kontoen som ble brukt til å publisere komponenten, men har ingen skriverettigheter i kildekodelageret). Mange angrep oppdages rutinemessig ved hjelp av disse reglene: for eksempel Ledger-angrep kunne lett oppdages langs disse linjene. Kontekstanalyse identifiserer derfor slike avvik i publiseringsprosessen.
Avhengighetsbrannmur
En annen tilnærming er å ha en omfattende hviteliste over komponenter for alle avhengighetsgrafer som brukes i programvaren din, slik at det i enhver bygging pipeline bare godkjente komponentversjoner kan installeres og brukes i organisasjonen din.brannmur«håndheves ved hjelp av et internt register der tarballene for de tillatte komponentversjonene serveres (bufret eller via proxy). Vær oppmerksom på at hvitelister ikke vil fungere med mindre du har teknologien for å klassifisere nye versjoner som rimelig sikre, slik at de kan legges til hvitelisten.»
Vær oppmerksom på at tidlig varsling (rask deteksjon så snart som mulig etter publisering av den nye versjonen) må kombineres med en måte å bruke denne informasjonen proaktivt på for å blokkere komponenten som påvirker byggingen. pipelineeller utviklernes maskiner [4]Vi kaller dette «avhengighetsbrannmur«: en karantenemekanisme for å beskytte automatiserte bygg mot skadelige pakker. Interne pakker og bilderegistre er gode for å isolere organisasjoner fra ytre ondskap, men bevis som er sterke nok er nødvendige for å gjøre karantenen effektiv.
Kjøretids-sandkasse
En alternativ tilnærming for deteksjon ved publisering er å analysere atferd under kjøretid. Ideen er å fange opp forventet atferd fra programvaren og oppdage (eller blokkere) eventuelle avvik som oppdages. Denne handlingslinjen har problemet med å måtte instrumentere kjøretiden for overvåking eller blokkering, og det er en lovende idé som vil bli lagt til arsenalet av beskyttelsesmekanismer mot den ondsinnede komponentplagen.
Sette en omfattende strategi
Den anbefalte strategien må kombinere ulike teknikker i programvareutviklingsprosessen, og ta kontroll over versjonsoppdateringer for å blokkere innkommende skadelige komponenter. Vi må legge til rette for versjonslåsing for å unngå automatisk infeksjon ved oppdatering av versjoner for å få rettelser for de viktige sårbarhetene; en rask og effektiv vurdering av direkte og indirekte avhengigheter under versjonsoppdateringer for å ha nok bevis på at de ikke er infisert med skadelig programvare. Programvareversjoner som er avhengige av kjente skadelige komponenter må blokkeres. Og alt må håndheves.
Bruk versjonslåsing når det er mulig, da det gjør bygg mer reproduserbare. Versjonslåsing med kontrollerte, manuelt godkjente versjonsbumpsog assistert av hjelpeteknologi, bør vurdere om oppdateringen bringer med seg skadelig programvare eller ødelegger programvaren, og forene oppdatering for å fikse sårbarheter med å unngå skadelig programvareinfeksjon. Verktøy kan hjelpe her, ved å (1) prioritere hvilke sårbarheter som virkelig betyr noe (nåelige og utnyttbare, med høy risiko for å bli mål for angripere), (2) velge målversjoner som er kompatible med gjeldende komponentbruk og ikke ødelegger programvaren, (3) velge målversjoner som ikke inneholder ondsinnet oppførsel, og (4) gjøre versjonsoppdateringen for direkte og indirekte avhengigheter til en leg, ved å foreslå endringer i manifestfilene som raskt kan godkjennes. Trinn (3) trenger spesifikk informasjon om skadelige komponenter så nær publiseringstidspunktet som mulig.
Denne prosessen med å oppdatere avhengigheter må være håndheves og verifisert på alle steder. Prosessen må dokumenteres, og alle involverte parter bør få opplæring, ettersom utvikling og programvarebygging/distribusjon ofte eksternaliseres. Den CI/CD pipelines bør endres deretter, slik at automatisering ikke tillater at en ondsinnet indirekte avhengighet slipper inn i bygget: guardrails Å blokkere byggingen hvis det er nok bevis på potensiell skadelig programvare i en avhengighet er den anbefalte veien å gå.
Hvis organisasjonen din har et internt register som fungerer som en sikkerhetsproxy for å oppbevare de tillatte komponentversjonene, må du innhente informasjon om skadelige komponenter (i tillegg til andre kriterier) for å kontrollere en forespurt komponent før du legger den til i tillatelseslisten.
Det er ikke lett å bruke åpen kildekode-programvare på en sikker måte, og skadevarefaktoren må tas fullt ut i betraktning, med tilsvarende innsats i håndtering av sårbarheter.
En siste merknad: Kildens opprinnelse, i form av programvareattestasjoner, generert på byggetidspunktet for komponenten, er en annen viktig del av arbeidet med å spore artefakten (komponent-tarball) med kildene og byggeprosessen som produserte den. Merk at denne koblingen mellom kilde-snapshotet + byggemiljøet og den tilhørende programvareartefakten (signert av det pålitelige byggesystemet) ikke i seg selv forhindrer at komponenten ikke inneholder ondsinnet oppførsel, men gjør det vanskeligere for skurkene å injisere skadelig programvare. Og å gjøre proveniensvalidering til et vanlig krav for å konsumere åpen kildekode-komponenter vil ta lang tid, og bare nylig lagt til i NPMÅ gjøre disse pålitelige bygge- og distribusjonssystemene manipuleringssikre, eller å muliggjøre deteksjon av manipulering i byggingen, er en annen historie, som ikke faller inn under dette innlegget.
Videre lesing
Den neste episoden Skadelige pakker med åpen kildekode: Xygeni-tilnærmingen vil presentere strategien vi følger hos Xygeni for vår Tidlig advarsel om skadelig programvare (MEW)-system. Nye pakkeversjoner i de offentlige pakke- og bilderegistrene skannes, og bevis innhentes ved hjelp av en kombinasjon av statisk, dynamisk, funksjons- og kontekstuell analyse. Bevisene, kombinert med brukerens omdømme og historikken over endringer i kildekodelagre, muliggjør en helautomatisert klassifisering av en komponent i høyrisiko- og sannsynligvis skadelige kategorier. Systemet lærer av tidligere bevis samlet fra pakker for å redusere falske positiver til et minimum.
Abonnente organisasjoner mottar et varsel for komponenter de bruker, direkte eller indirekte, når en skadelig versjon kategoriseres. Deretter utføres en manuell analyse av våre analytikere, som bekrefter eller avviser klassifiseringen. For bekreftet skadelig programvare varsles det offentlige registeret slik at det kan utføre sin egen analyse og vanligvis fjerne den skadelige versjonen eller iverksette ytterligere tiltak, for eksempel å blokkere eller fjerne den aktuelle brukerkontoen.
Vi vil forklare hvordan vi hjelper NPM, PyPI, GitHub og andre viktige infrastrukturer i åpen kildekode-økosystemet med å redusere oppholdstiden en ny, skadelig komponent som publiseres forblir aktiv inntil den er bekreftet som skadelig programvare og fjernet fra registeret. Og hvordan organisasjoner kan dra nytte av MEW-systemet for å få mye bedre beskyttelse mot angrep i programvareforsyningskjeden som involverer åpen kildekode-komponenter.
- [1] Uansett må brukere av komponenten sjekke om komponentens tar-fil er mellomlagret eller registrert et sted, for eksempel i et internt register, slik at sykdommen utryddes.
- [2] Den pakkede komponenten inneholder et manifest som deklarerer innhold og metadata, kildekode eller kompilert kode, installasjonsskript og tilleggselementer som testpakker, i henhold til et pakkeformat og vanligvis i komprimert form. Dette kalles «komponent-tarball».
- [3] Selv om den ondsinnede aktøren kan endre en publisert komponent på grunn av et brudd i selve registeret, kan en vanlig kryptografisk sammendrag oppdage enhver endring i tar-filen etter at analysen er ferdig.
- [4] Husk at noen skadelige komponenter kjører under installasjon, så det kan påvirke utviklernoder som uforvarende kjører «npm install X» med X som en skadelig komponent.
