När de kritiska sårbarheterna i PHP blev kända den 20 oktober fick det ett närmast explosionsartat genomslag i nyhetsmedierna. De allvarliga händelserna i Ukraina, Ryssland, USA, Israel och Gaza, för att nämna några oroshärdar, fick åtminstone i delar av rapporteringen stå tillbaka. Det är sannerligen något att reflektera över.
Den 21 oktober publicerade vi en artikel om eMudhras ”betrodda” PKI, där det visade sig att minst de första 376 av 384 bitarna i de privata nycklarna till åtta utfärdande CA var nollor. Det kan inte vara en slump att det var så dålig slump!
Med den vetskapen var det inte speciellt svårt att återskapa nycklarna och därmed skapa förfalskade server- och kodsigneringscertifikat som kunde accepteras av system som fortfarande litade på dessa CA. Detta var inte en traditionell teknisk sårbarhet, utan snarare ett exempel på hur brister i rutiner, kontroller och nyckelhantering kan bli förödande. Detta fick förhållandevis liten uppmärksamhet, trots att de långsiktiga konsekvenserna mycket väl kan bli värre än PHP-sårbarheternas.
Jag vill påstå att Oracles uppdatering av Java kort därefter fick betydligt större uppmärksamhet, möjligen också förstärkt av uppståndelsen kring PHP. Men uppdateringen hade ingenting med PHP att göra. Det handlade i själva verket om att ta bort berörda rotcertifikat från Javas lista över betrodda certifikatutfärdare, eftersom underordnade CA privata nycklar hade komprometterats. Oracle publicerade till och med en särskild säkerhetsvarning, CVE-2026-114820.
Litar ni fortfarande på eMudhra?
Ytterligare ett par dagar framåt på tidslinjen möttes vi av en allvarlig sårbarhet i Googles dekomprimeringsbibliotek Brotli. Brotli används bland annat av Node.js, .NET, webbläsare, webbservrar och olika API-tjänster. Sårbarheten kan, när angriparkontrollerad data dekomprimeras, leda till minneskorruption och potentiellt exekvering av skadlig kod. Den har, enligt CVSS 4.0, fått samma allvarlighetsvärde som PHP-sårbarheterna (9,2) men har ännu inte nått samma mediala fokus.
Allt detta under en enda kalendervecka!
Fler drar sig säkert till minnes sårbarheten i Log4j från december 2021, som fick namnet Log4Shell. Redan nu förekommer namn som PHP2Shell och node2shell. Det ligger nära till hands att fundera över hur många fler varianter på temat ”Shell” vi kommer att få se, men det är knappast namngivningen som borde oroa oss. I början av 2022, för övrigt månaden innan Rysslands fullskaliga invasion av Ukraina, skrev jag en krönika med rubriken Oroad. Den kanske snarare borde ha hetat ”Ingen annan” eller ”Någon annan”, eftersom den handlade om vem som egentligen tar ansvar i ett förändrat hotlandskap. Det var alltså innan allt detta händer.
Jag har funderat både ett och två varv på vad som egentligen har förändrats under dessa snart fem år. Jag vill påstå alldeles för lite.
I ljuset av detta vill jag ändå lyfta fram att de tillverkare vi samarbetar med snabbt och proaktivt informerade om att deras produkter inte var sårbara för de i dagarna aktuella bristerna. Det är ett gott exempel på ansvarstagande och helt i linje med förvätningarna som följer av Cyber Resilience Act (CRA). Det ska inte krävas att varje kund själv jagar sina leverantörer för att få besked om en produkt påverkats av kritiska sårbarheter i delkomponenter.
Jag vill också lyfta fram att lagstiftaren har skärpt kraven och tydligare börjat utkräva ansvar som med exemplet CRA. Det är också klädsamt att EU:s olika regleringar inom informations- och cybersäkerhetsområdet gemensamt lyfter fram behovet av att få det systematiska och riskbaserade informations- och cybersäkerhetsarbetet på plats. Om ett EU-direktiv inte ger önskvärd effekt väntar en EU-förordning med direkt tillämpliga krav. Sverige hade nog mått bra av att NIS2 hade varit en EU-förordning i stället för ett EU-direktiv, med tanke på det vingliga svenska införandet av NIS2-direktivet i form av cybersäkerhetslagen (CSL). Det hade åtminstone minskat utrymmet för nationella förseningar och särlösningar.
Det finns verkligen inget utrymme för att vingla i dagens hotlandskap!
På bara några kalenderdagar har vi mötts av flera kritiska sårbarheter och närmast ofattbara misstag. Den exponentiella resan har kanske bara påbörjats. Inte nödvändigtvis för att antalet sårbarheter ökar exponentiellt, utan för att beroendena mellan produkter, tjänster, leverantörer och ett led av leverantörens underleverantörer gör att konsekvenserna kan spridas i en allt högre takt. Förmågan att upptäcka, hantera, agera på och rapportera säkerhetsincidenter borde sedan länge vara en väl inövad del av det systematiska säkerhetsarbetet. Att det dessutom finns brister i den statliga samordningen riskerar att flytta fokus från det som verkligen är viktigt. Förblindas inte av det.
Prioritering och fokusering är nu helt avgörande. Det är ytterst förmågan till riskhantering som avgör om vi lyckas.
Författare: Thomas Nilsson