Lanac opskrbe softvera uključuje sve ljude, tvrtke, alate i usluge koji sudjeluju u kreiranju i dostavljanju softvera korisnicima. U napadu na lanac opskrbe napadač traži najranjiviju kariku u lancu, te prvo nju napada kako bi mogao zloćudni kod proširiti po lancu sve do željene žrtve. Softver otvorenog koda može biti sastavni dio opskrbnog lanca te je stoga njegovo korištenje također rizično. Najčešći napadi na softver otvorenog koda u cilj izvođena napada na opskrbni lanac su typosquatting i dependency confusion napadi, a sve se to može ublažiti ili u potpunosti spriječiti implementiranjem osnovnih zaštitnih mehanizama.
Jedan od najvećih doprinositelja upravljanju lancem opskrbe softvera, Sonatype, otkrio je porast kibernetičkih napada u projektima otvorenog koda za nevjerojatnih 700% u 2022. godini, što svjedoči o rastućim opasnostima korištenja ovisnosti otvorenog koda [4]. Uz nove napade na lanac opskrbe koji se pojavljuju svaki dan, tvrtke i pojedinačni programeri moraju brzo implementirati promjene u svoj proces odabira ovisnosti otvorenog koda koje planiraju koristiti u svojim projektima.
Dok prvo poglavlje ovog rada uvodi čitatelja u napade na lanac opskrbe, drugo se poglavlje fokusira na napade na lanac opskrbe u projektima otvorenog koda s pojedinostima o njihovim tipovima i nekoliko primjera iz stvarnog života. Rad završava prijedlozima za ublažavanje i prevenciju takvih napada te zaključkom.
U napadu na lanac opskrbe, napadač ima za cilj infiltrirati se u žrtvin sustav kompromitirajući pouzdanog, ali ranjivijeg dobavljača treće strane koji nudi softver ili usluge žrtvi i preko njih može proširiti zloćudni kod na željenu metu napada. Mnoge tvrtke koriste kod, proizvode i usluge trećih strana jer nema smisla sve raditi ispočetka te su stoga ranjive na ovu vrstu napada [1]. Napadi na lanac opskrbe obično se koriste protiv tvrtki koje je teško, ako ne i nemoguće, izravno kompromitirati pa se najprikladnija ulazna točka u ciljni sustav traži na najslabijoj karici u uzvodnom lancu opskrbe [2].
Postoji nekoliko različitih vrsta napada na opskrbni lanac. Daleko najpopularniji je uzvodni napad na poslužitelj gdje je softver koji korisnici mogu preuzeti zaražen zloćudnim kodom, a kao rezultat toga svi korisnici koji su preuzeli softver su zaraženi te stoga njihovi sustavi također mogu biti ugroženi. Ostale vrste napada uključuju kompromitiranje alata za razvoj softvera, krađu certifikata koji se koriste za autentifikaciju korisnika, infiltraciju zloćudnog softvera u CI/CD infrastrukturu i dependency confusion napade o kojima će više riječi biti u kasnijim poglavljima [1].
Jedan od najpoznatijih napada na opskrbni lanac koji se ikada dogodio bio je napad na tvrtku SolarWinds u prosincu 2020., koji je ugrozio mnoge tvrtke i organizacije visokog profila, uključujući FireEye, Microsoft i Ministarstvo domovinske sigurnosti SAD-a. Napadač, za kojeg je kasnije otkriveno da je ruski APT poznat pod nazivom Cozy Bear, ubacio je zloćudni kod u ažuriranje platforme SolarWinds Orion koja se koristi za IT nadzor i upravljanje, što je rezultiralo daljnjim kompromisima i, u konačnici, krađom podataka. SolarWinds je kasnije izvijestio da je približno 18.000 korisnika preuzelo zaražene verzije njihovog softvera, što ga čini jednim od najvećih napada na opskrbni lanac do danas [3].
Napadi na lanac opskrbe u softveru otvorenog koda obično se odnose na projekte, biblioteke i pakete koji su javno dostupni putem softverskih repozitorija kao što su npm Registry, PyPI, Maven Repository i mnogi drugi. Ove projekte otvorenog koda koriste mnoge tvrtke u svojim projektima zahvaljujući njihovoj dostupnosti i pristupačnosti. Postoji velika mogućnost brzog ažuriranja i nadogradnje koda jer cijela zajednica može doprinijeti projektu. Nažalost, postoji loša strana tog mehanizma, budući da se zajednica sastoji od potencijalno anonimnih članova, svatko može objaviti cijeli softver ili ažuriranje koje se na kraju spoji sa softverom i može, na taj način, isporučiti zloćudni kod žrtvi. Ako programeri nisu dovoljno pažljivi, ovaj kod se može preuzeti i izvršiti, potencijalno pružajući napadaču pristup sustavu i tako oštetiti sustav ili uzrokovati financijske probleme [4].
Nemar pri pregledu zahtjeva za povlačenje nije jedini izvor lošeg koda u legitimnom softveru. Bilo je brojnih slučajeva u kojima su autori bili prevareni da podijele svoje vjerodajnice zlonamjernim akterima koji su ih potom upotrijebili za otimanje korisničkog računa autora i objavljivanje zlonamjernih ažuriranja. Slično tome, poznato je da akteri iskorištavaju ranjivosti u projektima otvorenog koda za širenje zloćudnog koda [5].
Za pakete koji su od samog početka namijenjeni da budu zlonamjerni, napadač nema potrebe za ugradnjom lošeg koda u legitimne projekte, ali se suočava s problemom navođenja programera da instaliraju njihov paket umjesto legitimnog. Dakle, akteri moraju maskirati svoje pakete na takav način da u programerima ne uzrokuju sumnju prije preuzimanja paketa. Da bi se to postiglo, koriste se mnoge tehnike, od kojih su neke stvaranje README datoteke legitimnog izgleda ili čak kopiranje jedne iz legitimnih paketa, imenovanje paketa slično postojećem paketu te kopiranje cijelih projekata i skrivanje zlonamjernog koda negdje unutra.
Najčešći napadi su typosquatting i dependency confusion, također poznati kao namespace confusion napadi. Napadi typosquattinga događaju se kada zlonamjerni akter imenuje paket kao pogrešno napisani oblik legitimnog naziva paketa. Ova se metoda oslanja na činjenicu da programeri čine pogreške prilikom instaliranja paketa i, kao rezultat toga, instaliraju pogrešan paket, na primjer, umjesto preuzimanja paketa 'requests' preuzmu 'reuqests' [6]. Dependency confusion napade popularizirao je istraživač Alex Birsan nakon što je objavio svoj blog u kojem opisuje kako je uspio 'hakirati' velike tehnološke tvrtke poput Microsofta i Applea. Ova vrsta napada oslanja se na pogrešnu konfiguraciju načina na koji interni poslužitelji biraju lokaciju ovisnosti, što rezultira izvođenjem javnog ili vanjskog paketa umjesto internog s istim imenom [7].
Ovo nisu jedini načini na koje se programere može oštetiti. Autori mogu sabotirati vlastite, do tada legitimne, pakete iz više razloga. Jedan takav slučaj je bio 'node-ipc' paket gdje je autor odlučio objaviti ažurirani kod koji bi izbrisao sve datoteke s računala s IP adresama u Rusiji ili Bjelorusiji u znak protesta protiv ruske agresije na Ukrajinu [9]. S drugačijom motivacijom autor 'colors.js' i 'faker.js' sabotirao je ove pakete jer je smatrao da nije dobio dovoljnu novčanu naknadu od strane zajednice za njegov doprinos ovim popularnim projektima [10]. Još jedan poznati slučaj ugradnje zlonamjernog koda u popularni legitimni projekt dogodio se 2018. kada je napadač preuzeo vlasništvo nad paketom pod nazivom 'event-stream' i objavio novu verziju koja je sadržavala zlonamjernu ovisnost 'flatmap-stream'. U ovom slučaju vlasništvo je dragovoljno prenio izvorni autor nakon što je napadač uspio zadobiti njegovo povjerenje [8].
Tvrtke i razvojni programeri tek počinju shvaćati utjecaj napada na opskrbni lanac u projektima otvorenog koda i hitnost njihovog sprječavanja. Kako bi ublažile rizike uspješnog napada, tvrtke bi trebale investirati u rješenje koje može skenirati softver otvorenog koda u potrazi za poznatim ranjivostima i potencijalno zloćudnim sadržajem te uvijek koristiti pouzdane ovisnosti. Uključivanje Red team testiranja u procjenu rizika također je važan preventivni mehanizam. Individualni programeri trebali bi biti oprezni pri odabiru ovisnosti provjeravajući da naziv paketa nije pogrešno napisan i da projekt ima opsežnu dokumentaciju s dokazima o redovitim ažuriranjima u slučaju pronađenih ranjivosti [11].
Još jedna potvrda da je pronađeni projekt doista onaj kojeg programer traži je broj preuzimanja i održavatelja. Ako samo jedna osoba radi na projektu, postoji veći rizik od unesenih ranjivosti, pa čak i zloćudnog koda. Također, paket sa samo nekoliko preuzimanja vjerojatno nije pravi izbor za ovisnost, s brzo skeniranje koda prije preuzimanja može spriječiti mnoge jednostavne napade [6].
Autori projekata otvorenog koda također bi se trebali zaštititi od zlonamjernih aktera tako što će svoje vjerodajnice držati privatnima, biti svjesni potencijalnih phishing e-mailova i omogućiti višefaktorsku provjeru autentičnosti. Kada razmatraju zahtjev za povlačenjem, autori bi trebali pažljivo pregledati novi kod te potencijalno uključiti neku drugu osobu u pregled zahtjeva prije nego što ga spoje s ostatkom koda [12].
Porast napada u opskrbnom lancu softvera otvorenog koda očit je i još uvijek hvata mnoge tvrtke i programere nespremne i neopremljene da se nose s posljedicama. Uz mnogo primjera takvih napada, obrambena strana ekosustava uvodi svoja preventivna rješenja. Na programerima je da počnu implementirati ta rješenja i da oprezno upravljaju ovisnostima.