BSI: Kri­ti­sche Schwach­stel­le in log4j ver­öf­fent­licht (CVE-2021 – 44228)

Sach­ver­halt

Log4j ist eine belieb­te Pro­to­kol­lie­rungs­bi­blio­thek für Java-Anwen­dun­gen. Sie dient der per­for­man­ten Aggre­ga­ti­on von Pro­to­koll­da­ten einer Anwendung.

Das Blog eines Dienst­lei­sters für IT-Sicher­heit [LUN2021] berich­tet über die Schwach­stel­le CVE-2021 – 44228 [MIT2021] in log4j in den Ver­sio­nen 2.0 bis 2.14.1, die es Angrei­fern gege­be­nen­falls ermög­licht, auf dem Ziel­sy­stem eige­nen Pro­gramm­code aus­zu­füh­ren und so den Ser­ver zu kom­pro­mit­tie­ren. Die­se Gefahr besteht dann, wenn log4j ver­wen­det wird, um eine vom Angrei­fer kon­trol­lier­te Zei­chen­ket­te wie bei­spiels­wei­se den HTTP User Agent zu protokollieren.

Ein Pro­of-of-Con­cept (PoC) der Schwach­stel­le wur­de auf Git­hub ver­öf­fent­licht [GIT2021a] und auf Twit­ter geteilt [TWI2021]. Neben dem PoC exi­stie­ren auch Bei­spie­le für Skrip­te, die Syste­me stich­pro­ben­ar­tig auf Ver­wund­bar­keit hin unter­su­chen [GIT2021b]. Skrip­te sol­cher Art kön­nen zwar Admi­ni­stra­to­ren kei­ne Sicher­heit über die Ver­wund­bar­keit geben, aber erlau­ben Angrei­fern kurz­fri­stig rudi­men­tä­re Scans nach ver­wund­ba­ren Systemen.

Die­se kri­ti­sche Schwach­stel­le hat dem­nach mög­li­cher­wei­se Aus­wir­kun­gen auf alle aus dem Inter­net erreich­ba­ren Java-Anwen­dun­gen, die mit Hil­fe von log4j Tei­le der Nut­zer­an­fra­gen protokollieren.

Update 1:
Der Schwach­stel­le wur­de nach Ver­öf­fent­li­chung des Blog-Posts ein CVSS-Wert von 10.0 zuge­wie­sen.
Erste öffent­li­che Quel­len wei­sen auf breit­flä­chi­ges Scan­nen nach ver­wund­ba­ren Syste­men hin. Das BSI kann der­ar­ti­ge
Scan-Akti­vi­tä­ten bestätigen.

Update 2:
Im Gegen­satz zur ursprüng­li­chen Ein­schät­zung kann die kri­ti­sche Schwach­stel­le ggf. auch auf inter­nen Syste­men
aus­ge­nutzt wer­den, sofern die­se exter­ne Daten ent­ge­gen­neh­men oder ver­ar­bei­ten.
Eini­ge Pro­duk­t­her­stel­ler haben bereits öffent­lich bzgl. einer mög­li­chen (Nicht-)Betroffenheit ihrer Pro­duk­te
hin­ge­wie­sen und teil­wei­se bereits Updates ver­öf­fent­licht ([APA2021c], [BRO2021], [CIS2021], [FSE2021], [MCA2021],
[SOP2021], [TRE2021], [VMW2021a], [VMW2021b], [UNI2021]). Zu den betrof­fe­nen Her­stel­lern gehö­ren z. B.:
• VMWare
• Apa­che
• Uni­Fi
Die­se Liste ist nicht abschlie­ßend und erhebt kei­nen Anspruch auf Voll­stän­dig­keit. Zahl­rei­che wei­te­re Her­stel­ler prü­fen
aktu­ell noch eine Betroffenheit.

Update 3:
Auf Git­hub wur­de unter [GIT2021e] eine Liste mit Sicher­heits­war­nun­gen für Pro­duk­te von über 140 Her­stel­lern
ver­öf­fent­licht. Eini­ge der Links ver­wei­sen direkt auf Her­stel­ler­sei­ten, die neben Infor­ma­tio­nen zur Betrof­fen­heit auch
Updates für Ihre Pro­duk­te bereit­stel­len. Die Inhal­te wur­den durch das BSI stich­pro­ben­ar­tig veri­fi­ziert und sol­len als
erste Ori­en­tie­rungs­hil­fe die­nen.
Das NCSC NL (Natio­naal Cyber Secu­ri­ty Cen­trum Nether­lands) plant im Lau­fe des Nach­mit­ta­ges die Ver­öf­fent­li­chung
eines Git­hub-Repo­si­to­ries unter [NCSC2021] mit gesi­cher­ten Infor­ma­tio­nen zu betrof­fe­nen Her­stel­lern. Zum
Redak­ti­ons­schluss war das Repo­si­to­ry noch nicht veröffentlicht.

Bewer­tung

Log4j wird in vie­len Java-Anwen­dun­gen ein­ge­setzt. Der Schutz gegen eine akti­ve, brei­te Aus­nut­zung ist durch die
Ver­füg­bar­keit eines PoC sehr gering. Das Patch­ma­nage­ment von Java-Anwen­dun­gen ist nicht tri­vi­al, sodass bis zu einer
Update-Mög­lich­keit die kurz­fri­sti­gen Miti­ga­tio­nen emp­foh­len wer­den.
Wenn­gleich das Nach­la­den von Schad­code über den im PoC auf­ge­zeig­ten Weg bei Grund­schutz-kon­form
ein­ge­rich­te­ten Syste­men fehl­schla­gen soll­te, sind auch ande­re Wege denk­bar, ggf. auch auto­ma­ti­siert und ohne
Nach­la­den Schad­code zur Aus­füh­rung zu brin­gen. Hier­bei ist die Kom­ple­xi­tät im Ver­gleich zum PoC deut­lich erhöht.
Update 1:
Auf­grund der wei­ten Ver­brei­tung der Biblio­thek ist es nur schwer abseh­bar, wel­che Pro­duk­te alle betrof­fen sind.
Das BSI sieht aktu­ell eine Erhö­hung der IT-Bedro­hungs­la­ge für Geschäfts­pro­zes­se und Anwen­dun­gen. Durch das aktu­ell
breit­flä­chi­ge Scan­nen ist eine mög­li­che anschlie­ßen­de Infek­ti­on von anfäl­li­gen Syste­men und Anwen­dun­gen, auch auf
Grund aktu­ell oft­mals noch feh­len­den Patches, nicht aus­zu­schlie­ßen.
Update 2:
Das Aus­maß der Bedro­hungs­la­ge ist aktu­ell nicht abschlie­ßend fest­stell­bar. Die Reak­ti­ons- und Detek­ti­ons­fä­hig­keit des
IT-Betrie­bes ist kurz­fri­stig geeig­net zu erhö­hen, um ange­mes­sen die Syste­me über­wa­chen zu kön­nen bzw. zu reagie­ren.
Aus meh­re­ren CERT-Quel­len erreich­ten das BSI Benach­rich­ti­gun­gen über welt­wei­te Mas­sen­scans und ver­such­te
Kom­pro­mit­tie­run­gen. Es gibt bereits erste Mel­dun­gen über erfolg­rei­che Kom­pro­mit­tie­run­gen (bis­lang u.a. mit
Kryp­to­mi­ner).
Es sind zudem Aus­nut­zun­gen der Schwach­stel­le zu beob­ach­ten, die kein expli­zi­tes Nach­la­den eines Schad­codes
benö­ti­gen und einen mali­ziö­sen Code direkt in der Abfra­ge ent­hal­ten. Dies gefähr­det auch Grund­schutz-kon­for­me
Syste­me, die i.d.R. kei­ne Ver­bin­dung ins Inter­net auf­bau­en können.

ktu­ell ist noch nicht bekannt in wel­chen Pro­duk­ten die­se Biblio­thek ein­ge­setzt wird, was dazu führt, dass zum jet­zi­gen
Zeit­punkt noch nicht abge­schätzt wer­den kann, wel­che Pro­duk­te von der Schwach­stel­le betrof­fen sind.
Auch inter­ne Syste­me, die Infor­ma­tio­nen oder Daten von ande­ren Syste­men ver­ar­bei­ten, kön­nen ggf. kom­pro­mit­tiert
wer­den und sind daher umge­hen zu patchen.
Auf­grund der neu­en Sach­ver­hal­te hat das BSI ent­schie­den die Warn­mel­dung von der Warn­stu­fe Oran­ge auf Rot
hoch­zu­stu­fen.
Update 3:
Neben erfolg­rei­chen Kom­pro­mit­tie­run­gen mit Kryp­to­mi­nern gibt es unter [3602021] erste Hin­wei­se dar­auf, dass die
Schwach­stel­le auch von Bot­net­zen aus­ge­nutzt wird. Die Wahr­schein­lich­keit ist groß, dass die mit die­ser Schwach­stel­le
in Ver­bin­dung ste­hen­den Angrei­fer­ak­ti­vi­tä­ten in den näch­sten Tagen deut­lich zuneh­men werden.

Maß­nah­men

Ser­ver soll­ten gene­rell nur sol­che Ver­bin­dun­gen (ins­be­son­de­re in das Inter­net) auf­bau­en dür­fen, die für den
Ein­satz­zweck zwin­gend not­wen­dig sind. Ande­re Zugrif­fe soll­ten durch ent­spre­chen­de Kon­troll­in­stan­zen wie Paket­fil­ter
und App­li­ca­ti­on Lay­er Gate­ways unter­bun­den wer­den. [BSI2021b]
Es soll­te ent­spre­chend dem Grund­schutz­bau­stein [BSI2021a] ein Update auf die aktu­el­le Ver­si­on 2.15.0 [APA2021] (git-
tag: 2.15.0‑rc2 [GIT2021c]) von log4j in allen Anwen­dun­gen sicher­ge­stellt wer­den. Da Updates von Abhän­gig­kei­ten in
Java-Anwen­dun­gen häu­fig nicht zeit­nah erfol­gen kön­nen, soll­te bis dahin die fol­gen­de Miti­ga­ti­ons­maß­nah­me ergrif­fen
wer­den:
Die Opti­on “log4j2.formatMsgNoLookups” soll­te auf “true” gesetzt wer­den, indem die Java Vir­tu­al Machi­ne mit dem
Argu­ment

 – Dlog4j2.formatMsgNoLookups=True”
gestar­tet wird.
Update 2:
Alter­na­tiv kann auch die Umge­bungs­va­ria­ble LOG4J_​FORMAT_​MSG_​NO_​LOOKUPS auf true gesetzt wer­den. Die­se
bei­den Miti­ga­ti­ons­maß­nah­men funk­tio­nie­ren erst ab Log4J Ver­si­on 2.10.
Ach­tung: Die­se Maß­nah­me kann die Funk­ti­ons­wei­se der Appli­ka­ti­on beein­träch­ti­gen, wenn die Look­up-Funk­ti­on
tat­säch­lich ver­wen­det wird.
Update 2:
Die Log4J Ver­sio­nen 1.x sind von der aktu­el­len Schwach­stel­le nach aktu­el­ler Kennt­nis nicht betrof­fen [GIT2021d]. Die
Ver­si­on 1.x wird, auch wenn sie noch in diver­sen Pro­duk­ten ein­ge­setzt wird, nicht mehr vom Her­stel­ler unter­stützt. Sie
ist End-of-Life und durch ande­re Schwach­stel­len ver­wund­bar. Daher soll­ten auch noch ein­ge­setz­te Log4J Ver­sio­nen 1.x
eben­falls auf eine nicht-ver­wund­ba­re Ver­si­on 2.x aktua­li­siert wer­den.
Sofern das Log4j als eige­ne jar-Datei vor­liegt, kann die­se ggf. aus­ge­tauscht wer­den. Hier ist vor­ab die
Her­stel­ler­do­ku­men­ta­ti­on zu prü­fen, ob und unter wel­chen Umstän­den die­ses Ver­fah­ren das System absi­chert.
Als Alter­na­ti­ve, die auch in Ver­sio­nen ab 2.0‑beta9 und höher funk­tio­niert, emp­fiehlt der Her­stel­ler die Klas­se
Jndi­Look­up aus dem Klas­sen­pfad zu löschen [APA2021b]:
zip ‑q ‑d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Sofern die Her­stel­ler Updates zur Ver­fü­gung stel­len, soll­ten die­se umge­hend instal­liert wer­den.
In den jewei­lig zu ver­ant­wor­ten­den Berei­chen soll­te qua­li­fi­zier­tes IT-Per­so­nal ein­ge­setzt wer­den, um die kri­ti­schen, vor
allem von außen zu errei­chen­de Syste­me eng­ma­schig zu über­wa­chen.
Um poten­ti­ell betrof­fe­ne Syste­me leich­ter zu iden­ti­fi­zie­ren, kann zunächst über­prüft wer­den, wel­che Syste­me Java als
Instal­la­ti­ons­vor­aus­set­zung haben oder Java instal­lie­ren. Zu sol­chen Syste­men soll­ten die Mel­dun­gen des jewei­li­gen
Her­stel­lers prio­ri­tär geprüft wer­den. Sofern sei­tens des Her­stel­lers noch kein Secu­ri­ty Advi­so­ry ver­öf­fent­licht wur­de,
soll­te eine ent­spre­chen­de Anfra­ge gestellt werden.

Da eine Aus­nut­zung nicht zwin­gend ein Nach­la­den von Schad­code aus dem Inter­net benö­tigt, son­dern bereits mit
einer ein­zi­gen Anfra­ge mög­lich ist, muss für alle ver­wund­ba­ren Syste­me die Angriffs­flä­che redu­ziert wer­den. Kon­kre­te
Schrit­te hier­zu sind:
• Nicht zwin­gend benö­tig­te Syste­me abschal­ten.
• Netz­wer­ke seg­men­tie­ren, sodass ver­wund­ba­re Syste­me von nicht extern-ver­bun­de­nen/in­ter­nen Syste­men
iso­liert wer­den
Syste­me, die auf­grund der Kri­ti­ka­li­tät für unab­ding­ba­re Geschäfts­pro­zes­se nicht abge­schal­tet wer­den kön­nen:
• In Web-App­li­ca­ti­on-Fire­walls (WAF), Intru­si­on Pre­ven­ti­on Syste­men (IPS) oder Rever­se Pro­xies Ver­bin­dun­gen,
die Angriffs­mu­ster auf­wei­sen, direkt ohne Wei­ter­ga­be an die Fach­ap­pli­ka­ti­on abwei­sen oder nicht zwin­gend
benö­tig­te HTTP-Hea­der auf sta­ti­sche Wer­te set­zen.
• Blockie­ren aller nicht zwin­gend not­wen­di­gen, aus­ge­hen­den Ver­bin­dun­gen.
• Umfas­sen­des Log­ging und die Pro­to­kol­lie­rung aller ein­ge­hen­der und aus­ge­hen­der Ver­bin­dun­gen, um im
Nach­gang eine Kom­pro­mit­tie­rung leich­ter fest­stel­len zu kön­nen.
• Ano­ma­lie­de­tek­ti­on auf dem Host betrei­ben.
• Prü­fen, mit wel­chen Rech­ten der betrof­fe­ne Dienst betrie­ben wird und die­se auf das not­wen­di­ge Mini­mum
redu­zie­ren.
• Ver­bin­dun­gen zu ande­ren Syste­men soll­ten getrennt wer­den.
Für nach Bekannt­wer­den der Schwach­stel­le gepach­te Syste­me muss zusätz­lich unter­sucht wer­den, ob die­se bereits
kom­pro­mit­tiert wur­den. Dies betrifft auch Syste­me, die nicht direkt mit dem Inter­net ver­bun­den sind, da die­se über
ver­bun­de­ne Syste­me kom­pro­mit­tiert wor­den sein könn­ten.
Infor­mie­ren Sie sich auf den Web­sei­ten der von Ihnen ein­ge­setz­ten Her­stel­ler (u.a. den oben genann­ten) über Patches
und Work­arounds und spie­len sie die­se unver­züg­lich ein.
Update 3:
Unter [GIT2021e] und [NCSC2021] (mög­li­cher­wei­se erst am spä­ten Nach­mit­tag ver­füg­bar) wur­den Hin­wei­sen zu einer
mög­li­chen Betrof­fen­heit zahl­rei­cher Pro­duk­te ver­öf­fent­licht. Als erste Ori­en­tie­rungs­hil­fe ist es zu emp­feh­len, die­se
Listen mit eige­nen ein­ge­setz­ten Pro­duk­ten abzu­glei­chen. Das BSI hat die Inhal­te nicht voll­stän­dig veri­fi­ziert. Die Listen
wer­den mit hoher Wahr­schein­lich­keit fort­lau­fend aktua­li­siert, so dass eine mehr­ma­li­ge Über­prü­fung not­wen­dig ist.
Die­ser Abgleich kann die zwin­gend erfor­der­li­chen eige­nen Über­prü­fungs­maß­nah­men ergän­zen.
Da zum aktu­el­len Zeit­punkt kei­ne gesi­cher­te Aus­sa­ge dar­über getrof­fen wer­den kann, in wel­chen Pro­duk­ten die
Biblio­thek ein­ge­setzt wird, kann das unter [GIT2021h] ver­öf­fent­lich­te Tool zum Suchen von betrof­fe­nen log4j
Biblio­the­ken ver­wen­det wer­den. Das Tool durch­sucht dabei Hash­sum­men-basiert .jar und .war Archi­ve nach
ein­deu­ti­gen Java-Klas­sen. Da ledig­lich die offi­zi­ell kom­pi­lier­ten Releases erkannt wer­den, kann es ins­be­son­de­re bei
Linux-Syste­men vor­kom­men, dass betrof­fe­ne log4j Biblio­the­ken nicht erkannt wer­den.
Unter [GIT2021f] wur­de eine Auf­li­stung von Befeh­len ver­öf­fent­licht, mit denen man Log-Daten auf eine mög­li­che
Aus­nut­zung der Schwach­stel­le über­prü­fen kann. Im Fal­le von Tref­fern ist es drin­gend zu emp­feh­len wei­te­re
Maß­nah­men sofort ein­zu­lei­ten. Zu die­sen zäh­len z.B.: Netz­tren­nung, Suche nach den Schwach­stel­len, deren Schlie­ßung
(ggf. durch Neu­in­stal­la­ti­on) und dann die Feststellung/​Bereinigung einer mög­li­chen Kom­pro­mit­tie­rung mit Schad­code
unter Betrach­tung auch wei­te­rer benach­bar­ter und dahin­ter­lie­gen­der Syste­me (late­ral movement).