Boletins de segurança

A seguinte descrição refere-se aos boletins de segurança relacionados com o Apigee.

Para receber os boletins de segurança mais recentes, faça uma das seguintes ações:

  • Adicione o URL desta página ao seu leitor de feeds.
  • Adicione o URL do feed diretamente ao seu leitor de feeds: https://cloud.google.com/feeds/apigee-security-bulletins.xml

GCP-2025-023

Publicado: 2025-05-05

Descrição Gravidade Notas

Este boletim aborda potenciais lacunas de segurança que poderiam ser exploradas se não fossem resolvidas nas políticas JavaCallout e PythonScript que foram descobertas e resolvidas. Estas políticas podem levar à execução de código remoto (RCE) não autorizado e à escalada de privilégios no ambiente de tempo de execução do Apigee. Estas possíveis explorações requerem acesso de utilizadores autorizados internos (utilizadores com privilégios para implementar proxies) para serem exploradas. Estas potenciais vulnerabilidades resultam de uma sandbox insuficiente para cenários como o acesso por reflexão e a falsificação de objetos de autorização para contornar o gestor de segurança.

Produtos afetados

O impacto está confinado às políticas JavaCallout e PythonScript. Isto inclui implementações nas seguintes plataformas Apigee:

  • Apigee
  • Apigee Edge para nuvem pública
  • Apigee Hybrid
  • Apigee Edge para nuvem privada

O que devo fazer?

Tome as seguintes medidas para cada produto afetado:

Apigee

Não é necessária nenhuma ação para os clientes que usam a versão do Google Cloud do Apigee. As correções de vulnerabilidades foram aplicadas à versão 1-14-0-apigee-8 do Apigee.

Se a equipa de lançamento não conseguir implementar o lançamento para as suas organizações, um TAM ou um representante do apoio técnico entra em contacto consigo para corrigir todos os pacotes de proxy JavaCallout afetados.

Apigee Hybrid

Tem de atualizar para uma das seguintes versões do patch de segurança:

Versão principal híbrida Lançamento de patch de segurança para a versão secundária afetada
1.12 1.12.4
1.13 1.13.3
1.14 1.14.1
1.11 1.11.2 hotfix3
Alto

Apigee Edge para nuvem pública

Não é necessária nenhuma ação por parte dos clientes do Apigee Edge. As correções foram aplicadas ao runtime do Edge mais recente. Se for um cliente cuja versão do Edge não pode ser atualizada para a versão mais recente devido a itens de ação pendentes conhecidos, um representante do apoio ao cliente vai entrar em contacto consigo.

Apigee Edge para nuvem privada

Se for um utilizador do Edge for Private Cloud, deve rever as suas políticas JavaCallout e PythonScript para garantir que está a usar código e bibliotecas de fontes fidedignas. As modificações a estas políticas requerem acesso autorizado interno (utilizadores com autorizações para implementar proxies). Por isso, recomendamos que audite as suas autorizações para garantir que apenas os utilizadores fidedignos mantêm esse acesso. Foram aplicadas correções de vulnerabilidades às versões 4.52.02 e 4.53.00 do Edge Private Cloud.

GCP-2024-040

Publicado: 02/07/2024

Este boletim inclui detalhes específicos de cada um destes produtos do Apigee:

Nuvem pública do Edge

Descrição Gravidade Notas

Foi descoberta recentemente uma vulnerabilidade de execução remota de código, CVE-2024-6387, no OpenSSH. A vulnerabilidade explora uma condição de concorrência que pode ser usada para obter acesso a um shell remoto, permitindo que os atacantes obtenham acesso de raiz aos nós do GKE. No momento da publicação, o Apigee Edge para a nuvem pública não é explorável e existem mitigações em vigor.

Embora esta CVE não seja explorável, o Apigee vai atualizar as cargas de trabalho para resolver a CVE acima.

O que devo fazer?

Não é necessária nenhuma ação por parte dos utilizadores do Apigee.

A aplicação de patches para cargas de trabalho vai ser feita nos próximos dias e o boletim de segurança vai ser atualizado quando a aplicação de patches estiver concluída.

 Crítico

Nuvem privada do Edge

Descrição Gravidade

Foi descoberta recentemente uma vulnerabilidade de execução remota de código, CVE-2024-6387, no OpenSSH. A vulnerabilidade explora uma condição de corrida que pode ser usada para obter acesso a um shell remoto, o que permite aos atacantes obter acesso de raiz aos nós da VM. Os clientes da nuvem privada do Edge são proprietários e gerem as VMs/hosts físicos onde a nuvem privada do Edge está implementada.

Versão Impacto
OpenSSH < 4.4p1 Vulnerável
4.4p1 <= OpenSSH < 8.5p1 Não vulnerável
8.5p1 <= OpenSSH < 9.8p1 Vulnerável

O que devo fazer?

Reveja a versão do OpenSSH emitindo o comando ssh -V e valide a versão do OpenSSH. Se estiver a usar alguma versão do OpenSSH afetada, atualize para uma versão que NÃO seja vulnerável a esta CVE. O OpenSSH lançou a versão 9.8p1 a 1 de julho de 2024.

 Crítico

Edge Microgateway

Descrição Gravidade Notas

Foi descoberta recentemente uma vulnerabilidade de execução remota de código, CVE-2024-6387, no OpenSSH. A vulnerabilidade explora uma condição de corrida que pode ser usada para obter acesso a um shell remoto, o que permite aos atacantes obter acesso de raiz aos nós da VM. Os clientes do Edge Microgateway são proprietários e gerem as VMs/hosts físicos onde o Edge Microgateway está implementado.

Versão Impacto
OpenSSH < 4.4p1 Vulnerável
4.4p1 <= OpenSSH < 8.5p1 Não vulnerável
8.5p1 <= OpenSSH < 9.8p1 Vulnerável

O que devo fazer?

Reveja a versão do OpenSSH emitindo os comandos ssh -V e valide a versão do OpenSSH. Se estiver a usar alguma das versões do OpenSSH afetadas, atualize para uma versão que NÃO seja vulnerável a esta CVE. O OpenSSH lançou a versão 9.8p1 a 1 de julho de 2024.

 Crítico

Apigee

Descrição Gravidade Notas

Foi descoberta recentemente uma vulnerabilidade de execução remota de código, CVE-2024-6387, no OpenSSH. A vulnerabilidade explora uma condição de concorrência que pode ser usada para obter acesso a um shell remoto, permitindo que os atacantes obtenham acesso de raiz aos nós do GKE. No momento da publicação, o Apigee não é explorável e existem mitigações em vigor.

Embora esta CVE não seja explorável, o Apigee vai atualizar as cargas de trabalho para resolver a CVE-2024-6387.

O que devo fazer?

Não é necessária nenhuma ação por parte dos utilizadores do Apigee. A aplicação de patches para as cargas de trabalho vai ser feita nos próximos dias e o boletim de segurança vai ser atualizado quando a aplicação de patches estiver concluída.

Nota: se os grupos de instâncias geridos forem implementados num projeto de cliente para o balanceamento de carga northbound, especificamente InternalRouting (VPC) e ExternalRouting (MIG), verifique a versão do OpenSSH instalada nos mesmos. Se a versão for vulnerável ao CVE, atualize para o OpenSSH versão 9.8p1 lançado a 1 de julho de 2024 por si, uma vez que o Apigee não gere estes MIGs.

Crítico

Apigee Hybrid

Descrição Gravidade Notas

Foi descoberta recentemente uma vulnerabilidade de execução remota de código, CVE-2024-6387, no OpenSSH. A vulnerabilidade explora uma condição de concorrência que pode ser usada para obter acesso a uma shell remota, o que permite aos atacantes obter acesso de raiz aos nós do GKE. No momento da publicação, as imagens híbridas não são vulneráveis porque o OpenSSH não está incluído em nenhuma das imagens de contentores híbridos. No entanto, se o SO do anfitrião/nó do GKE estiver a ser executado com as versões vulneráveis do OpenSSH abaixo, os seus clusters híbridos serão exploráveis.

Versão Impacto
OpenSSH < 4.4p1 Vulnerável
4.4p1 <= OpenSSH < 8.5p1 Não vulnerável
8.5p1 <= OpenSSH < 9.8p1 Vulnerável

O que devo fazer?

Este problema foi resolvido no boletim de segurança do Google Cloud Customer Care GCP-2024-040.

Para ver instruções e mais detalhes, consulte os seguintes boletins:

 Crítico

GCP-2024-006

Publicado: 2024-2-5

Descrição Gravidade Notas

Quando um proxy de gestão de APIs do Apigee se liga a um ponto final de destino ou a um servidor de destino, o proxy não faz a validação do nome do anfitrião para o certificado apresentado pelo ponto final de destino ou pelo servidor de destino por predefinição. Se a validação do nome de anfitrião não estiver ativada através de uma das seguintes opções, os proxies do Apigee que se ligam a um ponto final de destino ou a um servidor de destino podem estar em risco de um ataque man-in-the-middle por um utilizador autorizado. Para mais informações, consulte o artigo Configurar o TLS a partir da extremidade para o back-end (nuvem e nuvem privada).

Produtos afetados

As implementações de proxy do Apigee nas seguintes plataformas do Apigee são afetadas:

  • Apigee Edge para nuvem pública
  • Apigee Edge para nuvem privada

O que devo fazer?

Os clientes podem usar qualquer uma das seguintes opções para ativar esta validação:

Opção 1: adicione uma configuração ao seu proxy

Pode ativar a validação do ponto final de destino ou do servidor de destino adicionando uma configuração <CommonName> à secção SSLInfo do elemento <HTTPTargetConnection> na configuração do proxy, conforme mostrado:

<HTTPTargetConnection>
  <SSLInfo>
    <Enabled>true</Enabled>
    <TrustStore>ref://mytruststoreref</TrustStore>
    <CommonName>*.example.com</CommonName>
  </SSLInfo>
  <URL>https://my.example.com/</URL>
</HTTPTargetConnection>

Se esta configuração estiver presente no elemento <HTTPTargetConnection> da configuração do proxy, o Apigee usa o valor especificado em <CommonName> para a validação do nome do anfitrião. Podem ser usados carateres universais neste campo.

A Apigee recomenda esta abordagem. Pode testar os proxies individualmente para confirmar que a validação está a funcionar como previsto, com uma potencial interrupção mínima do tráfego. Para mais informações sobre como testar a validação do nome do anfitrião nos seus proxies e ver falhas, consulte o artigo Usar a ferramenta de rastreio.

Opção 2: defina uma flag ao nível da organização

Pode definir uma flag ao nível da organização do Apigee para ativar a validação do nome do anfitrião para todos os proxies e destinos implementados na sua organização. Se a flag features.strictSSLEnforcement estiver definida como true nas propriedades da organização, a validação do nome do anfitrião é aplicada sempre que o proxy se liga a um ponto final de destino ou a um servidor de destino.

Nota: embora esta opção possa ajudar a ativar a funcionalidade em toda a organização, podem ocorrer falhas de validação do nome do anfitrião se os seus alvos não apresentarem os certificados esperados.

  • Para implementações do Apigee Edge para nuvem pública:

    Contacte o Google Cloud apoio técnico para que a flag features.strictSSLEnforcement seja definida como true nas propriedades da organização.

    Nota: a ativação desta flag aplica a verificação SSL a todos os ambientes numa organização e a todos os proxies implementados nesses ambientes.

  • Para implementações do Apigee Edge para nuvem privada :

    A flag features.strictSSLEnforcement pode ser definida como true pela organização ou pelo administrador do sistema. Para mais informações sobre como definir a flag, consulte o artigo Atualizar propriedades da organização.

    Nota: quando atualizar as flags ao nível da organização através da API Organizations, certifique-se de que inclui todas as flags existentes no seu pedido POST para evitar substituir as definições de configuração anteriores.

    Depois de definir a flag, cada processador de mensagens tem de ser reiniciado individualmente para que a alteração entre em vigor. Use o seguinte comando:

    apigee-service edge-message-processor restart

    Para reverter esta alteração, use a mesma API Organizations para definir a flag como false e, em seguida, reinicie cada processador de mensagens.

    Nota: a ativação desta flag aplica a verificação SSL a todos os ambientes numa organização e a todos os proxies implementados nesses ambientes. No entanto, se <IgnoreValidationErrors> estiver definido como true, todos os erros de validação detetados são ignorados.

A Apigee recomenda que implemente esta alteração primeiro em ambientes de não produção para garantir que a validação funciona como esperado e não resulta em interrupções de produção. Caso a validação do nome do anfitrião falhe para quaisquer destinos, é devolvida a seguinte mensagem de falha:

{"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/10/2023

Atualizado: 03/11/2023

Descrição Gravidade Notas

Atualização de 03-11-2023: adicionámos um problema conhecido para o Apigee Edge para nuvem privada.

Foi recentemente descoberta uma vulnerabilidade de negação de serviço (DoS) em várias implementações do protocolo HTTP/2 (CVE-2023-44487), incluindo o serviço Apigee Ingress (Cloud Service Mesh) usado pelo Apigee X e pelo Apigee hybrid. A vulnerabilidade pode levar a um DoS da funcionalidade de gestão de APIs da Apigee.

Produtos afetados

  • Apigee X

    As implementações do Apigee X acessíveis através de um Google Cloud Network Load Balancer (camada 4) ou um balanceador de carga de camada 4 personalizado são afetadas. Foi aplicada uma correção rápida a todas as instâncias do Apigee X.

  • Apigee Hybrid

    As instâncias híbridas do Apigee que permitem que os pedidos HTTP/2 alcancem o Apigee Ingress são afetadas. Os clientes devem verificar se os balanceadores de carga que estão à frente das entradas híbridas do Apigee permitem que as solicitações HTTP/2 alcancem o serviço de entrada do Apigee.

  • Apigee Edge para nuvem privada

    Os componentes do router e do servidor de gestão do Edge for Private Cloud estão expostos à Internet e podem ser potencialmente vulneráveis. Embora o HTTP/2 esteja ativado na porta de gestão de outros componentes específicos do Edge para a nuvem privada, nenhum desses componentes está exposto à Internet. Nos componentes que não são do Edge, como o Cassandra, o Zookeeper e outros, o HTTP/2 não está ativado. Recomendamos que siga os passos descritos em Problemas conhecidos com o Edge para a nuvem privada para resolver a vulnerabilidade do Edge para a nuvem privada.

Produtos não afetados

  • Apigee X

    As instâncias do Apigee X acedidas apenas através de Google Cloud equilibradores de carga de aplicações (camada 7) não são afetadas. Isto inclui implementações que têm o HTTP/2 ativado para proxies gRPC.

  • Google Cloud API Gateway

    Google Cloud O gateway da API não é afetado.

  • Apigee Edge Cloud

    O Apigee Edge Cloud não é afetado por esta vulnerabilidade.

O que devo fazer?

  • Apigee X

    Atualização de 3 de novembro de 2023: a vulnerabilidade foi resolvida através da atualização das instâncias do Apigee X lançada a 13 de outubro de 2023. Consulte as Notas de lançamento para ver detalhes.

  • Apigee Hybrid

    Os clientes do Apigee hybrid têm de atualizar para uma das seguintes versões de patch:

  • Apigee Edge para nuvem privada

    Os utilizadores do Apigee Edge para nuvem privada podem seguir as instruções publicadas em Problemas conhecidos com o Edge para nuvem privada para desativar explicitamente o HTTP/2 para componentes expostos.

Que vulnerabilidades são abordadas por estas correções?

A vulnerabilidade, CVE-2023-44487, pode levar a um DoS da funcionalidade de gestão de APIs do Apigee.

Alto CVE-2023-44487