Boletins de segurança

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

Para receber os boletins de segurança mais recentes, siga um destes procedimentos:

  • 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-2024-040

Publicado: 2024-07-02

Este boletim inclui detalhes específicos para 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 suporteGoogle 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: 2023-10-13

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 meio de um Google Cloud balanceador de carga de rede (camada 4) ou de um balanceador de carga de camada 4 personalizado são 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