Sicherheitsbulletins

Im Folgenden werden Sicherheitsbulletins im Zusammenhang mit Apigee beschrieben.

Führen Sie einen der folgenden Schritte aus, um die neuesten Sicherheitsbulletins zu erhalten:

  • Fügen Sie Ihrem Feedreader 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 beschrieben, die ausgenutzt werden könnten, wenn sie nicht in den JavaCallout- und PythonScript-Richtlinien berücksichtigt werden, die gefunden und behoben wurden. Diese Richtlinien können zu einer unbefugten Remote-Code-Ausführung (RCE) und einer Rechteausweitung in der Apigee-Laufzeitumgebung führen. Für diese möglichen Ausnutzungen ist der Zugriff von internen autorisierten Nutzern (Nutzer mit Berechtigung zum Bereitstellen von Proxys) erforderlich. Diese potenziellen Sicherheitslücken resultieren aus unzureichender Sandboxing-Technologie für Szenarien wie Zugriff durch Reflexion und Spoofing von Berechtigungsobjekten, um den Sicherheitsmanager zu umgehen.

Betroffene Produkte

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

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

Was soll ich tun?

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. Sicherheitslücken wurden in der Apigee-Version 1-14-0-apigee-8 behoben.

Wenn das Release-Team das Release nicht für Ihre Organisationen bereitstellen kann, wenden 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:

Hauptversion der Hybridumgebung Veröffentlichung des Sicherheitspatches 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

Apigee Edge-Kunden müssen nichts weiter tun. Die Fehlerkorrekturen wurden auf die neueste Edge-Laufzeit angewendet. Wenn Sie aufgrund von bekannten ausstehenden Maßnahmen nicht auf die neueste Edge-Version umstellen können, wird sich ein Kundenservicemitarbeiter mit Ihnen in Verbindung setzen.

Apigee Edge for Private Cloud

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

GCP-2024-040

Veröffentlicht: 2.7.2024

Dieses Bulletin enthält Details zu den einzelnen Apigee-Produkten:

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 erhalten dadurch Root-Zugriff auf GKE-Knoten. Zum Zeitpunkt der Veröffentlichung kann Apigee Edge for Public Cloud nicht ausgenutzt werden und es gibt Sicherheitsmaßnahmen.

Obwohl dieses CVE nicht ausgenutzt werden kann, wird Apigee die Arbeitslasten aktualisieren, um das oben genannte CVE zu beheben.

Was soll ich tun?

Von Apigee-Nutzern ist keine Aktion erforderlich.

Die Patches für Arbeitslasten werden in den kommenden Tagen bereitgestellt. Das Sicherheitsbulletin wird aktualisiert, sobald die Patches installiert wurden.

 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 Root-Zugriff auf VM-Knoten erhalten. Edge Private Cloud-Kunden sind Inhaber der und Verwalten die VMs/physischen Hosts, auf denen Edge Private Cloud bereitgestellt wird.

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

Was soll ich tun?

Überprüfen Sie die OpenSSH-Version, indem Sie den Befehl ssh -V verwenden und die OpenSSH-Version prüfen. Wenn Sie eine betroffene OpenSSH-Version verwenden, aktualisieren Sie 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 erhalten dadurch Root-Zugriff auf VM-Knoten. Edge Microgateway-Kunden sind Inhaber der und Verwalten die VMs/physischen Hosts, auf denen Edge Microgateway bereitgestellt ist.

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

Was soll ich tun?

Überprüfen Sie die OpenSSH-Version, indem Sie die Befehle ssh -V verwenden und die OpenSSH-Version prüfen. Wenn Sie eine betroffene OpenSSH-Version verwenden, aktualisieren Sie 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 erhalten dadurch Root-Zugriff auf GKE-Knoten. Zum Zeitpunkt der Veröffentlichung kann Apigee nicht ausgenutzt werden und es gibt Sicherheitsmaßnahmen.

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

Was soll ich tun?

Von Apigee-Nutzern ist keine Aktion erforderlich. Die Patches für Workloads werden in den kommenden Tagen bereitgestellt. Das Sicherheitsbulletin wird aktualisiert, sobald die Patches installiert wurden.

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

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 erhalten dadurch Root-Zugriff auf GKE-Knoten. Zum Zeitpunkt der Veröffentlichung sind Hybrid-Images nicht anfällig, da OpenSSH in keinem der Hybrid-Container-Images enthalten ist. Wenn das Betriebssystem Ihres Hosts oder GKE-Knotens jedoch mit den folgenden angreifbaren Versionen von OpenSSH ausgeführt wird, können Ihre Hybridcluster manipuliert werden.

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

Was soll ich tun?

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: 5.2.2024

Beschreibung Schweregrad Notes

Wenn ein Apigee API-Verwaltungsproxy eine Verbindung zu einem Zielendpunkt oder Zielserver herstellt, führt der Proxy standardmäßig keine Hostnamenvalidierung für Hostnamenüberprüfung für das vom Zielendpunkt oder Zielserver bereitgestellte Zertifikat durch. Wenn die Hostnamenüberprüfung nicht mit einer der folgenden Optionen aktiviert ist, sind Apigee-Proxys, die eine Verbindung zu einem Zielendpunkt oder Zielserver herstellen, möglicherweise einem Man-in-the-Middle-Angriff durch einen autorisierten Nutzer ausgesetzt. Weitere Informationen finden Sie unter TLS von Edge mit dem Back-End 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

Was soll ich tun?

Kunden haben folgende Möglichkeiten, diese Bestätigung zu aktivieren:

Option 1: Proxy eine Konfiguration hinzufügen

Sie können die Validierung des Zielendpunkts oder Zielservers aktivieren, indem Sie dem Bereich SSLInfo des Elements <HTTPTargetConnection> in Ihrer Proxy-Konfiguration eine <CommonName>-Konfiguration hinzufügen, wie hier gezeigt:

<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 Validierung des Hostnamens. In diesem Feld können Platzhalter verwendet werden.

Apigee empfiehlt diesen Ansatz. Sie können Proxys einzeln testen, um sicherzustellen, dass die Validierung wie vorgesehen funktioniert, und dabei die Unterbrechung des Traffics so gering wie möglich halten. Weitere Informationen zum Testen der Hostnamenüberprüfung in Ihren Proxys und zum Ansehen von Fehlern finden Sie unter Trace-Tool verwenden.

Option 2: Flag auf Organisationsebene setzen

Sie können ein Apigee-Flag auf Organisationsebene festlegen, um die Überprüfung von Hostnamen für alle bereitgestellten Proxys und Ziele in Ihrer Organisation zu aktivieren. Wenn das Flag features.strictSSLEnforcement in den Organisationseigenschaften auf true festgelegt ist, wird die Hostnamenüberprüfung 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, damit das Flag features.strictSSLEnforcement in den Organisationseigenschaften auf true gesetzt wird.

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

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

    Das Flag features.strictSSLEnforcement kann vom Administrator der Organisation oder des Systems 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 gesetzt wurde, muss jeder Nachrichten-Prozessor einzeln neu gestartet werden, damit die Änderung wirksam wird. Verwenden Sie den folgenden Befehl:

    apigee-service edge-message-processor restart

    Wenn Sie diese Änderung rückgängig machen möchten, setzen Sie das Flag mit derselben Organisations-API auf false und starten Sie dann jeden Nachrichten-Prozessor neu.

    Hinweis: Wenn Sie dieses Flag aktivieren, wird die SSL-Prüfung für alle Umgebungen in einer Organisation und alle in diesen Umgebungen bereitgestellten Proxys 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 Hostnamenüberprüfung 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: 23. Oktober 2023

Aktualisiert: 3. November 2023

Beschreibung Schweregrad Hinweise

Update vom 3. November 2023: Ein bekanntes Problem für Apigee Edge for Private Cloud wurde 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 kann zu einem DoS der Apigee API-Verwaltungsfunktionen führen.

Betroffene Produkte

  • Apigee X

    Bereitstellungen von Apigee X, auf die über einen Google Cloud Netzwerk-Load Balancer (Layer 4) oder einen benutzerdefinierten Layer 4-Load Balancer zugegriffen werden kann, sind betroffen. Auf alle Apigee X-Instanzen wurde ein Hotfix 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, den Apigee-Ingress-Dienst zu erreichen.

  • Apigee Edge for Private Cloud

    Die Komponenten des Routers und Verwaltungsservers von Edge for Private Cloud sind über das Internet zugänglich 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 im Internet zugänglich. Bei anderen Komponenten als Edge-Komponenten wie Cassandra und Zookeeper ist HTTP/2 nicht aktiviert. Führen Sie die Schritte unter Bekannte Probleme mit Edge for Private Cloud aus, um die Sicherheitslücke von Edge for Private Cloud zu beheben.

Nicht betroffene Produkte

  • Apigee X

    Apigee X-Instanzen, auf die nur über Google Cloud Application 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.

Was soll ich tun?

  • 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 Einzelheiten finden Sie in den Versionshinweisen.

  • Apigee Hybrid

    Apigee Hybrid-Kunden müssen auf eine der folgenden Patchversionen upgraden:

  • 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 bereitgestellte Komponenten explizit zu deaktivieren.

Welche Sicherheitslücken werden mit diesen Patches geschlossen?

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

Hoch CVE-2023-44487