7
Kurzes Log4shell Statement
Hallo,
sorry - wenn ich hier mit einem Extra Thread frage, dieses Statement ist absolut richtig oder?
Ich frage für SMB/KMU ohne eigene öffentlich erreichbare Webserver.
MS Exchange EAS via Port 443 ist für Log4Shell aktuell nicht gefährlich.
Ihre Frage war: gibt es hinsichtlich Log4Shell und unserer lokalen Hardwarefirewall, dem lokalen Windows Server (1) und den lokalen PCs (2) Risiken bzgl. Log4Shell?
Antwort:
Wenn Ihre lokale Hardware-Firewall eingehend kein Portforwarding auf ein lokales Netzwerkgerät mit Webserver hat, dann sind Sie schon sehr sicher unterwegs"
Log4Shell verbreitet sich von aktuell primär von draußen nach drinnen.
Wenn jedoch gar kein Fenster (Port) offen ist, dann besteht signifikant weniger Gefahr und Ihre EDV ist zunächst quasi fast nicht auf dem Radar für Log4Shell.
sorry - wenn ich hier mit einem Extra Thread frage, dieses Statement ist absolut richtig oder?
Ich frage für SMB/KMU ohne eigene öffentlich erreichbare Webserver.
MS Exchange EAS via Port 443 ist für Log4Shell aktuell nicht gefährlich.
Ihre Frage war: gibt es hinsichtlich Log4Shell und unserer lokalen Hardwarefirewall, dem lokalen Windows Server (1) und den lokalen PCs (2) Risiken bzgl. Log4Shell?
Antwort:
Wenn Ihre lokale Hardware-Firewall eingehend kein Portforwarding auf ein lokales Netzwerkgerät mit Webserver hat, dann sind Sie schon sehr sicher unterwegs"
Log4Shell verbreitet sich von aktuell primär von draußen nach drinnen.
Wenn jedoch gar kein Fenster (Port) offen ist, dann besteht signifikant weniger Gefahr und Ihre EDV ist zunächst quasi fast nicht auf dem Radar für Log4Shell.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 1622306081
Url: https://administrator.de/contentid/1622306081
Printed on: April 19, 2024 at 13:04 o'clock
7 Comments
Latest comment
Moin,
richtig. Sofern der Router (EDIT: bzw. Firewall etc. wenn von außen erreichbar) selbst nicht betroffen ist, muss dann der Angriff von innen kommen.
Viele Grüße
Trommel
richtig. Sofern der Router (EDIT: bzw. Firewall etc. wenn von außen erreichbar) selbst nicht betroffen ist, muss dann der Angriff von innen kommen.
Viele Grüße
Trommel
Moin,
Was ich sagen möchte, die Kombination von Exploits verschiedener Sicherheitsücken bietet genug Zündstoff doch noch Opfer zu werden.
Gruß,
Dani
MS Exchange EAS via Port 443 ist für Log4Shell aktuell nicht gefährlich.
direkt nicht. Indirekt nach wie vor denkbar. Es gibt immer noch genügend Exchange Server die gar oder schlecht gesichert sind. Da ist es durch aus denkbar, dass zuerst der Exchange-Server "geknackt" wird. Somit ist man meistens in der grünen Zone (LAN) und dann könnte Log4Shell zum Zuge kommen.Was ich sagen möchte, die Kombination von Exploits verschiedener Sicherheitsücken bietet genug Zündstoff doch noch Opfer zu werden.
Gruß,
Dani
Hallo,
ist dieses Statement auch richtig?
Sprachlich etwas holprig, aber in der Sache ja richtig.
Wenn ein cleaner Client auf einen infizierten Webserver trifft gibt es natürlich Ärger, keine Frage.
Sofern Sie sich mit Ihrem Client-PC z.B. auf Webseiten/Webservern einloggen (die Java verwenden und für Log4shell anfällig sind) dann sind Sie nicht automatisch sofort einer hohen Gefahr ausgesetzt und müssen bei sich am Client PC wegen Log4shell auch keine besonderen Maßnahmen treffen. (ausser den Java Versionsstand prüfen)
Die Gefahr zielt primär auf die Webserver und den dortigen Daten/Ressourcen und nicht direkt auf die Clients.
ist dieses Statement auch richtig?
Sprachlich etwas holprig, aber in der Sache ja richtig.
Wenn ein cleaner Client auf einen infizierten Webserver trifft gibt es natürlich Ärger, keine Frage.
Sofern Sie sich mit Ihrem Client-PC z.B. auf Webseiten/Webservern einloggen (die Java verwenden und für Log4shell anfällig sind) dann sind Sie nicht automatisch sofort einer hohen Gefahr ausgesetzt und müssen bei sich am Client PC wegen Log4shell auch keine besonderen Maßnahmen treffen. (ausser den Java Versionsstand prüfen)
Die Gefahr zielt primär auf die Webserver und den dortigen Daten/Ressourcen und nicht direkt auf die Clients.
Zitat von @ManuManu2021:
Hallo,
ist dieses Statement auch richtig?
Sprachlich etwas holprig, aber in der Sache ja richtig.
Wenn ein cleaner Client auf einen infizierten Webserver trifft gibt es natürlich Ärger, keine Frage.
Sofern Sie sich mit Ihrem Client-PC z.B. auf Webseiten/Webservern einloggen (die Java verwenden und für Log4shell anfällig sind) dann sind Sie nicht automatisch sofort einer hohen Gefahr ausgesetzt und müssen bei sich am Client PC wegen Log4shell auch keine besonderen Maßnahmen treffen. (ausser den Java Versionsstand prüfen)
Die Gefahr zielt primär auf die Webserver und den dortigen Daten/Ressourcen und nicht direkt auf die Clients.
Hallo,
ist dieses Statement auch richtig?
Sprachlich etwas holprig, aber in der Sache ja richtig.
Wenn ein cleaner Client auf einen infizierten Webserver trifft gibt es natürlich Ärger, keine Frage.
Sofern Sie sich mit Ihrem Client-PC z.B. auf Webseiten/Webservern einloggen (die Java verwenden und für Log4shell anfällig sind) dann sind Sie nicht automatisch sofort einer hohen Gefahr ausgesetzt und müssen bei sich am Client PC wegen Log4shell auch keine besonderen Maßnahmen treffen. (ausser den Java Versionsstand prüfen)
Die Gefahr zielt primär auf die Webserver und den dortigen Daten/Ressourcen und nicht direkt auf die Clients.
Naja ... ja und nein.
Soweit ich es verstehe, läuft es einfach gesagt ja so:
Server mit verwundbarer Version von Log4J ist von außen erreichbar -> Server loggt den präparierten Befehl und lädt den Code nach -> Server führt diesen Schadcode aus und wurde damit übernommen
Nun kann dort natürlich alles mögliche passieren. Daten abziehen, Botnetz oder eben auch wieder Schadcode eingepflegen, womit man sich dann als Client infizieren kann.
Viele Grüße
Trommel
1
Hallo,
die Aussagen sind nicht vollkommen falsch, aber von "absolut richtig" auch weit entfernt, also in meinen Augen zumindest unnötig bis irreführend.
Generell verbeitet sich nichts spezfisch "von außen nach innen", sondern alle Angriffe naturgemäß vom Angreifer zum Angriffsziel. Wo der Angreifer sitzt, entzieht sich jeder Kontrolle.
Da eine Logging-Bibliothek in der Regel nicht direkt mit einem Frontend versehen wird, ist im Fall von Log4Shell klar, dass jeder praktische Angriff indirekt erfolgt. Das kann indirekt auf einem erreichbaren Gesamtsystem sein (in meinem Verantwortungsbereich z.B. ein webbasierter Konfigurationsmanager, der von einem böswilligen Admin hätte übernommen werden können).
Es kann aber auch indirekt über mehrere Systeme hinweg erfolgen. Die Annahme einer Abhängigkeit von netzwerktechnisch extern (bzw. einem Angreifer direkt) erreichbaren Systemen ist daher nicht zielführend.
Es geht vielmehr darum, ob ein Angreifer Daten erzeugen kann, die irgendwann in ihrem Lebenszyklus einmal von Log4j geparst werden.
Ein typisches Beispiel für eine nicht direkt erreichbare Lösung wäre ein javabasierter E-Mail-Archivserver, der bei einer bestimmten Logging-Konfiguration und geschickter Gestaltung einer zu archivierenden Nachricht kompromittiert werden kann. Bei Desktopsoftware stellt sich dasselbe Problem vielleicht noch verschärft, da die Konnektivität ins Internet oft schlechter kontrolliert ist als aus Servernetzen. Keinesfalls reicht es, nur auf eine aktuelle Java-Installation zu achten, sondern die Anwendung muss gepatcht sein. Erstens brächte sie log4j mit, zweitens bringt sie ohnehin oft ihre eigene Laufzeitumgebung mit oder wird der Einfachheit halber zumindest so verteilt.
Grüße
Richard
die Aussagen sind nicht vollkommen falsch, aber von "absolut richtig" auch weit entfernt, also in meinen Augen zumindest unnötig bis irreführend.
Generell verbeitet sich nichts spezfisch "von außen nach innen", sondern alle Angriffe naturgemäß vom Angreifer zum Angriffsziel. Wo der Angreifer sitzt, entzieht sich jeder Kontrolle.
Da eine Logging-Bibliothek in der Regel nicht direkt mit einem Frontend versehen wird, ist im Fall von Log4Shell klar, dass jeder praktische Angriff indirekt erfolgt. Das kann indirekt auf einem erreichbaren Gesamtsystem sein (in meinem Verantwortungsbereich z.B. ein webbasierter Konfigurationsmanager, der von einem böswilligen Admin hätte übernommen werden können).
Es kann aber auch indirekt über mehrere Systeme hinweg erfolgen. Die Annahme einer Abhängigkeit von netzwerktechnisch extern (bzw. einem Angreifer direkt) erreichbaren Systemen ist daher nicht zielführend.
Es geht vielmehr darum, ob ein Angreifer Daten erzeugen kann, die irgendwann in ihrem Lebenszyklus einmal von Log4j geparst werden.
Ein typisches Beispiel für eine nicht direkt erreichbare Lösung wäre ein javabasierter E-Mail-Archivserver, der bei einer bestimmten Logging-Konfiguration und geschickter Gestaltung einer zu archivierenden Nachricht kompromittiert werden kann. Bei Desktopsoftware stellt sich dasselbe Problem vielleicht noch verschärft, da die Konnektivität ins Internet oft schlechter kontrolliert ist als aus Servernetzen. Keinesfalls reicht es, nur auf eine aktuelle Java-Installation zu achten, sondern die Anwendung muss gepatcht sein. Erstens brächte sie log4j mit, zweitens bringt sie ohnehin oft ihre eigene Laufzeitumgebung mit oder wird der Einfachheit halber zumindest so verteilt.
Grüße
Richard
Hallo Richard,
du hast schon.
Ich fragte sozusagen aus der Perspektive von KMU:
KMU mit on-prem
1x Hardware Firewall
1x Fileserver + Mailsserver
5x PC
kein WLAN
keine offenen Firewallports ausser 25 und 443 (noch ohne reverse proxy *hust *hust*)
kein Cloud Software
keine NAS
Zu zwei drittel Wahrscheinlichkeit ist der Angreifer aus dieser Perspektive "draußen" und hat wenig Angriffsfläche. (mal von exchange - iis - 443 / 25 abgesehen)
Log4shell kann ohne ohne Benutzer-Interaktion wie Mail-Anhang öffnen, verseuchte WWW-Homepage besuchen oder gefundenen USB Stick aus Neugier anschließen bei o.g. KMU kein Schaden meiner Meinung nach anrichten.
du hast schon.
Ich fragte sozusagen aus der Perspektive von KMU:
KMU mit on-prem
1x Hardware Firewall
1x Fileserver + Mailsserver
5x PC
kein WLAN
keine offenen Firewallports ausser 25 und 443 (noch ohne reverse proxy *hust *hust*)
kein Cloud Software
keine NAS
Zu zwei drittel Wahrscheinlichkeit ist der Angreifer aus dieser Perspektive "draußen" und hat wenig Angriffsfläche. (mal von exchange - iis - 443 / 25 abgesehen)
Log4shell kann ohne ohne Benutzer-Interaktion wie Mail-Anhang öffnen, verseuchte WWW-Homepage besuchen oder gefundenen USB Stick aus Neugier anschließen bei o.g. KMU kein Schaden meiner Meinung nach anrichten.
Hallo,
ich kenne mich zu wenig aus - Advoware hatte folgendes Statement:
Falls spontan jemand weiß, ob das richtig ist, das "jeder Rechner" sicherer ist" wenn diese Umgebungs-Systemvariable "Advoware Client" PC ist, danke für eine Info.
Zitat: Unabhängig von der Benutzung von advoware empfehlen wir Ihnen dringend, an jedem Rechner die Systemvariable LOG4J_FORMAT_MSG_NO_LOOKUPS unter Verwendung von Administratorrechten auf true zu setzen. Damit erreichen Sie, dass auch andere Programme, die ebenfalls von der Java-Schwachstelle betroffen sind, voraussichtlich keinen Schaden anrichten können. Dies ist zumindest der derzeitige Stand, der aus Expertenkreisen kommuniziert wird.
+++
In der BSI PDF steht das so:
Maßnahmen
Server sollten generell nur solche Verbindungen (insbesondere in das Internet) aufbauen dürfen, die für den
Einsatzzweck zwingend notwendig sind. Andere Zugriffe sollten durch entsprechende Kontrollinstanzen wie Paketfilter
und Application Layer Gateways unterbunden werden. [BSI2021b]
Es sollte entsprechend dem Grundschutzbaustein [BSI2021a] ein Update auf die aktuelle Version 2.15.0 [APA2021] (gittag: 2.15.0-rc2 [GIT2021c]) von log4j in allen Anwendungen sichergestellt werden. Da Updates von Abhängigkeiten in
Java-Anwendungen häufig nicht zeitnah erfolgen können, sollte bis dahin die folgende Mitigationsmaßnahme ergriffen
werden:
Die Option "log4j2.formatMsgNoLookups" sollte auf "true" gesetzt werden, indem die Java Virtual Machine mit dem
Argument
"–Dlog4j2.formatMsgNoLookups=True”
gestartet wird.
Update 2:
Alternativ kann auch die Umgebungsvariable LOG4J_FORMAT_MSG_NO_LOOKUPS auf true gesetzt werden. Diese
beiden Mitigationsmaßnahmen funktionieren erst ab Log4J Version 2.10.
Achtung: Diese Maßnahme kann die Funktionsweise der Applikation beeinträchtigen, wenn die Lookup-Funktion
tatsächlich verwendet wird.
ich kenne mich zu wenig aus - Advoware hatte folgendes Statement:
Falls spontan jemand weiß, ob das richtig ist, das "jeder Rechner" sicherer ist" wenn diese Umgebungs-Systemvariable "Advoware Client" PC ist, danke für eine Info.
Zitat: Unabhängig von der Benutzung von advoware empfehlen wir Ihnen dringend, an jedem Rechner die Systemvariable LOG4J_FORMAT_MSG_NO_LOOKUPS unter Verwendung von Administratorrechten auf true zu setzen. Damit erreichen Sie, dass auch andere Programme, die ebenfalls von der Java-Schwachstelle betroffen sind, voraussichtlich keinen Schaden anrichten können. Dies ist zumindest der derzeitige Stand, der aus Expertenkreisen kommuniziert wird.
+++
In der BSI PDF steht das so:
Maßnahmen
Server sollten generell nur solche Verbindungen (insbesondere in das Internet) aufbauen dürfen, die für den
Einsatzzweck zwingend notwendig sind. Andere Zugriffe sollten durch entsprechende Kontrollinstanzen wie Paketfilter
und Application Layer Gateways unterbunden werden. [BSI2021b]
Es sollte entsprechend dem Grundschutzbaustein [BSI2021a] ein Update auf die aktuelle Version 2.15.0 [APA2021] (gittag: 2.15.0-rc2 [GIT2021c]) von log4j in allen Anwendungen sichergestellt werden. Da Updates von Abhängigkeiten in
Java-Anwendungen häufig nicht zeitnah erfolgen können, sollte bis dahin die folgende Mitigationsmaßnahme ergriffen
werden:
Die Option "log4j2.formatMsgNoLookups" sollte auf "true" gesetzt werden, indem die Java Virtual Machine mit dem
Argument
"–Dlog4j2.formatMsgNoLookups=True”
gestartet wird.
Update 2:
Alternativ kann auch die Umgebungsvariable LOG4J_FORMAT_MSG_NO_LOOKUPS auf true gesetzt werden. Diese
beiden Mitigationsmaßnahmen funktionieren erst ab Log4J Version 2.10.
Achtung: Diese Maßnahme kann die Funktionsweise der Applikation beeinträchtigen, wenn die Lookup-Funktion
tatsächlich verwendet wird.
