Security

Log4j

Stephan Andersson

Uppdatering om det allvarliga läget gällande sårbarheten i Log4j (“Log4Shell”)

Uppdaterad 2021-12-20

Kort sammanfattning

Den 9 december 2021 blev en kritisk sårbarhet i det Java-baserade verktyget Apache Log4j (“Log4Shell”) känd publikt. Det är många organisationer som är sårbara då ett flertal vanligt förekommande system och produkter använder Log4j.

Angreppsförsök pågår mot intressenter globalt och här i Sverige. Det finns också indikationer på att det görs försök att göra sårbarheten till en automatiserad mask, ett extremt allvarligt scenario som kan innebära att den sprids okontrollerat på internet

Vad har hänt

Sårbarheten är listad som CVE-2021-44228 med namnet ”Log4Shell”. Sårbarheten klassas som 10.0 på den 10-gradiga CVSS skalan och anses därmed vara en kritisk sårbarhet som bör åtgärdas så fort som möjligt. Sättet som sårbarheten påverkar systemen gör att aktören har en myriad av möjligheter att påverka eller skada systemet och kringliggande IT-mijö.

Java-paketet används i miljontals applikationer så som bland annat; UniFi, VMware, Atlassian Confluence, och Elastic Search. Er organisations attackyta kan därmed vara spridd över en mycket stor mängd system.

Sårbarheten beskrivs nu som en av de allvarligaste sårbarheterna i modern historia. Ett antal källor börjar även frukta för en mask som nyttjar Log4Shell för att sprida sig själv för att till slut utföra fullskaliga ransomware attacker likt WannaCry 2017.

Mycket tyder på att sårbarhet har utnyttjats innan den blev publicerad publikt, just nu som tidigast 2021-12-01. Det är därför viktigt att söka efter intrångsförsök även innan den 2021-12-09.

Vad du ska göra för att skydda er

Arbetet med att identifiera, prioritera, motverka och detektera är mödosamt och komplext. En rationell lösning bygger på nära samverkan mellan team samt aktivt utnyttjande av verktyg och metoder som löpande tas fram

 

Identifiera

För att underlätta identifiering finns ett antal olika hjälpmedel, till exempel;

 

Viktigt! System som inte är exponerade mot internet måste uppdateras för att minimera attackytan. Det räcker att en server med Log4j loggar en skadlig sträng för att bli komprometterad, och vissa system kan ibland ta emot loggar från andra system längre ut i miljön som kan vara exponerade.

 

Prioritera

Förslag på prioriteringsordning för potentiellt sårbara system;

 

  1. Publikt tillgängliga system
  2. System med personuppgifter eller annan känslig information
  3. Affärskritiska system
  4. Övriga

 

Motverka

För att motverka sårbarheten i egenutvecklade applikationer finns det olika tillvägagångssätt, vi förklarar kortfattat de olika alternativen nedan.

Notera att den absolut mest effektiva mitigeringen är att uppdatera Log4j2 till version 2.16.0 eller senare.

  • Uppdatera Log4j2 till version 2.16.0 eller senare.
  • Sätt log4j2.formatMsgNoLookups till ’true’ i versioner 2.10.0 till 2.14.1 för att inaktivera den sårbara funktionen, alternativt sätt environment variabeln LOG4J_FORMAT_MSG_NO_LOOKUPS=”true”.
  • Kubernetes administratörer kan använda kommandot ”kubectl set env” för att sätta ovan environment variabel över Kuberneteskluster med Java applikationer som nyttjar versioner 2.10.0 till 2.14.1 av Log4j2.
  • För versioner 2.0-beta9 till 2.10.0 är mitigeringen att ta bort JndiLookup-klassen från klassökvägen: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

 

För att motverka sårbarheten i tredjepartsapplikationer rekommenderar vi att ni följer applikationtillverkarens utlåtanden och rekommendationer. Det finns ett antal olika sammanställningar med utlåtanden från applikationstillverkare angående om de är sårbara eller inte, till exempel: log4shell/README.md at main · NCSC-NL/log4shell (github.com)

 

Detektera

Grunden i skydden mot attacker är möjligheten att detektera dem. I det här fallet är loggar från brandväggar, IDP/IDS, WAF, DNS, och webbservrar de grundläggande källorna en organisation kan nyttja för att detektera intrångsförsök.

Microsoft har gått ut med ett antal detektionsregler för Microsoft Sentinel (Guidance for preventing, detecting, and hunting for CVE-2021-44228 Log4j 2 exploitation – Microsoft Security Blog), och Asurgent har tidigt i veckan aktiverat applicerbara detektionsregler för alla CloudOps Security-kunder.

Vi rekommenderar starkt att ni skickar relevanta loggar till ett SIEM-system såsom Microsoft Sentinel för att snabbt kunna upptäcka och agera på den här typen av intrångsförsök.

Rekommendationer för vägen framåt

Asurgents förslag på konkreta nästa steg är:

  1. Aktivera IT-krisorganisation eller motsvarande om detta redan inte är gjort
  2. Genomför nödvändig inventering internt och i samverkan med era externa parter
  3. Löpande genomföra motverkande åtgärder där sårbarheten har identifierats
  4. Förstärk er förmåga att detektera misstänkta aktiviteter
  5. Planera för det värsta, dvs gör nu klart planer, checklistor samt gör klart proaktiva åtgärder så som förstärkning av backuper. Allt för att minska påverkan om aktörer har hittat en väg in och utnyttjar möjligheten

 

Vänta inte!

Vårt team är i full beredskap och verkar fortsatt nära våra kunder och de av er som begär stöd för att komma vidare med att skydda verksamheten mot ett konkret och mycket allvarligt hot.

 

Uppdatering 2021-12-20

Vi har i ett förhöjt beredskap läge fortsatt att följa utvecklingen under helgen och inledningen av veckan. Vi ser som många andra, en fortsatt relativt hög frekvens av scanningar, men som väl görs emot redan allt fler patchade system och applikationer. För de flesta bör därmed akut-fasen att vara över och man kan övergå till efterarbete och inte minst erfarenhets återvinning.

Viktigt: Tidigare versionen 2.16 har visat sig ha en sårbarhet (CVE-2021-45105). Ny version 2.17 är släppt och rekommenderas likt tidigare att appliceras på berörda system och applikationer omgående.

Upptäck mer