Säkerhet 2023.03.29

Hur säker är din kod?

Skriven av Richard Haaga

För varje utvecklingsprojekt så är det i princip oundvikligt att använda och förlita sig på andras kod. Därmed undviker du också att behöva uppfinna hjulet för varje projekt. Men hur mycket kännedom har du om den kod som finns i ditt projekt? Av vem är den skriven, hur fungerar den i detalj och hur pass aktuell är den?

Tredjepartsbibliotek är i dag en naturlig del av utvecklarnas kod. Det är väldigt få projekt som har klarat sig undan dessa bibliotek och hur man än väljer att se på dem så är de oundvikligen en källa till att få funktionalitet i sitt projekt. Men baksidan med dessa bibliotek är att de, utöver funktionalitet, även kan tillföra säkerhetsbrister. Många minns julen 2021 när en sårbarhet upptäcktes i loggningsramverket Log4j^[1^] som medförde att en angripare kunde exekvera godtycklig kod. Enkelheten i att utnyttja sårbarheten samt hur pass välanvänt Log4j är orsakade att IT-avdelningar runtom i världen fick spendera många kvällar med att uppdatera sina system. Tyvärr så hittas fortfarande system som än idag inte har uppdaterats för att hantera Log4j-sårbarheten.

Log4j-sårbarheten belyste ett problemområde som många organisationer inte har sett eller valt att blunda för, nämligen säkerheten i tredjepartsbibliotek. En empirisk studie^[2] som gjordes på Fudan University, Kina, har använt kvantitativa analyser för att kartlägga säkerheten i tredjepartsbibliotek hos 806 open source-projekt, alla skrivna i Java. I studien framgår det att 55% av de analyserade projekten aldrig uppdaterar mer än hälften av sina importerade bibliotek och 51% har en fördröjning på uppdateringarna på över 60 dagar. 69% av de importerade biblioteken har säkerhetsbrister.

Åtgärdas alla brister?

Det händer även att rapporterade säkerhetsbrister aldrig åtgärdas. Under 2022 så upptäckte Kasimir Schulz från cybersecurityföretaget Trellix en säkerhetsbrist i tarfile-modulen i Python^[3] som används för att läsa och skriva arkivfiler. Efter lite utredning så visade det sig att bristen inte var ny utan hade varit känd sedan 2007. Utvecklaren Lars Gustäbel som då ansvarade för denna sårbarhet insåg att bristen inte var lätt att åtgärda utan att få konsekvenser, samt att bristen inte gick att utnyttja i praktiken och bestämde att de skulle låta den vara. Lars föreslog en åtgärd 2014 men fick ingen respons från några andra utvecklare och diskussionen återuppstod inte igen förrän 2018, men på grund av tidsbrist så valde Lars till slut att avsluta sina åtaganden i Python-projektet. Sårbarheten föll i glömska och under 2022 ”återupptäcktes” den då Trellix visade att sårbarheten gick mycket väl att utnyttja i praktiken och hittade två verkliga exempel på fall där den kunde skriva arbitära filer till filsystemet. En analys av implementerande projekt på GitHub visade att 61% av dessa projekt var sårbara.

Vem kan du lita på?

Användningen av tredjepartsbibliotek belyser även ett annat problem: Hur är man säker på att det är rätt bibliotek? Användningen öppnar även porten till supply chain-attacker där ett importerat bibliotek kan ha modifierats, oftast utan utvecklarens vetskap. Supply chain-attacker är när en del av en leveranskedja attackeras för att förändra en slutprodukt, något som förekommer i flera sektorer så som finansiella, industriella och hård- eller mjukvaruleveranser. När filnamnet på biblioteket stämmer och funktionaliteten är intakt så finns det sällan skäl till misstanke och det är få, om ens några, organisationer som kontrollerar filhashen, ett unikt värde som motsvarar innehållet i filen, på sina bibliotek. Det finns även exempel på när utvecklare av betrodda bibliotek har löpt amok^[4] och skapat uppdateringar innehållande skadlig kod i bibliotek som miljontals projekt förlitar sig på. Marak, utvecklaren bakom det populära JavaScript-biblioteket colors, skapade medvetet en oändlig slinga i sin kod för att förstöra projektet. Projektet colors var så populärt att det nådde 20 miljoner nedladdningar per vecka vilket medförde en massiv påverkan. Marak förklarade sin handling att han helt enkelt var trött på att ingen betalade för sig och när företaget Retool implementerade ett av sina projekt så rann bägaren över.

Hur ska du göra?

Det finns inget sätt att göra 100% rätt. Att hålla dina bibliotek uppdaterade är det första steget du bör ta och detta ganska omedelbart. Det är också viktigt att du vet vad det är du importerar. Biblioteken bör komma från en betrodd källa, vara verifierade med filhash och du bör även hålla dig till de större, mer betrodda utvecklarna som exempelvis Apache Software Foundation. Det finns många populära projekt som tyvärr är väldigt personberoende så för att vara försiktig bör du då även utreda hur många utvecklare som är delaktiga i projektet. Ska du försöka undvika tredjepartsbibliotek så gott det går? Detta kan låta attraktivt, men sanningen är att det nog är en utopisk tanke, och ett ganska ineffektivt sätt att arbeta.. Och det sista en utvecklare bör göra är att lägga sin tid på att ständigt återuppfinna hjulet.

Advania Security labs kan hjälpa din verksamhet med kodgranskning. Det kan till exempel ske i samband med ett penetrationstest där vi granskar källkoden samtidigt som vi utför säkerhetstester. Vi tittar då på kodkvalitet, tredjepartsberoenden och säkerhetsbrister, gör en analys och dokumenterar resultatet i en rapport som vi tillsammans går igenom.