Mitigação de Falsificação de Protocolo Blast-RADIUS (CVE-2024-3596)

Introdução

Este documento descreve como mitigar a falsificação do protocolo Blast RADIUS.

Overview

Em 7 de julho de 2024, os pesquisadores de segurança revelaram esta vulnerabilidade no protocolo RADIUS: CVE-2024-3596: O protocolo RADIUS no RFC 2865 é susceptível a ataques forjados por um invasor no caminho que pode modificar qualquer Resposta válida (Access-Accept, Access-Reject ou Access-Challenge) para qualquer outra resposta usando um ataque de colisão com prefixo escolhido contra a assinatura do Autenticador de Resposta MD5. Eles publicaram um documento detalhando suas descobertas neste white paper que demonstra uma falsificação de resposta bem-sucedida contra fluxos que não utilizam o atributo Message-Authenticator.

Para obter uma lista atualizada dos produtos Cisco afetados por essa vulnerabilidade e versões que contêm correções, visite: Vulnerabilidade de Falsificação de Protocolo RADIUS (Blast-RADIUS): julho de 2024. Este artigo aborda as técnicas gerais de mitigação e como elas se aplicam a alguns, mas não a todos, produtos da Cisco; a documentação individual dos produtos deve ser consultada para obter detalhes. Como o principal servidor RADIUS da Cisco, o Cisco Identity Service Engine é abordado com mais detalhes.

Background

Esse ataque aproveita um ataque de prefixo escolhido MD5 utilizando colisões em MD5, o que permite que um invasor adicione dados adicionais ao pacote de resposta RADIUS enquanto modifica atributos existentes do pacote de resposta. Um exemplo demonstrado foi a capacidade de alterar um RADIUS Access-Reject em um RADIUS Access-Accept. Isso é possível porque o RADIUS por padrão não inclui um hash de todos os atributos no pacote. O RFC 2869 adiciona o atributo Autenticador de mensagem, mas atualmente ele só precisa ser incluído ao usar protocolos EAP, o que significa que o ataque descrito no CVE-2024-3596 é possível contra qualquer intercâmbio não EAP onde o Cliente RADIUS (NAD) não inclui o atributo Autenticador de mensagem.

Atenuação

Autenticador de mensagem

1.- O cliente RADIUS deve incluir o atributo Message-Authenticator.

Quando o Network Access Device (NAD) inclui o atributo Message-Authenticator na solicitação de acesso, o Cisco Identity Services Engine inclui o Message-Authenticator no pacote resultante Access-Accept, Access-Challenge ou Access-Reject em todas as versões.

2.- O servidor RADIUS deve impor o recebimento do atributo Message-Authenticator.

Não basta incluir apenas o Autenticador de Mensagem na Solicitação de Acesso, pois o ataque possibilita retirar o Autenticador de Mensagem da Solicitação de Acesso antes que ela seja encaminhada ao Servidor RADIUS. O servidor RADIUS também deve exigir que o NAD inclua Message-Authenticator na solicitação de acesso. Isso não é padrão no Cisco Identity Services Engine, mas pode ser habilitado no nível de protocolos permitidos, que se aplica no nível do conjunto de políticas. A opção na configuração de protocolos permitidos é Require Message-Authenticator para todas as solicitações RADIUS:

Opção de protocolos permitidos no Identity Services Engine

Autenticações que correspondem a um conjunto de políticas em que a configuração de protocolos permitidos requer o Autenticador de mensagem, mas em que a Solicitação de acesso não contém o atributo Autenticador de mensagem é descartado pelo ISE:

É importante verificar se o NAD está enviando Message-Authenticator antes de ser exigido pelo servidor RADIUS, pois esse não é um atributo negociado. Cabe ao NAD enviá-lo por padrão ou configurá-lo para enviá-lo. O Message-Authenticator não é um dos atributos relatados pelo ISE, uma captura de pacote é a melhor maneira de determinar se um NAD/caso de uso está incluindo o Message-Authenticator. O ISE incorporou a funcionalidade de captura de pacotes em Operations > Troubleshoot > Diagnostic Tools > General Tools > TCP Dump. Lembre-se de que casos de uso diferentes do mesmo NAD podem incluir ou não o Autenticador de mensagem.

Este é um exemplo de captura de uma solicitação de acesso que inclui o atributo Autenticador de mensagem:

Atributo Message-authenticator em solicitação de acesso Radius

Este é um exemplo de captura de uma solicitação de acesso que não inclui o atributo Autenticador de mensagem:

Criptografar com TLS/IPSec

A solução de longo prazo mais eficaz para proteger o RADIUS é criptografar o tráfego entre o servidor RADIUS e o NAD. Isso acrescenta privacidade e uma integridade criptográfica mais forte do que simplesmente contar com o Autenticador de Mensagens derivado do MD5-HMAC. Que, se qualquer um deles puder ser usado entre o servidor RADIUS e o NAD, dependerá de ambos os lados que suportam o método de criptografia.

Os termos gerais usados em toda a indústria para a criptografia TLS do RADIUS são:

• RadSec - refere-se ao RFC 6614
• RadSec TLS - refere-se ao RFC 6614
• RadSec DTLS - refere-se ao RFC 7360

É importante distribuir a criptografia de maneira controlada, pois há sobrecarga de desempenho para a criptografia TLS, bem como considerações sobre o gerenciamento de certificados. Os certificados também devem ser renovados regularmente.

RADIUS sobre DTLS

O Datagram Transport Layer Security (DTLS) como uma camada de transporte para o RADIUS é definido pelo RFC 7360 que usa certificados para autenticar mutuamente o servidor RADIUS e o NAD criptografa o pacote RADIUS completo usando um túnel TLS. O método de transporte permanece UDP e requer que os certificados sejam implantados no servidor RADIUS e no NAD. Tenha em mente que, ao implantar RADIUS sobre DTLS, é imperativo que a expiração e a substituição de certificados sejam gerenciadas de perto para evitar que certificados expirados interrompam a comunicação RADIUS. O ISE suporta DTLS para comunicação ISE para NAD, já que o ISE 3.4 Radius sobre DTLS não é suportado para RADIUS-Proxy ou RADIUS Token Servers. O RADIUS sobre DTLS também é suportado por muitos dispositivos Cisco que atuam como NADs, como switches e controladores sem fio que executam o Cisco IOS-XE®.

RADIUS sobre TLS

A Criptografia TLS (Transport Layer Security) para RADIUS é definida pelo RFC 6614, altera o transporte para TCP e usa TLS para criptografar totalmente os pacotes RADIUS. Isso é comumente usado pelo serviço eduroam como um exemplo. A partir do ISE 3.4, o RADIUS sobre TLS não é suportado, mas é suportado por muitos dispositivos Cisco que atuam como NADs, como switches e controladores sem fio que executam o Cisco IOS-XE.

IPSec

O Identity Services Engine tem suporte nativo para túneis IPSec entre ISE e NADs que também suportam túneis IPSec de terminação. Essa é uma boa opção onde o RADIUS sobre DTLS ou o RADIUS sobre TLS não é suportado, mas deve ser usado moderadamente, pois somente 150 túneis são suportados por nó de serviços de política do ISE. O ISE 3.3 e posterior não exige mais uma licença para IPSec, agora está disponível de forma nativa.

Mitigação parcial

Segmentação RADIUS

Segmente o tráfego RADIUS para VLANs de gerenciamento e links criptografados seguros, como pode ser fornecido via SD-WAN ou MACSec. Essa estratégia não elimina o risco do ataque, mas pode reduzir consideravelmente a superfície de ataque da vulnerabilidade. Isso pode ser uma boa medida de intervalo de parada, enquanto os produtos implementam o requisito Message-Authenticator ou o suporte DTLS/RadSec. A exploração exige que um invasor consiga usar a comunicação RADIUS com êxito como MITM (Man-in-the-Middle), de modo que, se um invasor não conseguir entrar em um segmento de rede com esse tráfego, o ataque não será possível. O motivo disso ser apenas uma mitigação parcial é que uma configuração incorreta da rede ou o comprometimento de uma parte da rede pode expor o tráfego RADIUS.

Se o tráfego RADIUS não puder ser segmentado ou criptografado, recursos adicionais podem ser implementados para evitar MITM bem-sucedido em segmentos de risco como: Proteção de origem de IP, inspeção ARP dinâmica e rastreamento de DHCP. Também é possível utilizar outros métodos de autenticação com base no tipo de fluxo de autenticação, como TACACS+, SAML, LDAPS e outros.

Status de vulnerabilidade do Identity Services Engine

Essas tabelas descrevem o que está disponível no Cisco ISE 3.4 para tornar os fluxos de autenticação protegidos contra Blast-RADIUS.

Para recapitular, estes três itens seguintes devem estar no lugar para um fluxo que utiliza apenas o Autenticador de Mensagem e não a criptografia DTLS/RadSec/IPSec, para que o fluxo não seja vulnerável:

• O dispositivo de acesso à rede DEVE enviar o atributo Message-Authenticator na solicitação de acesso.
• O servidor RADIUS DEVE exigir o atributo Message-Authenticator em Access-Request.
• O servidor RADIUS DEVE responder com o atributo Message-Authenticator nos campos Access-Challenge, Access-Accept e Access-Reject.

Consulte o bug da Cisco ID CSCwk6747, que monitora as alterações para fechar as vulnerabilidades quando o Cisco ISE está atuando como cliente RADIUS.

ISE como um servidor RADIUS

ISE como um cliente RADIUS

Atualizações do ISE como cliente RADIUS

Os aprimoramentos do Cisco ISE que atua como um cliente RADIUS estão incluídos nas seguintes versões: Patch 3.1 10, patch 3.2 8, patch 3.3 5, patch 3.4 2, 3.5 e versões posteriores via ID de bug da Cisco CSCwk6747. Após o patch ou upgrade, qualquer novo recurso criado é padronizado para a nova configuração mais segura. Os recursos existentes devem ser modificados para usar a configuração mais segura após o patch ou a atualização. Uma nova caixa de seleção foi adicionada: "Autenticador de Mensagem Obrigatório na Resposta", se marcado, serve a uma finalidade dupla: O Cisco ISE sempre envia o Autenticador de mensagens e falha na autenticação se uma resposta for recebida sem um Autenticador de mensagens. O comportamento é o seguinte:

Caso	NAD incluiu Autenticador de Mensagem na solicitação	O NAD não incluiu o Autenticador de Mensagens na solicitação
Antes do patch/upgrade	O ISE envia o Autenticador de Mensagens para o Token RADIUS, Servidor RADIUS Externo ou CoA	O ISE não envia o Autenticador de mensagem para o Token RADIUS, servidor RADIUS externo ou CoA
A caixa de seleção Após patch/upgrade e Autenticador de mensagem necessário na resposta é desmarcada.	O ISE envia o Autenticador de Mensagens para o Token RADIUS, Servidor RADIUS Externo ou CoA	O ISE não envia o Autenticador de mensagem para o Token RADIUS, servidor RADIUS externo ou CoA
Depois que a caixa de seleção Patch/Upgrade e Autenticador de mensagem necessário na resposta estiver marcada.	O ISE envia o Autenticador de Mensagens para o Token RADIUS, Servidor RADIUS Externo ou CoA	O ISE envia o Autenticador de Mensagens para o Token RADIUS, servidor RADIUS Externo ou CoA

Servidor de token RADIUS

Uma nova caixa de seleção: Message Authenticator Required On Response foi adicionada na guia Authentication da configuração do RADIUS Token Server:

Com a caixa marcada, se uma resposta RADIUS for recebida sem o Autenticador de mensagem, uma mensagem de falha será registrada no log de autenticação detalhado, que pode ser acessado por meio de logs dinâmicos ou de um relatório de autenticação RADIUS:

Servidor RADIUS externo

Uma nova caixa de seleção: O Autenticador de Mensagem Necessário na Resposta foi adicionado à configuração do Servidor RADIUS Externo:

Com a caixa marcada, se uma resposta RADIUS for recebida sem o Autenticador de mensagem, uma mensagem de falha será registrada no log de autenticação detalhado, que pode ser acessado por meio de logs dinâmicos ou de um relatório de autenticação RADIUS:

Alteração de autorização (CoA)

As alterações de CoA foram feitas nos perfis de dispositivo de rede sob a alça Alteração de autorização (CoA):

A opção Send Message-Authenticator é um recurso anterior, a nova opção é Message-Authenticator Required na resposta. O Cisco ISE enviará o atributo Autenticador de mensagem se o Autenticador de mensagem necessário na resposta estiver marcado, independentemente de Enviar Autenticador de mensagem estar ou não marcado. Send Message-Authenticator é retido para as configurações existentes. Se o NAD não incluir o Autenticador de mensagem na Resposta de CoA, o seguinte erro será visto no relatório de autenticação detalhado disponível através dos registros em tempo real:

Os Perfis de dispositivo de rede fornecidos pela Cisco não podem ser modificados, para usar a nova opção, o Perfil de dispositivo de rede pode ser duplicado e a configuração ativada no perfil duplicado. Os dispositivos de rede precisam ser atribuídos ao perfil de dispositivo de rede recém-criado. Isso foi feito para reduzir o risco de causar uma interrupção de rede após um patch ou atualização, introduzindo uma incompatibilidade entre o Cisco ISE e os NADs existentes. Se um perfil definido pelo usuário existente estiver em uso, é recomendável duplicar esse perfil e testar pelo menos 1 de cada tipo de dispositivo na rede usando esse perfil antes de fazer uma alteração no perfil do dispositivo de rede existente.

Histórico de revisões

Revisão	Data de publicação	Comentários
2.0	21-Aug-2026	Formatação principal, alterações de texto Alt, seção Introdução, Links
1.0	07-Aug-2024	Versão inicial