Boletines de seguridad

A continuación, se describen los boletines de seguridad relacionados con Apigee.

Para recibir los últimos boletines de seguridad, tienes estas opciones:

  • Añade la URL de esta página a tu lector de feeds.
  • Añade la URL del feed directamente a tu lector de feeds: https://cloud.google.com/feeds/apigee-security-bulletins.xml.

GCP-2025-023

Publicación: 05/05/2025

Descripción Gravedad Notas

En este boletín se abordan posibles vulnerabilidades de seguridad que podrían explotarse si no se solucionan en las políticas JavaCallout y PythonScript que se han descubierto y solucionado. Estas políticas podrían provocar una ejecución remota de código (RCE) no autorizada y una apropiación de privilegios en el entorno de tiempo de ejecución de Apigee. Para aprovechar estas posibles vulnerabilidades, se necesita acceso interno de usuarios autorizados (usuarios que tengan privilegios para implementar proxies). Estas posibles vulnerabilidades se deben a un aislamiento insuficiente en escenarios como el acceso por reflexión y la suplantación de objetos de permisos para eludir el gestor de seguridad.

Productos afectados

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

  • Apigee
  • Apigee Edge para nubes públicas
  • Apigee Hybrid
  • Apigee Edge para nubes privadas

¿Qué debo hacer?

Realice las siguientes acciones para cada producto afectado:

Apigee

Los clientes que usen la versión de Google Cloud de Apigee no tienen que hacer nada. Se han aplicado correcciones de vulnerabilidades a la versión 1-14-0-apigee-8 de Apigee.

Si el equipo de lanzamiento no puede implementar la versión en tus organizaciones, un gestor de cuentas técnicas o un representante del equipo de Asistencia se pondrá en contacto contigo para corregir los paquetes proxy de JavaCallout afectados.

Apigee Hybrid

Debes actualizar a una de las siguientes versiones del parche de seguridad:

Versión principal de Hybrid 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 nubes públicas

Los clientes de Apigee Edge no tienen que hacer nada. Se han aplicado correcciones al tiempo 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 asistencia se pondrá en contacto contigo.

Apigee Edge para nubes privadas

Si eres usuario de Edge para Nube privada, debes revisar tus políticas JavaCallout y PythonScript para asegurarte de que utilizas código y bibliotecas de fuentes fiables. Para modificar estas políticas, se necesita acceso interno autorizado (usuarios que tengan permisos para implementar proxies), por lo que te recomendamos que audites tus permisos para asegurarte de que solo los usuarios de confianza conserven dicho acceso. Se han aplicado correcciones de vulnerabilidades a las versiones 4.52.02 y 4.53.00 de Edge Private Cloud.

GCP-2024-040

Publicación: 02/07/2024

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

Edge Public Cloud

Descripción Gravedad Notas

Hace poco se ha descubierto una vulnerabilidad de ejecución remota de código, CVE-2024-6387, en OpenSSH. La vulnerabilidad aprovecha una condición de carrera que se podría usar para obtener acceso a una shell remota, lo que permitiría a los atacantes obtener acceso root a los nodos de GKE. En el momento de la publicación, Apigee Edge para nube pública no se puede aprovechar y se han implementado medidas de mitigación.

Aunque esta CVE no se puede aprovechar, Apigee actualizará las cargas de trabajo para solucionar la CVE anterior.

¿Qué debo hacer?

Los usuarios de Apigee no tienen que hacer nada.

En los próximos días se aplicarán los parches a las cargas de trabajo y se actualizará el boletín de seguridad cuando se hayan completado.

 Crítica

Edge Private Cloud

Descripción Gravedad

Hace poco se ha descubierto una vulnerabilidad de ejecución remota de código, CVE-2024-6387, en OpenSSH. La vulnerabilidad aprovecha una condición de carrera que se podría usar para obtener acceso a una shell remota, lo que permitiría a los atacantes obtener acceso root a los nodos de la VM. Los clientes de Edge Private Cloud son propietarios y gestionan las máquinas virtuales o los hosts físicos en los que se implementa Edge Private Cloud.

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 con el comando ssh -V y valida la versión de OpenSSH. Si usas alguna de las versiones de OpenSSH afectadas, actualiza a una versión que NO sea vulnerable a este CVE. OpenSSH ha lanzado la versión 9.8p1 el 1 de julio del 2024.

 Crítica

Edge Microgateway

Descripción Gravedad Notas

Hace poco se ha descubierto una vulnerabilidad de ejecución remota de código, CVE-2024-6387, en OpenSSH. La vulnerabilidad aprovecha una condición de carrera que se podría usar para obtener acceso a una shell remota, lo que permitiría a los atacantes obtener acceso root a los nodos de la VM. Los clientes de Edge Microgateway son propietarios y gestionan las máquinas virtuales 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 con los comandos ssh -V y valida la versión de OpenSSH. Si usas alguna de las versiones de OpenSSH afectadas, actualiza a una versión que NO sea vulnerable a este CVE. OpenSSH ha lanzado la versión 9.8p1 el 1 de julio del 2024.

 Crítica

Apigee

Descripción Gravedad Notas

Hace poco se ha descubierto una vulnerabilidad de ejecución remota de código, CVE-2024-6387, en OpenSSH. La vulnerabilidad aprovecha una condición de carrera que se podría usar para obtener acceso a una shell remota, lo que permitiría a los atacantes obtener acceso root a los nodos de GKE. En el momento de la publicación, Apigee no se puede aprovechar y se han implementado medidas de mitigación.

Aunque esta CVE no se puede aprovechar, Apigee actualizará las cargas de trabajo para solucionar la CVE-2024-6387.

¿Qué debo hacer?

Los usuarios de Apigee no tienen que hacer nada. El parcheo de las cargas de trabajo se realizará en los próximos días y el boletín de seguridad se actualizará cuando se haya completado.

Nota: Si los grupos de instancias gestionados se implementan en un proyecto de cliente para el balanceo de carga de entrada, concretamente InternalRouting (VPC) y ExternalRouting (MIG), comprueba la versión de OpenSSH instalada en ellos. Si la versión es vulnerable a la CVE, actualiza a OpenSSH versión 9.8p1, publicada el 1 de julio del 2024, ya que Apigee no gestiona estos MIGs.

Crítica

Apigee Hybrid

Descripción Gravedad Notas

Hace poco se ha descubierto una vulnerabilidad de ejecución remota de código, CVE-2024-6387, en OpenSSH. La vulnerabilidad aprovecha una condición de carrera que se podría usar para obtener acceso a una shell remota, lo que permitiría a los atacantes obtener acceso root a los nodos de GKE. En el momento de la publicación, las imágenes híbridas no son vulnerables porque OpenSSH no se incluye en ninguna de las imágenes de contenedor híbridas. Sin embargo, si el SO de tu host o nodo de GKE se ejecuta con las versiones vulnerables de OpenSSH que se indican a continuación, tus clústeres híbridos serán vulnerables.

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 ha solucionado en el boletín de seguridad GCP-2024-040 de Atención al Cliente de Google Cloud.

Para obtener instrucciones y más información, consulta los siguientes boletines:

 Crítica

GCP-2024-006

Publicación: 5/2/2024

Descripción Gravedad Notas

Cuando un proxy de gestión de APIs de Apigee se conecta a un endpoint de destino o a un servidor de destino, el proxy no valida el nombre de host del certificado presentado por el endpoint o el servidor de destino de forma predeterminada. Si la validación del nombre de host no está habilitada mediante una de las siguientes opciones, las proxies de Apigee que se conectan a un endpoint de destino o a un servidor de destino pueden estar en riesgo de sufrir un ataque de intermediario por parte de un usuario autorizado. Para obtener más información, consulta el artículo Configurar TLS desde el perímetro hasta el backend (Cloud y Private Cloud).

Productos afectados

Las implementaciones de proxies de Apigee en las siguientes plataformas de Apigee se ven afectadas:

  • Apigee Edge para nubes públicas
  • Apigee Edge para nubes privadas

¿Qué debo hacer?

Los clientes pueden utilizar cualquiera de las siguientes opciones para habilitar esta validación:

Opción 1: Añadir una configuración a tu proxy

Para habilitar la validación de tu endpoint o servidor de destino, añade una configuración <CommonName> a la sección SSLInfo del elemento <HTTPTargetConnection> en tu configuración de proxy, tal 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 de tu proxy, Apigee usará el valor especificado en <CommonName> para la validación del nombre de host. En este campo se pueden usar comodines.

Apigee recomienda este enfoque. Puedes probar los proxies individualmente para confirmar que la validación funciona correctamente y que el tráfico no se verá afectado. Para obtener más información sobre cómo probar la validación de nombres de host en tus proxies y ver los errores, consulta Usar la herramienta de seguimiento.

Opción 2: Definir una marca a nivel de organización

Puedes definir una marca a nivel de organización de Apigee para habilitar la validación de nombres de host en todos los proxies y destinos implementados de tu organización. Si la marca features.strictSSLEnforcement se define como true en las propiedades de la organización, la validación del nombre de host se aplicará cada vez que el proxy se conecte a un endpoint o servidor de destino.

Nota: Aunque esta opción puede ayudarte a habilitar la función en toda la organización, pueden producirse errores de validación del nombre de host si tus destinos no presentan los certificados esperados.

  • En las implementaciones de Apigee Edge Public Cloud,

    Ponte en contacto con el Google Cloud equipo de Asistencia para que se defina el valor true en la propiedad features.strictSSLEnforcement de la organización.

    Nota: Si habilitas esta marca, se aplicará la comprobación SSL a todos los entornos de una organización y a todos los proxies implementados en esos entornos.

  • En las implementaciones de Apigee Edge para nubes privadas :

    El administrador de la organización o del sistema puede asignar el valor true a la marca features.strictSSLEnforcement . Para obtener más información sobre cómo definir la marca, consulta Actualizar las propiedades de la organización.

    Nota: Cuando actualice las marcas a nivel de organización mediante la API Organizations, asegúrese de incluir todas las marcas en su solicitud POST para evitar que se sobrescriban los ajustes de configuración anteriores.

    Una vez que se haya definido la marca, cada procesador de mensajes debe reiniciarse individualmente para que el cambio surta efecto. Usa el siguiente comando:

    apigee-service edge-message-processor restart

    Para deshacer este cambio, usa la misma API Organizations para asignar el valor false a la marca y, a continuación, reinicia cada procesador de mensajes.

    Nota: Si habilitas esta marca, se aplicará la comprobación SSL a todos los entornos de una organización y a todos los proxies implementados en esos entornos. Sin embargo, si <IgnoreValidationErrors> se define como true, se ignorarán los errores de validación que se detecten.

Apigee recomienda implementar este cambio primero en entornos que no sean de producción para asegurarse de que la validación funciona correctamente y no provoca interrupciones en la producción. Si no se puede validar el nombre de host de algún destino, se devuelve 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

Publicación: 13/10/2023

Fecha de actualización: 2023-11-03

Descripción Gravedad Notas

Actualización del 3 de noviembre del 2023: se ha añadido un problema conocido de Apigee Edge para nubes privadas.

Recientemente, se ha descubierto una vulnerabilidad de denegación de servicio (DoS) en varias implementaciones del protocolo HTTP/2 (CVE-2023-44487), incluido el servicio Apigee Ingress (Cloud Service Mesh) que usan Apigee X y Apigee hybrid. La vulnerabilidad podría provocar una denegación de servicio de la función de gestión de APIs de Apigee.

Productos afectados

  • Apigee X

    Las implementaciones de Apigee X a las que se puede acceder a través de un Google Cloud balanceador de carga de red (capa 4) o de un balanceador de carga de capa 4 personalizado se ven afectadas. Se ha aplicado una corrección a todas las instancias de Apigee X.

  • Apigee hybrid

    Las instancias de Apigee Hybrid que permiten que las solicitudes HTTP/2 lleguen a Apigee Ingress se ven afectadas. Los clientes deben verificar si los balanceadores de carga que están delante de sus Ingresses híbridos de Apigee permiten que las solicitudes HTTP/2 lleguen al servicio Ingress de Apigee.

  • Apigee Edge para nubes privadas

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

Productos no afectados

  • Apigee X

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

  • Google Cloud API Gateway

    Google Cloud API Gateway no se ve afectado.

  • Apigee Edge Cloud

    Esta vulnerabilidad no afecta a Apigee Edge Cloud.

¿Qué debo hacer?

  • Apigee X

    Actualización del 3 de noviembre del 2023: la vulnerabilidad se ha solucionado mediante la actualización de las instancias de Apigee X que se lanzó el 13 de octubre del 2023. Para obtener más información, consulte las notas de la versión.

  • Apigee hybrid

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

  • Apigee Edge para nubes privadas

    Los usuarios de Apigee Edge para nubes privadas pueden seguir las instrucciones publicadas en Problemas conocidos de Edge para nubes privadas para inhabilitar explícitamente HTTP/2 en los componentes expuestos.

¿Qué vulnerabilidades solucionan estos parches?

La vulnerabilidad CVE-2023-44487 podría provocar una denegación de servicio de la función de gestión de APIs de Apigee.

Alta CVE-2023-44487