Dette er den første episoden i en serie artikler om den vanligste typen angrep på programvareforsyningskjeden: de som (mis)bruker et offentlig register over programvarekomponenter, beregnet på open source-prosjekter å laste opp artefakter som kan deles med andre brukere. Når skurkene publiserer skadelig programvare der, og bruker registeret som et middel for distribusjon av skadelig programvare, har vi et forsyningskjedeangrep når offerorganisasjonene installerer eller kjører den infiserte programvarekomponenten.
For å forenkle diskusjonen vil vi snakke om programvarepakker:, komponenter i pakket form produsert av tredjeparter. Dette inkluderer ikke bare komponenter som brukes av pakkebehandlere som NPM eller Poetry, men også operativsystemkomponenter inkludert biblioteker og kjørbare binærfiler, bilder av containere, og virtuelle maskiner, eller verktøyforlengelser for utviklings-, bygge- og distribusjonsverktøy. Vi har sett ondsinnede pakker overalt. Nettkriminelle bryr seg ikke: de er begeistret for alternativene som tilbys av moderne programvareinfrastrukturer og bruker registeret og verktøyet som passer best til deres hensikt. Så husk at programvarepakker er en forkortelse for containerbilder, binære pakker, åpen kildekode-repositorier og utvidelser eller plugins av alle slag (IDE-er, CI/CD systemer, byggeverktøy). Alle er rutinemessig under angrep.
Serien vil ha 5 episoder:
- Hva er problemet med pakker med åpen kildekode? Dette er temaet for dette innlegget. Hvorfor publiserer kriminelle av alle slag ondsinnede pakker? Hvorfor burde jeg være bekymret?
- Anatomien til skadelige pakker: Hva er trendene? I denne episoden fokuserer vi på trusselen vi overvåker med MEW-systemet vårt, dag etter dag. Med mye bakgrunnsstøy på grunn av et stort antall ondsinnede pakker som bruker typosquatting eller avhengighetsforvirring, er en mindre prosentandel av angrepene mye mer lumske og utgjør en større risiko. Hvordan har de ondsinnede aktørenes oppførsel angående operativsystemet endret seg i den senere tid? Hva er tallene? Hva er taktikkene, teknikkene og prosedyrene som brukes, og de skadelige handlingene som er observert?
- Beskyttelse mot skadelige pakker med åpen kildekode: Hva fungerer (ikke fungerer)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å feilrettinger, og at det er den riktige, anbefalte måten å redusere risikoen for avhengigheter av åpen kildekode, etter prinsippet «oppdatering tidlig, oppdatering ofte». I denne episoden skal vi gjennomgå hvorfor disse ideene er feil, og hvordan slike misforståelser 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.
- Skadelige pakker med åpen kildekode: Xygeni-tilnærmingenI denne episoden presenterer vi strategien vi følger hos Xygeni for vårt Malware Early Warning (MEW)-system. Hvordan fungerer dette flertrinnssystemet i sanntid når en ny pakkeversjon publiseres, hvordan bevis samles inn fra forskjellige kilder, hvordan triage utføres, hvilke klassifiseringskriterier følger vi, og hvorfor det fortsatt er behov for manuell analyse for å bekrefte arten av en ondsinnet pakkekandidat? Hvordan tilbakemeldinger fra våre interne og registerteam hjelper systemet med å lære av tidligere bevis samlet inn for å redusere falske positiver til et minimum. Vi vil også forklare hvordan vi hjelper NPM, GitHub, PyPI og andre viktige infrastrukturer i åpen kildekode-økosystemer med å redusere oppholdstiden..
- Utnyttelse av åpen kildekode: Hva du kan forvente av de slemme guttaSerien avsluttes med å fokusere på de nyeste tiltakene motstanderne tar i bruk for å gjøre angrepene mer snikende, vanskeligere å oppdage, mer målrettede mot spesifikke bransjer, og for å få mer utbytte av denne angrepsklassen. Vil ransomware-angrep bli levert ved hjelp av dette kjøretøyet? Hvordan utnytter skurkene AI-verktøy for å levere mer sofistikerte ondsinnede pakker? Er populære toppprosjekter i fare? Dette er for å gi leserne en følelse av dette våpenkappløpet, og hva de kan forvente på kort sikt (andre halvdel av 2024) og mellomlang sikt (2025). Vi vil lære hvordan angrep som de siste ... XZ-Utils bakdør, eller angrepet på å leve av landet elektronbygger i mars 2024 viser at vi bør være årvåkne over hvordan motstanderne utvikler seg.
La oss åpne scenen med den første episoden: Hva skjer med ondsinnede åpen kildekode-pakker?
Hva er problemet med pakker med åpen kildekode?
I de senere år har lovbrytere av alle slag brukt registre med åpen kildekode-programvare for å utføre ondsinnet oppførsel. Disse aktivitetene er like gamle som åpen kildekode, men hyppigheten har eksplodert de siste tre årene.
Publisering av skadelige komponenter i offentlige registre (avhengighetsbaserte angrep) er asymmetrisk geriljakrigføring som trusselaktører bruker til å distribuere skadelig programvare, og utnytter tilliten organisasjoner har til komponenter med åpen kildekode fra ukjente utviklere (husk avhengighet xkcd tegneserie?). Fordi du stoler på pakker og ikke har noe imot å gjennomgå pakkeinnholdet og avhengighetene manuelt, er disse angrepene usedvanlig effektive. Og asymmetrien kommer fordi de i stor grad kan automatiseres, og de kriminelle trenger ikke å samhandle direkte med offeret. De laster ganske enkelt opp pakken til det offentlige registeret og lar den gå.
Ondsinnede pakker økte med en 6x-faktor i 2022, og fortsatte å vokse med en 2.5-dobbel faktor i 2023. I fjor ble hele 245 000 ondsinnede pakker observert, et tall som mer enn dobler det totale antallet fra tidligere år til sammen. Dette er eksponentiell vekst! Fra fjerning av pakker til bekreftet skadelig programvare i hundrevis i løpet av 2021 og i tusenvis i løpet av 2022 så vi mye mer bakgrunnsstøy i løpet av 2023, med et lignende tempo for i år. Og skjult i den bakgrunnen forårsaket av usofistikerte nettkriminelle som fulgte «minste motstands vei», nådde et mindretall av høyprofilerte angrep overskrifter selv i generelle medier.
Hvorfor er dette et problem av en slik størrelsesorden? Det finnes en overdreven tillit over hele kjeden. Programvare med åpen kildekode distribueres med kildekoden og utgis under en gitt lisens. Ja, hvem som helst kan inspisere kildekoden, men hvem gjør det egentlig? Hvem, etter å ha inspisert at programvaren ikke har skadelig programvare, bygger programvaren fra kildekodene? Hvem, før den pakkede komponenten (også kjent som en pakke) nedstrøms til pakkebehandleren eller byggeverktøyet, sørger for at pakken ikke er full av skadelig programvare og samsvarer med den antatte kildekoden den skal komme fra?
Hvorfor tillater infrastrukturen så enkle angrep?
Pakkeregistre er åpne, og krever ofte minimal verifisering av utgiverens identitet. «Alle er velkomne til å publisere programvaren sin her!» Listen for angripere er satt lavt: de bruker engangs-e-postadresser og engangs-GitHubGithub-kontoer for å lage hundrevis av ondsinnede pakker i korte, phishing-lignende kampanjer. Bare for målrettede pakker er det behov for høyere raffinement: Vi så til og med at man opprettet et troverdig GitHub-kildelager med mange stjerner og commitfra flere falske bidragsytere og andre målinger av popularitet og vedlikehold. Få stjernekikkere og omdømme fra falske bidrag er ikke vanskelig å automatisere. Vi så misbruk av åpne programvareinfrastrukturer av alle slag, ikke bare skadelig programvare, som teprotokollhendelse.
Pakkebehandlere ble designet for brukervennlighet og ikke for sikkerhetDe kan kjøre skript før og etter installasjon (noen ganger er det nødvendig å kompilere innebygd kode for et bibliotek). I tillegg, Pakkeforvaltere installere pakker fra flere kilder, og noen ganger er standardinnstillingen å bruke offentlige registre. De sjekket ikke for avvik mellom metadataene i publiseringsforespørselen og metadataene i selve pakken.
Avhengigheter er nestet og danner en graf. I visse økosystemer som Node (JavaScript) akkumuleres småskalige avhengigheter i hundrevis eller tusenvis. Én ting er å ha streng kontroll over direkte avhengigheter deklarert av programvareprosjektene mine, men transitive avhengigheter er vanskeligere å kontrollere. Åpen kildekode fulgte «vennene til vennene mine er vennene mine». Brorskap er normen i det ville Fjerne Østen! Trusselaktører vet dette og skjuler den ondsinnede oppførselen dypt i obskure avhengigheter som ofte er ukjente. Dette var tilfellet med hendelsesstrøm hendelse rettet mot Copay-lommebok.
Slik har åpen kildekode-programvare fungert siden starten. Det vil ikke endre seg mye. Noen pakkeregistre krever i beste fall tofaktorautentisering, og ofte bare for de mest populære pakkene. Noen registre tilbyr omfang, et navnerom eid av en verifisert organisasjon, men tragisk andre støtter det ikke (PyPI) eller gjør det valgfritt (NPM). Det er interessant å merke seg at selv en enkel screeningordning (basert på kontroll av DNS- eller GitHub-depotet/organisasjonen som samsvarer med gruppe-ID-en) og gjør PGP-signaturer er obligatoriske for alle artefakter unntatt sjekksummer fjerner det meste av "støyen", typosquatting-lignende ondsinnede pakker, og begrenser mye av avhengighetsforvirringSofistikerte angrep er mulige, men mye vanskeligere, med bare noen få som den com.github.codingandcoding:maven-compiler-plugin kjent for Maven Central. Og ikke alle Maven-registre følger de samme fremgangsmåtene!
Sikkerhetskontroller på pakkebehandlere kan være en belastning, men hindre ikke avhengighetsangrep. Problemet med flerfaktorautentisering er at for automatisering genereres avledede legitimasjonsopplysninger som tilgangstokener eller APIapi-nøkler for kontoer som skal brukes i APIapi-kall gjort fra automatiseringsskript, uten at en støttende interaktiv bruker gir en sekundær faktor. MFA er bra for å beskytte brukerkontoer mot passordlekkasjer, men de genererte tilgangstokenene eller APIapi-nøklene må beskyttes mens de er aktive, ellers vil eieren bli utgitt av motstanderne. En stor andel av pakkebaserte forsyningskjedekampanjer starter med en lekket nøkkel/token. Bare husk hendelser som Ledger, 3CX, og mange flere, hvor ikke-interaktive legitimasjonsdetaljer først ble strammet inn i et forberedende innbrudd for å iverksette forsyningskjedeangrepet.
Responsen som ble gitt på denne trusselen var ikke robust nok. I den tredje episoden skal vi fokusere på hva som fungerte, og hva som mislyktes fullstendig. Bransjen må samarbeide om standards, prosesser, opplæring og verktøy for å redusere risikoer for globale forsyningskjeder. Dette er ikke et problem en enkelt organisasjon kan løse alene.
For å avslutte denne delen, den avgjørende misforståelsen: vi snakker om skadelig pakker, ikke sårbare Sårbarheter kommer fra design- eller kodefeil, introdusert ved et uhell, uten ond hensikt. Sårbarhetene kan utnyttes, men mange blir ikke det. Ondsinnede pakker er alltid forsettlige, og det er 100 % utnyttbarhet hvis de blir utført. Ingen sammenlignbar risiko! Derfor Det er paradoksalt å se hvor mye arbeid som legges ned i å oppdage og redusere sårbarheter, og mangelen på tilsvarende tiltak for skadelige komponenter..
«Vi tar sikkerhet på alvor»
La oss forestille oss det vanlige Acme CorporationAcme, en stor leverandør av WileCoyote.com, har mesteparten av programvaren sin fra tredjeparter, med mer enn 80 % fra åpen kildekode-prosjekter. De produserer programvare for intern bruk, men de tilbyr også programvare for sine partnere, leverandører og kunder/sluttbrukere. Acme har programvare skrevet i Go, JavaScript, Java, C# og Python, og kjører mesteparten av programvaren sin i skyen, under Kuberneteskubernetes-klynger. Acme bygger sine tilpassede images fra basisimages hentet fra Docker Hub og andre registre. Og de deler også noen få biblioteker, pakker og containerimages i offentlige registre.
Acme tar sikkerhet på alvor. De er ganske klar over problemet med open source security, og risikoen det medfører. Alle utviklere, systemadministratorer og DevOpsdevops-ingeniører bruker disse søte små kryptonøklene som andrefaktorautentisering. Alle commits til kodelager er signert, grenbeskyttelse er aktivert med obligatoriske kodegjennomganger, CI/CD låst, hemmeligheter lagret i et hemmelig hvelv, og med et internt register som delvis speiler eksterne registre der bare de tillatte, hvitelistede komponentene er lagret. Det kreves at programvare bygget av Acme må ta tredjepartsavhengigheter fra dette registeret.
Sannsynligvis passer de fleste organisasjoner inn i denne profilen. Kjære leser, din passer absolutt inn hvis du allerede er her, ikke sant?
Så en skjebnesvanger dag, en viktig frontend-utvikler på Acme ran npm installerer acme-cute-lib, og glemte at @acme/cute-lib var den riktige avhengigheten. Den nøyaktige feilen er ikke viktig, mye kan gå galt selv når man tar perfekt kontroll over programvarens livssyklus. Utvikleren vår visste ikke at en APT-gruppe siktet seg inn på Acme og publiserte en ondsinnet komponent under det navnet, på en utspekulert måte, slik at den ondsinnede oppførselen bare aktiveres når programvaren er installert på Acme-datamaskiner. Pakken ble ikke oppdaget i flere uker etter publiseringen.
Et installasjonsskript kjøres som søker etter påloggingsinformasjon (det var mange saftige tilgangstokener på utviklerens bærbare datamaskin), noe som gir tilgang til interne programvarelagre og det nevnte interne arkivet, som selvfølgelig bare er tilgjengelig via VPN. Den ondsinnede koden klarte å bruke den eksisterende VPN-tilkoblingen og publisere en andrefase-skadelig komponent i det interne registeret, noe som påvirket et felles verktøybibliotek som deles av mesteparten av programvaren levert av Acme.
Uker etterpå begynte andre organisasjoner som brukte Acmes publiserte verktøy å se merkelig trafikk på nettverkene sine. Trafikken brukte Acmes protokoll, men ble dirigert til verter som lignet Acme-domenet. Trafikken var kryptert, men systemovervåkingsverktøyene fant tilgang til uventede filer og kjøring av prosesser som ser ut som systemkommandoer, men som ender opp med å kjøre nedlastede kjørbare filer.
Resten er historie: Acme benektet først at slik oppførsel kunne tilskrives dem, og at alle sikkerhetstiltak var på plass. Først etter at cybersikkerhetsmediene begynte å spørre hvorfor kilden til den oppdagede oppførselen kom fra Acmes komponenter, og sikkerhetsanalyser publiserte hvor fulle av skjult skadevare disse komponentene var, måtte Acme gjenkjenne hendelsen og tilkalle et hendelsesresponsfirma. En negativ markedsføringskampanje som undergravde den hardt opptjente tilliten på et sekund.Acme var én npm-installasjon unna disaster«var en vanlig overskrift. Så fulgte søksmål og kansellerte kontrakter etter.
Ser du likheter med kjente hendelser fra tidligere? Acme rammet en hendelse i forsyningskjeden i to faser, ved hjelp av en blanding av avhengighetsforvirring/typosquatting angrep som brukte en utviklerarbeidsstasjon som et brohode for å infisere komponenter som havnet i programvare brukt av tredjeparter. Hvordan kunne dette forhindres eller reduseres?
Hvorfor forgiftede pakker er så populære
Denne hypotetiske hendelsen viser at selv med en rimelig tilnærming til åpen kildekode-sikkerhet, trenger organisasjoner spesifikke tiltak for å unngå å bli ofre for skadelig programvare i åpen kildekode-komponenter. Skjematisk kan trusselaktøren:
- Opprett en ny pakke (i følge de velkjente metodene for typosquatting eller avhengighetsforvirring, er dette den mest brukte skurkene i volum);
- Prøv å infisere en eksisterende, enten ved å injisere den i kildekoden, eller ved å prøve å skjule den som en bidragsyter via pull request, eller bruke sosial manipulering for å bli en vedlikeholder (slik «Jao Tan» gjorde i XZ Backdoor eller høyre9ctrl GitHub-brukeren gjorde i hendelsesstrøm hendelsen høsten 2018), eller ved å skaffe seg legitimasjon for åpen kildekode-arkiv og utgi seg for å være vedlikeholderen;
- Injisere skadelig programvare under byggingen av pakken, enten ved å kjøre et skadelig byggeskript, eller forstyrre nedlastinger av pakker med «man-in-the-middle»-avskjæringer (heldigvis er TLS nå alltid påkrevd i de fleste registre).
- Injiser den pakkede komponenten direkte i registeret, vanligvis ved å fange registerlegitimasjonen (det foretrukne alternativet for mange sofistikerte angrep som Acmes, der den kompromitterte arbeidsstasjonen i første fase hadde det interne registertilgangstokenet, f.eks. i det vanlige .og V or ~/.m2/settings.xml(Skurkmakere vet hvor de skal lete etter hemmeligheter). Sårbarheter i registrene ble også utnyttet.
Å forgifte registre med skadelig programvare er grunnlaget for avhengighetsangrep. Ikke noe nytt under solen: utbredelsen eksploderte, men de samme teknikkene fungerer nå som for fem år siden.
kilde: Ryggstikkerens knivsamling.
Den skadelige pakken kan operere under installasjon, under programvarebygging eller under kjøretid. Og oppførselen spenner fra informasjonsutvinning, f.eks. utpakking av hemmeligheter for et andre forsøk, til utpakking av kildekode og slukking av ytterligere skadelig programvare. I neste episode skal vi dissekere de skadelige pakkene og hvordan de publiseres.
Videre lesing
Den neste episoden Anatomien til skadelige pakker: Hva er trendene? vil fokusere på reelle tilfeller vi overvåker med vårt system for tidlig varsling av skadelig programvare, dag etter dag. Vi vil gjennomgå hvilke typer skadelig programvare som ble observert, og hvilke taktikker, teknikker og prosedyrer som er favorittene. Vi vil undersøke obfuskasjon og hvordan de prøver å skjule seg for potensielle anmeldere, unnvikelsesteknikkene for å unngå oppdagelse, og hvordan de utvikler seg med telemetri og sideveis bevegelse. Følg med!
Referanser
- Backstabber's Knife Collection: En gjennomgang av angrep på forsyningskjeden med åpen kildekode-programvareM. Ohm et al., mai 2020.
- Beskyttelse mot skadelig programvare med åpen kildekodeHvitbok fra Xygeni.
- Software Supply Chain Security Tilbakeblikk: Å forme et tryggere 2024Rapport fra Xygeni.
