Log4J - was hängt da eigentlich so im Heimnetz alles dran?

Ein Anhaltspunkt wären diese Listen hier:
https://gist.github.com/SwitHak/b66db3…b71a8718970c592
https://www.techsolvency.com/story-so-far/c…og4j-log4shell/

Das Problem ist ganz Simpel das keiner so recht weiss wo diese Lib überall drinsteckt.

Eine schöne Erklärung gibt es auch hier:
https://www.golem.de/news/log4j-lue…112-161757.html

Meine Einschätzung: Solange man im Internet keine Dienste hängen hat die Log4J nutzen (größtenteils wohl Java Programme) sollte man sicher sein.

Zitat von darkside40

Meine Einschätzung: Solange man im Internet keine Dienste hängen hat die Log4J nutzen (größtenteils wohl Java Programme) sollte man sicher sein.

Die Einschätzung deckt sich mit der ursprünglichen Einschätzung des BSI. BSI hat das aber mittlerweile revidiert: "Im Gegensatz zur ursprünglichen Einschätzung kann die kritische Schwachstelle ggf. auch auf internen Systemen ausgenutzt werden, [...]"

Better safe than sorry. (Auch wenn die genauen Konditionen vielleicht nicht ganz klar sind und es bei Systemen, die nicht Dienste direkt im Internet anbieten wohl unwahrscheinlicher ist, dass da was passiert). Kritische Schwachstelle in log4j veröffentlicht (CVE-2021-44228) (bund.de)

Vielleicht können wir die verschiedenen Threads hier im Forum mal zusammen fassen?!

Nur so ne Idee. Dann haben wir alle Infos dazu an einer Stelle

Zitat von buers

BSI hat das aber mittlerweile revidiert

Man muss den Satz aber vollständig zitieren. Ansonsten ist der irreführend:

Im Gegensatz zur ursprünglichen Einschätzung kann die kritische Schwachstelle ggf. auch auf internen Systemen ausgenutzt werden, [...] sofern diese externe Daten entgegennehmen oder verarbeiten.

Ist das nicht der Fall, dann ist man intern von der Schwachstelle geschützt. Denn von extern gestellt Anfragen enden erstmal am Router. Anfragen kommen unangefragt nur dann rein, wenn ich das einstelle. Sei es nun ein VPN was da auf meiner IP lauscht oder ich habe ein Port-Forwarding eingerichtet. Ist das alles nicht der Fall, endet die Anfrage direkt an der Firewall und wird abgelehnt, da der Router auch gar nicht wüsste wohin er die Anfrage schicken soll. Zumindest bei TCP. Und da das Internet nun mal TCP/IP ist, sollte da auch nichts durch kommen. So zumindest mein Verständnis in der Sache.

Habe ich natürlich einen Server laufen und eine Portweiterleitung eingerichtet, dann bin ich sehr wohl betroffen, wenn der Server Log4j benutzt.

Zitat von darkside40

Meine Einschätzung: Solange man im Internet keine Dienste hängen hat die Log4J nutzen (größtenteils wohl Java Programme) sollte man sicher sein.

Die Zeiten sind leider vorbei, soweit meine Erfahrung ... aktuelle Schadsoftware wird auch im internen Netz nach dieser Lücke suchen um weitere Geräte zu infizieren. Selbst wenn der eigene Rechner nicht erfolgreich geknackt werden konnte durch solch Schadsoftware versucht sie soweit es möglich ist andere zu finden die sie Angreifen kann.

Wie ich geschrieben habe, ist das (mir und Spezialisten in meinem Umfeld) nicht ganz klar. Es gibt da andere Interpretationen. "Externe Daten verarbeiten" kann heißen: Ich surfe nach draußen, hole mir was mit http get. *) Kein Dienst steht im Internet (über NAT/Port-Weiterleitung, direkt, ...). In der ursprünglichen Fassung vom BSI war das ausgeschlossen, nach unserer Lesweise. Jetzt ist es nicht mehr klar ausgeschlossen. Wir haben auch Hersteller-Info erhalten, die da explizit warnen. Ich denke in so einer Situation, ist Vorsicht nicht falsch.

(Ich verstehe schon, was es bedeutet, dass ein Dienst im Internet steht).

*) Ich gehe nicht davon aus, dass mein Browser die lib nutzt. Sollte nur als Beispiel dienen, wie "externe Daten verarbeiten" gemeint sein kann oder gar wird. Wird ja auch einen Grund geben, dass das BSI das jetzt explizit hinzugefügt hat.

@noob_at_pc Ein externer Dienst kann in einem internen Netz nur dann nach der entsprechenden Lücke suchen wenn ich ihn auch rein lasse. Shodan z. B. kann gern versuchen über meine öffentliche IP meine Ubiquiti Hardware zu scannen. Meine IP ist genattet (CGN) und diese teile ich mir nicht etlichen anderen Kunden meines ISPs. Das wird also so nichts.

Selbst wenn ich einen Dienst betreibe und von intern nach draußen surfe, dann müsste ich einen speziel preparierten String parsen, der dann geloggt wird und die entsprechende Stelle ausnutzt.

Zitat von buers

"Externe Daten verarbeiten" kann heißen: Ich surfe nach draußen, hole mir was mit http get.

Ja, und das was du dir da holst müsste entsprechend prepariert sein, damit der exploit funktioniert. Ich sage nicht, dass es zu 100% ausgeschlossen ist. Ich sage nur, dass diese Wahrscheinlichkeit, dass ich eine Webseite mit einem solch prepariertem String anzusurfen doch mehr als gering ist.

Ich will das alles nicht verharmlosen. Ich möchte nur nicht, dass man paranoid wird, nur weil man zu Hause einen Server laufen lässt. Die Sicherheitslücke befasst sich weiter mit "remote code execution" und kann darüber auch eine Shell öffnen. Das ist kein "Wurm", der sich verbreitet oder eine Software, die sich installiert.

Und natürlich sollte man prüfen, ob seine Systeme anfällig sind und die entsprechenden Updates einspielen. Dafür sind Updates da. Aber man sollte jetzt auch nicht wahnsinnig werden

Zitat von buers

Ich gehe nicht davon aus, dass mein Browser die lib nutzt.

Dein Browser wird, wie viele andere, in C++ geschrieben sein. Da ist es nahezu ausgeschlossen, dass er ne Java-Lib nutzt ;). Genauso wie Grafana nicht betroffen ist, da Grafana in Go geschrieben ist. Plugins jedoch, können natürlich in der entsprechenden Sprache geschrieben sein und so könnte man sich die Lücke auch wieder einfangen. 3rd Party Apps zu prüfen macht das ganze noch viel komplexer

Wenn du aber Schadsoftware auf ein PC in deinem Netzwerk hast ... so war es gemeint. Die Gefahr kommt ebenso von Innen da Schadsoftware mittlerweile enorm viel Zusatzmodule mitlädt um möglichst viele Lücken ansprchen zu können. Und das macht das ganze doch problematischer als manche denken.

Jo, das stimmt. Da gebe ich dir Recht.

Ich glaube aber nicht das das die Fragestellung des TE war.
Wenn ich die Schadsoftware erstmal in meinem internen Netz habe ist es eh zu spät.

Auch das stimmt. Wobei aus seiner Frage auch nicht hervor geht, ob er die Dienste im Netz stehen hat (also sie von "außen" erreichbar sind) oder nicht. Aber er fragt nach jeglichen Szenarien, die möglich wären. Das sind ziemlich viele Konjunktive. "Hätte", "wäre", "könnte" etc..... Leider ist die Fragestellung so noch nicht mal wirklich für eine Security-Untersuchung zielführend. Da muss man viel zu viele Gegenfragen stellen um eine valide Aussage treffen zu können.

Man kann auch einfach mal auf die entsprechenden Server selbst drauf gehen und folgendes machen: sudo find / -name “log4j*”. Wenn da ne Lib installiert ist, gibt es auch eine Datei dazu.

Im Fall von "NextCloud" kann es halt auch sein, dass da noch andere Docker drauf laufen, die das beinhalten. NextCloud selbst z. B. ist in PHP geschrieben. Daher ist auch da der Angriffsvektor recht gering. Zu den zusätzlich installieren Plugins/Services kann ich nichts sagen mangels Information

Machen wir mal weiter....

Zitat von Commerzpunk

LetsEncrypt, TVH, Emby, SWAG, Syncthing + weiteres.

Letsencrypt ist eine Certificate authority. Da schließt sich mir der Kreis eines Angriffes ohnehin nicht.

Ich habe auf meinem Unraid einen TVH docker. Nach der Suche, die ich oben genannt habe, konnte ich keine Daten dazu finden. Somit würde ich das auch ausschließen. Selbst nach einer Suche innerhalb des Dockers nicht. Weiter ist TVH in "C" geschrieben: https://github.com/tvheadend/tvheadend

Emby ist auch nicht in Java geschrieben: https://github.com/MediaBrowser/Emby

SWAG setzt einen NGINX Server mit PHP Support auf. https://hub.docker.com/r/linuxserver/swag Weiter ist da noch fail2ban dabei. Ob die einzelnen Komponenten angreifbar sind, darf der Fragesteller selbst ergoogeln mit: <name der komponente> log4j

Syncthing ist zum Großteil in Go geschrieben: https://github.com/syncthing/syncthing

"weiteres" werde ich so nicht googlen können

Ich würde also mal ganz entspannt behaupten, das er bis auf NextCloud sicher ist. Wenn man auf NextCloud auch noch eine ElasticSearch installiert hat, dann ist man betroffen, da ElasticSearch selbst verwundbar ist und erst seit der Version 7.16 einen Patch raus gebracht hat. Man kann aber in den Java-Opts das Auflösen des Strings unterbinden indem man folgendes hinzufügt: -Dlog4j2.formatMsgNoLookups=true

Siehe: https://xeraa.net/blog/2021_miti…-elasticsearch/

Was aber in der Nextcloud noch installiert ist, weiß nur der @Commerzpunk

So...das habe ich alles in 15 Minuten Google herausgefunden ;).

Was hier stand, war zumindest teilweise nicht angebracht - sorry.

Neutral geschrieben nur so viel - solange es nicht ganz klar ist, in welcher Weise interne Systeme auch betroffen sind die "... Externe Daten verarbeiten ..." ist Vorsicht fürs erste nicht verkehrt.

Zitat von buers

Auf den Hinweis, dass hat auch "interne Systeme" (kommt u.a. vom BSI) betroffen sind, wiegeln die hier respektierten Teilnehmer @DaVu und @darkside40 ab.

Tun wir nicht. Was bitte ist dein Problem?

Ich verweise aber gern auf den von dir verlinkten Text:

https://www.bsi.bund.de/SharedDocs/Cyb…icationFile&v=8

Zitat

Im Gegensatz zur ursprünglichen Einschätzung kann die kritische Schwachstelle ggf. auch auf internen Systemenausgenutzt werden, sofern diese externe Daten entgegennehmen oder verarbeiten.

Ich glaube du missverstehst das "entgegennehmen oder verarbeiten" von "externen Daten". Vielleicht verstehe ich es auch falsch. Dann klär mich auf. Ich bin ganz Ohr. Die Schwachstelle wird nicht durch einen Browser ausgelöst. Es sei denn, du hast eine Java-Applikation laufen und der Browser schreibt Logdaten in diese Java Anwendung die Log4j verwendet.

Log4j wird auf Servern eingesetzt die Java-Applikationen betreiben. Wenn du mit deinem Browser irgendwo drauf klickst, wird erstmal gar nichts passieren. Sind wir uns da einig oder nicht?

Ich würde dir gern den unterschied zwischen "internen" und "externen" System näher bringen, so wie ich sie verstehe....

Nehmen wir an du hast eine Anwendung, die du betreibst. Egal was. Das ganze betreibst du z. B. in der Azure. Die Anwendung selbst ist extern erreichbar und nimmt Usereingaben entgegen und schreibt Logs. Diese Logs werden an einen Graylog (zentrale Logginstelle, damit ich nicht jeden Node meiner HA-Anwendung orchestriert mit Kubernetes auf 8 Nodes mit etlichen Replicas kontrollieren muss) weiter gegeben. Diesen Graylog erreichst du aber nur wenn du dich selbst in einem gewissen CN (Corporate Network meist eine VPN Verbindung) befindest. Es besteht aber durch Firewallregeln eine Kommunikation zwischen der externen Anwendung und dem internen Graylog. Sollte in der Anwendung nun etwas abgesetzt werden, was entsprechend prepariert wurde und der Graylog genau das logt (Graylog war auch betroffen übrigens), dann nimmt das interne System externe Daten entgegen, verarbeitet diese ggf und die Lücke wird ausgenutzt.

Jetzt geht es noch weiter....der Graylog kann seine Daten in eine ElasticSearch schreiben. Das ist sogar ziemlich gängig. Beide Systeme (Graylog und Elastic) waren (und sind) in gewissen Versionen angreifbar. Selbst wenn also der Graylog gefixt ist, die Daten aber in die Elastic geschrieben werden, können sie dort immer noch geparst, verarbeitet und die Schwachstelle ausgenutzt werden. Die Elastic ist also ein "internes System" eines internen Systems . Oder aus der Sicht der Elastic ist der Graylog das "externe" System. Die Elastic selbst hat in dem Fall keinerlei Verbindung zur eigentlichen Applikation. Sondern nur zum Graylog. Man muss also natürlich auch diese Systeme fixen.

So viel zum meinem Verständnis wie "interne" und "externe" Systeme auch gemeint sein kann. Das ist übrigens mein täglich Brot. Ich mag an einigen Stellen das Problem vielleicht noch nicht komplett durchdacht zu haben und da lasse ich mich auch gern aufklären. Aber auf dem Baum wohne ich diesbezüglich auch nicht.

Und das alles hat, meiner Meinung nach, nichts damit zu tun, dass ich zu Hause einen Server habe und ich mich mit meinem normalen PC im Internet bewege solange dieser Server nicht von extern (dem Internet) erreichbar ist. Mein Server und die entsprechende Java-Applikation darauf, müsste eine Anfrage nach von innen nach draußen stellen und die Antwort müsste dann entsprechend prepariert sein, damit da was ausgelöst wird. So wäre es möglich. Da gebe ich dir Recht. Aber wie wahrscheinlich ist das? Das ist eine ernstgemeinte Frage und ich hoffe auf eine ernstgemeinte Anwort.

Zitat von buers

dass da eine neue Lücke aufgegangen ist. Dass "Externe Daten" (Zitat BSI), die früher halt kein Problem darstellten, nun eine neue Sicherheitslücke ausnützen?

Die Lücke ist immer noch die gleiche. Wo man vielleicht neue Erkenntnisse bekommen hat ist der Trigger wie man die Lücke ausnutzen kann. Das ändert aber nichts an der Sicherheitslücke. Die ist gleich geblieben. Das BSI hat nur verstanden, dass Host-Systeme auch angreifbar sind, wenn nur die Gast-Systeme erreichbar sind. Beispiel Hypervisor (ESXi, Proxmox....) und VM. Je nachdem, was das Host-System loggt und wie. Gerade bei Hypervisoren (ist der Plural so richtig?!...hm...egal), die loggen Dinge ohnehin noch ganz anders als ein Handelsüblicher PC und deren GUI kann auch Java beinhalten.

Natürlich kann ich auch eine Java-Applikation auf meinem Rechner haben, die eine Anfrage ans Internet stellt. Da sollten wir aber auch mal überlegen, was das für Anfragen sein sollen und wohin diese gestellt werden. Nehmen wir mal das hier:

https://github.com/MarcoFleres/tinyMediaManager

Komplett geschrieben in Java. Keine Ahnung obs verwundbar wäre oder nicht. Ist auch schnuppe. Auf jeden Fall kann diese Anwendung Anfragen nach außen senden. Das halt an gewisse Stellen. Diese Stellen bzw. die Antworten die diese Stelle sendet, müssten dann schon so prepariert sein, damit da was passiert. Wie wahrscheinlich ist das? Oder anders gefragt, welche Java Anwendung greift random irgendwelche Strings von irgendwelchen dubiosen Webseiten ab? Da würde ich überlegen, was die Anwendung überhaupt soll.
Jetzt können wir uns auch gern noch den anderen Weiten des Hackens widmen, wie MITM wo ich mich zwischen die Empfängerstelle und den Anfrager setze und die Antwort verändere. Wenn wir da hin wollen, dann ist es vielleicht besser wir gehen alle direkt offline

Zitat von buers

Alphatiere und Meinungsmacher

Spar dir das bitte nur weil dir gerade mal nicht jeder zustimmt. @darkside40 hat nur seine Einschätzung abgegeben. Selbiges mache ich auch. Du gibst halt deine ab. Auf den, im Zorn geschriebenen, Rest gehe ich mal gerade nicht weiter ein, da das das Niveau nur noch weiter senken würde, was ich sehr schade fände. Also lass uns entweder wie Erwachsene unterhalten oder besser gar nicht.

Ich weiß gerade nicht, warum du so pissig reagierst.

Und bevor noch die Frage aufkommt, wie das mit Android-Geräten aussieht und den Java-Applikationen darauf....

Android selbst nutzt kein Log4j sondern was selbst-implementiertes. Weiter laufen Java-Apps in Android unter ihrem eigenen User in ihrere eigenen Umgebung. Aus dieser können sie (vielleicht) austreten, wenn der User das erlaubt (App "blabla" möchte Zugriff auf Fotos und Videos haben - Ja/Nein). Da kommt es dann wieder auf den Menschenverstand an.

Es ist möglich log4j in Android Applikationen einzubinden:
https://stackoverflow.com/questions/2823…g4j2-on-android

Dennoch laufen diese Applikationen dann immer separiert.

Hier noch ein Link zu Android und dessen Verwundbarkeit in Bezug auf Log4j:
https://android.stackexchange.com/questions/2432…t-android-users

Diese Antwort finde ich übgrigens sehr gut.

@buers "Alphatiere", "Meinungsmacher"? Schlechten Tag gehabt?

Das meiste hat @DaVu von deinen Dockern oben schon ja aufgedröselt. Da ist also nichts bei was direkt problematisch wäre.
Ich habe mir mein Netzwerk auch mal angeschaut und der einzige Dienst (bei dem ich was machen kann) war bei mir Booksonic Air.

Kurz ins Github Repo geschaut, gab vor drei Tagen nen Update für die Log4J Komponente darin, Docker Container geupdated, sollte jetzt safe sein. Falls da überhaupt wirklich ein Gefahr bestand. Denn der Docker ist nicht aus dem Internet bei mir erreichbar.

Der einzige andere Dienst der bei mir noch die verwundbare Komponente haben könnte ist Homematic das ich hier als Debmatic laufen habe, aber das ist Closed Source.

Zitat von Commerzpunk

Bei sowas habe ich leider keine Ahnung, das läuft halt alles in Docker Containern auf UnRAID.

Das ist ja kein Problem

Und bitte....fühl dich nicht angeklagt. Offen zu sagen "Ich hab keine Ahnung, das macht alles die GUI und ich mache mir sorgen. Bitte helft mir" ist keine Schande. Im Gegenteil

Ich habe heute Morgen nur zu wenig Zeit um dir das ausführlich zu erklären. Das mache ich heute Nachmittag. Bis dahin könntest du aber die Frage, ob dein Server von außen erreichbar ist, beantworten

Das mache ich jetzt in einem separaten Post, weil ich es wichtig finde.

Das ist eine neue Lücke: https://cve.mitre.org/cgi-bin/cvenam…=CVE-2021-45046

Diese macht den oben erwähnten Hotfix mit: -Dlog4j2.formatMsgNoLookups=true obsolet. Lösungswege sind in dem CVE beschrieben.

@Commerzpunk Das ist nichts, was dir mehr Sorgen machen muss

Naja Nextcloud z.B. macht recht wenig sinn wenn die nicht von aussen erreichbar ist