Programvareteknologien utviklet seg, og hackere utviklet seg med den. Våpenkappløpet med skurker var stort sett begrenset til sårbarheter og angrep rettet mot den distribuerte programvaren. Å angripe programvarens forsyningskjede, om enn ikke usett, var ikke det primære målet for skurkene ...
Angrepet mange adresserte som starten på et skifte i modus operandi for avanserte vedvarende trusler (APT-er) var SolarWinds angriperIkke den første, men med en slik innvirkning at den skapte overskrifter og tok ITsec med storm.
Eksempler: SolarWinds, Codecov, Kaseya
SolarWinds er en stor programvareleverandør som tilbyr verktøy for nettverks- og infrastrukturovervåking. Et av selskapets produkter er Orion, en plattform for infrastrukturovervåking og -administrasjon. Den brukes av mer enn 30 000 offentlige og private organisasjoner for å administrere IT-ressursene sine. Orion får tilgang til IT-systemer for å innhente logg- og systemytelsesdata.
I desember 2019 fikk hackere tilgang til nettverkene, systemene og dataene til tusenvis av SolarWinds-kunder. De angrep programvareforsyningskjeden deres ved å sette inn skadelig kode i plattformen. Deretter leverte SolarWinds bakdørs-skadevaren som en oppdatering til Orion-programvaren, som hackere kunne få tilgang til og utgi seg for å være brukere og kontoer til offerorganisasjoner. SolarWinds-bruddet førte til en oppvåkning innen nettsikkerhet for alle organisasjoner som opererer i den skybaserte verdenen.
Dette angrepet på forsyningskjeden ble etterfulgt av andre, som Codecov, et verktøy for programvarekodedekning. I januar 2021 ble en angriperen hentet ut en legitimasjon lagret ved en feiltakelse i Codecovs Docker-bilde, som aktøren brukte til å endre et opplastingsskript i verktøyet. Aktøren satte bare inn en enkelt kodelinje som sendte alle CI-ens miljøvariabler til angriperens kontrollerte server da skriptet ble kjørt. I flere måneder fikk de ondsinnede aktørene potensiell tilgang til systemer som brukte det modifiserte Codecov-skriptet.
Senere, 2. juli 2021, den angrepet på Kaseya skjedde. VSA-plattformen deres brukes av mange MSP-er som tilbyr IT-tjenester til andre selskaper for å utføre patchhåndtering og kundeovervåking. Hackere angrep Kaseya VSAs forsyningskjede, kompromitterte infrastrukturen og slapp deretter ut ondsinnede oppdateringer på VSAs lokale servere for å infisere de administrerte selskapenes systemer, kryptere dataene deres og kreve løsepenger. Løsepengevirus via et trojansk verktøy brukt av MSP-er på deres administrerte selskaper, som er sluttmålene. Så smart!
Siden SolarWinds-hendelsen har det vært flere og flere angrep mot programvareforsyningskjeden, noe som har påvirket imaget og økonomien til selskaper som Samsung, Uber, Nissan, Nvidia og mange andre. Ifølge Gartner vil «45 % av organisasjoner over hele verden innen 2025 ha opplevd angrep på programvareforsyningskjedene sine, en tredobling siden 2021».
En ny generasjon av angrep på programvareforsyningskjeden
Å angripe et selskaps proprietære applikasjoner eller produksjonsmiljøer genererer bare ett offer. Dette, kombinert med det faktum at de aller fleste selskaper allerede har implementert AppSec-beskyttelse som AST, SCA eller WAF-verktøy, har ført til fremveksten av en ny generasjon angripere som retter seg mot programvareutvikling pipelineAngrep på forsyningskjeden kan påvirke tusenvis av selskaper med bare ett enkelt angrep: den ideelle forsterkeren.
Utviklingsinfrastrukturen er et enkelt mål for angripere. Den store angrepsflaten gir tilgang til produksjonsmiljøet og dets data. Hele infrastrukturen av DevOps-verktøy: repositorier, kildekontrollsystemer, byggeverktøy, distribusjonsverktøy, infrastruktur som kodemaler, containere, skriptfiler osv., er ganske stor og sårbar. Dessuten er alle disse verktøyene langt fra sikkerhetsområdets kontroll og administreres av utviklings- og produksjonsteamene. Hackere vet dette og utnytter disse svakhetene.
Det nye målet
Utviklere skriver ofte hemmeligheter i kildekoden, som for eksempel legitimasjon og nøkler for testing under utvikling. Disse lagres i filer, ofte under versjonskontroll, og kan bli funnet av angripere i fremtiden, selv om filene eller hemmelighetene fjernes. Dette vil tillate angripere å installere bakdører, lese kildekoden, sette inn skadelig kode, trekke ut sensitive data osv. ... Når ondsinnede aktører har gyldige ... login legitimasjon de kan bevege seg sidelengs gjennom SDLCDisse påloggingsinformasjonene lar dem gå videre til andre verktøy og få avanserte brukerrettigheter for å søke etter informasjon av høyere verdi.
Hackere kan bruke legitimasjon til å bryte seg inn i SDLC, men de kan også bryte seg inn i databaser eller verktøy som er feil konfigurert eller usikre, noe som setter systemer og data i fare.
Angrep retter seg også mot pakker med åpen kildekode. Vi kjenner alle skrekkhistorier om angrep som utnytter kjente sårbarheter, som Log4j. På den annen side er angrep i forsyningskjeden annerledes: angripere injiserer skadelig kode i populære pakker med åpen kildekode for senere bruk i byggeprosessen av mange organisasjoner i verden.
Kort sagt: hackere kan utnytte privilegert tilgang, feilkonfigurasjoner og sårbarheter i CI/CD pipeline infrastruktur som en vektor for å sette inn skadelig programvare i programvare som kan brukes av mange.
Hvordan beskytte våre SDLC fra angrep i programvareforsyningskjeden?
Antallet angrep i forsyningskjeden øker jevnt og trutt, og markedet reagerer på dette scenariet. Noen organisasjoner har etablert rammeverk for å håndtere dette. software supply chain security, som NIST Secure Software Development Framework (SSDF) og Googles Supply Chain Levels for Software Artifacts (SLSA). Det er imidlertid ikke mange selskaper som prioriterer å beskytte DevOps-verktøy og -infrastruktur for å unngå angrep på forsyningskjeden. Faktisk, 82 % av IT-sjefer tror de vil være sårbare for dem.
Bedrifter må ikke bare bekymre seg for å beskytte applikasjonene sine, men også programvareinfrastrukturen og artefaktene som er en del av deres SDLC ettersom ondsinnede aktører retter seg mot forsyningskjeden. Bredden i angrepsflaten, mangelen på bevissthet hos utviklingsteamene om denne typen angrep og mangelen på spesialiserte sikkerhetsverktøy gjør at angripere kan fokusere på programvarens forsyningskjede.
Avsluttende kommentarer
Beskytter vår pipeline blir mer presserende for hver dag, og en prioritet for CISOs, som må sørge for at sikkerhetsteamene følger med på forsyningskjeden og samarbeider med Devops-teamene for å beskytte SDLC fra denne typen angrep.
Bruk av verktøy som hjelper oss med å sikre oss SDLC, identifisere bakdører, mistenkelig atferd og stoppe angrep i forsyningskjeden er nødvendig for å holde DevOps-miljøet vårt privat og sikkert. De første verktøyene for å beskytte software supply chain security begynner å dukke opp. Noen er mer fokusert på utviklingssiden og andre på driftssiden. Og noen, som for eksempel Xygeni, har som oppdrag å beskytte integriteten og sikkerheten til programvareøkosystemet gjennom hele DevOps.
For å lese mer |
|
|
|
|
