A continuación, se describen todos los boletines de seguridad relacionados con Apigee.
Para recibir los boletines de seguridad más recientes, realiza una de las siguientes acciones:
- Agrega la URL de esta página a tu lector de feeds.
- Agrega la URL del feed directamente a tu lector de feeds:
https://cloud.google.com/feeds/apigee-security-bulletins.xml
GCP-2024-040
Se publicó: 2024-07-02
Nube pública de Edge
| Descripción | Gravedad | Notas |
|---|---|---|
|
Se detectó hace poco una vulnerabilidad de ejecución de código remoto, CVE-2024-6387, en OpenSSH. La vulnerabilidad explota una condición de carrera que se puede usar para obtener acceso a una shell remota, lo que permitiría que los atacantes obtengan acceso raíz a nodos de GKE. Al momento de la publicación, no se puede aprovechar Apigee Edge para la nube pública, además, existen mitigaciones. Aunque no se puede aprovechar esta CVE, Apigee actualizará las cargas de trabajo para abordar la CVE anterior. ¿Qué debo hacer? No se requiere ningún elemento de acción de los usuarios de Apigee. La aplicación de parches para cargas de trabajo se realizará en los próximos días y el boletín de seguridad se actualizará una vez que se complete la aplicación de parches. |
Crítico |
Nube privada de Edge
| Descripción | Gravedad | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
Se descubrió hace poco una vulnerabilidad de ejecución de código remoto, CVE-2024-6387, en OpenSSH. La vulnerabilidad explota una condición de carrera que se puede usar para obtener acceso a una shell remota, lo que permitiría que los atacantes obtengan acceso raíz a nodos de VM. Los clientes de la nube privada de Edge son propietarios y administran las VMs o los hosts físicos en los que se implementa la nube privada de Edge.
¿Qué debo hacer? Revisa la versión de OpenSSH mediante la emisión del comando |
Crítico |
Edge Microgateway
| Descripción | Gravedad | Notas | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
Se descubrió hace poco una vulnerabilidad de ejecución de código remoto, CVE-2024-6387, en OpenSSH. La vulnerabilidad explota una condición de carrera que se puede usar para obtener acceso a una shell remota, lo que permitiría que los atacantes obtengan acceso raíz a nodos de VM. Los clientes de Edge Microgateway son propietarios y administran las VM o los hosts físicos en los que se implementa Edge Microgateway.
¿Qué debo hacer? Revisa la versión de OpenSSH mediante la emisión de los comandos |
Crítico |
Apigee
| Descripción | Gravedad | Notas |
|---|---|---|
|
Se detectó hace poco una vulnerabilidad de ejecución de código remoto, CVE-2024-6387, en OpenSSH. La vulnerabilidad explota una condición de carrera que se puede usar para obtener acceso a una shell remota, lo que permitiría que los atacantes obtengan acceso raíz a nodos de GKE. Al momento de la publicación, no se puede aprovechar Apigee y existen mitigaciones. Aunque no se puede aprovechar esta CVE, Apigee actualizará las cargas de trabajo para abordar la CVE-2024-6387. ¿Qué debo hacer? No se requiere ningún elemento de acción de los usuarios de Apigee. La aplicación de parches para cargas de trabajo se realizará en los próximos días y el boletín de seguridad se actualizará una vez que se complete la aplicación de parches. Nota: Si los grupos de instancias administrados se implementan en un proyecto de cliente para el balanceo de cargas ascendente, en particular InternalRouting (VPC) y ExternalRouting (MIG), verifica la versión de OpenSSH instalada en ellas. Si la versión es vulnerable a la CVE, actualiza a la versión 9.8p1 de OpenSSH publicada el 1 de julio de 2024 por tu cuenta, ya que Apigee no administra estos MIG. |
Crítico |
Apigee Hybrid
| Descripción | Gravedad | Notas | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
Se detectó hace poco una vulnerabilidad de ejecución de código remoto, CVE-2024-6387, en OpenSSH. La vulnerabilidad explota una condición de carrera que se puede usar para obtener acceso a una shell remota, lo que permitiría que los atacantes obtengan acceso raíz a nodos de GKE. Al momento de la publicación, las imágenes híbridas no son vulnerables porque OpenSSH no está empaquetado en ninguna de las imágenes de contenedor híbridos. Sin embargo, si tu SO host o nodo de GKE se ejecuta con las siguientes versiones vulnerables de OpenSSH, se podrán aprovechar los clústeres híbridos.
¿Qué debo hacer? Este problema se abordó en el Boletín de seguridad de Atención al cliente de Google Cloud GCP-2024-040. Para obtener instrucciones y más detalles, consulta los siguientes boletines:
|
Crítico |
GCP-2024-006
Publicado: 5 de febrero de 2024
| Descripción | Gravedad | Notas |
|---|---|---|
|
Cuando un proxy de administración de API de Apigee se conecta a un extremo de destino o a un servidor de destino, el proxy no realiza la validación del nombre de host para el certificado que presenta el extremo o el servidor de destino de forma predeterminada. Si la validación del nombre de host no está habilitada a través de una de las siguientes opciones, los proxies de Apigee que se conectan a un extremo o un servidor de destino pueden estar en riesgo de que un usuario autorizado reciba un ataque de intermediario. Para obtener más información, consulta Configura TLS del perímetro al backend (nube y nube privada). Productos afectados: Las implementaciones de proxies de Apigee en las siguientes plataformas de Apigee se ven afectadas:
¿Qué debo hacer? Los clientes pueden usar cualquiera de las siguientes opciones para habilitar esta validación: Opción 1: Agrega una configuración a tu proxy Para habilitar la validación del extremo o servidor de destino, agrega una configuración de <HTTPTargetConnection>
<SSLInfo>
<Enabled>true</Enabled>
<TrustStore>ref://mytruststoreref</TrustStore>
<CommonName>*.example.com</CommonName>
</SSLInfo>
<URL>https://my.example.com/</URL>
</HTTPTargetConnection>
Si esta configuración está presente en el elemento Apigee recomienda este enfoque. Puedes probar los proxies de forma individual para confirmar que la validación se ejecuta según lo previsto, con una interrupción potencial mínima en el tráfico. Para obtener más información sobre cómo probar la validación del nombre de host en tus proxies y ver fallas, consulta Usa la herramienta de seguimiento. Opción 2: establece una marca a nivel de la organización Puedes configurar una marca a nivel de la organización de Apigee para habilitar la validación del nombre de host para todos los proxies y destinos implementados en tu organización. Si la marca Nota: Si bien esta opción puede ayudarte a habilitar la función en toda la organización, pueden ocurrir fallas en la validación del nombre de host si los destinos no presentan los certificados esperados.
Apigee recomienda implementar primero este cambio en entornos que no son de producción para garantizar que la validación funcione según lo previsto y no provoque interrupciones de la producción. En el caso de que la validación del nombre de host falle para algún destino, se muestra el siguiente mensaje de error: {"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"}}}
|
Alta |
GCP-2023-032
Publicado 13 de octubre 2023
Última actualización: 3 de noviembre de 2023
| Descripción | Gravedad | Notas |
|---|---|---|
|
Actualización del 3 de noviembre de 2023: Se agregó un problema conocido de Apigee Edge para la nube privada. Hace poco tiempo, se descubrió una vulnerabilidad de denegación del servicio (DoS) en varias implementaciones del protocolo HTTP/2 (CVE-2023-44487), incluido el servicio de Ingress de Apigee (Cloud Service Mesh) que usó Apigee X y Apigee hybrid. La vulnerabilidad podría provocar un DoS de la funcionalidad de administración de la API de Apigee. Productos afectados:
Productos no afectados
¿Qué debo hacer?
¿Qué vulnerabilidad tratan estos parches? La vulnerabilidad, CVE-2023-44487, podría generar un DoS de la funcionalidad de administración de API de Apigee. |
Alta | CVE-2023-44487 |