Archiv für die Kategorie: Cybersicherheit

In den Log4J Exploit Nachrichten überschlagen sich momentan die Meldungen über einen kritischen Fehler in einer Java Logging Bibliothek.

Wir haben unsere Java basierten Anwendungen geprüft und können hier vorerst Entwarnung geben:

Unsere Java Anwendungen scheinen Stand heute nicht von einem Exploit betroffen zu sein.

Betroffen von dem aktuell kursierenden Exploit ist die log4j-core Bibliothek

(vgl. https://nvd.nist.gov/vuln/detail/CVE-2021-44228)

Wir verwenden in unseren Anwendungen slf4j mit der logback Bibliothek, das lediglich die log4j API verwendet, um die Funktionalität für andere Bibliotheken bereitzustellen.

Die Log4J core Bibliothek, die angreifbar ist für den genannten Exploit, wird nicht verwendet. (http://slf4j.org/log4shell.html)

Des Weiteren wurden die angreifbaren Java Versionen für das Nachladen von Code über einen LDAP Server eingegrenzt: (vgl. https://www.lunasec.io/docs/blog/log4j-zero-day/ und https://nvd.nist.gov/vuln/detail/CVE-2021-44228)

„JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected by the LDAP attack vector. In these versions com.sun.jndi.ldap.object.trustURLCodebase is set to false meaning JNDI cannot load remote code using LDAP.”

“Java 8u121 (see https://www.oracle.com/java/technologies/javase/8u121-relnotes.html) protects against remote code execution by defaulting “com.sun.jndi.rmi.object.trustURLCodebase” and “com.sun.jndi.cosnaming.object.trustURLCodebase” to “false”.”

Genauere Informationen zu unseren Java basierten Anwendungen:

• enteliSAVE
  • Verwendet slf4j mit logback und log4j bridge, keine Abhängigkeit zu log4j-core
  • Verwendet mit Instanz Version 1.4.2 java 8u265 -> Code nicht über LDAP nachladbar
  • ActiveMQ verwendet log4j 1, das nicht von der Lücke betroffen ist
• Devicemonitor
  • Verwendet slf4j mit logback und log4j bridge, keine Abhängigkeit zu log4j-core
  • Verwendet eine veraltete Java Version, wird mit dem nächsten Update aktualisiert,
    aber da keine Abhängigkeit zum log4j-core besteht (s.o.) wird die Bedrohung als gering eingestuft
• Trendlog Manager
  • Verwendet slf4j mit logback und log4j bridge, keine Abhängigkeit zu log4j-core
  • Verwendet seit 1.7.15 java 11.0.11 -> Code nicht über LDAP nachladbar
• Dpcounter (ab 1.8.1)
  • Verwendet slf4j mit logack und log4j bridge, keine Abhängigkeit zu log4j-core
  • Hier liefern wir keine separate java Laufzeitumgebung mit
• Birt Reporting
  • Die Birt Report Engine in enteliWEB verwendet kein log4j
• enteliWEB
  • Es werden in enteliWEB keine Java basierten Anwendungen verwendet, die von dem log4j Exploit betroffen sind

Wie behalten die aktuelle Situation im Auge und nehmen sie zum Anlass, die Versionen unserer verwendeten Bibliotheken zu prüfen und zu aktualisieren.

Des Weiteren weisen wir darauf hin, dass die Modulversionen geprüft und ggf. aktualisiert werden sollten.

Sie erhalten zusätzlich aus unserer Entwicklung in Kanada ein offizielles Statement zu diesem Exploit, den sie unter dem folgenden Link aufrufen können:

https://www.deltacontrols.de/media/newsletter/log4j_vulnerability_delta_controls_statement.pdf