Orientação sobre a vulnerabilidade crítica do OpenSSH regreSSHion
Resumo executivo
O CVE-2024-6387 é uma vulnerabilidade crítica de execução remota de código (RCE) no OpenSSH que deriva de uma regressão de um CVE de 2006.
Para a exploração ocorrer, ela deve ganhar uma condição de corrida e pode levar horas ou até mesmo semanas para ser bem-sucedida.
O curso de ação recomendado é aplicar patches a uma versão não afetada do servidor OpenSSH em sistemas Linux baseados em glibc. Para circunstâncias em que isso não é possível, incluímos outras opções de mitigação para reduzir os impactos potenciais.
Também fornecemos um OSQuery para detectar versões vulneráveis do OpenSSH.
Análise técnica e de histórico da vulnerabilidade do OpenSSH
Uma nova vulnerabilidade crítica (CVE-2024-6387) no OpenSSH foi descoberta recentemente pela Unidade de pesquisa de ameaças da Qualys que pode levar a uma RCE não autenticada. Em 1º de julho de 2024, divulgaram os resultados sobre a regressão da vulnerabilidade CVE-2006-5051, que foi corrigida em 2006 e reapareceu em 2021.
A causa principal do CVE é uma condição de corrida causada pelo tratamento inseguro de sinais quando a autenticação do usuário expira. Após o tempo limite, um sinal SIGALRM é gerado, o que causa uma interrupção em um thread que está executando uma rotina de gerenciamento de heap. Se o próprio manipulador de sinais chamar a rotina de gerenciamento de heap, poderá ocorrer um comportamento inesperado e, nesse caso, executar código arbitrário.
Atualmente, há uma prova de conceito pública (PoC) que explora esta vulnerabilidade, tornando-a uma vulnerabilidade explorada conhecida (esta PoC é oferecida por um terceiro não afiliado à Akamai, portanto, faça sua própria análise antes de tentar qualquer interação com o código). Apesar da gravidade, a PoC destaca algumas limitações para uma exploração bem-sucedida. Uma das principais limitações é o tempo que leva para explorar: em alguns sistemas, pode levar várias horas; em outros, pode levar até uma semana. Outras limitações incluem estar sujeito à distribuição do sistema operacional e à versão e configuração do servidor OpenSSH.
O que está vulnerável?
A vulnerabilidade afeta muitas versões do OpenSSH, incluindo a maioria das distribuições Linux, já que elas são fornecidas com o OpenSSH por padrão.
Como a causa raiz da vulnerabilidade é uma regressão no código do OpenSSH, versões muito antigas do servidor OpenSSH são afetadas pelo CVE original, e versões mais recentes (antes da regressão) não são afetadas.
Até a data de publicação deste artigo, as versões conhecidas do OpenSSH afetadas por esta vulnerabilidade são as seguintes:
A versão antiga da vulnerabilidade (CVE-2006-5051) está afetando as versões do OpenSSH anteriores ao OpenSSH 4.4/4.4p1 (2006-09-27) (a menos que tenham sido corrigidas para CVE-2006-5051 e CVE-2008-4109)
A regressão da vulnerabilidade foi introduzida na versão OpenSSH 8.5/8.5p1 (2021-03-03)
Os mantenedores do OpenSSH corrigiram a vulnerabilidade na versão OpenSSH 9.8/9.8p1 (2024-07-01)
Uma maneira de pesquisar servidores afetados é usando a seguinte consulta do Insight:
SELECT
name AS vulnerable_item,
'DEB' AS type,
version,
CAST(SUBSTR(version, 3, 3) AS REAL) AS version_to_compare,
source,
arch,
revision,
maintainer AS vendor
FROM deb_packages
WHERE LOWER(name) = 'openssh-server'
AND (version_to_compare < 4.4
OR (version_to_compare >= 8.5 AND version_to_compare < 9.8))
UNION
SELECT
name AS vulnerable_item,
'RPM' AS type,
version,
CAST(SUBSTR(version, 1, 3) AS REAL) AS version_to_compare,
source,
arch,
release AS revision,
vendor
FROM rpm_packages
WHERE LOWER(name) = 'openssh-server'
AND (version_to_compare < 4.4
OR (version_to_compare >= 8.5 AND version_to_compare < 9.8))
Observamos que 75% das redes tinham algumas máquinas com uma versão vulnerável do OpenSSH e, em média, aproximadamente 35% das máquinas em uma determinada rede estavam vulneráveis. Olhando pelo lado positivo, em nossos ambientes monitorados, ainda temos que ver uma máquina com uma porta SSH aberta para a Internet arbitrariamente. Ainda assim, uma pesquisa rápida no Shodan mostra mais de 6 milhões de máquinas acessíveis com uma versão vulnerável (Figura).
Possível impacto
Como a vulnerabilidade afeta o OpenSSH por padrão, o possível impacto é enorme, afetando a maioria das distribuições do Linux, especialmente as versões mais recentes devido à regressão.
No entanto, há três advertências que reduzem a necessidade de pânico total:
A PoC atual é apenas para máquinas x86, já que a exploração em máquinas amd64 (que hoje são o padrão) é exponencialmente mais complexa devido a proteções de memória mais fortes.
Atualmente, acredita-se que a exploração bem-sucedida requer um longo tempo e várias conexões para ser acionada. Dessa forma, ela deve acionar a maioria dos detectores de ataque de força bruta.
Devido às duas advertências acima, esse ataque parece ser mais adequado como um vetor de acesso inicial da Internet. Parte do impacto pode ser mitigada usando-se a segmentação adequada para conexões SSH de Internet e para tráfego de máquinas que precisam ter interfaces SSH voltadas para a Internet (como jump boxes).
Mitigação
Aplicação de patches
O curso de ação mais óbvio é aplicar o patch do OpenSSH à versão atualizada e não vulnerável. No entanto, como o OpenSSH geralmente vem com distribuições Linux, a aplicação de patches depende da versão do fornecedor de um patch, que pode levar mais tempo e testes.
Os administradores de rede podem usar o OSQuery fornecido nesta postagem do blog para detectar seus ativos vulneráveis e rastreá-los ao longo do tempo. Os clientes da Akamai Guardicore Segmentation também podem usar consultas agendadas para essa finalidade e, em seguida, rotular seus ativos com base nos resultados da consulta.
Segmentação
Como observamos acima, essa exploração de CVE é mais provavelmente adequada para a violação inicial em redes, já que a exploração bem-sucedida pode levar horas, se não dias. Portanto, é essencial mapear todas as instâncias de interfaces OpenSSH da Internet e fechar ou restringir o acesso a elas.
Nos casos em que é necessário acesso SSH arbitrário a partir da Internet, recomendamos aplicar segmentação de rede nessas máquinas para restringir o acesso à rede interna e limitar o raio de explosão em caso de exploração e violação bem-sucedidas.
Sensibilidade de alerta de ameaça
Como os patches ainda não estão necessariamente disponíveis, pode ser prudente aumentar a sensibilidade do alerta nas cargas de trabalho que podem estar potencialmente vulneráveis e sem patches. Assim, mesmo que a vulnerabilidade seja explorada sem ser detectada, ainda será possível conhecer os efeitos posteriores. Em particular, recomendamos a sensibilidade a tentativas de força bruta, pois é assim que a exploração provavelmente ficaria.
No entanto, aumentar a sensibilidade do alerta também aumentará a fadiga do alerta. Como resultado, também recomendamos ajustar a sensibilidade de alerta de acordo com a importância da carga de trabalho afetada para a rede ou seu impacto.
Resumo
Nesta publicação do blog, revisamos as informações disponíveis sobre a vulnerabilidade crítica regreSSHion no OpenSSH, que foi corrigida e divulgada recentemente.
Para os defensores, o mais importante é determinar a vulnerabilidade das cargas de trabalho em sua rede. Tentamos ajudar fornecendo um OSQuery para detectar versões vulneráveis do OpenSSH. Também discutimos o que fazer para mitigar alguns dos riscos (ou seja, ajustar sua sensibilidade de alerta de ameaças) quando o patch não estiver disponível.
Esta publicação apresenta uma visão geral da nossa compreensão atual e nossas recomendações com base nas informações disponíveis. Nossa revisão está em andamento e todas as informações aqui incluídas estão sujeitas a alterações. Você também pode visitar nossa conta do X para obter atualizações em tempo real.