Peter Membrey, chefsarkitekt för ExpressVPN, minns tydligt att han såg nyheten om Log4j-sårbarheten bryta upp online.
“Så fort jag såg hur du kunde utnyttja det, det var skrämmande, säger Membrey. “Som en av de där katastroffilmerna där det finns ett kärnkraftverk, märker de att det kommer att smälta ner, men de kan inte stoppa det. Du vet vad som kommer, men det finns mycket begränsade saker du kan göra.”
Sedan sårbarheten avslöjades förra veckan har cybersäkerhetsvärlden börjat överdriva för att identifiera sårbara applikationer, upptäcka potentiella attacker och mildra utnyttjandet av hur det än är möjligt. Ändå är allvarliga hacks som använder utnyttjandet nästan säkra.
“Så fort jag såg hur du kunde utnyttja det, var det skrämmande”
Hittills har forskare observerat angripare som använder sårbarheten Log4j för att installera ransomware på honeypot-servrar – maskiner som gjorts medvetet sårbara i syfte att spåra nya hot. Ett cybersäkerhetsföretag rapporterade att nästan hälften av företagsnätverk som den övervakade hade sett försök att utnyttja sårbarheten. VD:n för Cloudflare, en leverantör av webbplats- och nätverkssäkerhet, meddelade tidigt att hotet var så illa att företaget skulle rulla ut brandväggsskydd till alla kunder, inklusive de som inte hade betalat för det. Men konkreta nyheter om exploatering i det vilda är fortfarande knappa, troligtvis för att offren antingen inte vet eller ännu inte vill erkänna offentligt att deras system har brutits.
Vad man säkert vet är att omfattningen av sårbarheten är enorm. En lista över påverkad programvara sammanställd av Cybersecurity and Infrastructure Security Agency (CISA) – och begränsad till enbart företagsmjukvaruplattformar – omfattar mer än 500 artiklar långa vid presstillfället. En lista över alla berörda applikationer skulle utan tvekan omfatta många tusen fler.
Vissa namn på listan kommer att vara bekanta för allmänheten (Amazon, IBM, Microsoft), men några av de mest alarmerande problemen har kommit med programvara som stannar bakom kulisserna. Tillverkare som Broadcom, Red Hat och VMware tillverkar programvara som företagskunder bygger företag ovanpå, och fördelar effektivt sårbarheten på en kärninfrastrukturnivå hos många företag. Detta gör processen att fånga upp och eliminera sårbarheter desto svårare, även efter att en patch för det berörda biblioteket har släppts.
Även med standarden för högprofilerade sårbarheter är Log4Shell träffar en ovanligt stor del av internet. Det är en återspegling av det faktum att programmeringsspråket Java används flitigt i företagsprogramvara, och för Java-programvara är Log4j-biblioteket mycket vanligt.
“Jag körde frågor i vår databas för att se varje kund som använde Log4j i någon av sina applikationer”, säger Jeremy Katz, medgrundare av Tidelift, ett företag som hjälper andra organisationer att hantera mjukvaruberoende med öppen källkod. “Och svaret var: varenda en av dem som har några applikationer skrivna i Java.”
Upptäckten av en lätt exploaterbar bugg som hittas på ett mestadels företagsfokuserat språk är en del av vad analytiker har kallat en “nästan perfekt storm” kring Log4j-sårbarheten. Vilket företag som helst kan använda många program som innehåller det sårbara biblioteket — i vissa fall med flera versioner i en applikation.
“Java har funnits i så många år, och det är så tungt används inom företag, särskilt stora, säger Cloudflares CTO John Graham-Cumming. “Detta är ett stort ögonblick för människor som hanterar programvara inom företag, och de kommer att gå igenom uppdateringar och begränsningar så fort de kan.”
“Jag körde frågor i vår databas för att se varje kund som använde Log4j. Svaret var: Varenda en av dem som har applikationer skrivna i Java”
Med tanke på omständigheterna är “så snabbt de kan” en mycket subjektiv term. Programvaruuppdateringar för organisationer som banker, sjukhus eller statliga myndigheter utförs i allmänhet på en skala av veckor och månader, inte dagar; Vanligtvis kräver uppdateringar flera nivåer av utveckling, auktorisering och testning innan de tar sig in i en liveapplikation.
Under tiden ger begränsningar som snabbt kan skjutas ut ett avgörande mellansteg och köper värdefull tid medan stora och små företag kämpar för att identifiera sårbarheter och distribuera uppdateringar. Det är där korrigeringar på nätverkslagret har en nyckelroll att spela: eftersom skadliga program kommunicerar med sina operatörer över internet, kan åtgärder som begränsar inkommande och utgående webbtrafik utgöra ett stopp för att begränsa effekterna av utnyttjandet.
< p id="dtxSmV">Cloudflare var en organisation som rörde sig snabbt, förklarade Graham-Cumming, och lade till nya regler för sin brandvägg som blockerade HTTP-förfrågningar som innehåller strängar som är karakteristiska för Log4j-attackkoden. ExpressVPN modifierade också sin produkt för att skydda mot Log4Shell och uppdaterade VPN-reglerna för att automatiskt blockera all utgående trafik på portar som används av LDAP – ett protokoll som utnyttjaren använder för att hämta resurser från fjärr-URL:er och ladda ner dem till en sårbar maskin.
< p id="oONfBq">“Om en kund blir infekterad har vi redan sett skannrar som en skadlig nyttolast, så de kan börja skanna internet och infektera andra människor”, säger Membrey. “Vi ville sätta ett tak på det, inte bara för våra kunders skull utan för alla andras skull – lite som med Covid och vacciner.”
“Sofistikerade angripare kommer att utnyttja sårbarheten, etablera en uthållighetsmekanism och mörkna sedan”
Dessa förändringar sker vanligtvis snabbare eftersom de sker på servrar som tillhör brandväggen eller VPN-företagen och kräver lite (om någon) åtgärd från slutanvändaren. Med andra ord kan en föråldrad programvara fortfarande få en anständig skyddsnivå från ett uppdaterat VPN – även om det inte ersätter korrekt patchning.
Tyvärr, med tanke på allvaret av sårbarheten kommer vissa system att äventyras, även med snabba lösningar utplacerade. Och det kan ta lång tid – till och med år – innan effekterna märks fullt ut.
“Sofistikerade angripare kommer att utnyttja sårbarheten, etablera en uthållighetsmekanism och sedan gå mörkt”, säger Daniel Clayton, vicepresident för globala cybersäkerhetstjänster på Bitdefender. “Om två år kommer vi att höra om stora intrång och sedan få reda på att de bröts för två år sedan.”
Buggen i Log4j belyser ännu en gång nödvändigheten och utmaningen att finansiera projekt med öppen källkod på ett adekvat sätt. (En stor mängd teknisk infrastruktur kan lika gärna bero på “ett projekt som någon slumpmässig person i Nebraska oförtröttligt har underhållit sedan 2003”, som en ständigt relevant XKCD-serie förklarar.) Bloomberg rapporterade tidigare i veckan att många av utvecklarna som är involverade i kapplöpningen för att utveckla en patch för Log4j-biblioteket var obetalda volontärer, trots den globala användningen av programvaran i företagsapplikationer.
En av de sista sårbarheterna på internet, Heartbleed, var på liknande sätt orsakad av en bugg i ett allmänt använt bibliotek med öppen källkod, OpenSSL. Efter det felet åtog sig teknikföretag som Google, Microsoft och Facebook att lägga mer pengar på projekt med öppen källkod som var kritiska för internetinfrastruktur. Men i kölvattnet av Log4j-nedfallet är det tydligt att hantering av beroenden fortfarande är ett allvarligt säkerhetsproblem – och ett vi inte är nära att lösa.
“När du tittar på de flesta av stora hacks som har hänt under åren, det är normalt inte något riktigt sofistikerat som gör att stora företag ångrar”, säger Clayton. “Det är något som inte har åtgärdats.”