Dette er den fjerde episoden i serie innlegg om skadelige komponenter, der vi presenterer Xygeni tilnærming for å håndtere denne trusselen, som en del av vår dekning for Open Source Security.
Vi så at overdreven tillit til åpen kildekode-komponenter med usikker kildekode utnyttes av alle slag for å levere uventet oppførsel som enten kjøres på utviklermaskiner, CI/CD systemer, eller innebygd i offerorganisasjonens programvare, slik at den sendes videre til organisasjonens kunder. Vi dissekerte i episode #2 angrepene som bruker offentlige registre til å levere skadelig programvare, og hva vi har lært etter å ha sett hvordan de ondsinnede aktørene opererer, og i de forrige episode #3 Kontrollene som fungerer (og de som feiler) mot denne trusselen ble undersøkt.
Nå er det på tide å se på vår tilnærming til problemet. I denne episoden presenterer vi hvilken strategi vi følger hos Xygeni for vår Tidlig advarsel om skadelig programvare (MEW)-system. Hvordan dette flertrinnssystemet fungerer i sanntid når en ny pakkeversjon slippes, hvordan bevis samles inn fra forskjellige kilder, hvordan sortering gjøres, hvilke klassifiseringskriterier følger vi, og hvorfor det fortsatt er behov for manuell analyse for å bekrefte arten av en ondsinnet pakkekandidat. Vi vil også forklare hvordan vi hjelper NPM, GitHub, PyPI og andre viktige infrastrukturer i økosystemer med åpen kildekode med å redusere oppholdstiden for skadelig programvare.
Ocuco pipeline
Xygeni Malware Early Warning (MEW) behandler kontinuerlig komponenter, enten pakke-tarballer for biblioteker og rammeverk for støttede programmeringsøkosystemer som JavaScript/Node eller Python, Docker/OCI-containerbilder, eller utvidelser og plugins for verktøy som IDE-er eller CI/CD systemer. Slike komponenter publiseres i offentlige registre med ulike nivåer av brukergodkjenning.
Følgende er en skjematisk fremstilling av hvordan systemet fungerer:
Ocuco oppdageren prosessen henter inn feeden for publiseringshendelser. En publiseringshendelse er opprettelsen av en ny versjon av en ny eller eksisterende komponent. Siden de populære registrene ikke tilbyr en publiseringsmekanisme for interesserte forbrukere, gjøres dette ofte ved å avstemme registeret for nylige hendelser. Et utmerket prosjekt fra OSSF, pakkefeeder, Brukerstøtte populære registre som PyPI eller Maven Central, og gir et enhetlig feedbasert grensesnitt. I MEW har vi lagt til noen spesifikke implementeringer som reduserer ventetiden, for eksempel med en kopi av CouchDB-databasen som brukes av NPM, som er synkronisert med den offentlige registerdatabasen.
I Xygeni har vi et lager[1] av alle komponentene (direkte eller indirekte) som brukes av kundenes programvare. Kundenes komponentkoordinater mates regelmessig til MEW for prioritering av analysene: komponenter som brukes av kundene våre behandles tidligere. Prioritet er også basert på utgiverens omdømme og hvor kritisk komponenten er, så komponenter som kommer fra utgivere med lavt omdømme prioriteres også.
Ocuco analysatorer forbruk deretter de ventende komponentene i prioritetskøen. Når en komponentversjon velges for analyse, lastes tar-ballen ned fra registeret. Merk at den pakkede, binære komponenten analyseres: De fleste åpen kildekode-komponenter kommer vanligvis fra et åpen kildekode-arkiv, ofte på github.com, som kun brukes for kontekst, og skadelig programvare søkes alltid etter i komponent-tar-ballen fordi trusselaktører systematisk lyver om kildene de hevder å ha brukt til å bygge komponent-tar-ballen de utgir.
Fra brukerens perspektiv
Jeg hører deg tenke: Hvordan kan jeg dra nytte av å vite om en skadelig pakkeversjon tidlig? I episoden "Anatomi av skadelige pakker: Hva er trendene?" Vi så at den totale oppholdstiden er i området dager, mens det første varselet fra MEW til kunder som bruker den berørte komponenten er i området minutter. Med et enkelt rekkverk[2] Du kan blokkere byggingen (det er to varslingsnivåer, ett helt automatisert når motoren konkluderer med potensiell skadelig programvare, og et senere varsel når sikkerhetsteamet vårt bekrefter tilstedeværelsen av skadelig programvare ved manuell inspeksjon). Å vente til registeret bekrefter skadelig programvare og fjerner den fra registeret er vanligvis for sent på grunn av det lange eksponeringsvinduet.
Organisasjonen kan bruke et beskyttelsesrail som sjekker om det finnes en komponent med potensiell skadelig programvare (i et av de to varslingsnivåene), eller via API raskt vite om noen av de direkte eller indirekte avhengighetene i et programvareprosjekt bruker en skadelig komponent.
Hvordan MEW fungerer: Innsidedetaljer
Kjernen: Motor for deteksjon av skadelig programvare
Analysatoren bruker forskjellige detektorer for å fange opp bevis på urettmessig handling. Detektorene kombinerer statisk analyse, kapasitetsanalyse og kontekstanalyse.[3], som beskrevet i forrige innlegg i denne serien.
Hos Xygeni har vi et ingeniørteam med lang erfaring innen statisk analyse, og dette er hovedforskjellen fra andre løsninger mot skadelig programvare. Merk at for noen økosystemer inneholder den pakkede tarballen enten kildekode (f.eks. JavaScript- eller TypeScript-kode for NPM-pakker, Python-kildekode for PyPI-pakker), eller kompilert kode som er nær nok kildekoden for statisk analyse (f.eks. bytekode i JAR-filer for Maven). For andre, for eksempel containerbilder, er binære kjørbare filer vanlige, så funksjonsinferens er teknikken som brukes, sammen med konvensjonell skadelig programvaredeteksjon basert på YARA-regler og skadelig programvaresignaturer.
Vær oppmerksom på at enkle teknologier som regulære uttrykk eller signaturer ikke er egnet for å oppdage ondsinnet oppførsel. Tenk deg å oppdage en dropper eller nedlaster: Noe kode eller binærfil ligger i pakken eller er lastet ned fra et eksternt domene, ikke relatert til komponenten (kan være fra en stor liste over domener kjøpt av trusselaktøren[4]Eller en legitimt domene for å unngå oppdagelse). Den koden kjøres deretter ved hjelp av en av funksjonene for det. Koden kan transformeres for å skjule nedlastings-URL-en eller funksjonen som brukes til å kjøre den nedlastede koden. Fullstendig dataflytanalyse er nødvendig for å oppdage den, ved å bruke hele maskineriet for statisk analyse, eller en sandkassekjøring (hvis betingelsene for at ondsinnet oppførsel skal kjøre faktisk er oppfylt) kan oppdage dette i det generelle tilfellet.
Trusselaktører følger de samme teknikkene og detektorene som er designet og implementert for dem. Det er også noen forhåndsbehandlingstrinn, for eksempel for å fjerne obfuskasjon, som ofte er nødvendige for å avdekke den skjulte atferden.
Legge til kontekst
Noen detektorer bruker kontekstinformasjon. For eksempel utgjør et avvik mellom versjonen i komponentregisteret og taggen/utgivelsen i det tilknyttede GitHub-depotet sterke bevis på at kanskje en ondsinnet aktør har fått publiseringslegitimasjon for registeret, men ikke for GitHub-depotet. Angrep som det som rammer leverandøren av kryptolommebøker. Ledger kunne lett oppdages av denne uoverensstemmelsen.
A ondsinnetspoengsum (MS) beregnes fra funnene fra detektorkjøringen, basert på styrken på bevisene som er fanget. Ikke alle funn er like, og rekkefølgen for utførelse er relevant.
Bruker- og komponentomdømme
Ikke alle utviklere med åpen kildekode er skapt like!
En anerkjent utvikler kan få sin NPM-konto kapret (dette skjer selv med sikkerhetsbevisste personer), og skadelig programvare publisert ved hjelp av den kontoen. Omdømmet bør åpenbart falle brått, og bare gjenopprettes til fordums ære når den kaprede kontoen er gjenopprettet og utvikleren retter opp forholdene som førte til kontoovertakelsen. Omdømme er vanskelig å oppnå, men kan gå tapt på et øyeblikk.
Hos MEW har vi implementert et omfattende system for omdømmehåndtering for å belønne positiv oppførsel og straffe mistenkelig aktivitet. Dette systemet starter med nye brukere i en nøytral holdning og justerer omdømmet deres basert på deres pågående aktiviteter.
En brukers omdømme forbedres gjennom positive handlinger som å opprettholde aktive sosiale mediekontoer, aktivere flerfaktorautentisering, bidra regelmessig til prosjekter og signere commits med verifiserbare nøkler. Motsatt forringes omdømmet på grunn av fiendtlige handlinger som publisering av skadelig programvare, bruk av engangs-e-postadresser, manglende signering commits, eller som viser uvanlige mønstre i bidrag.
Systemets hovedmål er å sikre et trygt og pålitelig miljø. Dette oppnås ved å dynamisk justere brukernes omdømme basert på ulike faktorer, samtidig som vi respekterer personvernhensyn og begrensningene til ulike registre.
En intern omdømmescore beregnes for brukeren (ved å bli med i registeret og GitHub-kontoen når det er mulig), og sammen med skadelighetsscoren som brukes under klassifiseringen av komponenten som analyseres, og for bedre å kvalifisere hvem som er under komponentpublikasjonen.
Bevis på ondsinnet oppførsel ble funnet. Hva så? Den manuelle gjennomgangsprosessen
Den nåværende klassifiseringen setter den analyserte komponentversjonen i en av kategoriene «bekreftet skadelig», «sannsynligvis skadelig», «høy risiko», «lav risiko» eller «ikke-skadelig» basert på terskler på poengsummene som kondenserer funnene og bruker-/komponentomdømmet. En klassifisering i kategoriene «høy risiko» eller «sannsynligvis skadelig» utløser manuell gjennomgang og første varsel. Kategorien «bekreftet skadelig» settes etter manuell gjennomgang eller når bevisene samsvarer med de samme bevisene for en tidligere versjon som ble bekreftet skadelig.
Når det finnes nok bevis for potensiell ondsinnet oppførsel, sendes et første varsel (karantenevarsel) til de berørte organisasjonene. Som nevnt tidligere kan dette blokkere installasjon eller bygging av programvare som er avhengig av den karantenesatte komponenten.
Det skaper et problem i MEWs interne system dashboard slik at sikkerhetsanalytikere kan starte den manuelle gjennomgangsprosessen for komponenten. Teamet har spesialiserte verktøy (sandkasse, deobfuskatorer, distribusjon for malware-forskning, rapporteringsverktøy for malware) for raskt å vurdere typen komponentversjon som undersøkes. Mesteparten av den skadelige programvaren («ansjosen» eller usofistikerte ondsinnede komponenter) blir gjennomgått.
Resultatet av gjennomgangen konkluderer med enten trygge, slik at den automatiske analysemotoren fant en falsk positiv som brukes som tilbakemelding til maskinlæringsklassifiseringen for å lære mønsteret; eller bekreftet ondsinnet, slik at komponenten blir ansvarlig rapportert som skadelig til det offentlige registeret, etter rapporteringsprosessen. Et nytt varsel sendes til de berørte organisasjonene, som igjen kan oppheve karantenen for komponenten, eller definitivt blokkere den fra versjonsoppgraderingsprosessen eller komponentbrannmuren som brukes i det interne registeret.
Denne innstillingen lar oss analysere titusenvis av nye versjoner daglig og identifisere de titalls som sannsynligvis er skadelige, som vi deretter gjennomgår manuelt. Husk fra forrige episode at én av ti tusen er andelen skadelige komponenter vi ser ute i det fri for øyeblikket.
Rapportering til registeret
Vi fant ut at de fleste offentlige registre, en av ryggradene i åpen kildekode-infrastrukturen, tilbyr ganske begrensede mekanismer for rapportering av sikkerhetsproblemer, og spesielt skadelige komponenter. Vi sliter med å forbedre den underliggende organiseringen av rapporteringsprosessen. Vanligvis mottar vi maksimalt en tilbakemeldings-e-post fra sikkerhetsteamet i registeret som bekrefter at komponenten ble fjernet fra registeret.
Noen ganger blir registeret misbrukt, noe som bryter bruksvilkårene, men det forårsaker ikke ondsinnet oppførsel i den leverte programvaren. Dette rapporteres også til registeret, men det varsles ikke til organisasjoner for å begrense støyen.
Fremtidig arbeid
Mange forbedringer er for tiden på vei. Først og fremst en offentlig portal for OS-komponenttilstand, spesielt knyttet til bevisene som er funnet for potensiell skadelig innhold, er for tiden under utvikling. Dette er ment som et beskjedent bidrag til åpen kildekode-fellesskapet. Følg med.
En annen pågående utvikling er en forbedret maskinlæringsklassifiseringMEW vil lære av tidligere klassifiseringer. Vektoren av funn fra motordetektorer, pluss den avledede skadelighetspoengene og omdømmepoengene for både komponenten og utgiveren («bevisene som er funnet»), brukes som input til et maskinlæringssystem som oppdaterer klassifiseringsmodellen. Utdatavariabelen er ganske enkelt om registeret bekreftet om komponenten var skadelig. Dette har kodenavnet «Oraklet» og vil hjelpe med en mer presiscise-kvalifikator, designet for å være solid (høy recall, dvs. ikke overse skadelige komponenter), men med færre falske positiver (ikke rapporter trygge komponenter som skadelige).
A kritiskhetspoengsum vil bli lagt til for prioriteringskriterier, i tillegg til å tilhøre settet med kunders avhengigheter, og utgiverens lave omdømme. Det er tydelig at prosjekter med mer innflytelse og betydning bør vurderes tidligere for analyse. Vi vil ikke finne opp hjulet på nytt her, og følge Kritisk poengsum for åpen kildekode-prosjekter.
Støtte for flere økosystemer er under utvikling. Utbredte teknologier og verktøy som PHP- eller Jenkins-pluginer er på planen.
Vi undersøker også om den manuelle gjennomgangsprosessen kan forbedres med kunstig intelligens for å effektivisere analysen av de få mer sofistikerte skadelige komponentene.
I den neste og siste delen av denne serien, «Utnyttelse av åpen kildekode: Hva du kan forvente av de slemme gutta«, vil vi fokusere på de nyeste metodene motstanderne bruker for å gjøre angrepene mer snikende, vanskeligere å oppdage, mer målrettede mot spesifikke bransjer og mer lønnsomme. Vil ransomware-angrep bli utført ved hjelp av dette kjøretøyet? Hvordan utnytter skurkene AI-verktøy for å levere mer sofistikert skadelig programvare? Er populære prosjekter i faresonen? 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 avslutte med noen tanker om hvilke små skritt fellesskapet kan ta uten å endre for mye åpenheten i åpen kildekode-verdenen. For eksempel ville en mer effektiv mekanisme for rapportering av skadelig programvare til offentlige registre, og deling av bevis på potensielt skadelige komponenter med registrene og fellesskapet være et lite skritt i riktig retning mot målet om å lukke dørene for trusselaktører.
Skadevare i komponenter med åpen kildekode bør ikke forstyrre de enorme fordelene som åpen kildekode-fellesskapet har brakt samfunnet vårt.
- [1] Skanneren vår oppdager komponenter med åpen kildekode som det refereres til i programvareprosjektene som analyseres, slik at den fullstendige, oppdaterte avhengighetsgrafen er kjent, i hvert fall for prosjekter som skannes regelmessig. Xygeni OSS eksponerer et API som kunder også kan bruke under hvitlisting av en komponent av interesse, inkludert informasjon om sårbarheter og skadelige bevis.
- [2] Et beskyttelsesrekkverk kan ødelegge bygget hvis det oppdages en tilstand som samsvarer med sikkerhetsproblemer. Sikkerhetsfunn som en kritisk og tilgjengelig sårbarhet eller bruk av en komponent i karantene kan anses som alvorlige nok til å ødelegge bygget for den berørte programvaren.
- [3]Våre sikkerhetsanalytikere kjører komponenten eller installasjonsskriptene i et sandkassemiljø når det er nødvendig. MEW utfører imidlertid ikke dynamisk analyse, hovedsakelig fordi den ondsinnede oppførselen ikke alltid utføres i målrettede angrep og på grunn av unnvikelseslogikken som trusselaktører bruker for å unngå dynamisk analyse.
- [4] Denne teknikken fikk navnet Registrerte domenegenereringsalgoritmer eller RDGA, og nye trusselaktører som den såkalte Revolver kanin investerte så mye som 1 million dollar i 500 000 domener, noe som viser hvor lønnsom nettkriminalitetsindustrien er.
