Mildern Sie die Apache Log4j2 JNDI-Sicherheitslücke in Jitterbit Harmony

Zusammenfassung

Auf dieser Seite werden die Apache Log4j2-Sicherheitslücken zusammengefasst, ihre Auswirkungen auf Jitterbit-Produkte beschrieben und erklärt, wie die Sicherheitslücken behoben wurden.

Entdeckung von Schwachstellen

Am 9. Dezember 2021 wurde eine kritische Zero-Day-Sicherheitslücke von Apache offengelegt, das Apache Log4j2 betrifft (CVE-2021-44228). Eine weitere damit verbundene Schwachstelle wurde von Apache am 14. Dezember 2021 offengelegt (CVE-2021-45046).

Schadensminderung für private Agenten

Am 16. Dezember 2021 führte Jitterbit eine Notfallwartung durch, um die Apache Log4j2-Sicherheitslücken zu beheben.

Nach Abschluss der Wartung am 16. Dezember 2021 um 17:00 Uhr PST (17. Dezember 2021 12:00 Uhr AEDT; 17. Dezember 2021 02:00 Uhr MEZ; 17.12.2021 01:00 UTC) müssen Sie die folgenden Schritte ausführen, damit das Update wirksam wird:

1. Auf jedem privaten Agenten müssen Sie alle JAR-Dateien manuell löschen von <JITTERBIT_HOME>/Connectors. (Ausgenommen hiervon sind alle JAR-Dateien für Konnektoren, die Sie lokal installiert haben.)
2. Jeder private Agent muss neu gestartet werden.
3. Führen Sie einen Operation aus, bei dem jeder Connector verwendet wird, oder testen Sie jede Verbindung für jedes Connector-JAR auf dem Agenten.

Wenn Sie nach Abschluss der Wartung nicht alle oben genannten Schritte in dieser Reihenfolge ausgeführt haben, tun Sie dies umgehend, um Ihr Unternehmen vor diesen Sicherheitslücken zu schützen.

In einer früheren Version dieser Seite wurden Benutzer nur angewiesen, private Agenten neu zu starten. Das Neustarten privater Agenten ist für die meisten Konnektoren wirksam. Für einige Konnektoren ist es jedoch erforderlich, alle Schritte auszuführen. Wir empfehlen, alle JAR-Dateien im Connectors Verzeichnis, um sicherzustellen, dass Sie vor diesen Schwachstellen geschützt sind. Sie können überprüfen, ob Sie geschützt sind, indem Sie nach log4j in allen Dateinamen und Überprüfen der Log4j-Version wie unten beschrieben.

Bisherige Problemumgehung für private Agenten

Vor dem 16. Dezember 2021 wurde auf dieser Seite vor der Notfallwartung bereits ein Workaround zur manuellen Behebung der Schwachstellen veröffentlicht. Dieser Workaround ist für keine privaten Agentenversionen mehr erforderlich.

Wenn Sie den Workaround bereits durchgeführt haben, müssen Sie ihn nicht rückgängig machen. Wenn Sie private Agenten seit Abschluss der Notfallwartung nicht neu gestartet haben, sollten Sie die Agenten neu starten, damit sie das Update für die Notfallwartung erhalten. In Bezug auf diese Schwachstellen werden keine weiteren Maßnahmen außer dem Neustart empfohlen.

Was sind die JNDI-Schwachstellen von Apache Log 4j2?

Aus der NIST National Vulnerability Database CVE-2021-44228:

Apache Log4j2 \<=2.14.1 JNDI-Funktionen, die in Konfiguration, Protokollnachrichten und Parametern verwendet werden, schützen nicht vor von Angreifern kontrollierten LDAP und anderen JNDI-bezogenen Endpoints. Ein Angreifer, der Protokollnachrichten oder Protokollnachrichtenparameter kontrollieren kann, kann beliebigen Code ausführen, der von LDAP -Servern geladen wurde, wenn die Nachrichtensuche-Ersetzung aktiviert ist. Ab Log4j 2.15.0 ist dieses Verhalten standardmäßig deaktiviert.

Eine damit verbundene Schwachstelle ist CVE-2021-45046, das eine Sicherheitslücke in der Log4j 2.15.0-Bibliothek beschreibt. Beide Sicherheitslücken werden hier behandelt und behoben.

Welche Jitterbit-Produkte waren von den Sicherheitslücken betroffen?

Diese Schwachstellen beschränkten sich auf Integration Studio Konnektoren erstellt mit dem Integration Studio Connector-SDK ("Integration Studio Connector SDK-Konnektoren").

Da Konnektoren normalerweise nicht als eigenständige Jitterbit-Produkte betrachtet werden und auf einem Jitterbit-Agenten ausgeführt werden müssen, sind einige Erläuterungen erforderlich, um die Auswirkungen und Minderungsmaßnahmen zur Behebung dieser Schwachstellen zu erläutern:

• Was ist an Integration Studio Connector SDK-Connector?
  Integration Studio Connector SDK-Konnektoren sind Konnektoren, die mit dem Integration Studio Connector-SDK. Sie umfassen derzeit bestimmte Konnektoren, die von Jitterbit oder einem Drittanbieter erstellt wurden:
  • Jitterbit: Die meisten der aktuellen Integration StudioAnwendungskonnektoren wurden mit dem Connector SDK erstellt. Ausnahmen sind die Konnektoren NetSuite, Salesforce, Salesforce Service Cloud, SAP und ServiceMax, die nicht mit dem Connector SDK erstellt wurden und nicht betroffen sind. Siehe die vollständige Liste unten der von diesen Sicherheitslücken betroffenen Jitterbit-Konnektoren. Zukünftige Konnektoren, die von Jitterbit mithilfe des Connector SDK erstellt werden, werden davon nicht betroffen sein.
  • Drittanbieter: Da das Connector SDK öffentlich verfügbar ist, um Integration Studio Konnektoren, Ihre Organisation verwendet möglicherweise zusätzliche Konnektoren, die mit dem Connector SDK von einem Partner oder Dritten erstellt wurden und ebenfalls von diesen Sicherheitslücken betroffen sein können. Bitte wenden Sie sich an den Anbieter dieses Konnektors, um festzustellen, ob er seinen Konnektor überprüft und ggf. korrigiert hat.
• In welcher Beziehung stehen diese Konnektoren zu Agenten?
  Die neueste Version von an Integration Studio Der Connector-SDK-Connector wird bei Bedarf von einem Jitterbit-Agenten von Harmony heruntergeladen, wenn Sie den Connector verwenden.
• Welche Agenten waren betroffen?
  Jeder Cloud- oder private Agent, der verwendet wurde an Integration Studio Der Connector SDK-Connector war von den Schwachstellen betroffen, da die Apache Log4j2-Bibliothek heruntergeladen und auf dem Agenten verwendet wurde, um Protokolle zu schreiben, während der Connector verwendet wurde.
  • Cloud-Agenten: Auf Cloud-Agenten hat Jitterbit diese Schwachstellen sofort durch entsprechende Sicherheitskontrollen behoben. Es sind keine weiteren Maßnahmen erforderlich.
  • Private Agenten: Auf privaten Agenten wurden Kunden vor der Notfallwartung am 16. Dezember 2021 angewiesen, die zuvor dokumentierte Problemumgehung zu befolgen, um diese Schwachstellen zu beheben.

Diese Jitterbit-Produkte waren nicht betroffen:

• Agenten, die noch nie verwendet wurden an Integration Studio Connector-SDK-Connector: Nicht betroffen.
• Jitterbit Design Studio (und seine Konnektoren): Nicht betroffen.
• Jitterbit Harmony Cloud: Nicht betroffen.
• Jitterbit eiCloud: Nicht betroffen.

Jitterbit Integration Studio Connector-SDK-Anschlüsse

Nachfolgend finden Sie eine Liste aller Integration Studio Konnektoren ab 16. Dezember 2021, die von Jitterbit erstellt wurden mit dem Integration Studio Connector SDK und sind von den Apache Log4j-Sicherheitslücken betroffen.

Da das Connector SDK für Entwickler öffentlich verfügbar ist, verwendet Ihre Organisation möglicherweise einen hier nicht aufgeführten Connector, der von einem Partner oder Drittpartei erstellt wurde und der Integration Studio Connector-SDK. Diese Konnektoren können ebenfalls von den Apache Log4j-Sicherheitslücken betroffen sein. Wenden Sie sich bitte an den Anbieter dieses Konnektors, um herauszufinden, ob er seinen Konnektor überprüft und ggf. korrigiert hat.

Was hat die Wartung vom 16. Dezember 2021 bewirkt?

Am 16. Dezember 2021 führte Jitterbit eine Notfallwartung durch, um die Apache Log4j2-Schwachstellen zu beheben.

Im Rahmen der Wartung aktualisierte Jitterbit die Integration Studio Mit dem Connector SDK erstellte Konnektoren, um eine verfügbare Version der Log4j-Bibliothek zu verwenden, die die beiden Apache Log4j-Schwachstellen behoben hat.

Nach Abschluss der Wartung am 16. Dezember 2021 um 17:00 Uhr PST (17. Dezember 2021 12:00 Uhr AEDT; 17. Dezember 2021 2:00 Uhr MEZ; 17.12.2021 01:00 UTC) müssen Sie die folgenden Schritte ausführen, damit das Update wirksam wird:

1. Auf jedem privaten Agenten müssen Sie alle JAR-Dateien manuell löschen aus <JITTERBIT_HOME>/Connectors. (Ausgenommen hiervon sind alle JAR-Dateien für Konnektoren, die Sie lokal installiert haben.)
2. Jeder private Agent muss neu gestartet werden.
3. Führen Sie einen Operation aus, bei dem der Connector verwendet wird, oder testen Sie die Verbindung.

Wenn Sie nach Abschluss der Wartung nicht alle oben genannten Schritte in dieser Reihenfolge ausgeführt haben, tun Sie dies umgehend, um Ihr Unternehmen vor diesen Sicherheitslücken zu schützen.

In einer früheren Version dieser Seite wurden Benutzer nur angewiesen, private Agenten neu zu starten. Das Neustarten privater Agenten ist für die meisten Konnektoren wirksam. Für einige Konnektoren ist es jedoch erforderlich, alle Schritte auszuführen. Wir empfehlen, alle JAR-Dateien im Connectors Verzeichnis, um sicherzustellen, dass Sie vor diesen Schwachstellen geschützt sind. Sie können überprüfen, ob Sie geschützt sind, indem Sie nach log4j in allen Dateinamen und Überprüfen der Log4j-Version wie unten beschrieben.

Wie kann ich den Schutz vor diesen Sicherheitslücken bestätigen?

Nachdem Sie die Maßnahmen zur Risikominderung für private Agenten implementiert haben, können Sie Ihren Schutz bestätigen, indem Sie in den Unterverzeichnissen der Agenteninstallation nach Dateinamen suchen, die Folgendes enthalten: log4j.

Alle früheren Dateinamen, die Folgendes enthalten log4j und eine Seriennummer der Version 2, wie log4j-api-2.11.1.jar, sollte nicht mehr vorhanden sein. Alle Dateinamen der Log4j-Version 2-Reihe sollten jetzt durch einen Namen ersetzt werden, der angibt, dass die Version mindestens 2.16.0 ist.

Wenden Sie sich für weitere Unterstützung an den Jitterbit-Support.

Bisheriger Workaround für private Agenten

Dieser Workaround wurde bereits vor der Notfallwartung am 16. Dezember 2021 veröffentlicht. Dieser Workaround wird nicht mehr benötigt und die Schwachstellen werden mit einem Agentenneustart nach der Wartung am 16. Dezember 2021 behoben. Wenn Sie diesen Workaround bereits durchgeführt und private Agenten neu gestartet haben, sind keine weiteren Maßnahmen erforderlich.

Für Kunden mit privaten Agenten wurden zuvor die folgenden Schritte zum Schutz vor den Apache Log4j-Schwachstellen empfohlen.

Privater Linux Agent

Bei privaten Linux Agenten besteht die manuelle Problemumgehung darin, das Script für den Tomcat-Server zu bearbeiten.

Die zu ändernde Datei ist catalina.sh, gelegen in <JITTERBIT_HOME>/tomcat/bin/catalina.sh. Bei einer typischen Installation befindet es sich an diesem Ort:

/opt/jitterbit/tomcat/bin/catalina.sh

1. Fügen Sie direkt nach den Kommentarzeilen am Anfang der Datei die folgende Zeile hinzu:

   JAVA_OPTS="$JAVA_OPTS -Dlog4j2.formatMsgNoLookups=true"
   

2. Zum Beispiel:

   . . .
   # case the default is "true"
   # -----------------------------------------------------------------------------
   JAVA_OPTS="$JAVA_OPTS -Dlog4j2.formatMsgNoLookups=true"
   
   # OS specific support. $var _must_ be set to either true or false.
   . . .
   

3. Speichern Sie die Änderungen an der Datei und beenden Sie Ihren Editor.

4. Starten Sie den privaten Agenten neu:

   > jitterbit stop
   > jitterbit start
   

Überprüfung der Änderung

Um die Ergebnisse dieser Änderung zu überprüfen, führen Sie den Befehl aus ps -ef | grep java und suchen Sie in der Ausgabe nach -Dlog4j2.formatMsgNoLookups=true.

Privater Windows Agent

Bei privaten Windows Agenten müssen Sie die Registrierung bearbeiten.

Gehen Sie folgendermaßen vor:

1. Stoppen Sie den privaten Windows Agenten.

2. Verwenden Sie die Windows Suche, um zu finden regedit und öffnen Sie damit den Registrierungseditor.

3. Navigieren Sie zu Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Apache Software Foundation\Procrun 2.0\Jitterbit Tomcat Server\Parameters\Java.

4. Ändern Sie die Optionen und fügen Sie Folgendes vor dem -Xms Zeile:

   -Dlog4j2.formatMsgNoLookups=true
   

   Beispiel:

   

5. Beenden Sie den Registrierungseditor.

6. Starten Sie den privaten Windows-Agent neu.

Überprüfung der Änderung

So überprüfen Sie die Ergebnisse dieser Änderung:

• Öffnen Sie Notepad (oder einen ähnlichen Editor).

• Öffnen Sie die aktuellste Protokolldatei unter:

  <JITTERBIT_HOME>\tomcat\logs\catalina.{date}.log
  

• Suche nach -Dlog4j2.formatMsgNoLookups=true um zu überprüfen, ob das Befehlszeilenargument verwendet wird.

Beispiel einer Überprüfungsausgabe