XF2.2 log4j - einer muss es ja mal ansprechen...

otto

otto

Die 5k-Labertasche
Lizenzinhaber
Registriert
11. Dez. 2010
Beiträge
5.516
Punkte
448
XF Version
  1. 2.2.15
XF Instanz
Hosting
PHP-Version
8.2.x
MySQL/MariaDB
10.3.x
Provider/Hoster
Strato/Hetzner
Zuletzt bearbeitet:
Kümmert mich nicht. Hab kein Apache und der ES ist von aussen nicht erreichbar.

Hatte auf der Arbeit genug damit zu tun.
 
Ja ich war auch überrascht wo der scheiß überall drin gesteckt hat.
 
Geloggt wird nur bei Bedarf, das erhöht die Laufzeit der SSDs und bringt Performance. Nutze kein ES, kein *Java* und war daher in der Sache auch ganz entspannt. :balance:
 
Hoffi schrieb:
Kümmert mich nicht. Hab kein Apache und der ES ist von aussen nicht erreichbar.
Zum Vergrößern anklicken....
Magst Du das etwas näher erläutern? Ich verstehe es nämlich ehrlich gesagt nicht wirklich:
Apache (also Apache Webserver) ist AFAIK eh nicht betroffen (da kein Java)?

Dass ein ES nicht von außen erreichbar ist heißt ja noch lange nicht dass es nicht anfällig wäre.
Ist zwar eher unwahrscheinlich, aber sollte es einem Angreifer z.B. durch eine Suche gelingen einen entsprechenden Log-Eintrag mit JNDI Lookup zu triggern, dann diese ES-Instanz ggf. angreifbar wenn diese entsprechende Verbindungen (LDAP im LAN o.ä.) aufbauen kann?
 
Kirby schrieb:
Apache (also Apache Webserver) ist AFAIK eh nicht betroffen (da kein Java)?
Zum Vergrößern anklicken....
Puh, ich meinte bei den ganzen Infos die auf mich einprasselten auch den Apache Webserver gelesen zu haben. Ich kann mich aber auch täuschen. Das war echt viel am Montag morgen.

Mein ES läuft auf einer eigenen Instanz in der AWS welche in einer Security Group mit dem Nginx läuft, und per Richtlinie nur von diesem über den einen Port angesprochen werden kann. Muss ich mal per Konsole drauf zugreifen, gebe ich ich für den Zeitraum meine IP für SSH frei.

Selbst wenn man also den Server infiziert, wird es schwierig damit was anzustellen.

Falls ich eine Lücke übersehe bin ich für einen Hinweis dankbar.
 
Hat sich mal einer - EINER ;), die Infos aus meinen Links oben durchgelesen? Da bezieht ja u.a. ES selbst Stellung und gibt zu die Bibliothek zu verwenden, aber die Art der Verwendung wird für sicher befunden.

ES war übrigens das einzige wo ich log4j über die mir bisher bekannten Suchen entdecken konnte. Das System als solches wird freilich up to date gehalten.
 
Hoffi schrieb:
Puh, ich meinte bei den ganzen Infos die auf mich einprasselten auch den Apache Webserver gelesen zu haben. Ich kann mich aber auch täuschen. Das war echt viel am Montag morgen.
Zum Vergrößern anklicken....
Also ich glaub da hast Du etwas missverstanden bzw. verwechselt:
Log4j steht unter der Apache-Lizenz, wird unter dem Dach der Apache Foundation entwickelt - aber nicht vom Apache Webserver genutzt.
Ich wüsste ehrlich gesagt auch nicht wie da ohne größere Verrenkungen technisch überhaupt möglich sein sollte, denn der Apache Webserver ist ja nicht in JAVA geschrieben sondern in C.

Bei z.B. Hadoop und Solar sieht das anders, die sind vmtl. anfällig.

Mein ES läuft auf einer eigenen Instanz in der AWS welche in einer Security Group mit dem Nginx läuft, und per Richtlinie nur von diesem über den einen Port angesprochen werden kann. Muss ich mal per Konsole drauf zugreifen, gebe ich ich für den Zeitraum meine IP für SSH frei.

Selbst wenn man also den Server infiziert, wird es schwierig damit was anzustellen.
Zum Vergrößern anklicken....
Es kommt für die Frage ob ein ES prinzipiell anfällig is ja nicht darauf an ob es direkt von außen erreichbar ist sondern ob der Prozess selbst eine Verbindung (LDAP, HTTP, etc.) zu einem vom Angreifer kontrollierten Server aufbauen kann.
Wenn das möglich ist (und das dürfte es in vielen Fällen sein), dann ist eine Ausnutzung prinzipiell denkbar.

otto schrieb:
Hat sich mal einer - EINER ;), die Infos aus meinen Links oben durchgelesen? Da bezieht ja u.a. ES selbst Stellung und gibt zu die Bibliothek zu verwenden, aber die Art der Verwendung wird für sicher befunden.
Zum Vergrößern anklicken....
Ich hab das (zum ersten mal) gelesen lange bevor Du den Thread überhaupt eröffnet hast, nämlich am 10.12.2021 gegen ca. 20h ;)

Und wie so oft: Es ist komplizierter als es auf den ersten Blick erscheint:
  • ES < 5 ist nicht betroffen da es keine der betroffenen Log4j-Versionen nutzt
  • ES 5 ist betroffen, sowohl für Leak als auch RCE
  • ES 6 und 7 sind nach eigener Aussagen nicht für RCE anfällig auf Grund der Nutzung des Java SM
    Bei älteren JVM-Versionen (< 9) aber für Leak
 
Zuletzt bearbeitet:
Kirby schrieb:
Ich hab das (zum ersten mal) gelesen lange bevor Du den Thread überhaupt eröffnet hast, nämlich am 10.12.2021 gegen ca. 20h ;)

Und wie so oft: Es ist komplizierter als es auf den ersten Blick erscheint:
  • ES < 5 ist nicht betroffen da es keine der betroffenen Log4j-Versionen nutzt
  • ES 5 ist betroffen, sowohl für Leak als auch RCE
  • ES 6 und 7 sind nach eigener Aussagen nicht für RCE anfällig auf Grund der Nutzung des Java SM
    Bei älteren JVM-Versionen (< 9) aber für Leak
Zum Vergrößern anklicken....
Also würdest du erstmal deren Einschätzung teilen - ich nutze aktuell ES 7.16.2

ps. du machst das beruflich (nehme ich mal an) ich nur neben dem Hauptjob, der mich seit Wochen 7 Tage die Woche mit 12-14h am Tag fordert. Von daher hab ich das zwar im Radio mitbekommen, aber eine adäquate Recherche war erst in den Tagen danach möglich.
 
Zuletzt bearbeitet:
otto schrieb:
Also würdest du erstmal deren Einschätzung teilen - ich nutze aktuell ES 7.16.2
Zum Vergrößern anklicken....
Ja, würde ich.

Wer noch einen Schritt weitergehen will:
Den ES Prozess (per iptables/nftables, SELinux, AppArmor, ...) daran hindern aktiv Verbindungen ("nach außen") aufzubauen - dann dürfte es reichlich schwierig werden Code von irgendwo nachzuladen (selbst wenn es da noch eine Lücke gäbe).
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben