Öppen källkod är en grundbult inom modern digitalisering. Genom färdiga kodpaket från ekosystem som npm, PyPI, Crates.io och Composer kan företag utveckla tjänster snabbare, billigare och ofta bättre. Men effektiviteten skapar också ett växande säkerhetsproblem. När tusentals verksamheter använder samma komponent räcker det med ett enda manipulerat kodpaket för att det ska bli en distributionskanal rakt in i företagens utvecklingsmiljöer – och användas för cyberattacker.
Mellan den 18 maj och den 1 juni, identifierades fyra separata angreppskampanjer mot sex olika ekosystem för öppen källkod. Metoderna varierade, men målet var att köra skadlig kod där företagens autentiseringsuppgifter lagras. Angriparna sökte bland annat efter nycklar och token till AWS, Azure, Google Cloud, GitHub, SSH och Kubernetes.
Tusentals kodförråd infekterades på några timmar
Det finns fler skrämmande exempel som bör vara en varningsklocka för svenska företag. I attacken Megalodon placerades 5 718 skadliga kodändringar i 5 561 GitHub-förråd på sex timmar. Angriparna använde till synes oskyldiga meddelanden om optimeringar av byggprocessen, men lade samtidigt in arbetsflöden som kunde stjäla hemligheter från utvecklingsmiljöerna.
I ett annat angrepp manipulerades över 700 versioner av kodpaket kopplade till Laravel-Lang. Den skadliga koden sökte efter nycklar till Amazon Web Services, Google Cloud och Microsoft Azure, inloggningsuppgifter i webbläsare och lösenordshanterare samt information om kryptoplånböcker.
Kampanjen TrapDoor spreds samtidigt genom tre olika paketsystem. Där försökte angriparna även injicera promptar riktade mot AI-kodassistenter. Syftet var att få verktygen att uppfatta angreppet som en legitim säkerhetskontroll och hjälpa till att dölja stölden.
Angreppen krävde inga spektakulära zero day-sårbarheter. I stället utnyttjades betrodda konton, kodpaket, automatiserade arbetsflöden och publiceringsmekanismer.
En stulen nyckel är ofta början, inte slutet
Utvecklingsmiljön betraktas ofta som skild från den verkliga verksamheten. Men dagens automatiserade bygg- och publiceringssystem behöver omfattande behörigheter för att kunna fungera. Där finns nycklar till molntjänster, databaser, kundsystem och produktionsmiljöer.
Skadlig kod på en utvecklares dator kan därför nå långt utanför den komponent där angreppet började. Om angriparen redan har fått tillgång till viktiga tjänster kan den åtkomsten finnas kvar även efter att infektionen har avlägsnats.
Hotet är redan relevant i Sverige
Den 14 juli varnade CERT-SE för skadliga versioner av fyra npm-paket inom AsyncAPI. Paketen hade manipulerats genom ett koordinerat leveranskedjeangrepp mot GitHub-miljöer och innehöll kod som gav åtkomst till olika system. CERT-SE:s varning visar att svenska organisationer i högsta grad kan utsättas för denna typ av angrepp.
Sverige har redan sett konsekvenserna av en komprometterad digital leverantörskedja. Kaseya-angreppet 2021 spreds genom ett fjärradministrationsverktyg och ledde bland annat till att Coop tvingades stänga hundratals butiker. Angreppet var inte identiskt, men principen var densamma: angriparen utnyttjade en betrodd länk i leveranskedjan i stället för att angripa varje slutkund.
Säkerhetsarbetet måste flytta närmare utvecklingen
Att sluta använda öppen källkod är varken realistiskt eller önskvärt. Däremot behöver företag bättre kontroll över sina komponenter och de behörigheter som komponenterna kan nå.
För det första behövs en aktuell förteckning över kodberoenden. När ett paket pekas ut som skadligt måste säkerhetsteamet snabbt kunna se vilka produkter, system och versioner som berörs. Det kräver automatiserad kontroll och ofta en programvaruförteckning, en SBOM.
För det andra måste hemligheter hanteras som färskvara. Nycklar bör vara kortlivade, ha minsta möjliga behörighet och kunna roteras automatiskt. Permanenta molnnycklar i kod, konfigurationsfiler eller på utvecklarnas datorer är en onödig risk.
För det tredje bör företag begränsa vad som får ske automatiskt när ett paket installeras. Paketversioner bör låsas, nya beroenden riskbedömas och avvikande ändringar i byggprocessen granskas särskilt.
Slutligen måste en misstänkt komponent behandlas som en möjlig identitetsincident. Frågan är inte bara om skadlig kod har funnits i miljön, utan vad den kunde komma åt. Att avinstallera paketet utan att spärra och ersätta exponerade nycklar kan lämna dörren öppen.
Det här angår inte enbart utvecklare eller it-säkerhetsavdelningen. Företagsledningen behöver veta vilka externa kodkomponenter verksamheten är beroende av, vem som ansvarar för dem och hur snabbt organisationen kan agera vid en incident. Öppen källkod bygger på förtroende, men förtroende får inte förväxlas med frånvaro av kontroll.
Guillaume Valadon
Staff cybersecurity researcher, Gitguardian
