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

Introdução

Em 7 de julho de 2024, os pesquisadores de segurança revelaram a seguinte 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 em https://www.blastradius.fail/pdf/radius.pdf que demonstra uma falsificação de resposta bem-sucedida contra fluxos que não utilizam o atributo Autenticador de mensagem.

Para obter uma lista atualizada dos produtos Cisco afetados por essa vulnerabilidade e versões que contêm correções, visite: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-radius-spoofing-july-2024-87cCDwZ3. Este artigo abordará 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 Identity Service Engine será 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 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 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 ele seja encaminhado ao Servidor RADIUS. O servidor RADIUS também deve exigir que o NAD inclua Message-Authenticator na solicitação de acesso. Esse não é o padrão no 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 é "Exigir autenticador de mensagem" para todas as solicitações RADIUS:

Opção de protocolos permitidos no Identity Services Engine

As autenticações que correspondem a um conjunto de políticas em que a configuração de protocolos permitidos requer o Message-Authenticator, mas em que a solicitação de acesso não contém o atributo Message-Authenticator, serão eliminadas 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.

Veja a seguir 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

Veja a seguir 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
• "TLS RadSec" - refere-se ao RFC 6614
• "DTLS RadSec" - 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 terão de 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 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 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 são suportados, mas devem ser usados 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 pode ser possível utilizar outros métodos de autenticação baseados no tipo de fluxo de autenticação, como TACACS+, SAML, LDAPS, etc...

Status de vulnerabilidade do Identity Services Engine

As tabelas a seguir descrevem o que está disponível a partir do ISE 3.4 para tornar os fluxos de autenticação protegidos contra Blast-RADIUS. Para recapitular, os 3 itens a seguir 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:
1) O dispositivo de acesso à rede DEVE enviar o atributo Message-Authenticator na solicitação de acesso.

2) O servidor RADIUS DEVE exigir o atributo Message-Authenticator na solicitação de acesso.

3) O servidor RADIUS DEVE responder com o atributo Message-Authenticator nos campos Access-Challenge, Access-Accept e Access-Reject.

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

ISE como um servidor RADIUS

ISE como um cliente RADIUS

Atualizações do ISE como cliente RADIUS

As melhorias no ISE que atua como um cliente RADIUS estão incluídas nas versões: patch 10 do 3.1, patch 8 do 3.2, patch 5 do 3.3, patch 2 do 3.4, patch 2 do 3.5 e versões posteriores via CSCwk6747. Após o patch ou upgrade, qualquer novo recurso criado assumirá como padrão 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 ISE sempre enviará o Autenticador de mensagens e o ISE falhará na autenticação se uma resposta for recebida sem um Autenticador de mensagens. O comportamento é o seguinte:

Servidor de token RADIUS

Uma nova caixa de seleção: "Message Authenticator Required On Response" foi adicionada na guia Authentication para a 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 através de logs dinâmicos ou de um relatório de autenticação RADIUS:

**Nota: A autenticação geral ainda pode passar com base na configuração de política, através da autenticação pode corresponder a uma política inesperada.

Servidor RADIUS externo

Uma nova caixa de seleção: "Message Authenticator Required On Response" foi adicionada à 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 através de logs dinâmicos ou de um relatório de autenticação RADIUS:

**Nota: A autenticação geral ainda pode passar com base na configuração de política, através da autenticação pode corresponder a uma política inesperada.

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 on response. O 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" é mantido 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:

 **Nota: O CoA pode ser bem-sucedido no NAD mesmo se uma falha for registrada no ISE, já que o NAD pode ter processado o CoA, mas não incluído o Autenticador de Mensagem na resposta.

Os perfis de dispositivo de rede "fornecidos pela Cisco" padrão 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 precisarão 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 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.