I forrige episode, Skadelige pakker med åpen kildekode: Problemet, diskuterte vi hvorfor trusselaktørene var så entusiastiske når det gjelder å publisere nye skadelige komponenter eller injisere skadelig programvare i de nyeste versjonene av eksisterende komponenter: Den åpne kildekode-infrastrukturen lar hvem som helst hvor som helst opprette en kortvarig konto i et komponentregister (som NPM, PyPI, Docker Hub eller Visual Studio Marketplace) eller en samarbeidende utviklingsplattform (som GitHub). Null kostnad, og mange muligheter for å utnytte den overflødige tilliten som programvareteam tradisjonelt har til tredjepartskomponenter.
Asymmetrien mellom hvor enkelt det er for angripere å distribuere skadelig programvare ved hjelp av infrastrukturen som er tilgjengelig for åpen kildekode, og hvor vanskelig det er for organisasjoner som utvikler programvare (alle?) å unngå å bli infisert med skadelig programvare (og å levere skadelig programvare i programvaren de distribuerer for andre), førte til at en kvart million-grense av skadelige pakker nesten ble nådd i fjor.
Dette er et problem av en slik størrelsesorden at ingen enkeltorganisasjon kan løse det, og miljøet er i ferd med å omformulere åpen kildekode-prosessen angående tillit, prinsipper for sikker standard og sikker design, og livssyklusen til komponenter. Vi skal se på slike ideer i neste episode. Beskyttelse mot skadelige pakker med åpen kildekode: Hva fungerer (ikke fungerer).
Husk at vi snakker om programvarekomponenter som mesteparten av tiden samsvarer med programvarepakker: gjenbrukbare komponenter pakket slik at de kunne refereres til som en avhengighet i et programvaremanifest, og installert med en pakkebehandler eller et byggeverktøy. Vær oppmerksom på at dette tilfellet kan utvides til å omfatte offentlige containerbilder (brukes av containerkjøretider og orkestreringsplattformer som Kubernetes), og utvidelser til programvareverktøy (for bygging, automatisering og utrulling).
Her analyserer vi hvordan dette angrepstaktikk basert på ondsinnede komponenter fungerer, i henhold til tidligere eksempler og det vi har sett i vår plattform for tidlig varsling av skadelig programvare (MEW). Vi vil dissekere skadelige komponenter i forskjellige dimensjoner:
(1) den valgte distribusjonsmåten (registeret som brukes i en ny eller eksisterende komponent, og teknikken som brukes for å infisere den publiserte komponentversjonen), (2) hvordan skadevaren aktiveres eller utløses, (3) den ondsinnede oppførselen, dvs. hvilke skadelige handlinger som observeres og hva som er angriperens motivasjon, (4) hvilke teknikker som er vanlige for obfuskasjon, skjuling for å gå ubemerket hen, lateral bevegelse, kommunikasjon med kommando- og kontrollverter (C2), osv.; og (5) teknikkene for å oppnå nok popularitet og tillit slik at ofrene ender opp med å installere komponenten.
Den valgte distribusjonsmekanismen
Vi observerer en «bakgrunnsstøy"av usofistikerte, ondsinnede pakker som bruker typosquatting for å phishe uforsiktige utviklere med en skrivefeil i pakkenavnet for avhengigheten sin. Mange populære pakker mottar en strøm av pakker med lignende navn og skrivefeil, med forventning om at de vil phishe noen uforsiktige utviklere.
De bruker en kortvarig konto, publiserer en gruppe med typosquat-pakker, oppretter en annen, og publiserer en annen gruppe ... Ved å bruke litt automatisering og oppfinnsomhet kan de oppnå noe raffinement, men vanligvis er de ganske trivielle. Internt kaller vi dem «ansjos”Tyveri av legitimasjon er hovedmålet, men av og til finner vi spionprogrammer som stjeler kildekode eller sensitive data som personlig identifiserbar informasjon (PII), innhenting av utklippstavler og andre betenkeligheter.
Helt ut av det blå ser vi mer sofistikerte ondsinnede komponenter, «haiene». Et mindretall er rettet mot spesifikke grupper eller organisasjoner, vanligvis med kryptodrenering eller nettskimmere som aktiveres betinget, kanskje etter tilnærmingen vi ser i hendelsesstrømhendelse å dekryptere angrepsnyttelasten bare når pakken refereres til fra en målpakke.
Distribusjonsmekanismen ble analysert i den utmerkede og nå klassiske artikkelen, «Backstabber's Knife Collection: En gjennomgang av angrep på forsyningskjeden med åpen kildekode-programvare«, som er et must å lese. Du har sikkert sett dette fine diagrammet før:
Alle veier ble utforsket, inkludert nye og eksisterende pakker; påvirkning av kildekoden, byggesystemet eller selve den pakkede komponenten; bruk av stjålne påloggingsinformasjon eller sosial manipulering; kapring av forlatte kontoer og arkiver eller forgiftning av vedlikeholdte. Noen angrep fikk navn (Skrivefeil, Avhengighetsforvirring, Åpenbar forvirring, Repo-jackingosv.) og ble allerede diskutert andre steder.
Hva med de valgte registrene?
NPM fortsetter å lede an i det totale antallet ondsinnede pakker, men vi så en topp fra og med i år på PyPI. Python er et populært økosystem for datavitenskap og maskinlæring. Faktisk er tettheten av skadelig programvare nå høyere i PyPI enn i NPM.
Hvordan skadevaren utløses
Ondsinnede pakker utløses under installasjon i bare 4 av 10 tilfeller (i de senere år var det nærmere 6 av 10). Resten kjører ondsinnet oppførsel under kjøretid, med 1 av 100 utløst mens man kjører tester. Motstanderne ser ut til å vite at ukontrollert utførelse av installasjonsskript var deaktivert mange steder.
Hva får de onde gutta?
Vi vil liste opp kategoriene for ondsinnet oppførsel, med den mest populære først. Vær oppmerksom på at virkningen kan være ganske forskjellig: a svisker er gjenstridig destruktiv, men det er ikke vanlig og ble bare sett i noen få tilfeller, relatert til målrettede cyberkrigskampanjer eller brutal hacktivisme. Følgende kategorier er ganske vanlige:
- InfoStealer / Credentials DrainerDe klart hyppigste, over 90 % av de usofistikerte angrepene, er enkle tyveri som hovedsakelig leter etter påloggingsinformasjon som passord, tilgangstokener, API-nøkler og private nøkler (for SSH og lignende). Det er sannsynligvis det enkleste å skrive (sammen med «wipers»?). De lister opp kjente filer/kataloger og andre kilder (f.eks. registernøkler), pakker innholdet og sender disse dataene til en C2-server. Ideen er enkel: «Jeg publiserer en stjeler for phishing-påloggingsinformasjon, slik at jeg senere kan bruke påloggingsinformasjonen til å starte et rettet angrep».
C2-nettverket som observeres er vanligvis billig og skittent, som Telegram-kanaler eller ngrok-lignende tunnelverktøy (ofte i form av omvendte proxyer eksponert gjennom VPN-utgående IP-adresser). Det finnes hundrevis (!) av muligheter, med mange GitHub-prosjekter underlagt emne om passordtyveriSpesialiseringer som keyloggers er sjeldne for ondsinnede pakker og containerbilder, men hyppigere i verktøyutvidelser, der brukerinteraksjon forventes.
- Dropper / Nedlaster. Den nest mest populære, vanligvis først i flertrinnsangrep. Mer enn én av tre ondsinnede komponenter har droppere (hvis den ondsinnede nyttelasten er inkludert i pakken) eller nedlastere (nyttelasten lastes ned fra et endepunkt under angriperens kontroll). Nyttelasten er ofte en kjent binær variant av skadelig programvare, og den kjøres og noen ganger persisteres, for å installere bakdører, spionprogrammer, kryptodrenering og andre brukstilfeller. Nyttelasten som lastes ned eller distribueres starter et andrefaseangrep med all kraften som tilbys av eksisterende binærfiler for skadelig programvare. Binærfilene kan distribueres i pakken, ofte maskert som bilder eller angivelig uskyldige filtyper, for å unngå deteksjon mens du kobler til uventede nettsteder.
- Kryptovalutastjelere/-gruvearbeidereFinansielt motiverte motstandere er villige til å bruke skyressursene dine til å kjøre kryptominere (de oppdager til og med om de kjører i en virtuell skymaskin). De bryr seg ikke om lav profittrate på 1 dollar for hver 53 dollar som offeret blir belastet for den stjålne skyinfrastrukturen. Ofrene er kanskje ikke klar over dette før de mottar en uventet regning. Heldigvis kommer og går dette. Cryptojacking Kampanjer i ondsinnede pakker dukker av og til opp og forsvinner deretter, og driver med phishing for lommebokbrukere eller til slutt retter seg mot lommebokleverandøren, som i Ledger-angrep.
Andre oppførselsmåter, som å utplassere en backdoor for ekstern kodekjøring ved å åpne et reverse shell er sjeldnere nå enn tidligere. For eksempel, 123rf_bidragsyter_nett pakken (nå fjernet fra registeret) åpnes uten noen form for tilsløring et omvendt skall kopiert og limt inn fra Omvendt skall-jukseark:
I tillegg til legitime og ondsinnede komponenter har vi observert flere misbruk, inkludert:
Spampakker
Det finnes tusenvis av små pakker, hovedsakelig i NPM, uten skadelig programvare, men som lover enkle inntekter, slangeolje, lenker til Viagra-tilbud og alt det der. Noen få brukere publiserer slik spam og tar mye båndbredde fra registeret. En annen aktør(er), muligens fra Indonesia, prøvde å utnytte dette ved å misbruker teRank ment for å kompensere utviklere med åpen kildekode, ved å lage titusenvis av sammenkoblede NPM-pakker med relaterte GitHub-dummy-repositorier. Dette er et klart brudd på bruksvilkårene.
Bug bounty og sikkerhetsforskningssvindel
Når en pakke beskriver seg selv som å eksfiltrere data for gode formål, som å oppdage sikkerhetsfeil for bug bounty-programmer eller undersøke visse aspekter av økosystemet. Vi har sett tusenvis av pakker i denne kategorien, som henter identifikasjonsdata, men ikke for sensitive data, til en Burp Collaborator-adresse fra PortSwigger (f.eks. vert i oastify.com-domenet). Vi observerte ofte etterligninger av Avhengighetsforvirring konseptbevis av Alex Birsan, som aurora-webmail-pro pakke (fjernet fra registeret), som ganske enkelt kjører denne ekle koden i forhåndsinstallasjonsskriptet:
Og inkluderte også en «Dette er et enkelt konseptbevis for avhengighetsforvirringsangrep"ansvarsfraskrivelsesbeskrivelse i pakke.jsonDette er et klart brudd på tjenestevilkårene, selv uten ondsinnet hensikt.
Noen gode nyheter? Vi har (ennå) ikke sett ransomware-angrep levert gjennom ondsinnede komponenter. Av ukjente årsaker ser det ut til at nettkriminelle foretrekker mer tradisjonelle e-postphishing, RDP-baserte og drive-by-nedlastingsleveringsmekanismer.
Ytterligere teknikker observert
Mange teknikker ble brukt for utholdenhet, forsvarsunndragelse, informasjonsinnsamling, kommunikasjon med kommando- og kontrollverter og eksfiltrering.
Utholdenhet i skadelige komponenter oppnås ved hjelp av persistensfunksjonene i en binær skadelig programvare i andre trinn, men noen ganger er oppførselen plassert i pakkekoden, med planlagte oppgaver og endringer i Windows-registeret som de vanligste.
obfuscation er vanlig, men lite avansert. De fleste typosquatting-pakkene (husk «ansjos«?) bruker ikke obfuskering i det hele tatt; mange bruker enten trivielle koder (base64/heks-koding eller substitusjonschiffere som rot13) eller bruker tilgjengelige kodeobfuskatorer og minifisering, som enkelt kan reverseres med riktig verktøy. Bare «haiene» utfører ekte, hardbarket obfuskering som er vanskelig å reversere.
Tilsløring kan skjule angrepet, men hvorfor skulle kode i en åpen kildekode-komponent måtte tilsløres? Finnes det bevis for at noe må skjules for åpent syn? Vi har funnet mange tilfeller av ikke-skadelige pakker som bruker tilsløring for å beskytte åndsverk, noe som er i motsetning til «åpen kildekode». Tilsløring kan brukes som bevis på skadelig programvare, men det er ikke avgjørende. Det er også vanskelig å av-tilsløre.
Evasion fra forsvarskontroller tar i bruk enkle teknikker. Ondsinnet kode er ofte beskyttet i prøv … fang blokker som ignorerer eventuelle unntak, slik at unormal aktivitet ikke vises i loggene. Verifisering av miljøet (som kjører i en virtuell maskin eller container) er sjelden, med mindre det gjelder skadelig programvare som er rettet mot en bestemt organisasjon eller et bestemt miljø.
Å maskere binærfiler i bilder og PDF-filer (en slags steganografi) var en annen teknikk som ble sett for å unngå deteksjon.
Ettersom de vanligste skadelige komponentene er infotyveri, datainnsamling er essensielt. Hemmeligheter (passord, tilgangstokener, API-nøkler, kryptografiske nøkler) skannes rutinemessig i loggfiler, miljøvariabler og til og med utklippstavlen (sett med banktrojanere og kryptotyvere). Kildekodeutrensing er også vanlig, ettersom pakkeinstallasjonen ofte gjøres i en utviklingsnode der interne git-repositorier kan klones. Vi har sett pakker som lister opp kataloger på jakt etter git-repositorier. Å lete etter steder som .env, private.pem, settings.py, app.js eller application.properties er ganske vanlig.
Eksfiltrering er en annen mye brukt handling. Bare et mindretall av ondsinnede pakker prøver til og med å skjule destinasjonen til de utvunnede dataene. Telegram-kanaler og ngrok-lignende tunneler brukes ofte. Og det finnes mange vanligvis hvitelistede domener som brukes til eksfiltrering.
Andre teknikker, som privilegieøkning eller lateral bevegelse, var mindre vanlige.
Å oppnå popularitet og tillit
Se for deg en teknologikjeltring med en ferdiglaget, ondsinnet ting som lurer: «Hvordan gjør jeg denne drittsekken troverdig for de intetanende idiotene?»
Det betyr hvordan man lager oppføringen for den skadelige komponenten til å vise mange stjerner / forgreninger (for popularitet), pluss versjoner / problemer og pull requests (for aktivitet). Ideen er å oppnå fiktiv popularitet (stjerner) og avhengige personer, og et overbevisende utseende med hensyn til relevans og vedlikehold.
Registeret sjekker ikke om innholdet i et GitHub-prosjekt og pakkeinnholdet samsvarer.Dette er et velkjent problem i programvareforsyningskjeden. De offentlige registrene er gigantiske synkehull som sluker alt som blir kastet på dem. Du kan koble sammen hvilket som helst arkiv.
Hvis den ondsinnede pakken gjør en skrivefeil i en populær pakke, er det enkelt: bare referer til det eksisterende GitHub-repositoriet i avhengighetsmanifestet som brukes til å opprette pakken og publisere den i registeret. For nye pakker på et falskt GitHub-repo kan det hende du trenger mer oppfinnsomhet, kanskje å lage falske stjernekikking/forgrening GitHub-kontoer via skripting.
Og hvis innholdet i pakken din er rimelig likt depotet, kan du legge til et par veldesignede endringer her og der ... Du kan injisere skadelig programvare i en ny pakke som ligner på en populær pakke som refererer til det eksisterende depotet, og vente på skrivefeilene. Hvis noen tør å sammenligne innholdet i pakkens tarball med innholdet fra GitHub-depotet, kan forskjellene ved injeksjonspunktene for skadelig programvare lett bli oversett. Vi har sett denne tilnærmingen mange ganger før.
En mekanisme for at en komponent skal kunne lage en manipuleringssikker uttalelse om opprinnelse, hvordan pakken ble bygget fra, fra hvilke kilder og av hvem, ville være velkommen. Men det er en annen historie.
Er komponent X skadelig programvare?
Finnes det en (omfattende) database over ondsinnede pakker? Nei. Sårbarheter med åpen kildekode har en CVE-ID tildelt, men bare noen få ondsinnede pakker (spesielt de som skaper overskrifter) får en. CWE for ondsinnede pakker er CWE-506 (innebygd ondsinnet kode).
De vanlige skadevareverktøyene (VirusTotal, MalwareBazaar, SOREL-20M…) har ingen spesifikke muligheter for skadelige komponenter. Det ville vært velkomment!
Det finnes forskningsdatabaser og datasett for analyse (vi bruker noen få av dem), men oppføringene oppdateres bare når den skadelige pakken er kjent, noe som ofte er for sent. Hvis du er interessert, OpenSSF Ondsinnede pakker er en fin start.
I neste innlegg skal vi diskutere hvordan man kan vite om en gitt pakke er skadelig. Spoiler: ja, det finnes måter å sjekke etter skadelige komponenter tidlig i eksponeringsvinduet, før registeret fjerner en kjent skadelig komponent.
Videre lesing
I neste episode «Beskyttelse mot skadelige pakker med åpen kildekode: Hva fungerer (ikke fungerer)" Vi skal diskutere hva man bør og ikke bør gjøre når det gjelder sikkerhet med åpen kildekode. De fleste sikkerhetsbevisste fagfolk har intuisjon om hvordan de skal håndtere denne trusselen, men det finnes mange misoppfatninger.
Vi vil gjennomgå hvorfor disse ideene er feil, og hvordan slike misoppfatninger bidrar til populariteten til denne angrepsmekanismen, og til den overveldende risikoen som organisasjoner opplever. Vi vil deretter gå videre med hva som fungerer, og hva som er innsatsen og ressursene som er involvert.
Vi skal også legge ut innlegg om utviklingen av ondsinnede pakker med tanke på deres hensikt, injeksjonsmekanisme og angrepsteknikker.
Følg med!
