[Java] RCE 0-day exploit found in log4j lib

[foo_1337]

Hier ist die ganze Geschichte schön grafisch aufbereitet: https://twitter.com/GovCERT_CH/status/1470097783407398928/photo/1

 

[Hannibal Smith]

@Falc410 aber das ist ja dann schon die ganze Zeit so und ohne Internetzugriff ist die direkte Gefahr einer Kompromittierung zumindest nicht gegeben. Wenn jemand im Netz sitzt, hat man wahrscheinlich nicht nur dieses Problem

 

[Skysnake]

Warum sollte man dadurch geschützt sein. Am Ende reicht es doch wenn ein bösartiger User irgendwie an das System kommt. Es gab zu 2.x ja auch das Update, das auch offline Systeme bedroht sind, da man keine Gadgets etc braucht, sondern alles komplett selbst in der Anfrage mitliefern kann.

Die Systeme sind also GameOver sobald erreichbar für Logging durch einen bösartigen User.

Es gibt von RedHat auch ein CVE zu 1.x ich würde daher nicht wirklich sagen, das man mit 1.x "sicher" wäre. Ich sehe aktuell eher, das nur 2.15 safe ist und alles andere nicht. Das wird echt noch spannend die nächsten Tage/Wochen...

access.redhat.com/security/cve/CVE-2021-4104

 

[foo_1337]

1.x ist potentiell betroffen, wenn JMS Appender genutzt werden

 

[Skysnake]

Und wie findet man das raus?

 

[foo_1337]

Leider nur in der log4j Konfiguration der app. Das sieht z.B. so aus:
log4j.rootLogger=INFO, stdout, jms
log4j.appender.jms=org.apache.log4j.net.JMSAppender
log4j.appender.jms.InitialContextFactoryName=org.apache.activemq.jndi.ActiveMQInitialContextFactory
log4j.appender.jms.ProviderURL=tcp://localhost:61616
log4j.appender.jms.TopicBindingName=logTopic
log4j.appender.jms.TopicConnectionFactoryBindingName=ConnectionFactory

 

[Skysnake]

Na toll... lsof ist keine Option?

 

[Goodfred]

Danke für die Antworten,
noch mal kurz eine Frage: Wie finde ich heraus ob auf einem Windows (Server) System log4j installiert ist?
Ich suche schon seit einer Weile und finde nichts dazu.
Schon mal Danke für die Antwort!

 

[Bob.Dig]

Ich suche schon seit einer Weile und finde nichts dazu.
Schon mal Danke für die Antwort!

Hättest Du, statt dich extra dafür hier anzumelden, auf heise geguckt, dann hättest Du schon eine Lösung... 😉

 

[Goodfred]

Hättest Du, statt dich extra dafür hier anzumelden, auf heise geguckt, dann hättest Du schon eine Lösung... 😉

Dann werde ich wohl noch mal genauer auf heise schauen, habe ich wohl gekonnt überlesen. Danke!

Nachtrag: Wie gesagt, gekonnt überlesen. Ich dachte eher an etwas das Systemweit prüft ob die Library vorhanden ist. Das im Artikel verlinkte Tool kannte ich schon von der alten Version. Die neue ist etwas komfortabler anscheinend. (die vor ca. 3h erschienen ist) Man muss leider Java Programme angeben die es überprüft, ist aber immerhin besser als gar nichts!

Nachtrag 2: Mir gefällts hier bis jetzt - ich denke ich schaue immer wieder mal rein!

Nachtrag 3: Nach den nächsten 3 Posts habe ich mir gedacht das ich bereits gesagt habe, mir gefällt es hier bis jetzt!

 

[Ranayna]

Uff, ich bin grade ueber eine Info gestolpert, die insbesondere angesichts der doch gehaeuften Hacks der letzten Monate interessant sein duerfte.
Die Log4J Luecke soll wohl schon mehr als 6 Monate bekannt sein, inklusive Exploit-Code in diversen Githubs.

 

[Falc410]

Uff, ich bin grade ueber eine Info gestolpert, die insbesondere angesichts der doch gehaeuften Hacks der letzten Monate interessant sein duerfte.
Die Log4J Luecke soll wohl schon mehr als 6 Monate bekannt sein, inklusive Exploit-Code in diversen Githubs.

Ja das entsprechende Chinesische git Repo haben wir ebenfalls am WE entdeckt Man kann immer davon ausgehen, dass auch bei einem 0-Day schon einige Leute vorher davon gewusst haben und das ausgenutzt haben. Ist ja bei Geheimdiensten "normal".

Aber ob jetzt tatsächlich schon 6 Monate lang log4j ausgenutzt worden ist....das Problem ist halt, sobald man so etwas macht, ist die Gefahr da, dass man entdeckt wird und die Schwachstelle damit behoben wird. Wenn das massiv 6 Monate lang ausgenutzt worden wäre, wäre es schon früher aufgefallen. Aber ist trotzdem ein bisschen mysteriös denn das github repo lässt darauf schließen, dass der PoC Code schon ein paar Monate alt ist.

edit: korrigiere, 9 Monate https://github.com/nice0e3/log4j_POC

 

[Skysnake]

Autsch..

Btw etwas Entwarnung zu log4j 1.2. Der von mir gepostete CVE mit JSMAppender ist wohl noch zwingend vorhanden, da log4j 1.2.x das wohl noch nicht drin hat per default. JSMAppender kam erst mit log4j2 rein soweit ich das in den unterschiedlichen Branches richtig gesehen habe....

Die Latte an Anwendungen ist aber schon heftig. Gerade das auch ELK etc betroffen sind.

 

[###Zaunpfahl###]

Ich schreibs hier nochmals da ich denke das es für mehrere interessant sein könnte.
-------------------
Hab ein tolles tool gefunden. Wie das genau funktioniert ist mir noch nicht ganz klar aber auf alle Fälle hilfreich. (In einem Fall findet er erst etwas in der fat jar)
https://github.com/anchore/grype

Wenn man die executeable hat einfach grype path/to/project/or/jar machen

 

[Tanzmusikus]

Also mein Kollege hat seinen Scanner über den Haufen geworfen und verweist auf diesen hier: https://github.com/hillu/local-log4j-vuln-scanner

Habe gerade mal diesen Scanner über einige meiner Partitionen laufen lassen.
local-log4j-vuln-scanner.exe C: D: E: usw.

Holla, da kommt Einiges zum Vorschein: MediathekView (Java-basierend nutzt log4j.jar), CD von Röntgenaufnahmen o.ä. (nutzt log4j.jar), Slay the Spire "desktop-1.0.jar" -> besitzt 3 "JndiManager*.class"es.

Jetzt sollte ich vielleicht besser MediathekViewWeb.de (falls die überhaupt sicher davor ist) nutzen statt der Java-basiernden App.

Edit:
Ich muss mich korrigieren: Der log4j-vuln-scanner hatte den Fund auf meiner Win7-Partition angezeigt.
Dort ist eine nicht-aktuelle Version mit zwei Dateien von 2018 enthalten: "log4j-api-2.8.1.jar" und "log4j-core-2.8.1.jar".
Diese beiden Dateien habe ich auf meiner Win10-Partition gar nicht, vermutlich weil die entsprechende Option hier nicht aktiviert ist. Also alles halb so wild.
Und solange die Kommunikation per HTTPS läuft, sollte das auch bei der Win7-Version nicht gefährlich sein.

@Goodfred
Wäre der Scanner nicht etwas für Dich? 😉

Grüße

 

[Skysnake]

Ah.. das mit log4j 1.2 ist echt hässlich, weil jeden wohl halt doch drin ist. Irgendwie werde ich das Gefühl nicht los, dass da noch was kommt....

 

[Cl4whammer!]

Sry die zwischenfrage, sind davon auch diese ganzen java runtime /development kits dinger betroffen die man sich auf einem Windows Client installieren kann?

 

[foo_1337]

In JRE/JDK ist kein log4j enthalten. Das bringt die app mit.

 

[Gamefaq]

In JRE/JDK ist kein log4j enthalten. Das bringt die app mit.

Was bedeutet das bringt die App mit?

Als Laie fragt man sich nun ob man eventuell selber davon betroffen sein könnte entweder am PC oder zb. als Nutzer eines QNAP oder Synology NAS. Persönlich meide ich seit Jahrzehnten privat JAVA wie die Pest weil es eben wie die Pest ist, eine Seuche die schon immer von extrem vielen Sicherheitslücken betroffen war (ähnlich wie Adobe Flash...). Sprich es wird nur Software genutzt die nicht Java als Unterbau nutzt. Nur was ist eben mit den NAS? Ich weis es gibt JRE als APP dafür? Daher ist dein Satz nun ein Wiederspruch in sich da dort JRE eine optionale App für den NAS ist wenn andere Software aka App des NAS sie benötigt.

Aber auch generell würde mich interessieren ob die auf Linux basierenden Betriebssysteme von QNAP oder Synology irgendwo log4j abseits der JRE App nutzen?

 

[foo_1337]

Naka, es bedeutet, dass das log4j jar File (gezippte class files + Beilagen) die jeweilige Java Applikation mitbringt. Egal ob es eine Server- oder Clientapplikation bzw eine Desktop App ist. Es ist ein Individuelles Thema. JRE ist nur die Runtime.