Frage zu Log4J Problem

[Lemmy]

Servus,

wenn ich ein Jar habe, das "nur" auf meinem Rechner liegt, das jar aber nicht aktiv ausgeführt wird. Dort ist aber definitiv eine alte Log4J drin, dann kann doch diese Lücke nur dann ausgenutzt werden, wenn ich auf meinem Rechner ein Programm ausführe, das dann nach angreifbaren jar sucht. Wobei dann müsste das Programm ja noch die Jar ausführen?!?

Oder kann das Programm dann "lediglich" das kaputte Log4J aus dem Jar aktivieren und ausnutzen?

Grüße

P.s: mir ist klar, dass ich schon dann ein Problem habe, wenn ich ein unerwünschtes Programm auf meiner Kiste ausführe....

[himitsu]

Das ist egal.

Wenn das "böse" Programm bereits auf deinem Rechner läuft und Rechte hat diese Datei im Java auszuführen, dann braucht es diese Sicherheitslücke nicht mehr, weil es dann auch gleich direkt auf alles Zugriff haben würde,
bzw. es könnte auch seinen eigenen Code für Log4J mitbringen und braucht deine Datei garnicht.

[mjustin]

Zitat:

Zitat von Lemmy (Beitrag 1499226)

Servus,

wenn ich ein Jar habe, das "nur" auf meinem Rechner liegt, das jar aber nicht aktiv ausgeführt wird. Dort ist aber definitiv eine alte Log4J drin, dann kann doch diese Lücke nur dann ausgenutzt werden, wenn ich auf meinem Rechner ein Programm ausführe, das dann nach angreifbaren jar sucht.

Der passende Vergleich wäre ein Virus (in der Biologie): solange ein Virus nur so herumliegt, ist es ungefährlich. Erst wenn es in einer Umgebung ist in der sein DNA oder RNA Code 'ausgeführt' wird, kann es sich in seinem Wirt vermehren. (Also ja.)

[Phoenix]

Dazu kommt, das das Problem ja nur auftritt, wenn bestimmte Texte in den Platzhaltern der Lognachrichten mittels log4j gelogged werden.
Konkret: Loggt das Java-Programm nur statische Texte mit z.B. Datum und Zahlen, hast Du kein Problem. Nur wenn das Ding externe Eingaben loggt, und jemand so einen {jndi:ldap://url} - Text ins das Log reinbringt, DANN wird der Code hinter der Adresse nachgeladen und ausgeführt.

[Lemmy]

Danke für die Antworten.
Das Problem ist: Das teil ist nicht von mir, keinen Plan was das Ding so treibt und was wohin geschrieben wird.
Allerdings haben "wir" das halt an unsere Kunden ausgeliefert (ausliefern müssen) und jetzt stelle ich mir die Frage ob es nicht schlauer wäre, das Zeugs von den Kundenrechnern zu putzen, wenn wir die aktuelle Version ausliefern....

[sakura]

Zitat:

Zitat von Lemmy (Beitrag 1499234)

das Zeugs von den Kundenrechnern zu putzen, wenn wir die aktuelle Version ausliefern....

Definitiv, und mit einem Flammenwerfer hinterher alles reinigen.

...:cat:...

[hoika]

Hallo,
von der KBV gibt es mittlerweile neue Versionen vom Prüfmodul und Kryptomodul.
Falls es darum geht ...

[Rollo62]

Zitat:

Zitat von Lemmy (Beitrag 1499234)

... das Zeugs von den Kundenrechnern zu putzen, wenn wir die aktuelle Version ausliefern....

Gute Frage: Wie findet und bereinigt man das Log4J Problem am Besten und Einfachsten ?
Durch einfache Filesuche, oder gibt es von MS oder anderso schon Scanner ?
Wie findet und beseitigt das auf Apache-Servern und/oder NAS-Systemen ?

[Bernhard Geyer]

Zitat:

Zitat von sakura (Beitrag 1499243)

Zitat:

Zitat von Lemmy (Beitrag 1499234)

das Zeugs von den Kundenrechnern zu putzen, wenn wir die aktuelle Version ausliefern....

Definitiv, und mit einem Flammenwerfer hinterher alles reinigen.

...:cat:...

Wenn man von einem erfolgreichen Angriff ausgeht, wäre der Rechner neu aufzusetzen.
Also das "putzen" als ersten Schritt unnötig.

[Lemmy]

Zitat:

Zitat von hoika (Beitrag 1499245)

Hallo,
von der KBV gibt es mittlerweile neue Versionen vom Prüfmodul und Kryptomodul.
Falls es darum geht ...

ähm.. Ja.. aber halt "nur" für Q1-2022 und glaube Q4-2021. Aber der Rest halt nicht :-) Und die KBV empfiehlt inzwischen selbst die Entfernung bzw. die Ausführung in einer sicheren Umgebung...

https://update.kbv.de/ita-update/Ank..._Log4j_FAQ.pdf

[Lemmy]

Zitat:

Zitat von Rollo62 (Beitrag 1499246)

Zitat:

Zitat von Lemmy (Beitrag 1499234)

... das Zeugs von den Kundenrechnern zu putzen, wenn wir die aktuelle Version ausliefern....

Gute Frage: Wie findet und bereinigt man das Log4J Problem am Besten und Einfachsten ?
Durch einfache Filesuche, oder gibt es von MS oder anderso schon Scanner ?
Wie findet und beseitigt das auf Apache-Servern und/oder NAS-Systemen ?

es gibt einen Python-scanner
https://github.com/fox-it/log4j-finder

und sicherlich noch vieles mehr.

Zitat:

Zitat von Bernhard Geyer (Beitrag 1499247)

Wenn man von einem erfolgreichen Angriff ausgeht, wäre der Rechner neu aufzusetzen.
Also das "putzen" als ersten Schritt unnötig.

doch, nach einer Nacht drüber schlafen, sehe ich zumindest das Potential eines SocialEngineering Angriffs auf Arztpraxen (in unserem Fall) wenn die eine präparierte Abrechnungsdatei durch das KBV Prüfmodul jagen....

[Rollo62]

Das hier ist vielleicht auch hilfreich.

[hoika]

Hallo,
ja, die Ausführung zu verhindern.

Ich glaube nicht, dass man durch das Löschen der log4j-Datei das Problem löst.
Ich habe die Datei nicht gefunden.

[Harry Stahl]

Das BSI hat eine ständig aktualisierte Seite, wo auch Maßnahmen zu Detektion und Beseitigung beschrieben werden:

https://www.bsi.bund.de/DE/Themen/Un...og4j_node.html

Das unangenehme an der Sache ist, dass inzwischen klar, ist, dass auch ältere Versionen von Log4J (1.x) für Angriffe anfällig sind (und damit das Problem noch größer, als zunächst vermutet). Dafür wird es wahrscheinlich aber keines Fixes mehr geben, d.h. ein Umstieg auf aktuelle Versionen 2.x wird erforderlich sein.

[Bernhard Geyer]

Woraus liest du das auch log4j 1.x auch betroffen wäre?

Die Erweiterung mit Auswertung der Daten ist ja erst mit 2.x rein gekommen.
Oder verwechselst du da evtl. was mit das ältere Java-Versionen noch anfälliger wären?

[dummzeuch]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1499319)

Woraus liest du das auch log4j 1.x auch betroffen wäre?

Von hier:
https://github.com/apache/logging-lo...ment-990494126

Zitat:

Update (2021-12-12 10:09 JST): according to this analysis by @TopStreamsNet, strictly speaking, applications using Log4j 1.x may be impacted if their configuration uses JNDI. However, the risk is much lower.

Da ich aber keine Ahnung von Log4J habe, kann ich nicht beurteilen, ob das stimmt und wie problematisch das ist.

Btw: Der Embarcadero License Server (für Network Lizenzen) benutzt Log4J 1.x.

[Harry Stahl]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1499319)

Woraus liest du das auch log4j 1.x auch betroffen wäre?

Die Erweiterung mit Auswertung der Daten ist ja erst mit 2.x rein gekommen.
Oder verwechselst du da evtl. was mit das ältere Java-Versionen noch anfälliger wären?

Aus dem BSI-Papier vom 14.12.2012:

"Eine ähnliche Schwachstelle ist auch für die nicht mehr im Support befindlichen Versionen
1.x gemeldet worden, hierbei scheint die Ausnutzung allerdings komplexer zu sein. Da die Versionen 1.x jedoch den
End-of-life (EOL) Status erreicht haben, wird es zu diesen keine Sicherheitsupdates mehr geben [APA2021a]."