Angreb i virksomhedernes forsyningskæde steg med over 600 % i år

De fleste virksomheder mener, at de ikke bruger open source-softwarebiblioteker med kendte sårbarheder, men nye undersøgelser finder dem i 68% af udvalgte virksomhedsapplikationer.

Antallet af dokumenterede forsyningskædeangreb, der involverer ødelæggende tredjepartskomponenter, er steget 633% i løbet af det sidste år og sidder nu på over 88.000 kendte tilfælde, ifølge en ny rapport fra software supply chain management selskabet Sonatype. I mellemtiden har forekomster af transitive sårbarheder, som softwarekomponenter arver fra deres egne afhængigheder, også nået hidtil usete niveauer og plager to tredjedele af open source-biblioteker.

“Afhængighedernes netværkskarakter fremhæver vigtigheden af at have synlighed og bevidsthed om disse komplekse forsyningskæder,” siger Sonatype i sin nyligt udgivne State of the Software Supply Chain-rapport. “Disse afhængigheder påvirker vores software, så det er afgørende for sårbarhedsrespons at have en forståelse af deres oprindelse. Mange organisationer havde ikke den nødvendige synlighed og fortsatte deres hændelsesresponsprocedurer for Log4Shell langt ud over sommeren 2022 som følge heraf.

Log4Shell er en kritisk sårbarhed opdaget i november 2021 i Log4j, et meget populært Open Source Java-bibliotek, der bruges til logning og bundtes i millioner af virksomhedsapplikationer og softwareprodukter, ofte som en indirekte afhængighed. Ifølge Sonatypes overvågning ligger adoptionsraten for faste versioner af Log4j fra august 2022 på omkring 65%. Desuden tager dette ikke engang højde for det faktum, at Log4Shell-sårbarheden stammer fra en Java-klasse kaldet JndiManager, der er en del af Log4j-core, men som også er lånt af 783 andre projekter og nu findes i over 19,000 softwarekomponenter.

Log4Shell fungerede som et vendepunkt og fremhævede de iboende risici, der findes i open source-softwareøkosystemet – som sidder i kernen i moderne softwareudvikling – og behovet for at styre dem korrekt. Det førte også til flere initiativer til at sikre softwareforsyningskæden af private organisationer, software repository managers, Linux Foundation og offentlige organer. Alligevel er de fleste organisationer langt fra, hvor de skal være med hensyn til open source supply chain management.

Open source-forbruget fortsætter med at vokse

Den gennemsnitlige vækst fra år til år i pakkedownloads fra de øverste komponentlagre – Maven Central (Java), npm (JavaScript), PyPi (Python) og NuGet (.NET) – er 33%. Dette er lavere end i tidligere år, såsom 2021’s vækst på 73%, men antallet af komponentdownloads har allerede passeret 2021’s tal på tværs af alle arkiver og ligger samlet på over 3 billioner. Npm-depotet alene vil betjene flere downloads i år, end alle fire arkiver gjorde i 2021.

Faldet i open source-forbrugsraten skyldes ikke nødvendigvis, at brugerne implementerer strengere open source-indkøbs- og forvaltningspolitikker, men er snarere normalt i betragtning af den størrelse, som disse økosystemer for forskellige programmeringssprog har nået, og deres hastighed for tilføjelse af nye projekter og udgivelser.

“Selvom væksttempoet er aftagende, fortsætter den absolutte vækstskala med at forværres i forhold til de foregående årlige satser,” konkluderede Sonatype. “Tempoet i open source-adoption viser ingen tegn på at løbe tør for damp når som helst snart.”

Typer af forsyningskædeangreb har diversificeret

Sonatype havde sporet omkring 12,000 kendte tilfælde af ødelæggende angreb indtil udgangen af sidste år, men dette antal er nu vokset til over 88,000, en vækst på 633% år-til-år. Virksomheden har også opdaget 97,334 ondsindede pakker distribueret på en række forskellige måder.

En af de største bidragydere til væksten i ødelæggende pakker er en angrebsteknik kaldet afhængighedsforvirring, der blev offentliggjort af sikkerhedsforskere i februar 2021 og siden har set bred vedtagelse. Teknikken udnytter adfærden hos de fleste pakkehåndteringsklienter, der er konfigureret til at søge efter pakker i både offentlige fællesskabslagre og interne lagre.

Når der findes et pakkenavn begge steder, trækker klienten det med det højeste versionsnummer. Dette forårsager et problem, fordi mange organisationer bruger internt udviklede pakker, der kun findes i deres interne arkiver og aldrig var beregnet til at blive offentliggjort offentligt. Men hvis angribere finder navnene på disse pakker fra manifestfiler, kan de offentliggøre ødelæggende pakker med disse navne i de offentlige arkiver med et højere versionsnummer for at narre softwareopbygningsklienter.

Det er svært at sige, om alle tilfælde har været ødelæggende, fordi teknikken også er populær blandt penetrationstestere. Organisationer kan dog beskytte sig selv ved enten at registrere navnene på deres private pakker i de offentlige arkiver eller bruge præfikser til alle deres pakker, som de derefter kan registreres som navnerum eller omfang på offentlige arkiver, hvilket betyder, at angribere ikke længere skal kunne offentliggøre pakker med disse præfikser.

Andre typer masseangreb, der har været kendt i et stykke tid, er typosquatting og brandjacking, Typosquatting involverer angribere, der registrerer ødelæggende pakker med navne, der ligner dem på nogle populære og udbredte pakker. Dette er et passivt angreb, der er afhængig af, at udviklere laver fejl – stavefejl – når de skriver pakkenavne i deres build-scripts eller kommandoer.

Brandjacking er ens, men er målrettet mod andre pakkevedligeholdere i håb om, at de vil inkludere en kapret eller typosquatted pakke som en afhængighed i deres egne komponenter. Dette kan også ske, når vedligeholderen af en legitim pakke overdrager ejerskabet til en anden, eller når de holder op med at udvikle den pågældende pakke og sletter den, og det gamle navn bliver tilgængeligt.

Ødelæggende kodeinjektion er en anden teknik, der er mere målrettet og involverer angribere, der kompromitterer en udviklers system eller kodelager og injicerer ondsindet kode i deres pakke uden deres viden. Dette kan også ske, når en pakkevedligeholder giver flere parter commit adgang til deres kodelagre, og disse parter enten har ødelæggende hensigter, eller de bliver kompromitteret.

En anden angrebstype, der ligner ødelæggende kodeinjektion, men som begås af legitime udviklere, er kendt som protestware. Dette refererer til hændelser, hvor en udvikler tilføjer ødelæggende kode til deres egen tidligere rene pakke som et tegn på protest.

Valg af komponenter med god sikkerhedspraksis

Opbygning og vedligeholdelse af en oversigt over komponenter, der bruges på tværs af alle interne softwareudviklingsindsatser og sporing af sårbarheder, der opdages i dem, er et centralt aspekt af at afbøde sikkerhedsrisici. Det er dog lige så vigtigt at have klare politikker omkring komponentherkomst. At vælge komponenter eller biblioteker med en lav forekomst af sårbarheder i deres egen kode er ikke en garanti, fordi mange af dem kan arve sårbarheder fra deres egne afhængigheder, så den tid, det tager dem at reagere på sådanne sårbarheder og opdatere deres egne afhængigheder, er kritisk.

Sonatype analyserede et sæt på over 12,000 biblioteker, der almindeligvis bruges i virksomhedsapplikationer, og fandt ud af, at kun 10% af dem havde en sårbarhed direkte i deres kode. Men når man inkluderer transitive sårbarheder arvet fra afhængigheder og afhængigheder af disse afhængigheder, steg forekomsten til 62%. I gennemsnit havde hvert bibliotek 5,7 afhængigheder.

At vælge komponenter baseret på en lavere grad af sårbarheder betyder heller ikke nødvendigvis bedre sikkerhedsresultater i det lange løb, fordi der er meget bias i, hvordan forskere vælger de projekter, de vil undersøge. Med andre ord kan et populært projekt have et højere antal sårbarheder opdaget, bare fordi flere øjne er på det.

“Da de fleste sårbarheder stammer fra transitive afhængigheder, er den klareste vejledning nøje at overveje hvert bibliotek, du bruger,” siger Sonatype. “Favoriserer dem med mindre afhængighedstræer. Se efter projekter, der er hurtige at opdatere, når nye versioner af deres afhængigheder frigives (lav MTTU – gennemsnitlig tid til opdatering). Minimering af det samlede antal afhængigheder og opretholdelse af lave opdateringstider for dit eget projekts afhængigheder er to kritiske faktorer for at reducere risikoen for transitive sårbarheder.

Flere målinger er tilgængelige for at bedømme sikkerhedspraksis for open source-projekter. En af dem er Security Scorecard-systemet udviklet af Open Source Security Foundation (OpenSSF). Dette system udfører en række automatiserede kontroller for at kontrollere, om open source-projekter har urettede sårbarheder, hvis de bruger værktøjer til at hjælpe med at opdatere deres afhængigheder, hvis de kører CI-tests, hvis de kører automatiseret kodefuzzing, hvis de bruger statiske kodeanalyseværktøjer, hvis de undgår farlig kodningspraksis, hvis de udfører kodegennemgang, før de fletter ny kode,  hvis de erklærer og fastgør deres afhængigheder og meget mere.

Sonatype brugte sine egne data til at vurdere stor indflydelse, som nogle af disse fremgangsmåder har på at sænke chancen for, at et projekt havde sårbarheder og fandt ud af, at de højeste effekthandlinger var kodegennemgange, ikke inklusive binære artefakter, undgå farlige kodningspraksis, fastgørelse af afhængigheder og gennemgang af kodeforpligtelser.

“Vi anbefaler fortsat, at udviklere vælger komponenter med den højeste MTTU, Security Scorecard, OpenSSF Criticality og SourceRank i den rækkefølge,” siger rapporten fra Sonatype. “Vi forstår, at det kan være svært at samle og veje de forskellige scoringer. Vi har gjort det nemmere ved at tilføje den nye Sonatype Safety Rating til vores offentlige sårbarhedsdatabase OSS Index.”

Virksomheder er overmodige i deres open source-praksis

Sonatype kørte en undersøgelse af 662 virksomhedsingeniører og stillede 40 spørgsmål om deres brug af open source-komponenter, afhængighedsstyring, styring, godkendelsesprocesser og værktøjer. De fleste af svarene angav niveauer af supply chain management, der var lavere end hvad der kræves for at producere resultater af høj kvalitet i Sonatypes vurdering.

De højeste scorer var i kategorierne afhjælpning og applikationsopgørelse. For eksempel sagde 68% af respondenterne, at de var sikre på, at deres applikationer ikke brugte kendte sårbare biblioteker, og 84% sagde, at de undersøger sikkerhedshistorikken for de open source-komponenter, de bruger. Dette matchede imidlertid ikke Sonatypes resultater i praksis, hvor en scanning af 55,000 tilfældigt udvalgte virksomhedsapplikationer afslørede, at 68% af dem havde kendte sårbarheder.

“Vi udnyttede de demografiske data, der blev indsamlet under undersøgelsen, og opdelte resultaterne efter jobtitel,” siger forskerne. “Resultaterne var oplysende. Der er en løbende bias mod at se tingene i et bedre lys, hvor ledere rapporterer højere modenhedsstadier sammenlignet med hvad der rapporteres af andre roller. I hele undersøgelsen er denne uoverensstemmelse statistisk signifikant, når man sammenligner it-chefer og dem, der arbejder i informationssikkerhedsroller.

Kilde: CSO

Foto: Pexels