Förhindra attacker i leveranskedjan med Encryption Consultings Build Verifier

Kodsignering är en avgörande mekanism för att etablera autenticitet och förtroende, vilket säkerställer att programvara inte äventyras under distribution. I dagens sammankopplade värld, där programvara utgör dess grund, har säkerheten i programvaruleveranskedjan aldrig varit viktigare. De senaste händelserna, exemplifierade av SolarWinds-attacken, har belyst de sårbarheter som kan utnyttjas inom denna leveranskedja, och de fungerar som en tydlig påminnelse om vikten av att skydda kodsigneringspraxisDen här bloggen fördjupar sig i invecklade aspekter av sådana attacker, belyser deras utförande och utforskar proaktiva säkerhetsmetoder för att stärka programvaruleveranskedjan.

Vad är SolarWinds-attacken?

SolarWinds-attacken var massiv försörjningskedjan attack som riktade sig mot SolarWinds Orion-plattformen, en allmänt använd programvara av stora företag och myndigheter för att hantera infrastruktur. Genom att kompromettera SolarWinds under programvaruutvecklingsfasen fick angriparna tillgång till plattformens kunders nätverk, vilka var deras slutgiltiga mål.

I en leveranskedjeattack injiceras skadlig kod i produkten under dess skapande eller tillverkningsprocess, vilket gör det möjligt för hackare att utnyttja slutanvändarna när de väl mottagit den infekterade produkten. I det här fallet infiltrerade angriparna programuppdateringarna med skadlig kod innan uppdateringarna distribuerades till kunderna som en del av det rutinmässiga underhållet.

Fördelen med denna attackstrategi är att den skapar en dold bakdörr in i nätverket för varje slutanvändare som använder den komprometterade produkten. Med SolarWinds Orion-plattformen hade angriparna en ännu kraftfullare ingångspunkt eftersom den sträcker sig över användarens nätverk, vilket ger betydande kontroll.

Väl inne kunde hackarna distribuera ytterligare skadlig kod för att utöka sina möjligheter, eskalera attacken och bibehålla sin närvaro oupptäckt. Attacken hade en långtgående inverkan och påverkade ett flertal organisationer som förlitade sig på SolarWinds Orion för sin verksamhet och satte känsliga uppgifter i fara.

Hur genomfördes SolarWinds-attacken?

SolarWinds-attacken började med att skadlig kod infogades i programuppdateringar den 20 februari 2020. Den 26 mars 2020 hade komprometterade uppdateringar distribuerats till SolarWinds kunder, vilket installerade Sunburst-bakdörren på deras nätverk. Angriparna fick direkt åtkomst genom denna bakdörr. SolarWinds använde kodsignering, men angriparna infogade den skadliga koden under utvecklingen och kringgick därmed kodsigneringSunburst kommunicerade med angriparnas servrar förklädda till legitim trafik. Angriparna använde sedan skadliga program som Teardrop och Raindrop för att eskalera attacken mot utvalda offer. Attacken hade en betydande inverkan på organisationer som förlitade sig på SolarWinds Orion.

Låt oss diskutera var och en av dessa komponenter steg för steg:

1. Sunspot-skadlig programvara

   Sunspot, som driftsattes i september 2019, var den första skadliga programvaran som användes i SolarWinds-attacken. Dess enda syfte var att i hemlighet infoga en skadlig bakdörr i SolarWinds Orion-källkod, som fungerade i smyg på byggservern. När Orion-byggkommandon upptäcktes ersatte Sunspot i tysthet den legitima koden med den komprometterade versionen.

2. Sunburst-bakdörrsskadlig programvara

   Sunburst, den primära bakdörrsskadliga programvaran, låg i DLL-filen "SolarWinds.Orion.Core.BusinessLayer.dll". Dess funktion var att upprätta kommunikation med angriparnas servrar via HTTP. Den var dold i en trojaniserad version av en Windows Installer-patchfil, som samexisterade med legitima uppdateringsfiler. Sunburst försattes i två veckor i viloläge efter installationen för att undvika upptäckt och aktiverades sedan för att kommunicera med angriparnas domän. Den maskerade sin kommunikation som SolarWinds API-trafik och registrerade känsliga nätverksdata från offret.

3. Solorigate DLL-filen

   Angriparna bäddade in Sunbursts kod i en DLL-fil och döpte den till ”OrionImprovementBusinessLayer” för att den skulle smälta in. Klassen innehöll den fullständiga bakdörrsfunktionen och var utformad för att vara lätt och diskret. Den placerades i metoden ”RefreshInternal” för att säkerställa regelbunden anropning utan att störa normal drift.

4. Tårdroppe och regndroppe

   Efter den inledande rekognosceringen med Sunburst använde angriparna ytterligare skadlig kod, Teardrop och Raindrop, med sikte på specifika offer som bedömdes lämpliga för eskalering.

SolarWinds-angriparna genomförde en noggrann plan för att kompromettera byggservern före kodsigneringsstadiet och injicera den skadliga koden. Deras infiltration av byggservern gav dem ett strategiskt fotfäste för att manipulera programuppdateringsproceduren, vilket garanterade introduktionen av skadlig kod före det kritiska kodsigneringssteget. Detta gjorde det möjligt för angriparna att förbli oupptäckta, eftersom den komprometterade koden bar signaturen av ett giltigt SolarWinds-certifikat, vilket skapade en vilseledande fasad av äkthet.

Vilka metoder finns det för att framgångsrikt genomföra en sådan attack?

Låt oss förstå olika strategier som kan användas för att utföra liknande attacker och kompromettera mjukvaruleveranskedjan.

1. Få obehörig åtkomst till kodsigneringsnycklar

   Denna taktik innebär att man förvärvar kryptografiska nycklar används för att signera programkod. Dessa nycklar försäkrar användarna om att den nedladdade programvaran inte har manipulerats. Att stjäla dessa nycklar gör det möjligt för angripare att signera sin skadliga kod, vilket gör att den ser äkta och trovärdig ut för användare och säkerhetskontroller.

2. Intrång i byggservern, vilket observerades i SolarWinds-incidenten.

   Byggservern var ett kritiskt mål i SolarWinds-attacken. Angripare infiltrerade denna server, som ansvarade för att kompilera och paketera programuppdateringar. Genom att kompromettera byggservern fick de kontroll över programuppdateringsprocessen, vilket gjorde det möjligt för dem att injicera skadlig kod före kodsigneringsstadiet. Denna manipulation hjälpte dem att distribuera skadliga uppdateringar till intet ont anande användare.

3. Injicera skadlig kod direkt i källkodsförrådet (svårt eftersom det lämnar permanenta märken)

   Att injicera skadlig kod direkt i ett källkodsarkiv är utmanande eftersom det ofta lämnar spårbara spår. Det är i detta arkiv som utvecklare lagrar och hanterar källkoden för programvaruprojekt. Alla obehöriga ändringar, inklusive insättning av skadlig kod, kan potentiellt identifieras och spåras tillbaka till angriparen. Som ett resultat är denna metod mer riskabel och mer sannolikt att den upptäcks.

4. Att rikta in sig på utvecklarens arbetsstation för kompromettering

   Ett annat tillvägagångssätt är att kompromettera en utvecklares arbetsstation. Utvecklare använder dessa maskiner för att skriva, testa och utveckla kod. Om en angripare får tillgång till en utvecklares arbetsstation kan de manipulera koden innan den sparas i arkivet. Denna taktik kan vara svår att upptäcka om det inte finns robusta säkerhetsåtgärder för slutpunkter.

Strategier för att skydda sig mot sådana attacker

Följande metoder kan följas för att förhindra liknande attacker:

1. Hashvalidering

   Metoden med hashvalidering är ett centralt försvar mot attacker i leveranskedjan, som SolarWinds-intrånget. Den fungerar som en strikt grindvakt i mjukvaruutvecklingsprocessen och säkerställer att koden som ska signeras matchar den som lagras säkert i källkodsförrådet. Denna säkerhetsåtgärd innebär att byggservern genererar en kodhash, som sedan granskas av signeringsservern.

   Signeringsservern verifierar oberoende kodens integritet genom att initiera en deterministisk version i källkodsförrådet och jämföra hashvärden. Först när dessa hashvärden matchar godkänner signeringsservern kodsignering, vilket ger ett robust säkerhetslager som skyddar mot obehöriga kodändringar.

2. Byggverifierare

   En ytterligare förebyggande åtgärd mot sådana attacker innefattar ett rigoröst hashvalideringssystem som är sömlöst integrerat i programvaruutvecklingspipelinen. Processen börjar med att beräkna filhash när kod checkas in i en specifik releasegren, varvid dessa hash säkert lagras i en krypterad fil med hjälp av Krypteringskonsultföretagets CodeSign SecureNär byggservern därefter initierar en build från den angivna grenen hämtar den koden och beräknar hashvärden för alla filer och lagrar dem i en textfil. En Build Verifier-modul jämför sedan dessa hashvärden med de som är säkert krypterade i arkivet.

   Byggprocessen fortsätter utan problem om alla hashvärden matchas. Eventuella skillnader i hashvärden leder dock till att byggverifieraren markerar bygget som misslyckat, vilket omedelbart stoppar processen och utlöser aviseringar via CI/CD-pipelinen. Denna robusta metod säkerställer rigorös verifiering av kodintegritet i flera steg, vilket avsevärt stärker säkerheten i programvaruleveranskedjan.

Hur kan Encryption Consultings Build Verifier förhindra detta?

Encryption Consultings Build Verifier spelar en avgörande roll för att säkerställa byggprocessens integritet. Den skulle omedelbart identifiera denna förändring och kategorisera den specifika builden som ett FEL. Därefter genereras meddelanden och skickas till berörda parter för att initiera omedelbara korrigerande åtgärder. Denna kapacitet understryker effektiviteten hos Encryption Consultings Build Verifier när det gäller att upprätthålla säkerheten och tillförlitligheten i programvaruutvecklingspipelinen.

Medan den konventionella metoden för hashvalidering utan tvekan är en värdefull försvarsmekanism mot attacker i leveranskedjan, tar Encryption Consultings Build Verifier programvarusäkerhet till en mer omfattande nivå. Båda metoderna delar kärnprincipen att säkerställa kodintegritet genom att matcha hashvärden. Den viktigaste skillnaden ligger dock i omfattningen av deras vaksamhet. Den konventionella metoden fokuserar främst på koden och verifierar att den överensstämmer med arkivets version.

Slutsats

Mot bakgrund av SolarWinds-attacken, som avslöjade sårbarheter i mjukvaruleveranskedjan, är det avgörande att utforska proaktiva säkerhetsåtgärder. Angripare utför sådana intrång genom att noggrant kompromettera byggservrar före kodsigneringsprocessen, introducera skadlig kod i mjukvaruuppdateringar och undvika upptäckt genom giltiga signaturer.

Sammanfattningsvis kräver skyddet av mjukvaruleveranskedjan innovativa metoder som Encryption Consultings Build Verifier, vilket säkrar förtroende och tillit i den digitala världen. I takt med att cyberhoten utvecklas är det fortfarande avgörande att ligga steget före, och Build Verifier står som ett bevis på proaktiv säkerhet i ett komplext cybersäkerhetslandskap.