Boletines de seguridad

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-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 de Google 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"}}}
Alto

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 (Anthos Service Mesh) que usó Apigee X y Apigee hybrid. La vulnerabilidad podría provocar un DoS de la funcionalidad de administración de 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.

  • Puerta de enlace de APIs de Google Cloud

    La puerta de enlace de APIs de Google 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 generar un DoS de la funcionalidad de administración de API de Apigee.

Alta CVE-2023-44487