Boletines de seguridad

A continuación, se describen 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-2025-023

Fecha de publicación: 5 de mayo de 2025

Descripción Gravedad Notas

En este boletín, se abordan las posibles brechas de seguridad que se podrían aprovechar si no se abordan en las políticas de JavaCallout y PythonScript que se descubrieron y abordaron. Estas políticas podrían provocar una ejecución de código remoto (RCE) no autorizada y elevación de privilegios dentro del entorno de ejecución de Apigee. Estos posibles exploits requieren acceso interno de usuarios autorizados (usuarios que tienen privilegios para implementar proxies). Estas posibles vulnerabilidades se deben a una zona de pruebas insuficiente para situaciones como el acceso por reflexión y la falsificación de objetos de permisos para eludir al administrador de seguridad.

Productos afectados:

El impacto se limita a las políticas de JavaCallout y PythonScript. Esto incluye las implementaciones en las siguientes plataformas de Apigee:

  • Apigee
  • Apigee Edge para la nube pública
  • Apigee Hybrid
  • Apigee Edge para la nube privada

¿Qué debo hacer?

Realiza las siguientes acciones para cada producto afectado:

Apigee

Los clientes que usan la versión de Apigee de Google Cloud no deben realizar ninguna acción. Se aplicaron correcciones de vulnerabilidades a la versión 1-14-0-apigee-8 de Apigee.

Si el equipo de lanzamientos no puede lanzar la versión para tus organizaciones, un TAM o un representante de asistencia al cliente se comunicará contigo para corregir los paquetes de proxy de JavaCallout afectados.

Apigee Hybrid

Debes actualizar a una de las siguientes versiones de parches de seguridad:

Versión principal híbrida Lanzamiento del parche de seguridad para la versión secundaria afectada
1.12 1.12.4
1.13 1.13.3
1.14 1.14.1
1.11 1.11.2 hotfix3
Alta

Apigee Edge para la nube pública

Los clientes de Apigee Edge no deben realizar ninguna acción. Se aplicaron correcciones al entorno de ejecución de Edge más reciente. Si eres un cliente que no puede actualizarse a la versión más reciente de Edge debido a elementos de acción pendientes conocidos, un representante del servicio de atención al cliente se comunicará contigo.

Apigee Edge para la nube privada

Si eres usuario de Edge para Private Cloud, debes revisar tus políticas de JavaCallout y PythonScript para asegurarte de usar código y bibliotecas de fuentes de confianza. Las modificaciones de estas políticas requieren acceso interno autorizado (usuarios que tienen permisos para implementar proxies), por lo que se recomienda que audites tus permisos para garantizar que solo los usuarios de confianza conserven ese acceso. Se aplicaron correcciones de vulnerabilidades a las versiones 4.52.02 y 4.53.00 de la nube privada de Edge.

GCP-2024-040

Se publicó: 2024-07-02

Este boletín incluye detalles específicos de cada uno de estos productos de Apigee:

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.

Versión Impacto
OpenSSH < 4.4p1 Vulnerable
4.4p1 <= OpenSSH < 8.5p1 No vulnerable
8.5p1 <= OpenSSH < 9.8p1 Vulnerable

¿Qué debo hacer?

Revisa la versión de OpenSSH mediante la emisión del comando ssh -V y valida la versión de OpenSSH. Si ejecutas en cualquier versión de OpenSSH que se vea afectada, actualiza a una versión que NO sea vulnerable a esta CVE. OpenSSH lanzó 9.8p1 el 1 de julio de 2024.

 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.

Versión Impacto
OpenSSH < 4.4p1 Vulnerable
4.4p1 <= OpenSSH < 8.5p1 No vulnerable
8.5p1 <= OpenSSH < 9.8p1 Vulnerable

¿Qué debo hacer?

Revisa la versión de OpenSSH mediante la emisión de los comandos ssh -V y valida la versión de OpenSSH. Si ejecutas en alguna versión de OpenSSH que se ve afectada, actualiza a una versión que NO sea vulnerable a esta CVE. OpenSSH lanzó 9.8p1 el 1 de julio de 2024.

 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.

Versión Impacto
OpenSSH < 4.4p1 Vulnerable
4.4p1 <= OpenSSH < 8.5p1 No vulnerable
8.5p1 <= OpenSSH < 9.8p1 Vulnerable

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

  • Apigee Edge para la nube pública
  • Apigee Edge para la nube privada

¿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 <CommonName> a la sección SSLInfo del elemento <HTTPTargetConnection> en la configuración del proxy como se muestra a continuación:

<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 <HTTPTargetConnection> de la configuración del proxy, Apigee usará el valor especificado en <CommonName> para la validación del nombre de host. Se pueden usar comodines en este campo.

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 features.strictSSLEnforcement se establece como true en las propiedades de la organización, la validación del nombre de host se aplicará de manera forzosa cada vez que el proxy se conecte a un extremo o servidor de destino.

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.

  • Para implementaciones de Apigee Edge para la nube pública, haz lo siguiente:

    Comunícate con el equipo de asistencia deGoogle Cloud para que la marca features.strictSSLEnforcement se configure como true en las propiedades de la organización.

    Nota: Habilitar esta marca hará que se aplique la verificación de SSL a todos los entornos de una organización y a todos los proxies implementados dentro de esos entornos.

  • Para implementaciones de Apigee Edge para la nube privada , haz lo siguiente:

    La organización o el administrador del sistema pueden configurar la marca features.strictSSLEnforcement como true. Para obtener más información sobre cómo configurar la marca, consulta Actualiza las propiedades de la organización.

    Nota: Cuando actualices las marcas a nivel de la organización a través de la API de organizaciones, asegúrate de incluir todas las marcas existentes en tu solicitud POST para evitar reemplazar la configuración anterior.

    Una vez configurada la marca, cada procesador de mensajes debe reiniciarse de forma individual para que se aplique el cambio. Usa el siguiente comando:

    apigee-service edge-message-processor restart

    Para revertir este cambio, usa la misma API de organizaciones para establecer la marca en false y, luego, reinicia cada procesador de mensajes.

    Nota: Habilitar esta marca hará que se aplique la verificación de SSL a todos los entornos de una organización y a todos los proxies implementados dentro de esos entornos. Sin embargo, si <IgnoreValidationErrors> se configura como true, se ignorarán los errores de validación detectados.

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:

  • Apigee X

    Las implementaciones de Apigee X a las que se puede acceder a través de un balanceador de cargas de red de Google Cloud (capa 4) o un balanceador de cargas de capa 4 personalizado se ven afectadas. Se aplicó un parche rápido a todas las instancias de Apigee X.

  • Apigee Hybrid

    Las instancias de Apigee hybrid que permiten que las solicitudes HTTP/2 lleguen a Ingress de Apigee se ven afectadas. Los clientes deben verificar si los balanceadores de cargas que priorizan sus entradas de Apigee hybrid permiten que las solicitudes HTTP/2 lleguen al servicio de Apigee Ingress.

  • Apigee Edge para la nube privada

    Los componentes del servidor de administración y el router de la nube privada están expuestos a Internet y pueden ser vulnerables. Aunque HTTP/2 está habilitado en el puerto de administración de otros componentes específicos de Edge para la nube privada, ninguno de esos componentes está expuesto a Internet. En componentes que no son de Edge, como Cassandra, Zookeeper y otros, HTTP/2 no está habilitado. Te recomendamos que sigas los pasos de Problemas conocidos con Edge para la nube privada a fin de abordar la vulnerabilidad de Edge para la nube privada.

Productos no afectados

  • Apigee X

    Las instancias de Apigee X a las que solo se accede a través de los balanceadores de cargas de aplicaciones de Google Cloud(capa 7) no se ven afectadas. Esto incluye implementaciones que tienen habilitado HTTP/2 para proxies de gRPC.

  • Google Cloud API Gateway

    La puerta de enlace de APIs deGoogle Cloud no se ve afectada.

  • Apigee Edge Cloud

    Apigee Edge Cloud no se ve afectado por esta vulnerabilidad.

¿Qué debo hacer?

  • Apigee X

    Actualización del 3 de noviembre de 2023: La vulnerabilidad se abordó mediante la actualización a las instancias de Apigee X que se lanzó el 13 de octubre de 2023. Consulta las notas de la versión para obtener información más detallada.

  • Apigee Hybrid

    Los clientes de Apigee hybrid deberán actualizar a una de las siguientes versiones de parche:

  • Apigee Edge para la nube privada

    Los usuarios de Apigee Edge for Private Cloud pueden seguir las instrucciones publicadas en Problemas conocidos con Edge for Private Cloud para la inhabilitación explícita de HTTP/2 para los componentes expuestos.

¿Qué vulnerabilidad tratan estos parches?

La vulnerabilidad, CVE-2023-44487, podría provocar un DoS de la funcionalidad de administración de la API de Apigee.

Alta CVE-2023-44487