Kenne ich genug die das nur Lokal fahren 
Log4J - was hängt da eigentlich so im Heimnetz alles dran?
-
Commerzpunk -
14. Dezember 2021 um 09:21 -
Unerledigt
-
-
Nginx Reverse Proxy (SWAG)
Gehen wir einfach mal davon aus der Server ist von aussen erreichbar. So gut kenne ich @Commerzpunk -
-
Jupps, so ist das.
Ich bin gespannt auf die Prügel denn die kommen sicherlich gleich.
Von aussen erreichbar ist, und zwar alles hinter der SWAG Instanz via Reverse Proxy und https/ssl:
* Nextcloud
* Emby
* TVH
* Syncthing
* Firefox ( < das wird einige hier viell. triggern ;)) -
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.
-
-
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. -
-
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... -
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
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.
-
-
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
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. -
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.
-
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!