Jump to content

Vulnerabilidade OpenSSH (sshd) CVE-2024-6387


Recommended Posts

Prezados,

Está ocorrendo uma vulnerabilidade no OpenSSH (sshd) CVE-2024-6387. Seguem abaixo as instruções de como se proteger:

Entre em suas máquinas e executem os seguintes comandos:

sudo nano /etc/ssh/sshd_config

Procure por LoginGraceTime 2m, remova o # e substitua 2m por:

LoginGraceTime 0

Em seguida, reinicie o serviço:

service sshd restart

Fonte: https://www.qualys.com/regresshion-cve-2024-6387/

Se precisarem de mais informações, estaremos à disposição.

DELTA SERVERS
SOLUÇÕES CORPORATIVAS!

Link to comment
Share on other sites

Ótimo contributo! 

 

Só para reforçar as versões impactadas são:

 

OpenSSH versões 8.5p1 – 9.7p1

Versões do OpenSSH anteriores à versão 4.4p1

CWG PORTUGAL - Soluções em Tecnologia, Big Data e Cibersegurança. | PORTUGAL

DOLUTECH - Conheça nosso Blog de Tecnologia, adquira mais conhecimento de forma Gratuita.

eGestor - Plataforma completa de gestão de contratos e documentações.

Cloud Computing Gerenciado / Hospedagem Wordpress / Servidores Dedicados / Cibersegurança / Gestão de Contratos

Link to comment
Share on other sites

14 minutos atrás, daemoncesar disse:

Mas esta vulnerabilidade não seria remoto para ddos ?

O Atacante consegue pegar root na maquina sem senha mesmo ?

A vulnerabilidade descrita permite que um atacante obtenha execução remota de código (RCE) como root, mas isso não significa que o atacante precise ter acesso root para explorar a vulnerabilidade inicialmente. Vou detalhar melhor esse aspecto:

O atacante precisa primeiro identificar uma maneira de causar uma condição de corrida no manipulador de sinais do sshd. Isso geralmente envolve a exploração de timing e a execução simultânea de várias operações que interfiram entre si.

O atacante envia sinais maliciosos ao sshd para explorar a condição de corrida. Isso pode envolver o envio de uma série de pacotes especialmente criados que desencadeiam a execução simultânea de código no sshd.

Uma vez explorada a condição de corrida, o atacante consegue injetar e executar código arbitrário no servidor vulnerável. Como a vulnerabilidade permite que o código seja executado como root, o atacante tem controle total sobre o sistema.

Após a execução bem-sucedida do código, o atacante pode estabelecer uma conexão remota persistente ao servidor comprometido, frequentemente usando backdoors ou outros métodos para garantir acesso contínuo.

Entender e corrigir essa vulnerabilidade é crucial para manter a segurança dos sistemas que utilizam OpenSSH, especialmente em servidores de produção que são alvos frequentes de ataques.

A vulnerabilidade está no sshd, o daemon do OpenSSH, que é executado com privilégios elevados (tipicamente como root) para gerenciar conexões SSH.

A condição de corrida ocorre no manipulador de sinais, uma parte do código que lida com interrupções assíncronas no sshd.

Um atacante remoto pode explorar essa vulnerabilidade sem precisar de acesso root ou qualquer tipo de autenticação prévia. A exploração envolve a manipulação dos sinais enviados ao sshd, explorando a condição de corrida para executar código arbitrário no contexto do processo sshd.

Como o sshd é executado como root, qualquer código injetado e executado pelo processo vulnerável também será executado com privilégios de root.

Isso dá ao atacante controle total sobre o sistema, incluindo a capacidade de modificar arquivos críticos, instalar backdoors e comprometer completamente o servidor.

A vulnerabilidade é particularmente grave porque pode ser explorada sem que o atacante precise autenticar-se no sistema. Isso significa que qualquer pessoa com acesso à rede onde o sshd está exposto pode tentar explorar a falha.

 

DELTA SERVERS
SOLUÇÕES CORPORATIVAS!

Link to comment
Share on other sites

para complementar o post do @DELTA SERVERS fiz um tutorial de atualização para a versão oficial sem a vulnerabilidade.

 

Tutorial de Correção da CVE-2024-6387 no OpenSSH - Dolutech

CWG PORTUGAL - Soluções em Tecnologia, Big Data e Cibersegurança. | PORTUGAL

DOLUTECH - Conheça nosso Blog de Tecnologia, adquira mais conhecimento de forma Gratuita.

eGestor - Plataforma completa de gestão de contratos e documentações.

Cloud Computing Gerenciado / Hospedagem Wordpress / Servidores Dedicados / Cibersegurança / Gestão de Contratos

Link to comment
Share on other sites

4 minutos atrás, daemoncesar disse:

Colocando o parametro, LoginGraceTime 0... já resolve ?

Resolve o problema, porem qualquer update no OpenSSH, pode voltar as configurações padrões, sempre é recomendado o update para versão sem vulnerabilidade.

 

Nessa questão informada o update é simples e fácil de fazer.

CWG PORTUGAL - Soluções em Tecnologia, Big Data e Cibersegurança. | PORTUGAL

DOLUTECH - Conheça nosso Blog de Tecnologia, adquira mais conhecimento de forma Gratuita.

eGestor - Plataforma completa de gestão de contratos e documentações.

Cloud Computing Gerenciado / Hospedagem Wordpress / Servidores Dedicados / Cibersegurança / Gestão de Contratos

Link to comment
Share on other sites

Definir o parâmetro LoginGraceTime como 0 no sshd_config do OpenSSH pode ajudar a mitigar algumas formas de ataque, mas não é uma solução completa para essa vulnerabilidade específica de condição de corrida no manipulador de sinais do sshd. 

Vamos analisar o que LoginGraceTime faz e por que isso pode não ser suficiente.

O que é LoginGraceTime?

LoginGraceTime define o tempo em segundos que um usuário tem para se autenticar após a conexão inicial. Se a autenticação não for concluída dentro desse tempo, a conexão é encerrada.


Definindo LoginGraceTime 0, o servidor SSH imediatamente fecha conexões que não se autenticam, essencialmente prevenindo qualquer tentativa de login.

Mitigação parcial:

LoginGraceTime 0 pode impedir algumas formas de ataque de força bruta ou de negação de serviço onde o atacante tenta prolongar o tempo de login, mas não aborda a condição de corrida no manipulador de sinais.


Reduzir LoginGraceTime pode diminuir a janela de oportunidade para alguns ataques de timing, mas não elimina a vulnerabilidade fundamental.

Por que não é uma solução completa?

Condição de corrida: A vulnerabilidade descrita é uma condição de corrida que pode ser explorada mesmo antes de qualquer autenticação. 


LoginGraceTime só afeta o tempo permitido para autenticação, não a manipulação de sinais ou a condição de corrida em si.

Código arbitrário: Se a condição de corrida puder ser explorada dentro de qualquer janela de tempo, mesmo curta, o atacante ainda pode conseguir execução remota de código.

Quais medidas adequadas?

Atualização do OpenSSH:

A melhor maneira de mitigar essa vulnerabilidade é atualizar para uma versão do OpenSSH onde essa falha tenha sido corrigida. Verifique regularmente por atualizações de segurança e aplique-as prontamente.

Quais configurações de segurança?

Além de LoginGraceTime, outras configurações podem ajudar a endurecer a segurança do SSH:

AllowUsers ou AllowGroups para restringir quem pode se conectar.
DenyUsers ou DenyGroups para especificar quem não pode se conectar.
PermitRootLogin no para impedir logins diretos como root (embora não mitigue a vulnerabilidade se o sshd estiver comprometido).
Uso de autenticação por chave pública em vez de senhas.

Firewall e acesso restrito:

Use firewalls para restringir quais IPs podem acessar o serviço SSH.
Implementar VPNs ou túneis SSH para acessar o servidor SSH de forma mais segura.

Monitoramento e IDS:

Monitorar logs do sshd para detectar atividades suspeitas.
Usar sistemas de detecção de intrusão (IDS) para identificar e reagir a tentativas de exploração.

Conclusão:

Definir LoginGraceTime 0 pode ajudar a mitigar algumas formas de ataque e reduzir a superfície de ataque, mas não resolve a vulnerabilidade de condição de corrida no manipulador de sinais do sshd. 
A melhor abordagem é combinar várias medidas de segurança, incluindo a aplicação de atualizações de software, configurações seguras, uso de firewalls e monitoramento contínuo.

DELTA SERVERS
SOLUÇÕES CORPORATIVAS!

Link to comment
Share on other sites

tenho 2 servidores antigos..

ssh: 1:6.7p1-5+deb8u2

Reinstalar acredito que não vou conseguir pq não tem suporte a atualizações no caso não vou conseguir compilar o novo ssh sem as bibliotecas atualizadas.

Vou mudar a porta do SSH e colocar este parametro.

Link to comment
Share on other sites

7 minutos atrás, daemoncesar disse:

tenho 2 servidores antigos..

ssh: 1:6.7p1-5+deb8u2

Reinstalar acredito que não vou conseguir pq não tem suporte a atualizações no caso não vou conseguir compilar o novo ssh sem as bibliotecas atualizadas.

Vou mudar a porta do SSH e colocar este parametro.

qual a versão do SO? me envia aqui que te falo se tem como instalar a versão 9.8 do OpenSSH 

CWG PORTUGAL - Soluções em Tecnologia, Big Data e Cibersegurança. | PORTUGAL

DOLUTECH - Conheça nosso Blog de Tecnologia, adquira mais conhecimento de forma Gratuita.

eGestor - Plataforma completa de gestão de contratos e documentações.

Cloud Computing Gerenciado / Hospedagem Wordpress / Servidores Dedicados / Cibersegurança / Gestão de Contratos

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

Do you agree with our terms?