Schwerwiegende Log4Shell Sicherheitslücke in der Log4j Java Bibliothek - Synology ist nicht betroffen

Ulfhednir · 14. Dez 2021

Man sollte sich hier wirklich die Zeit nehmen. Insbesondere wer Docker-Anwendungen verwendet, sollte sich die Mühe machen.
Nicht selten werden Docker-Images nicht mehr gepflegt.

xDreaM · 14. Dez 2021

was ist mit den Applikationen, die auf NodeJS zugreifen? Beispielsweise Synology Calendar?

tproko · 14. Dez 2021

NodeJs ist ja javascript? Hat also nichts mit Java Anwendungen zu tun.

ebusynsyn · 14. Dez 2021

Hallo

Ich weiss jetzt nicht genau an wen ich mich wenden soll. Darum erlaube ich mir mal hier ein paar Zeilen zu formulieren. Meine beiden Synology sind offenbar nicht betroffen. Das habe ich verstanden.

Es laufen aber 2 Anwendungen im Docker. Was ist damit?

Generell ist mein Heimnetzwerk von Aussen nur via VPN erreichbar. Im Router sind keine Port geöffnet/weitergeleitet. Muss/kann ich irgendwelche Massnahmen umsetzen um meine Infrastruktur etwas besser zu schützen?

tproko · 14. Dez 2021

Macht sonst einen eigenen Faden damit auf.
vpn ist schon mal gut.

Ad docker: das kommt darauf an, welche docker images du da am Laufen hast. Mit java? Dann können sie betroffen sein. Aber such einfach nach log4j vulnerbility und einem Image Namen.

tommytom79 · 15. Dez 2021

Hallo!

Seit heute fällt mir auf, dass ich eine höhere CPU Auslastung habe, sie schwankt immer so von 20 bis 60 %. Kann es mit diesem Problem etwas zutun haben? Ich habe DSM 7 und JAVA Installer von readnoah installiert. Docker habe ich nicht installiert.

Danke und

LG
Thomas

AndiHeitzer · 15. Dez 2021

tommytom79 schrieb:
Ich habe DSM 7 und JAVA Installer von readnoah installiert.

Ich habe meine Kisten wie folgt durchsucht:
find / -iname "*log4j*"

Das dauert zwar etwas, aber nun habe ich Klarheit ...

tommytom79 · 15. Dez 2021

Hallo!

Danke für den Tipp. Ich bin aber leider nicht ganz so fit mit den Befehlen. Wie mache ich das genau? Mittels Putty eine Verbindung zu meinem NAS als root herstellen und dann muss ich welchen Befehl eingeben?

Danke und

LG
Thomas

Uwe96 · 15. Dez 2021

Bei mir wurde nichts gefunden. Hat aber auch nur ein paar Minunten gedauert.

geimist · 15. Dez 2021

Im Prinzip, ja.
Verbindung auf das NAS als ein admin und dann mit sudo -i zu root wechseln. Anschließend den Befehl absetzen und die Ergebnisse (= Suchtreffer) abwarten.

Wenn man die Benutzerbereiche ausschließt, sollte diese Suche bedeutend schneller gehen (volume-Namen ggf. anpassen):
find / \( -path /volume1 -o -path /volume2 \) -prune -o -iname "*log4j*"

PS:

Treffer gab es bei mir in jitsi-videobridge (wurde im Container / Image gefunden. jitsi läuft aber aktuell nicht bei mir).

pottypott · 15. Dez 2021

Wenn ihr den Unifi Controller im Docker nutzt, dann müsst ihr diesen zwingend auf 6.5.54 updaten. Der ist betroffen.

Zusätzlich solltet ihr schauen, wenn ihr einen Minecraft Server laufen habt. Habe den im Docker und da schwanken die Aussagen:
1.18 sollte sicher sein, allerdings gehen die Meinungen auseinander.
1.18.1 enthält wohl defintiv einen Sicherheitspatch

Das ist zumindest der Senf, den ich dazugeben kann.

tommytom79 · 15. Dez 2021

Hallo geimist!

Danke für den Code. Ich habe es jetzt genau so gemacht, wie du geschrieben hast. Nach Betätigen der Enter Taste hat er gleich unter dem Befehl "/volume2" und "/volume1" geschrieben. Nach einer halben Minute hat er mir dann wieder die grüne Kommandozeile angezeigt.
Heißt das jetzt, dass die Suche durchgeführt wurde und nichts gefunden wurde?

Danke und

LG
Thomas

DKeppi · 15. Dez 2021

pottypott schrieb:
Wenn ihr den Unifi Controller im Docker nutzt, dann müsst ihr diesen zwingend auf 6.5.54 updaten. Der ist betroffen.

jacobalberty hat auch einige alte Unifi Images aktualisiert, zB 6.0.45

https://github.com/jacobalberty/unifi-docker/issues/494

pottypott · 15. Dez 2021

Ach super, OK. Ich war auf 6.0.23 und bin jetzt einfach auf die 6.5.54 gegangen. Ich kann bis jetzt nichts negatives feststellen. Aber je nach Umfang der Infrastruktur sicher interessant für den ein oder anderen

DKeppi · 15. Dez 2021

Hatte da irgendwie immer Probleme mit meinem Setup ab Controller Version 6.1.xx.
Bin auch immer noch auf den 4.x.xx Firmwares der Devices, da irgendwie bei den 5.x.xx auch Probleme auftraten - Wireless Uplink wurde langsamer, etc.

Evtl. sollte ich es nochmals versuchen...ziehe eh bald um, dann wärs vielleicht an der Zeit

tommytom79 · 16. Dez 2021

Hallo!

Ich wollte nur noch einmal nachfragen, ob ich alles richtig gemacht habe und das Verhalten meiner DS richtig ist, so wie ich es im Post #13 geschrieben haben?

Danke und

LG
Thomas

Huhie · 16. Dez 2021

Moin Zusammen,

ich bin gerade darüber gestoplert, das mein WLAN per Unifi nicht mehr Ordnungsgemäß funktioniert

Ich habe auf meiner DS920+ im Docker einen Unifi Controller laufen und haben den vorgestern aktualisiert. Per heute Nacht ist es so,
das ich keine WLAN Verbindung mehr aufgebaut bekommen habe. Die vergebenen IP Adressen sind nicht aus meinem DHCP Bereich
und somit kein Internet dahinter...

Ich habe den Befehl "find / -iname "*log4j*"" abgesetzt und bekomme aus dem Unifi Docker Container logs zu sehen, wo "log4j" Infos
drinne stehen. Somit bin ich wohl infiziert

Unifi habe ich vorerst offline genommen.

Mir stellt sich die Frage, was ich nun am besten mache?
Unifi Controller komplett löschen und neu aufsetzen?
Was ist mit den Dateien in meinem Netzwerk? Kann ich die irgendwie checken?

Ports sind durch die Fritz!Box nur 3Stück offen?

Kann mir da jemand helfen oder Rat geben?

starpvtpaula · 16. Dez 2021

Mach dazu einen eigenen Thread auf aber du solltest nicht "infiziert" sein sondern das sagt nur das der Docker Unifi diese Bibliothek nutzt. Bei mir genauso aber jenachdem welches Image du nutzt kannst du einfach updaten.

DKeppi · 16. Dez 2021

Auf welcher Version warst du?
Es gibt bereits 6.5.55 die noch eine Lücke schließt.
Jacobalberty hat manuelle fixes in die Docker Images gelegt, ua. auch bei Version 6.0.45 und anderen
https://github.com/jacobalberty/unifi-docker/issues/494

Du hast doch sicher auch eine Firewall von Unifi oder?
Ist da das Thread Management aktiv - IPS oder nur IDS?

Ich habe ständig solche Einträge die bei mir durch IPS autom. blockiert werden:
Threat Management Alarm 1: Attempted Administrator Privilege Gain. Signatur ET EXPLOIT Apache log4j RCE Attempt (tcp ldap) (CVE-2021-44228). Von: 142.93.18.229:54514, auf: 192.168.178.23:80, Protokoll: TCP

Vermute mal stark dass es eher an der Unifi Controller Version oder an einer neuen Firmware liegt, dass DHCP bzw. WLAN nicht mehr geht.
Der Grund warum ich immer noch auf 6.0.45 bin und 4.x.xx Firmwares....die releasen nur Bug behaftetes zZ

Ich finde bei mir mit

Code:

find / -iname "*log4j*"

im Container folgendes:

Code:

/usr/lib/unifi/lib/log4j-api-2.13.3.jar                                                                                                                     
/usr/lib/unifi/lib/log4j-core-2.13.3.jar                                                                                                                   
/usr/lib/unifi/lib/log4j-slf4j-impl-2.13.3.jar                                                                                                             
/usr/lib/unifi/lib/tomcat-embed-logging-log4j-8.5.2.jar

Schwerwiegende Log4Shell Sicherheitslücke in der Log4j Java Bibliothek - Synology ist nicht betroffen

Es ist eine der schwersten Sicherheitslücken, die es je gab! Das BSI bewertet die Bedrohungslage mit rot, was nicht sehr häufig vorkommt.​

Da die Sicherheitslücke so weitreichend ist solltet ihr unbedingt eure komplette IT prüfen, ob andere Systeme betroffen sind.​

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Benutzer

Kaffeautomat

Es ist eine der schwersten Sicherheitslücken, die es je gab! Das BSI bewertet die Bedrohungslage mit rot, was nicht sehr häufig vorkommt.

Da die Sicherheitslücke so weitreichend ist solltet ihr unbedingt eure komplette IT prüfen, ob andere Systeme betroffen sind.