Im Folgenden werden alle 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-2024-040
Veröffentlicht: 2.7.2024
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. Das Patchen von Arbeitslasten wird in den nächsten Tagen durchgeführt und das Sicherheitsbulletin wird aktualisiert, sobald der Patch 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. Angreifer erhalten dadurch Root-Zugriff auf VM-Knoten. Edge Private Cloud-Kunden sind Inhaber der und Verwalten die VMs/physischen Hosts, auf denen Edge Private Cloud bereitgestellt wird.
Was soll ich tun? Prüfen Sie die OpenSSH-Version mit dem Befehl |
Kritisch |
Edge-Mikrogateway
| 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. 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.
Was soll ich tun? Überprüfen Sie die OpenSSH-Version, indem Sie die Befehle |
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 ist Apigee nicht ausnutzbar und es gibt Maßnahmen zur Risikominimierung. Obwohl dieses CVE nicht ausgenutzt werden kann, aktualisiert Apigee die Arbeitslasten, um CVE-2024-6387 zu beheben. Was soll ich tun? Von Apigee-Nutzern ist keine Aktion erforderlich. Das Patchen für Arbeitslasten wird in den nächsten Tagen durchgeführt und das Sicherheitsbulletin wird aktualisiert, sobald das Patching abgeschlossen ist. 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 CVE ist, aktualisieren Sie selbst auf die OpenSSH-Version 9.8p1, 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. Angreifer erhalten dadurch Root-Zugriff auf GKE-Knoten. Zum Zeitpunkt der Veröffentlichung sind Hybrid-Images nicht anfällig, da OpenSSH nicht in eines der Hybrid-Container-Images verpackt ist. Wenn Ihr Host-/GKE-Knotenbetriebssystem jedoch mit den folgenden anfälligen Versionen von OpenSSH ausgeführt wird, können Ihre Hybridcluster ausgenutzt werden.
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 | Hinweise |
|---|---|---|
|
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 Validierung des Hostnamens mit einer der folgenden Optionen nicht aktiviert ist, können Apigee-Proxys, die eine Verbindung zu einem Zielendpunkt oder Zielserver herstellen, dem Risiko eines Man-in-the-Middle-Angriffs durch einen autorisierten Nutzer schaden. 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:
Was soll ich tun? Kunden können eine der folgenden Optionen verwenden, um diese Validierung zu aktivieren: Option 1: Dem Proxy eine Konfiguration hinzufügen Sie können die Validierung Ihres Zielendpunkts oder Zielservers aktivieren, indem Sie dem Abschnitt <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 Element Apigee empfiehlt diesen Ansatz. Sie können Proxys einzeln testen, um zu prüfen, ob die Validierung wie vorgesehen funktioniert und der Traffic dabei geringfügig unterbrochen wird. Weitere Informationen zum Testen der Validierung des Hostnamens in Ihren Proxys und zum Aufrufen von Fehlern finden Sie unter Trace-Tool verwenden. Option 2: Kennzeichnung auf Organisationsebene festlegen Sie können ein Apigee-Flag auf Organisationsebene festlegen, um die Validierung des Hostnamens für alle bereitgestellten Proxys und Ziele in Ihrer Organisation zu aktivieren. Wenn das Flag 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.
Apigee empfiehlt, diese Änderung zuerst in Nicht-Produktionsumgebungen zu implementieren, um sicherzustellen, dass die Validierung wie beabsichtigt funktioniert und nicht zu Produktionsausfällen führt. Wenn die Validierung des Hostnamens für Ziele 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 könnte zu einem DoS der Apigee API-Verwaltungsfunktion führen. Betroffene Produkte
Nicht betroffene Produkte
Was soll ich tun?
Welche Sicherheitslücken werden durch diese Patches behoben? Die Sicherheitslücke CVE-2023-44487 könnte zu einem DoS von Apigee API-Verwaltungsfunktionen führen. |
Hoch | CVE-2023-44487 |