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

Dieses Thema im Forum "Fehler und Probleme" wurde erstellt von otto, 17. Dez. 2021.

  1. otto

    otto Bekanntes Mitglied Lizenzinhaber

    Zuletzt bearbeitet: 17. Dez. 2021
  2. Walter

    Walter Bekanntes Mitglied Lizenzinhaber

  3. Tealk

    Tealk Bekanntes Mitglied Lizenzinhaber

    Naja genau genomme ist es keine Lücke sondern es funktioniert wie es entworfen worden ist. Hier ist das schön nachzulesen.
     
    Hoffi gefällt das.
  4. Hoffi

    Hoffi !important Lizenzinhaber

    Kümmert mich nicht. Hab kein Apache und der ES ist von aussen nicht erreichbar.

    Hatte auf der Arbeit genug damit zu tun.
     
    Tealk gefällt das.
  5. Tealk

    Tealk Bekanntes Mitglied Lizenzinhaber

    Ja ich war auch überrascht wo der scheiß überall drin gesteckt hat.
     
  6. Masetrix

    Masetrix Bekanntes Mitglied Lizenzinhaber

    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:
     
  7. Kirby

    Kirby Bekanntes Mitglied Lizenzinhaber

    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?
     
    Masetrix gefällt das.
  8. Hoffi

    Hoffi !important Lizenzinhaber

    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.
     
  9. otto

    otto Bekanntes Mitglied Lizenzinhaber

    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.
     
  10. Kirby

    Kirby Bekanntes Mitglied Lizenzinhaber

    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.

    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.

    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: 20. Dez. 2021
  11. otto

    otto Bekanntes Mitglied Lizenzinhaber

    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: 19. Dez. 2021
  12. Kirby

    Kirby Bekanntes Mitglied Lizenzinhaber

    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).
     
    Masetrix und otto gefällt das.
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren, diese deiner Erfahrung anzupassen und dich nach der Registrierung angemeldet zu halten.
    Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden