BM21-004: Kritisk sårbarhet i vanligt förekommande Apache-biblioteket Log4j

Apache har publicerat en säkerhetsuppdatering som hanterar den andra sårbarheten i Log4j (CVE-2021-45046). Log4j 2.16.0 hanterar sårbarheten genom att vissa funktioner är inaktiverade som standard [1, 2].

Nu finns även rapporter om det första fallet av att sårbarheten används för exekvering av ransomware [3].

Det finns indikationer på att svenska intressenter har utsatts för angreppsförsök.

Bakdörrsramverken Mirai och Cobalt Strike används för flertal angreppsmodus, bl.a. bitcoin mining, laterala rörelser i nätverket, identitets- och datastöld [4, 5].Apache har publicerat en säkerhetsuppdatering som hanterar den kritiska sårbarheten i det Java-baserade verktyget Apache Log4j (CVE-2021-44228, CVE-2021-450 [1].

Sårbarheten kan utnyttjas av en fjärrangripare för att exekvera godtycklig kod (remote code execution).Sårbarheten CVE-2021-44228 och har tilldelats CVSS v3 10.0. Det finns en öppet tillgänglig exploateringkod (proof-of-concept) för sårbarheten.

Log4j är ett vanligt förekommande loggningsbibliotek baserat på Java, utvecklat av Apache Foundation. Denna används i väldigt många applikationer och tjänster. Detta innefattar många enterprise-applikationer, internt utvecklade produkter och många molntjänster, se länkar nedan till listor som sammanställer några sårbara produkter [6, 7, 8, 9, 10]. Log4j 2-biblioteket används som standard i flera Apache-ramverk [11]:* Apache Struts2* Apache Solr* Apache Druid* Apache Flink* Apache Swift

Påverkade produkter

Alla supporterade versioner av Apache log4j mellan 2.0 och 2.14.1 är sårbara. Har ni en äldre version än 2.0 kan även den under vissa omständigheter också vara sårbar, och behöver uppgraderas till senaste versionen [12].

Uppdatering 2021-12-17

Säkerhetsuppdateringen 2.15 som tidigare publicerats innehåller en sårbarhet som uppgraderats till CVSS-klassning 9,0 (CVE-2021-45046). Se till att uppdatera till version 2.16 omgående [14].

Uppdatering 2021-12-20

En ny patch (2.17) finns tillgänglig så se till att denna installeras skyndsamt [14]. Det rapporteras att ransomwaregruppen Conti utnyttjar Log4Shell-sårbarheten [15]. Läs gärna de playbooks som publicerats för mer bakgrund om Log4Shell [16, 17].

Uppdatering 2021-12-29

En RCE-sårbarhet (CVE-2021-44832) har upptäckts i Apache Log4j2 (versionerna 2.0-beta7 till 2.17.0) [18]. Om den utnyttjas kan en angripare med behörighet att ändra loggningskonfigurationsfilen skapa en skadlig konfiguration för att exekvera fjärrkod. Se till att uppdatera Apache Log4j2 till version 2.17.1, 2.12.4 och 2.3.2 eller senare [14].

Uppdatering 2022-01-31

Apache har rapporterat att även Log4j 1.x är sårbar. Sårbarheten CVE-2022-23307 har fått CVSS-klassningen 10. Eftersom version 1.x slutade underhållas 2015 kommer ingen säkerhetsuppdatering släppas. Uppdatera till Apache Log4j2 version 2.17.1 eller senare. [19, 20, 21]

Rekommendationer

- Installera de senaste säkerhetsuppdateringarna omedelbart där Log4j används.- Så hittar du okända instanser av Log4j inom er organisation- Sök i filsystem efter Log4j. Denna sökning skall även inkludera filer i EAR, JAR och WAR-filer. Ett exempel på en sådan sökning "find / -type f -print0 |xargs -n1 -0 zipgrep -i log4j2 2>/dev/null" - Om en pakethanterare används ett exempel på sökning kan vara: "dpkg -l | grep log4j". - Märk att flera instanser av Log4j kan finnas på systemet. - Genomför förebyggarna nätverksmonitorering/blockering- Organisationer som använder en "web Application Firewall" ska se till att regler finns på plats för att skydda mot sårbarheten. Dock finns varianter av exploit-koden som försöker obfuskera sig för att undvika upptäckt, därför ska inte en WAF vara det enda skyddet. - Leta i loggfilerna för Log4j som kan innehålla indata-strängar som t.ex. "jndi:ldap". - Yara-regler för ett antal scenarios finns tillgängliga där organisationer som har möjlighet att hantera dessa [13].

Källor

[1] https://logging.apache.org/log4j/2.x/security.html

[2] https://www.zdnet.com/article/second-log4j-vulnerability-found-apache-log4j-2-16-0-released/

[3] https://www.bleepingcomputer.com/news/security/new-ransomware-now-being-deployed-in-log4shell-attacks/

[4] https://blog.talosintelligence.com/2021/12/apache-log4j-rce-vulnerability.html

[5] https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/

[6] https://www.vmware.com/security/advisories/VMSA-2021-0028.html

[7] https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-qRuKNEbd

[8] https://www.circl.lu/pub/tr-65/

[9] https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core/usages

[10] https://github.com/NCSC-NL/log4shell/tree/main/software

[11] https://www.ncsc.gov.uk/news/apache-log4j-vulnerability

[12] https://access.redhat.com/security/cve/cve-2021-44228

[13] https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b

[14] https://logging.apache.org/log4j/2.x/security.html

[15] https://www.bleepingcomputer.com/news/security/conti-ransomware-uses-log4j-bug-to-hack-vmware-vcenter-servers/

[16] https://www.cisecurity.org/log4j-zero-day-vulnerability-response/

[17] https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance

[18] https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44832

[19] https://media.cert.europa.eu/static/SecurityAdvisories/2021/CERT-EU-SA2021-067.pdf

[20] https://logging.apache.org/log4j/1.2/

[21] https://www.cvedetails.com/cve/CVE-2022-23307/