Frage zu Log4J Problem

[mjustin]

Zitat von 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.

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 von Lemmy:

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

Definitiv, und mit einem Flammenwerfer hinterher alles reinigen.

......

[hoika]

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

[Lemmy]

Zitat von hoika:

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

[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.

[Bernhard Geyer]

Zitat von sakura:

Zitat von Lemmy:

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

Definitiv, und mit einem Flammenwerfer hinterher alles reinigen.

......

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

[Rollo62]

Zitat von Lemmy:

... 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 ?

[Lemmy]

Zitat von Rollo62:

Zitat von Lemmy:

... 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 von Bernhard Geyer:

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....