Sicherheitsbulletins

Im Folgenden werden Sicherheitsbulletins im Zusammenhang mit Apigee beschrieben.

Sie haben folgende Möglichkeiten, um die neuesten Sicherheitsbulletins zu erhalten:

  • Fügen Sie Ihrem Feed-Reader die URL dieser Seite hinzu.
  • Fügen Sie die Feed-URL direkt Ihrem Feed-Reader hinzu: https://cloud.google.com/feeds/apigee-security-bulletins.xml

GCP-2025-023

Veröffentlicht: 05. 05. 2025

Beschreibung Schweregrad Hinweise

In diesem Bulletin werden potenzielle Sicherheitslücken behandelt, die erkannt und behoben wurden und welche ausgenutzt werden könnten, wenn sie nicht in den JavaCallout- und PythonScript-Richtlinien berücksichtigt werden. Diese Richtlinien könnten zu einer unautorisierten Remote-Codeausführung (Remote Code Execution, RCE) und Rechteausweitung innerhalb der Apigee-Laufzeitumgebung führen. Für diese möglichen Exploits ist ein interner autorisierter Nutzerzugriff (Nutzer mit der Berechtigung zum Bereitstellen von Proxys) erforderlich. Diese potenziellen Sicherheitslücken sind auf unzureichendes Sandboxing für Szenarien wie den Zugriff durch Beurteilung und das Spoofing von Berechtigungsobjekten zurückzuführen, um den Sicherheitsmanager zu umgehen.

Betroffene Produkte

Die Auswirkungen beschränken sich auf die JavaCallout- und PythonScript-Richtlinien. Dazu gehören Bereitstellungen auf den folgenden Apigee-Plattformen:

  • Apigee
  • Apigee Edge for Public Cloud
  • Apigee Hybrid
  • Apigee Edge for Private Cloud

Wie gehe ich am besten vor?

Führen Sie für jedes betroffene Produkt die folgenden Schritte aus:

Apigee

Für Kunden, die die Google Cloud-Version von Apigee verwenden, sind keine Maßnahmen erforderlich. In der Apigee-Version 1-14-0-apigee-8 wurden Fehler im Zusammenhang mit Sicherheitslücken behoben.

Wenn das Release-Team das Release-Rollout für Ihre Organisationen nicht durchführen kann, wendet sich entweder ein TAM oder ein Supportmitarbeiter an Sie, um alle betroffenen JavaCallout-Proxy-Bundles zu korrigieren.

Apigee Hybrid

Sie müssen ein Upgrade auf eine der folgenden Sicherheitspatch-Releases durchführen:

Hybrid-Hauptversion Sicherheitspatch-Release für die betroffene Nebenversion
1.12 1.12.4
1.13 1.13.3
1.14 1.14.1
1.11 1.11.2 hotfix3
Hoch

Apigee Edge for Public Cloud

Für Apigee Edge-Kunden ist keine Aktion notwendig. Es wurden Korrekturen an der neuesten Edge-Laufzeit vorgenommen. Wenn Sie ein Kunde sind, der aufgrund bekannter ausstehender Aktionen nicht auf die neueste Edge-Version aktualisiert werden kann, wird sich ein Kundensupport-Mitarbeiter mit Ihnen in Verbindung setzen.

Apigee Edge for Private Cloud

Wenn Sie Edge for Private Cloud verwenden, sollten Sie Ihre JavaCallout- und PythonScript-Richtlinien überprüfen, um sicherzustellen, dass Sie Code und Bibliotheken aus vertrauenswürdigen Quellen verwenden. Änderungen an solchen Richtlinien erfordern einen internen autorisierten Zugriff (Nutzer mit Berechtigungen zum Bereitstellen von Proxys). Es wird daher empfohlen, Ihre Berechtigungen zu prüfen, um sicherzustellen, dass nur vertrauenswürdige Nutzer diesen Zugriff behalten. Sicherheitslücken wurden in den Edge Private Cloud-Releases 4.52.02 und 4.53.00 behoben.

GCP-2024-040

Veröffentlicht: 02. 07. 2024

Dieses Bulletin enthält Details, die spezifisch für jedes der folgenden Apigee-Produkte sind:

Edge Public Cloud

Beschreibung Schweregrad Hinweise

Bei OpenSSH wurde vor Kurzem eine Sicherheitslücke bei der Remote-Codeausführung, CVE-2024-6387, entdeckt. Die Sicherheitslücke nutzt eine Race-Bedingung, mit der Zugriff auf eine Remote-Shell erhalten werden kann, sodass Angreifer dadurch Root-Zugriff auf GKE-Knoten bekommen können. Zum Zeitpunkt der Veröffentlichung ist Apigee Edge for Public Cloud nicht ausnutzbar und Schutzmaßnahmen sind in Kraft.

Obwohl diese CVE nicht ausnutzbar ist, wird Apigee die Arbeitslasten aktualisieren, um die oben genannte CVE zu beheben.

Wie gehe ich am besten vor?

Von Apigee-Nutzern ist keine Aktion notwendig.

Das Patchen von Arbeitslasten erfolgt in den kommenden Tagen. Das Sicherheitsbulletin wird aktualisiert, sobald das Patchen abgeschlossen ist.

 Kritisch

Edge Private Cloud

Beschreibung Schweregrad

Bei OpenSSH wurde vor Kurzem eine Sicherheitslücke bei der Remote-Codeausführung, CVE-2024-6387, entdeckt. Die Sicherheitslücke nutzt eine Race-Bedingung, mit der Zugriff auf eine Remote-Shell erhalten werden kann, sodass Angreifer dadurch Root-Zugriff auf VM-Knoten bekommen können. Edge Private Cloud-Kunden sind Inhaber und Verwalter der VMs/physischen Hosts, auf denen Edge Private Cloud bereitgestellt ist.

Version Auswirkungen
OpenSSH < 4.4p1 Anfällig
4.4p1v<= OpenSSH < 8.5p1 Nicht anfällig
8.5p1 <= OpenSSH < 9.8p1 Anfällig

Wie gehe ich am besten vor?

Überprüfen Sie die OpenSSH-Version, indem Sie den Befehl ssh -V verwenden und die OpenSSH-Version prüfen. Wenn Ihr System auf einer der betroffenen OpenSSH-Versionen ausgeführt wird, aktualisieren Sie auf eine Version, die NICHT anfällig für diese CVE ist. OpenSSH hat am 1. Juli 2024 die Version 9.8p1 veröffentlicht.

 Kritisch

Edge Microgateway

Beschreibung Schweregrad Hinweise

Bei OpenSSH wurde vor Kurzem eine Sicherheitslücke bei der Remote-Codeausführung, CVE-2024-6387, entdeckt. Die Sicherheitslücke nutzt eine Race-Bedingung, mit der Zugriff auf eine Remote-Shell erhalten werden kann, sodass Angreifer dadurch Root-Zugriff auf VM-Knoten bekommen können. Edge Microgateway-Kunden sind Inhaber und Verwalter der VMs/physischen Hosts, auf denen Edge Microgateway bereitgestellt ist.

Version Auswirkungen
OpenSSH < 4.4p1 Anfällig
4.4p1v<= OpenSSH < 8.5p1 Nicht anfällig
8.5p1 <= OpenSSH < 9.8p1 Anfällig

Wie gehe ich am besten vor?

Überprüfen Sie die OpenSSH-Version, indem Sie die Befehle ssh -V verwenden und prüfen Sie die OpenSSH-Version. Wenn Ihr System auf einer der betroffenen OpenSSH-Versionen ausgeführt wird, aktualisieren Sie auf eine Version, die NICHT anfällig für diese CVE ist. OpenSSH hat am 1. Juli 2024 die Version 9.8p1 veröffentlicht.

 Kritisch

Apigee

Beschreibung Schweregrad Hinweise

Bei OpenSSH wurde vor Kurzem eine Sicherheitslücke bei der Remote-Codeausführung, CVE-2024-6387, entdeckt. Die Sicherheitslücke nutzt eine Race-Bedingung, mit der Zugriff auf eine Remote-Shell erhalten werden kann, sodass Angreifer dadurch Root-Zugriff auf GKE-Knoten bekommen können. Zum Zeitpunkt der Veröffentlichung ist Apigee nicht ausnutzbar und Schutzmaßnahmen sind in Kraft.

Obwohl diese CVE nicht ausgenutzt werden kann, wird Apigee die Arbeitslasten aktualisieren, um CVE-2024-6387 zu beheben.

Wie gehe ich am besten vor?

Von Apigee-Nutzern ist keine Aktion notwendig. Das Patchen von Arbeitslasten erfolgt in den kommenden Tagen. Das Sicherheitsbulletin wird aktualisiert, sobald das Patchen abgeschlossen ist.

Hinweis: Wenn verwaltete Instanzgruppen in einem Kundenprojekt für das Northbound-Load-Balancing bereitgestellt werden, insbesondere InternalRouting (VPC) und ExternalRouting (MIG), prüfen Sie, welche OpenSSH-Version auf diesen installiert ist. Wenn die Version anfällig für die CVE ist, müssen Sie selbst ein Upgrade auf OpenSSH Version 9.8p1 durchführen, die am 1. Juli 2024 veröffentlicht wurde, da Apigee diese MIGs nicht verwaltet.

Kritisch

Apigee Hybrid

Beschreibung Schweregrad Hinweise

Bei OpenSSH wurde vor Kurzem eine Sicherheitslücke bei der Remote-Codeausführung, CVE-2024-6387, entdeckt. Die Sicherheitslücke nutzt eine Race-Bedingung, mit der Zugriff auf eine Remote-Shell erhalten werden kann, sodass Angreifer dadurch Root-Zugriff auf GKE-Knoten bekommen können. Zum Zeitpunkt der Veröffentlichung sind Hybrid-Images nicht anfällig, da OpenSSH nicht in einem der Hybrid-Container-Images verpackt ist. Wenn auf dem Betriebssystem Ihres Hosts/GKE-Knotens jedoch die unten aufgeführten anfälligen Versionen von OpenSSH ausgeführt werden, sind Ihre Hybridcluster angreifbar.

Version Auswirkungen
OpenSSH < 4.4p1 Anfällig
4.4p1v<= OpenSSH < 8.5p1 Nicht anfällig
8.5p1 <= OpenSSH < 9.8p1 Anfällig

Wie gehe ich am besten vor?

Dieses Problem wurde im Google Cloud Customer Care-Sicherheitsbulletin GCP-2024-040 behandelt.

Anleitungen und weitere Informationen finden Sie in folgenden Sicherheitsbulletins:

 Kritisch

GCP-2024-006

Veröffentlicht: 05. 02. 2024

Beschreibung Schweregrad Hinweise

Wenn ein Apigee API-Verwaltungsproxy eine Verbindung zu einem Zielendpunkt oder Zielserver herstellt, führt der Proxy standardmäßig keine Hostnamenvalidierung für das vom Zielendpunkt oder Zielserver bereitgestellte Zertifikat durch. Wenn die Hostnamenvalidierung nicht mit einer der folgenden Optionen aktiviert ist, besteht für Apigee-Proxys, die eine Verbindung zu einem Zielendpunkt oder Zielserver herstellen, das Risiko eines Man-in-the-Middle-Angriffs durch einen autorisierten Nutzer. Weitere Informationen finden Sie unter TLS von Edge mit dem Backend konfigurieren (Cloud und Private Cloud).

Betroffene Produkte

Apigee-Proxy-Bereitstellungen auf den folgenden Apigee-Plattformen sind betroffen:

  • Apigee Edge for Public Cloud
  • Apigee Edge for Private Cloud

Wie gehe ich am besten vor?

Kunden können eine der folgende Möglichkeiten wählen, um diese Validierung zu aktivieren:

Option 1: Konfiguration Ihrem Proxy hinzufügen

Sie können die Validierung Ihres Zielendpunkts oder Zielservers aktivieren, indem Sie der Proxykonfiguration im Abschnitt SSLInfo des Elements <HTTPTargetConnection> die Konfiguration <CommonName> hinzufügen:

<HTTPTargetConnection>
  <SSLInfo>
    <Enabled>true</Enabled>
    <TrustStore>ref://mytruststoreref</TrustStore>
    <CommonName>*.example.com</CommonName>
  </SSLInfo>
  <URL>https://my.example.com/</URL>
</HTTPTargetConnection>

Wenn diese Konfiguration im <HTTPTargetConnection>-Element Ihrer Proxykonfiguration vorhanden ist, verwendet Apigee den in <CommonName> angegebenen Wert für die Hostnamenvalidierung. In diesem Feld können Platzhalter verwendet werden.

Apigee empfiehlt diesen Ansatz. Sie können Proxys einzeln testen, um zu bestätigen, dass die Validierung wie vorgesehen funktioniert, wobei Traffic-Unterbrechungen minimal gehalten werden. Weitere Informationen zum Testen der Hostnamenvalidierung in Ihren Proxys und zum Ansehen von Fehlern finden Sie unter Trace-Tool verwenden.

Option 2: Flag auf Organisationsebene festlegen

Sie können ein Flag auf Apigee-Organisationsebene festlegen, um die Hostnamenvalidierung für alle bereitgestellten Proxys und Ziele in Ihrer Organisation zu aktivieren. Wenn das Flag features.strictSSLEnforcement in den Organisationseigenschaften auf true gesetzt ist, wird die Hostnamenvalidierung jedes Mal erzwungen, wenn der Proxy eine Verbindung zu einem Zielendpunkt oder Zielserver herstellt.

Hinweis: Mit dieser Option können Sie das Feature in der gesamten Organisation aktivieren. Bei der Validierung des Hostnamens können jedoch Fehler auftreten, wenn Ihre Ziele nicht die erwarteten Zertifikate enthalten.

  • Für Apigee Edge for Public Cloud-Bereitstellungen:

    Wenden Sie sich an den Google Cloud Support, um das Flag features.strictSSLEnforcement in den Organisationseigenschaften auf true festlegen zu lassen.

    Hinweis: Wenn Sie dieses Flag aktivieren, wird die SSL-Prüfung für alle Umgebungen in einer Organisation und alle Proxys, die in diesen Umgebungen bereitgestellt werden, erzwungen.

  • Für Apigee Edge for Private Cloud-Bereitstellungen:

    Das Flag features.strictSSLEnforcement kann vom Organisations- oder Systemadministrator auf true gesetzt werden. Weitere Informationen zum Festlegen des Flags finden Sie unter Organisationseigenschaften aktualisieren.

    Hinweis: Wenn Sie Flags auf Organisationsebene mit der Organizations API aktualisieren, müssen Sie alle vorhandenen Flags in Ihre POST-Anfrage aufnehmen, um zu vermeiden, dass frühere Konfigurationseinstellungen überschrieben werden.

    Nachdem das Flag festgelegt wurde, muss jeder Message Processor einzeln neu gestartet werden, damit die Änderung wirksam wird. Verwenden Sie den folgenden Befehl:

    apigee-service edge-message-processor restart

    Wenn Sie ein Rollback dieser Änderung ausführen möchten, verwenden Sie dieselbe Organizations API, um das Flag auf false zu setzen, und starten Sie dann jeden Message Processor neu.

    Hinweis: Wenn Sie dieses Flag aktivieren, wird die SSL-Prüfung für alle Umgebungen in einer Organisation und alle Proxys, die in diesen Umgebungen bereitgestellt werden, erzwungen. Wenn <IgnoreValidationErrors> jedoch auf true festgelegt ist, werden alle erkannten Validierungsfehler ignoriert.

Apigee empfiehlt, diese Änderung zuerst in Nicht-Produktionsumgebungen zu implementieren, um sicherzustellen, dass die Validierung wie vorgesehen funktioniert und nicht zu Produktionsausfällen führt. Wenn die Hostnamenvalidierung für ein Ziel fehlschlägt, wird die folgende Fehlermeldung zurückgegeben:

{"fault":{"faultstring":"SSL Handshake failed java.security.cert.CertificateException: No subject alternative DNS name matching example.com found.","detail":{"errorcode":"messaging.adaptors.http.flow.SslHandshakeFailed"}}}
 		Hoch

GCP-2023-032

Veröffentlicht: 13. 10. 2023

Aktualisiert: 03. 11. 2023

Beschreibung Schweregrad Hinweise

Update vom 03. 11. 2023: Bekanntes Problem für Apigee Edge for Private Cloud hinzugefügt.

Vor Kurzem wurde in mehreren Implementierungen des HTTP/2-Protokolls (CVE-2023-44487) eine DoS-Sicherheitslücke (Denial of Service) festgestellt, darunter auch der von Apigee X und Apigee Hybrid verwendete Apigee Ingress-Dienst (Cloud Service Mesh). Die Sicherheitslücke könnte zu einem DoS der Apigee API-Verwaltungsfunktionen führen.

Betroffene Produkte

  • Apigee X

    Bereitstellungen von Apigee X, auf die über einen Google Cloud Network Load Balancer (Layer 4) oder einen benutzerdefinierten Layer 4-Load-Balancer zugegriffen werden kann, sind betroffen. Ein Hotfix wurde auf alle Apigee X-Instanzen angewendet.

  • Apigee Hybrid

    Apigee Hybrid-Instanzen, die es HTTP/2-Anfragen erlauben, Apigee Ingress zu erreichen, sind betroffen. Kunden sollten prüfen, ob die Load Balancer, die auf ihre Apigee Hybrid-Ingress-Ressourcen zugreifen, HTTP/2-Anfragen erlauben, um den Apigee-Ingress-Dienst zu erreichen.

  • Apigee Edge for Private Cloud

    Die Komponenten des Routers und Verwaltungsservers von Edge for Private Cloud sind für das Internet freigegeben und können anfällig sein. Obwohl HTTP/2 auf dem Verwaltungsport anderer Edge-spezifischer Komponenten von Edge for Private Cloud aktiviert ist, ist keine dieser Komponenten für das Internet freigegeben. Bei Nicht-Edge-Komponenten wie Cassandra, Zookeeper und anderen ist HTTP/2 nicht aktiviert. Wir empfehlen, dass Sie die Schritte unter Bekannte Probleme mit Edge for Private Cloud ausführen, um die Sicherheitslücke von Edge for Private Cloud zu beheben.

Nicht betroffene Produkte

  • Apigee X

    Apigee X-Instanzen, auf die nur über Google CloudApplication Load Balancer (Layer 7) zugegriffen wird, sind nicht betroffen. Dazu gehören auch Bereitstellungen, bei denen HTTP/2 für gRPC-Proxys aktiviert ist.

  • Google Cloud API Gateway

    Google Cloud API Gateway ist nicht betroffen.

  • Apigee Edge-Cloud

    Apigee Edge Cloud ist von dieser Sicherheitslücke nicht betroffen.

Wie gehe ich am besten vor?

  • Apigee X

    Update vom 3. November 2023: Die Sicherheitslücke wurde über das Update auf Apigee X-Instanzen behoben, das am 13. Oktober 2023 veröffentlicht wurde. Weitere Informationen finden Sie in den Versionshinweisen.

  • Apigee Hybrid

    Apigee Hybrid-Kunden müssen ein Upgrade auf eine der folgenden Patchversionen durchführen:

  • Apigee Edge for Private Cloud

    Nutzer von Apigee Edge for Private Cloud können die Anleitungen unter Bekannte Probleme mit Edge for Private Cloud befolgen, um HTTP/2 für gefährdete Komponenten explizit zu deaktivieren.

Welche Sicherheitslücken werden mit diesen Patches behoben?

Die Sicherheitslücke CVE-2023-44487 könnte zu einem DoS der Apigee API-Verwaltungsfunktionen führen.

Hoch CVE-2023-44487