Minderung der Apache Log4j2 JNDI-Sicherheitsanfälligkeit in Jitterbit Harmony

Zusammenfassung

Diese Seite fasst die Apache Log4j2-Sicherheitsanfälligkeiten zusammen, beschreibt deren Auswirkungen auf Jitterbit-Produkte und erklärt, wie die Sicherheitsanfälligkeiten gemindert wurden.

Entdeckung der Sicherheitsanfälligkeiten

Am 9. Dezember 2021 wurde eine kritische Zero-Day-Sicherheitsanfälligkeit von Apache offengelegt, die Apache Log4j2 betrifft (CVE-2021-44228). Eine zusätzliche verwandte Sicherheitsanfälligkeit wurde von Apache am 14. Dezember 2021 offengelegt (CVE-2021-45046).

Minderung für private Agenten

Am 16. Dezember 2021 führte Jitterbit eine Notwartung durch, um die Apache Log4j2-Sicherheitsanfälligkeiten zu beheben.

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

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

Wenn Sie nicht alle oben genannten Schritte in dieser Reihenfolge nach Abschluss der Wartung ausgeführt haben, tun Sie dies sofort, um Ihre Organisation vor diesen Sicherheitsanfälligkeiten zu schützen.

Eine frühere Version dieser Seite wies die Benutzer an, nur private Agenten neu zu starten. Das Neustarten privater Agenten ist für die meisten Connectoren wirksam. Für einige Connectoren ist es jedoch notwendig, alle Schritte auszuführen. Wir empfehlen, alle JAR-Dateien im Verzeichnis Connectors zu löschen, um sicherzustellen, dass Sie vor diesen Sicherheitsanfälligkeiten geschützt sind. Sie können überprüfen, ob Sie geschützt sind, indem Sie nach log4j in beliebigen Dateinamen suchen und die Log4j-Version wie unten beschrieben überprüfen.

Vorherige Umgehungslösung für private Agenten

Vor dem 16. Dezember 2021 wurde auf dieser Seite eine Umgehungslösung veröffentlicht, um die Sicherheitsanfälligkeiten manuell zu beheben, bevor die Notwartung durchgeführt wurde. Diese Umgehungslösung ist für keine Versionen privater Agenten mehr erforderlich.

Wenn Sie die Umgehungslösung bereits durchgeführt haben, müssen Sie sie nicht rückgängig machen. Wenn Sie die privaten Agenten seit Abschluss der Notwartung nicht neu gestartet haben, sollten Sie die Agenten neu starten, damit sie das Update zur Notwartung erhalten. Es wird keine zusätzliche Maßnahme über den Neustart hinaus empfohlen, um diese Sicherheitsanfälligkeiten zu beheben.

Was sind die Apache Log 4j2 JNDI-Sicherheitsanfälligkeiten?

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

Apache Log4j2 \<=2.14.1 JNDI-Funktionen, die in Konfigurationen, Protokollnachrichten und Parametern verwendet werden, bieten keinen Schutz gegen von Angreifern kontrollierte LDAP- und andere JNDI-bezogene Endpunkte. Ein Angreifer, der Protokollnachrichten oder Protokollnachrichtenparameter kontrollieren kann, kann beliebigen Code aus LDAP-Servern ausführen, wenn die Nachrichtenersetzungsfunktion aktiviert ist. Ab Log4j 2.15.0 wurde dieses Verhalten standardmäßig deaktiviert.

Eine verwandte Sicherheitsanfälligkeit ist CVE-2021-45046, die eine Sicherheitsanfälligkeit in der Log4j 2.15.0-Bibliothek beschreibt. Beide Sicherheitsanfälligkeiten werden hier behandelt und angesprochen.

Welche Jitterbit-Produkte waren von den Sicherheitsanfälligkeiten betroffen?

Diese Sicherheitsanfälligkeiten beschränkten sich auf Integration Studio-Connectoren, die mit dem Integration Studio Connector SDK ("Integration Studio Connector SDK-Connectoren") erstellt wurden.

Da Connectoren typischerweise nicht als eigenständige Jitterbit-Produkte betrachtet werden und auf einem Jitterbit-Agenten ausgeführt werden müssen, ist eine Erklärung erforderlich, um die Auswirkungen und die Maßnahmen zur Minderung dieser Sicherheitsanfälligkeiten zu erläutern:

• Was ist ein Integration Studio Connector SDK-Connector?
  Integration Studio Connector SDK-Connectoren sind Connectoren, die mit dem Integration Studio Connector SDK erstellt wurden. Sie umfassen derzeit bestimmte Connectoren, die von Jitterbit oder von Dritten erstellt wurden:
  • Jitterbit: Die meisten der aktuellen Integration Studio Anwendungs-Connectoren wurden mit dem Connector SDK erstellt. Ausnahmen sind die Connectoren von 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 Jitterbit-Connectoren, die von diesen Sicherheitsanfälligkeiten betroffen sind. Zukünftige Connectoren, die von Jitterbit mit dem Connector SDK erstellt werden, werden nicht betroffen sein.
  • Drittanbieter: Da das Connector SDK öffentlich verfügbar ist, um Integration Studio-Connectoren zu erstellen, könnte Ihre Organisation zusätzliche Connectoren verwenden, die von einem Partner oder Dritten mit dem Connector SDK erstellt wurden und ebenfalls von diesen Sicherheitsanfälligkeiten betroffen sein könnten. Bitte kontaktieren Sie den Anbieter dieses Connectors, um festzustellen, ob er seinen Connector bewertet und gegebenenfalls korrigiert hat.
• Wie hängen diese Connectoren mit Agenten zusammen?
  Die neueste Version eines Integration Studio Connector SDK-Connectors wird bei Bedarf von einem Jitterbit-Agenten aus Harmony heruntergeladen, wenn Sie den Connector verwenden.
• Welche Agenten waren betroffen?
  Jeder Cloud- oder private Agent, der einen Integration Studio Connector SDK-Connector verwendet hat, war von den Sicherheitsanfälligkeiten betroffen, da die Apache Log4j2-Bibliothek heruntergeladen und auf dem Agenten verwendet wurde, um Protokolle zu schreiben, wenn der Connector verwendet wurde.
  • Cloud-Agenten: Bei Cloud-Agenten hat Jitterbit diese Sicherheitsanfälligkeiten sofort durch geeignete Sicherheitsmaßnahmen behoben. Es sind keine weiteren Maßnahmen erforderlich.
  • Private Agenten: Bei privaten Agenten wurden die Kunden vor der Notwartung am 16. Dezember 2021 angewiesen, die zuvor dokumentierte Umgehungslösung zu befolgen, um diese Sicherheitsanfälligkeiten zu beheben.

Diese Jitterbit-Produkte waren nicht betroffen:

• Agenten, die noch nie einen Integration Studio Connector SDK Connector verwendet haben: Nicht betroffen.
• Jitterbit Design Studio (und seine Connectoren): Nicht betroffen.
• Jitterbit Harmony Cloud: Nicht betroffen.
• Jitterbit eiCloud: Nicht betroffen.

Jitterbit Integration Studio Connector SDK Connectoren

Im Folgenden finden Sie eine Liste aller Integration Studio Connectoren, die am 16. Dezember 2021 von Jitterbit erstellt wurden und die von den Apache Log4j-Sicherheitsanfälligkeiten betroffen sind.

Da das Connector SDK öffentlich für Entwickler verfügbar ist, könnte Ihre Organisation einen Connector verwenden, der hier nicht aufgeführt ist und von einem Partner oder Dritten mit dem Integration Studio Connector SDK erstellt wurde. Diese Connectoren könnten ebenfalls von den Apache Log4j-Sicherheitsanfälligkeiten betroffen sein. Bitte kontaktieren Sie den Anbieter dieses Connectors, um herauszufinden, ob er seinen Connector bewertet und gegebenenfalls korrigiert hat.

Was hat die Wartung am 16. Dezember 2021 bewirkt?

Am 16. Dezember 2021 führte Jitterbit eine Notfallwartung durch, um die Sicherheitsanfälligkeiten von Apache Log4j2 zu beheben.

Im Rahmen der Wartung aktualisierte Jitterbit die Integration Studio-Connectoren, die mit dem Connector SDK erstellt wurden, um eine verfügbare Version der Log4j-Bibliothek zu verwenden, die die beiden Sicherheitsanfälligkeiten von Apache Log4j behob.

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

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

Wenn Sie nicht alle oben genannten Schritte in dieser Reihenfolge nach Abschluss der Wartung ausgeführt haben, tun Sie dies sofort, um Ihre Organisation vor diesen Sicherheitsanfälligkeiten zu schützen.

Eine frühere Version dieser Seite wies die Benutzer an, nur die privaten Agenten neu zu starten. Das Neustarten der privaten Agenten ist für die meisten Connectoren wirksam. Für einige Connectoren ist es jedoch notwendig, alle Schritte auszuführen. Wir empfehlen, alle JAR-Dateien im Verzeichnis Connectors zu löschen, um sicherzustellen, dass Sie vor diesen Sicherheitsanfälligkeiten geschützt sind. Sie können überprüfen, ob Sie geschützt sind, indem Sie nach log4j in beliebigen Dateinamen suchen und die Log4j-Version wie unten beschrieben überprüfen.

Wie kann ich den Schutz vor diesen Sicherheitsanfälligkeiten bestätigen?

Nachdem Sie die Milderungsmaßnahmen für private Agenten umgesetzt haben, können Sie bestätigen, dass Sie geschützt sind, indem Sie in den Unterverzeichnissen der Agenteninstallation nach Dateinamen suchen, die log4j enthalten.

Frühere Dateinamen, die log4j und eine Versionsnummer der Serie 2 enthalten, wie log4j-api-2.11.1.jar, sollten nicht mehr vorhanden sein. Alle Dateinamen der Log4j-Version 2-Serie sollten jetzt durch einen Namen ersetzt worden sein, der anzeigt, dass die Version mindestens 2.16.0 beträgt.

Für weitere Unterstützung kontaktieren Sie Jitterbit-Support.

Vorherige Lösung für private Agenten

Diese Lösung wurde zuvor vor der Notwartung am 16. Dezember 2021 veröffentlicht. Diese Lösung ist nicht mehr erforderlich und die Sicherheitsanfälligkeiten werden mit einem Neustart des Agenten nach der Wartung am 16. Dezember 2021 behoben. Wenn Sie diese Lösung 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 empfohlen, um sich gegen die Apache Log4j-Sicherheitsanfälligkeiten zu schützen.

Linux privater Agent

Für Linux private Agenten besteht die manuelle Lösung darin, das Startskript für den Tomcat-Server zu bearbeiten.

Die Datei, die geändert werden muss, ist catalina.sh, die sich unter <JITTERBIT_HOME>/tomcat/bin/catalina.sh befindet. Bei einer typischen Installation befindet sich diese an folgendem Ort:

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

1. Fügen Sie die folgende Zeile unmittelbar nach den Kommentarzeilen am Anfang der Datei 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 Änderung in 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 ps -ef | grep java aus und suchen Sie in der Ausgabe nach -Dlog4j2.formatMsgNoLookups=true.

Windows privater Agent

Für Windows private Agenten müssen Sie die Registrierung bearbeiten.

Befolgen Sie diese Schritte:

1. Stoppen Sie den Windows-Privatagenten.

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

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 der -Xms-Zeile hinzu:

   -Dlog4j2.formatMsgNoLookups=true
   

   Beispiel:

   

5. Beenden Sie den Registrierungs-Editor.

6. Starten Sie den Windows-Privatagenten neu.

Überprüfung der Änderung

Um die Ergebnisse dieser Änderung zu überprüfen:

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

• Öffnen Sie die zuletzt erstellte Protokolldatei, die sich befindet unter:

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

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

Beispiel für die Überprüfungsausgabe