Boletins de segurança

Confira a seguir os boletins de segurança relacionados ao Apigee.

Para receber os boletins de segurança mais recentes:

  • 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 em: 05/05/2025

Descrição Gravidade Observações

Este boletim aborda possíveis falhas de segurança que poderiam ser exploradas se não fossem resolvidas nas políticas JavaCallout e PythonScript descobertas e corrigidas. Essas políticas podem levar à execução remota de código (RCE) não autorizada e ao escalonamento de privilégios no ambiente de execução do Apigee. Esses possíveis exploits exigem acesso interno de usuários autorizados (usuários com privilégio para implantar proxies). Essas possíveis vulnerabilidades decorrem de sandboxing insuficiente para cenários como acesso por reflexão e falsificação de objetos de permissão para burlar o gerenciador de segurança.

Produtos afetados

O impacto é limitado às políticas JavaCallout e PythonScript. Isso inclui implantações nas seguintes plataformas da Apigee:

  • Apigee
  • Apigee Edge para nuvem pública
  • Apigee híbrido
  • Apigee Edge para nuvem privada

O que devo fazer?

Faça o seguinte para cada produto afetado:

Apigee

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

Se a equipe de lançamento não conseguir fazer o lançamento para suas organizações, um TAM ou um representante de suporte vai entrar em contato com você para corrigir os pacotes de proxy JavaCallout afetados.

Apigee híbrido

Faça upgrade para uma das seguintes versões de 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
Alta

Apigee Edge para nuvem pública

Os clientes do Apigee Edge não precisam fazer nada. As correções foram aplicadas ao ambiente de execução do Edge mais recente. Se você for um cliente que não pode ser atualizado para a versão mais recente do Edge devido a itens de ação pendentes conhecidos, um representante de suporte ao cliente vai entrar em contato com você.

Apigee Edge para nuvem privada

Se você usa o Edge para nuvem privada, revise as políticas JavaCallout e PythonScript para garantir que está usando código e bibliotecas de fontes confiáveis. As modificações nessas políticas exigem acesso interno autorizado (usuários com permissões para implantar proxies). Por isso, recomendamos que você audite suas permissões para garantir que apenas usuários confiáveis mantenham esse acesso. As correções de vulnerabilidade foram aplicadas às versões 4.52.02 e 4.53.00 da nuvem privada do Edge.

GCP-2024-040

Publicado: 2024-07-02

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

Nuvem pública Edge

Descrição Gravidade Observações

Recentemente, uma vulnerabilidade de execução remota de código, a CVE-2024-6387, foi descoberta no OpenSSH. Ela explora uma disputa que pode ser usada para acessar um shell remoto, o que dá aos invasores acesso raiz aos nós do GKE. No momento da publicação da Apigee, o Apigee Edge para nuvem pública não pode ser explorado e as mitigações estão em vigor.

Mesmo que essa CVE não seja explorável, a Apigee vai atualizar as cargas de trabalho para lidar com a CVE acima.

O que fazer?

Os usuários da Apigee não precisam realizar nenhuma ação.

A correção das cargas de trabalho será feita nos próximos dias e o boletim de segurança será atualizado assim que a aplicação do patch for concluída.

 Crítico

Nuvem privada Edge

Descrição Gravidade

Recentemente, uma vulnerabilidade de execução remota de código, a CVE-2024-6387, foi descoberta no OpenSSH. Ela explora uma disputa que pode ser usada para acessar um shell remoto, o que dá aos invasores acesso raiz aos nós da VM. Os clientes de nuvem privada do Edge têm e gerenciam as VMs/hosts físicos em que a nuvem privada do Edge está implantada.

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 fazer?

Analise a versão do OpenSSH emitindo o comando ssh -V e valide a versão do OpenSSH. Se você estiver executando em qualquer versão do OpenSSH que foi afetada, atualize para uma versão que NÃO seja vulnerável a essa CVE. O OpenSSH lançou o 9,8p1 em 1º de julho de 2024.

 Crítica

Edge Microgateway

Descrição Gravidade Observações

Recentemente, uma vulnerabilidade de execução remota de código, a CVE-2024-6387, foi descoberta no OpenSSH. Ela explora uma disputa que pode ser usada para acessar um shell remoto, o que dá aos invasores acesso raiz aos nós da VM. Os clientes do Edge Microgateway são proprietários e gerenciam as VMs/hosts físicos em que o Edge Microgateway está implantado.

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 fazer?

Analise a versão do OpenSSH executando os comandos ssh -V e valide a versão do OpenSSH. Se você estiver executando em qualquer versão do OpenSSH que foi afetada, atualize para uma versão que NÃO seja vulnerável a essa CVE. O OpenSSH lançou o 9,8p1 em 1º de julho de 2024.

 Crítica

Apigee

Descrição Gravidade Observações

Recentemente, uma vulnerabilidade de execução remota de código, a CVE-2024-6387, foi descoberta no OpenSSH. Ela explora uma disputa que pode ser usada para acessar um shell remoto, o que dá aos invasores acesso raiz aos nós do GKE. No momento da publicação, a Apigee não pode ser explorada e há mitigações disponíveis.

Mesmo que essa CVE não seja explorável, a Apigee vai atualizar as cargas de trabalho para lidar com a CVE-2024-6387.

O que fazer?

Os usuários da Apigee não precisam realizar nenhuma ação. A correção das cargas de trabalho será feita nos próximos dias e o boletim de segurança será atualizado assim que a aplicação do patch for concluída.

Observação: se os grupos gerenciados de instâncias forem implantados em um projeto do cliente para o balanceamento de carga na direção norte, especificamente o InternalRouting (VPC). e ExternalRouting (MIG), verifica a versão do OpenSSH instalada neles. Se a versão for vulnerável a CVE, atualize para a versão 9.8p1 do OpenSSH, lançada em 1º de julho, por conta própria, já que a Apigee não gerencia esses MIGs.

Crítica

Apigee híbrido

Descrição Gravidade Observações

Recentemente, uma vulnerabilidade de execução remota de código, a CVE-2024-6387, foi descoberta no OpenSSH. Ela explora uma disputa que pode ser usada para acessar um shell remoto, o que dá aos invasores acesso raiz aos nós do GKE. No momento da publicação, as imagens híbridas não eram vulneráveis porque o OpenSSH não estava empacotado em nenhuma das imagens de contêiner híbridos. No entanto, se o SO do host/do nó do GKE estiver em execução com as versões vulneráveis do OpenSSH abaixo, seus clusters híbridos poderão ser explorados.

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 fazer?

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

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

 Crítico

GCP-2024-006

Publicado: 02/05/2024

Descrição Gravidade Observações

Quando um proxy de gerenciamento de APIs da Apigee se conecta a um endpoint de destino ou servidor de destino, o proxy não realiza a validação do nome do host para o certificado apresentado pelo endpoint ou servidor de destino por padrão. Se a validação do nome do host não estiver ativada usando uma das opções a seguir, os proxies da Apigee que se conectam a um endpoint ou servidor de destino poderão estar em risco de um ataque "man-in-the-middle" por um usuário autorizado. Para mais informações, consulte Como configurar o TLS da borda para o back-end (nuvem e nuvem privada).

Produtos afetados

As implantações de proxy da Apigee nas seguintes plataformas da Apigee foram afetadas:

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

O que devo fazer?

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

Opção 1: adicionar uma configuração ao proxy

Para ativar a validação do endpoint ou servidor de destino, adicione uma configuração <CommonName> à seção SSLInfo do elemento <HTTPTargetConnection> na configuração de 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 essa configuração estiver presente no elemento <HTTPTargetConnection> da configuração do proxy, a Apigee usará o valor especificado em <CommonName> para a validação do nome do host. Caracteres curingas podem ser usados nesse campo.

A Apigee recomenda essa abordagem. É possível testar os proxies individualmente para confirmar se a validação está funcionando conforme o esperado, com possível interrupção mínima do tráfego. Para saber mais sobre como testar a validação do nome do host nos proxies e verificar as falhas, consulte Como usar a ferramenta de rastreamento.

Opção 2: definir uma flag no nível da organização

É possível definir uma flag no nível da organização da Apigee para ativar a validação do nome do host em todos os proxies e destinos implantados na organização. Se a flag features.strictSSLEnforcement estiver definida como true nas propriedades da organização, a validação do nome do host será aplicada sempre que o proxy se conectar a um endpoint ou servidor de destino.

Observação: embora essa opção possa ajudar a ativar o recurso em toda a organização, poderão ocorrer falhas na validação do nome do host se os destinos não apresentarem os certificados esperados.

  • Para implantações do Apigee Edge for Public Cloud:

    Entre em contato com o suporte doGoogle Cloud para definir a flag features.strictSSLEnforcement como true nas propriedades da organização.

    Observação: ativar essa flag aplicará a verificação de SSL a todos os ambientes em uma organização e a todos os proxies implantados nesses ambientes.

  • Para implantações do Apigee Edge for Private Cloud :

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

    Observação: ao atualizar as flags no nível da organização usando a API Groups, inclua todas as flags atuais na solicitação POST para evitar a substituição das configurações anteriores.

    Depois que a flag é definida, é necessário reiniciar cada processador de mensagens individualmente para que a mudança entre em vigor. Use o comando a seguir:

    apigee-service edge-message-processor restart

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

    Observação: ativar essa flag aplicará a verificação de SSL a todos os ambientes em uma organização e a todos os proxies implantados nesses ambientes. No entanto, se <IgnoreValidationErrors> for definido como true, todos os erros de validação detectados serão ignorados.

A Apigee recomenda implementar essa mudança primeiro em ambientes que não sejam de produção, para garantir que a validação funcione conforme o esperado e não resulte em interrupções na produção. Caso a validação do nome do host falhe para algum destino, a seguinte mensagem de falha será retornada:

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

Atualizado em: 03/11/2023

Descrição Gravidade Observações

Atualização de 03/11/2023: foi adicionado um problema conhecido relacionado ao Apigee Edge para nuvem privada.

Uma vulnerabilidade de negação de serviço (DoS) foi descoberta recentemente em várias implementações do protocolo HTTP/2 (CVE-2023-44487), incluindo o serviço de entrada da Apigee (Cloud Service Mesh) usado pela Apigee X e Apigee híbrida. A vulnerabilidade pode levar a um DoS da funcionalidade de gerenciamento da API Apigee.

Produtos afetados

  • Apigee X

    As implantações da Apigee X que são acessíveis por um Google Cloud balanceador de carga de rede (camada 4) ou um balanceador de carga de camada 4 personalizado foram afetadas. Um hotfix foi aplicado a todas as instâncias da Apigee X.

  • Apigee híbrida

    As instâncias da Apigee híbrida que permitem que solicitações HTTP/2 cheguem à entrada da Apigee serão afetadas. Os clientes precisam verificar se os balanceadores de carga na entrada da Apigee híbrida permitem que solicitações HTTP/2 cheguem ao serviço de entrada da Apigee.

  • Apigee Edge para nuvem privada

    Os componentes do servidor de gerenciamento e do roteador do Edge para nuvem privada estão expostos à Internet e podem estar vulneráveis. Embora o HTTP/2 esteja ativado na porta de gerenciamento de outros componentes específicos do Edge relativos ao Edge para nuvem privada, nenhum deles está exposto à Internet. Em componentes que não são do Edge, como Cassandra, Zookeeper e outros, o HTTP/2 não está ativado. Recomendamos que você siga as etapas em Problemas conhecidos com o Edge para nuvem privada a fim de lidar com a vulnerabilidade do Edge para nuvem privada.

Produtos não afetados

  • Apigee X

    As instâncias da Apigee X que são acessadas apenas pelos balanceadores de carga de aplicativo Google Cloud(camada 7) não são afetadas. Isso inclui implantações com HTTP/2 ativado para proxies gRPC.

  • Google Cloud Gateway de API

    A API Gateway doGoogle Cloud não foi afetada.

  • Apigee Edge Cloud

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

O que devo fazer?

  • Apigee X

    Atualização de 03/11/2023: a vulnerabilidade foi resolvida por meio da atualização das instâncias da Apigee X, lançada em 13/10/2023. Consulte as Notas de lançamento para saber mais.

  • Apigee híbrida

    Os clientes da Apigee híbrida precisam fazer upgrade para uma das seguintes versões de patch:

  • Apigee Edge para nuvem privada

    Os usuários do Apigee Edge para nuvem privada podem seguir as instruções publicadas em Problemas conhecidos com o Edge para nuvem privada a fim de desativar explicitamente o HTTP/2 para os componentes expostos.

Quais vulnerabilidades serão corrigidas?

A vulnerabilidade CVE-2023-44487 pode levar a um ataque de DoS na funcionalidade de gerenciamento da API Apigee.

Alta CVE-2023-44487