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

Kenne ich genug die das nur Lokal fahren

Nginx Reverse Proxy (SWAG)
Gehen wir einfach mal davon aus der Server ist von aussen erreichbar. So gut kenne ich @Commerzpunk

Da ist aber nichts bei was anfällig sein könnte, wie gesagt das sind alles keine Java Programme.
Das alles hinter einem nginx läuft würde aber auch noch die Möglichkeit einer Web Application Firewall bieten, so das nginx gleich die (meisten) Angriffsversuche herausfiltern würde.

Aber damit habe ich mich auch noch nicht beschäftigt.

Zitat von Commerzpunk

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

Verstehe ich es also richtig, dass der TVH als Docker auf deinem UnRaid läuft und du das ausm Internet verfügbar hast?

Denn UnRaid hatten wir noch gar nicht in Betracht gezogen. Aber auch da kannst du beruhigt sein. Das habe ich bei mir getestet und UnRaid scheint nicht betroffen zu sein.

Wichtig wäre halt zu wissen, welche Sachen du Installiert hast. Welche Plugins, welche Add-ons, welche Container etc. Halt wirklich ALLES!!!. Nur dann kann man eine valide Aussage treffen.

Zu den Befehlen, die du in den Containern ausführen kannst, schreibe ich nachher dennoch ne kurze Anleitung

unRaid an sich bringt kein Java mit und die GUI ist in PHP geschrieben.
Sollte also auch safe sein.

Zitat von darkside40

Schlechten Tag gehabt?

Ja, sorry für meine Wortwahl.

Ich habe gestern meine Netzwerk-/Server-Infrastruktur gecheckt:
- Meine Ubiquitiy Dream Machine Pro (UDMP) war betroffen. Update wurde vor 2-3 Tagen zur Verfügung gestellt. Eingespielt. Müsste jetzt ok sein.
- Dann habe ich meinen OMV Server gecheckt. Damit: https://github.com/Neo23x0/log4shell-detector. Der war clean.
- Und dann sämtliche Docker Container Images nach der Anleitung hier per "docker scan": https://www.docker.com/blog/apache-log4j-2-cve-2021-44228/

Einsicht: log4j ist wohl eher kein Problem in meinem System. Wenn ich mir was eingefangen habe, dann über die UDMP.
ABER: Teilweise sind meine Docker Container voll mit anderen Vulnerabilities, z.B. weil die Base Images von den zugrunde liegenden Linux Systemen sehr lange nicht mehr upgedated wurden. Beispiel: easyepg container von @dlueth. Hab dort auch ein Issue aufgemacht. Ist völlig logisch, weil Linux dauernd gepatched und gefixed wird. Aber das war mir echt nicht bewusst, dass Docker Container mit sowas Ärger machen können. Das ist nativ einfacher, wenn Du regelmässig Updates fährst. Und Watchtower und Konsorten bringen auch nichts, wenn die Base-Images der Container nicht aktualisiert werden. Wieder was gelernt...

Zitat von Commerzpunk

Zu Plugins / Addons: Wovon gehen wir aus? In Unraid? Dürfte doch egal sein, da Unraid an sich nicht nach außen offen ist, oder? Und dann jeden Docker Container mit den jeweils darin evtl. aktiven Addons?

Jetzt kommen wir wieder zum Thema "welches Szenario müsste eintreten".

Du solltest die Dinge in Betracht ziehen, die Daten von außen entgegen nehmen oder verarbeiten. Jetzt kommt es noch ein wenig auf die Definition von "entgegen nehmen oder verarbeiten". Ohne zu wissen was bei dir

Zitat von Commerzpunk

jeden Docker Container mit den jeweils darin evtl. aktiven Addons

ist, kann ich dazu keine valide Aussage machen. Man muss halt überlegen, was der Container und die darin installierten Plugins/Addons machen oder machen sollen und dann abschätzen, ob das gefährlich werden könnte.

Hier die kurze Anleitung, die ich für gestern versprochen habe, aber dann doch zu müde vom Tag war.

Wenn irgendwo ein Linux System oder ein Docker läuft. kannst du mit folgendem Befehl prüfen ob entsprechende Log4j-Pakete JARs vorhanden sind oder nicht:

find / -name "log4j*"

Auf einem Linux System (also nicht Docker) ist das ja recht einfach auszuführen. Per SSH drauf, Befehl absetzen, fertig. Ggf sollte man noch ein sudo vor den Befehl setzen wenn es das System erfordert und man nicht ohnehin schon root ist.

Wenn der Befehl was findet, dann findet er JAR-Dateien die ungefähr so heißen: log4j-core-2.11.1.jar

Da muss man dann halt die Version vergleichen und dann schauen, ob die Version verwundbar ist oder nicht.

In einem Docker kann man das ebenfalls machen....

Laufende Container auflisten: docker ps
Ganze rechts in der Ausgabe steht der Name des containers. Um sich dann mit so einem Container zu verbinden, muss man folgenden Befehl ausführen:
docker exec -it <container_name> /bin/bash oder docker exec -it <container_name> /bin/sh da manche Container die Bash nicht kennen.

Ist der Befehl erfolgreich hat man nachher wieder eine Linux-Shell. Dort kann man wieder den entsprechenden find-Befehl von oben absetzen. Diesmal sehr wahrscheinlich "OHNE" sudo

Ist man betroffen und man findet keine neuere Version, kann man sich auch mit der bestehenden behelfen. Man kann sich das Docker-Image selbst bauen und das Log4j darin selbst patchen und das JNDI aus dem Pfad raus nehmen. Wenn das von nöten ist, einfach bescheid sagen. Ich habe das gestern schon für 2 unserer Dienste machen müssen, da wir aktuell die Version nicht updaten dürfen. Ist kein Hexenwerk, wie es scheint.

Zitat von DaVu

Kenne ich genug die das nur Lokal fahren

Ich gehöre dazu. Dient bei mir primär dazu, Fotos & Co vom Handy so synchronisieren damit ich diese sichern kann. Das reicht auch, wenn ich heimkomme.

Ich würde gerne mal aufschreiben, wie ich die Funktionsweise der Sicherheitslücke verstehe

Zitat von DaVu

Du solltest die Dinge in Betracht ziehen, die Daten von außen entgegen nehmen oder verarbeiten. Jetzt kommt es noch ein wenig auf die Definition von "entgegen nehmen oder verarbeiten". Ohne zu wissen was bei dir
ist, kann ich dazu keine valide Aussage machen. Man muss halt überlegen, was der Container und die darin installierten Plugins/Addons machen oder machen sollen und dann abschätzen, ob das gefährlich werden könnte.

Wenn ich diese Sicherheitslücke richtig verstanden habe, ist alles gefährdet, was irgendwie mit diesem log4j geloggt wird.
Mögliches, evtl. auch abstruses, Angriffszenario: Medienorganisationsprogramm ähnlich emby auf Java-Basis. Zieht sich z.B. von thetvdb Medieninformationen. Mit log4j wird da fleissig mitgeloggt. Evtl. - weil evtl. falsch eingestellt oder Bug - im Debug-Mode bei dem auch die Daten die von thetvdb reinkommen mitgeloggt werden. Also müsste ein evtl. Hacker "nur" in den Medieninformationen zu der Mediendatei die gerade eingelesen wird die entsprechenden Befehle unterbringen und zack hat er bei mir seine Backdoor installiert die er erst in Wochen/Monaten in Betrieb nimmt.

Zitat von da_user

Mögliches, evtl. auch abstruses, Angriffszenario: Medienorganisationsprogramm ähnlich emby auf Java-Basis. Zieht sich z.B. von thetvdb Medieninformationen. Mit log4j wird da fleissig mitgeloggt. Evtl. - weil evtl. falsch eingestellt oder Bug - im Debug-Mode bei dem auch die Daten die von thetvdb reinkommen mitgeloggt werden. Also müsste ein evtl. Hacker "nur" in den Medieninformationen zu der Mediendatei die gerade eingelesen wird die entsprechenden Befehle unterbringen und zack hat er bei mir seine Backdoor installiert die er erst in Wochen/Monaten in Betrieb nimmt.

Richtig. Das wäre der Fall, wenn die Antwort manipuliert werden würde. Du sagst es aber schon selbst, dass das ziemlich abstrus ist. Es ist nicht 100% ausgeschlossen, aber es wäre eine Möglichkeit. Dann würde es auch nur von rein "internen" (also privat im eigenen Netz) rein theoretisch möglich sein. Die Frage ist halt eben nur, wie wahrscheinlich ist das? Und wir können uns sicher sein, dass irgendein Scraper nicht irgendeine Random-Seite abgrast, die ich nicht selbst eingestellt habe.