Hackers iranianos alegam ter derrubado energia em Israel
Ransomware atinge empresa de logística no Brasil
USP, UFRJ e UFMG sob ataque de negação de serviço
Pane de rede retardou produção na Volkswagen
Site da Prefeitura de Suzano (SP) está fora do ar
DDoS atinge subdomínio da NASA

Assine nossa newsletter Premium e ganhe acesso ao grupo de WhatsApp In_Cyber.
Conheça também a versão Básica

Claroty detalha 5 vulnerabilidades dos roteadores Netgear Nighthawk RAX30

Share on linkedin
Share on twitter
Share on facebook

 

  • O Claroty Team82 divulgou cinco vulnerabilidades nos roteadores Netgear’s RAX30, como parte de sua pesquisa e participação na última edição de dezembro da competição de hackers Pwn2Own Toronto.
  • As categorias da Pwn2Own Toronto incluíam dispositivos inteligentes para escritórios pequenos e escritórios domésticos, incluindo roteadores, armazenamento conectado à rede, hubs de automação residencial, alto-falantes inteligentes, telefones celulares e muito mais. 
  • A Netgear corrigiu todas as cinco vulnerabilidades descobertas pelo Claroty Team82, três das quais eram vulnerabilidades de alta gravidade que permitem a execução remota de código, injeção de comando ou desvios de autenticação.
  • Exploits bem-sucedidos podem permitir que os invasores monitorem a atividade dos usuários e sequestrem conexões com a internet, e redirecionem o tráfego para sites maliciosos ou injetem malware no tráfego da rede.
  • Um invasor também pode usar essas vulnerabilidades para acessar e controlar os dispositivos inteligentes em rede (câmeras de segurança, termostatos, fechaduras inteligentes), alterar as configurações do roteador, incluindo credenciais ou configurações de DNS, ou usar uma rede comprometida para lançar ataques contra outros dispositivos ou redes.
  • Mais informações sobre cada vulnerabilidade podem ser encontradas no Team82’s Disclosure Dashboard:
  • O Claroty Team82 desenvolveu uma cadeia de exploits usando todas as cinco vulnerabilidades, para explorar as versões afetadas do roteador Netgear, burlando os mecanismos de proteção binária, como stack canaries.
  • Os usuários são incentivados a atualizar os seus roteadores RAX30, para lidar com essas vulnerabilidades. Veja a consultoria de segurança da Netgear para informações de mitigação e correção.

Introdução

A Internet das Coisas (IoT) tornou-se um alvo cada vez mais popular para ataques cibernéticos nos últimos anos, porque esses dispositivos geralmente são mal protegidos e podem ser facilmente comprometidos. Para destacar as vulnerabilidades dos dispositivos IoT e incentivar melhores práticas de segurança dos fabricantes, o Zero Day Initiative (ZDI) organizou uma competição Pwn2Own em dezembro, em Toronto, focada na invasão de dispositivos IoT, como impressoras, dispositivos de armazenamento conectado à rede (NAS), roteadores e alto-falantes inteligentes. Esta competição reuniu hackers experientes para demonstrar as suas habilidades em encontrar e explorar vulnerabilidades nesses dispositivos. Aqui, exploraremos a pesquisa que realizamos no roteador Netgear RAX30 para a competição Pwn2Own. 

image.png

Netgear RAX30

Ao realizar pesquisas para uma competição Pwn2Own, não é incomum descobrir várias vulnerabilidades no dispositivo ou software visado. Na verdade, logo no início da nossa pesquisa, identificamos várias vulnerabilidades que eram trivialmente exploráveis. No entanto, como a concorrência reduz os pontos para problemas em duplicidade, sabíamos que apenas relatar essas vulnerabilidades não seria o suficiente. Em vez disso, decidimos ir mais fundo e descobrir as vulnerabilidades mais complexas e novas, que nos proporcionariam uma vantagem competitiva.

Não demorou muito para identificarmos uma vulnerabilidade fácil de encontrar, mas difícil de explorar no processo soap_serverd em execução na porta 5000. Esse processo lida com mensagens SOAP relacionadas à funcionalidade de gerenciamento, principalmente na LAN.

Isso parecia uma boa opção a ser explorada, já que assumimos que a maioria das equipes buscaria por vitórias fáceis.

A vulnerabilidade que encontramos foi um buffer overflow baseado em stack. Geralmente, essa classe de vulnerabilidades é trivial de ser explorada, quando não há proteções stack. No entanto, em algumas versões anteriores, a Netgear decidiu recompilar todos os binários no roteador RAX30 com stack canaries, tornando a exploração muito mais difícil.

Eventualmente, tivemos que encontrar e explorar cinco vulnerabilidades em uma cadeia legal, que nos rendeu cinco pontos na competição Pwn2Own, onde o Claroty Team82 obteve sucesso em várias categorias, além de direcionar roteadores. Essa cadeia de exploração pode ser aproveitada por um invasor, para obter uma execução remota de código com pré-autenticação nos dispositivos afetados. 

Exploits bem-sucedidos podem permitir que os invasores monitorem a atividade dos usuários e sequestrem conexões com a internet, e redirecionem o tráfego para sites maliciosos ou injetem malware no tráfego da rede. Um invasor também pode usar essas vulnerabilidades para acessar e controlar dispositivos inteligentes em rede (câmeras de segurança, termostatos, fechaduras inteligentes), alterar as configurações do roteador, incluindo credenciais ou configurações de DNS, ou usar uma rede comprometida para lançar ataques contra outros dispositivos ou redes.

Compreendendo Stack Canaries

Antes de entrar em detalhes sobre a cadeia de exploits que desenvolvemos, vamos falar sobre stack canaries. Trata-se de um mecanismo de segurança amplamente usado, que ajuda a proteger contra ataques de buffer overflow. Eles trabalham colocando um pequeno valor no stack chamado canary, que é verificado quanto às modificações antes que uma função retorne. Se o canary for adulterado, o programa será encerrado para evitar mais explorações.

Ao tentar contornar o stack canaries, você geralmente tem três opções:

  1. Encontrar uma outra vulnerabilidade, que possa vazar o canary da memória;
  2. Força bruta do canary (isso só é possível em casos específicos);
  3. “Logicamente” burlar o canary: faça algo com overflow, antes que o canary seja verificado.

Vamos nos concentrar na terceira opção: logicamente burlar o canary. Embora isso seja algo que aconteça toda vez que o fato de burlar canaries é mencionado, não há muitos exemplos no mundo real em que essa técnica é utilizada.

Explorando o processo soap_serverd no Netgear RAX30

Os dispositivos Netgear têm um servidor dedicado (soap_serverd) rodando na porta 5000 (HTTP) e 5043 (HTTPS), que é usado como uma API programática (SOAP) para o roteador. 

A API exposta permite que os usuários consultem o dispositivo e alterem sua configuração. O servidor é usado principalmente pelo aplicativo Netgear Nighthawk para iOS e Android. São mais de 180 ações expostas pelo servidorm classificadas nas seguintes categorias:

  1. UserOptionsTC
  2. AdvancedQOS
  3. WANEthernetLinkConfig
  4. WANIPConnection
  5. DeviceInfo
  6. LANConfigSecurity
  7. WLANConfiguration
  8. DeviceConfig
  9. ParentalControl

Quase todas as funções expostas pelo servidor requerem autenticação.

Detalhes da vulnerabilidade do Netgear RAX30

1. CVE-2023-27357: Vulnerabilidade de divulgação de informações de autenticação ausente no GetInfo do Netgear RAX30

Um dos poucos comandos que não requer autenticação é o GetInfo. Na resposta Get, podemos encontrar detalhes sobre o dispositivo, como modelo, número de série e muito mais.  Não há muito que possamos fazer com esta informação neste momento, mas vamos guardar isso para mais tarde.

2. CVE-2023-27368: Vulnerabilidade de desvio de autenticação de buffer overflow baseado em stack do Netgear RAX30 soap_serverd

Para lidar com a comunicação, o soap_serverd lê os cabeçalhos HTTP primeiro e depois analisa-os usando a função sscanf para extrair o método HTTP, o caminho e a versão do protocolo.

image.pngsoap_serverd 0x5274

O código acima irá dividir POST /soap/server_sa/ HTTP/1.1 em três parâmetros:  

  • método: POST
  • caminho: /soap/server_sa/
  • protocolo: HTTP/1.1

Como podemos ver nas chamadas para memset, espera-se que cada parâmetro (método, caminho, protocolo) não tenha mais do que 0x7FC bytes. O servidor não verifica o comprimento dos campos de método, caminho e protocolo, o que significa que podemos transbordá-lo e sobrescrever os dados no stack.

Infelizmente, a função de recepção HTTP na porta TCP 5000 limita o tamanho do cabeçalho HTTP, limitando assim a quantidade de dados que podemos transbordar. Para evitar essa limitação, usamos algo um pouco diferente. 

3. CVE-2023-27369: Vulnerabilidade de desvio de autenticação de buffer overflow baseado em stack NETGEAR RAX30 soap_serverd

O soap_serverd binário escuta as mensagens recebidas em duas portas:

  • 5000
  • 5043 (SSL)

Diferentes funções de “leitura e gravação de socket” são chamadas dependendo da porta, para a qual a mensagem SOAP foi enviada. Ao ler os cabeçalhos das mensagens SOAP, o servidor lê os dados do soquete um byte por vez. No entanto, descobrimos que no fluxo SSL, a função read não verifica quantos bytes foram lidos, o que pode levar a um buffer overflow.

image.png

Ler os dados ilimitados pode resultar em dois problemas:

  1. Exaustão do stack: o envio de buffers grandes pode ler mais do que o tamanho do stack e travar o servidor;
  2. O buffer é de tamanho inesperado: o fluxo que analisa o cabeçalho espera que eles tenham um determinado tamanho máximo. 

Podemos usar essa vulnerabilidade para gravar buffers longos no stack, enquanto contornamos o limite geral de tamanho do buffer. Se usarmos SSL, para enviar a mensagem SOAP, não teremos limite de tamanho (devido ao stack overflow mencionado acima), o que significa que podemos sobrescrever quantos dados desejarmos.

Burlando o stack canaries

Agora que entendemos a vulnerabilidade sscanf, podendo acioná-lo sem quaisquer limitações sobre a quantidade de dados que podemos sobrescrever, ficamos com apenas uma questão: as conservas de stack. Depois de sobrescrever os dados da pilha, logo antes do retorno da função que lida com as solicitações HTTP, o canary stack é verificado e trava o programa.

Em versões recentes no roteador RAX30, a Netgear começou a compilar o binário soap_soerverd com proteções de stack. Essas proteções tornam muito mais difícil explorar o stack overflow da maneira tradicional. Nossa abordagem para ignorar o stack canary foi tentar (de certa forma), logicamente, burlá-lo. 

Os stack canaries são definidos no início das funções, que têm potencial para um overflow, mas são verificados apenas no final do quadro. Isso significa que, ao usar o sscanf de transbordo, podemos sobrescrever o canary, terminar o tratamento da solicitação e o fluxo de resposta e, só então, chegar ao final da função onde o canary é verificado. 

Layout do stack e chamadas

Como a maioria dos comandos SOAP requer autenticação, nos concentramos em tentar burlar o fluxo de autenticação. 

A primeira coisa que o servidor verifica ao autenticar os usuários é se a solicitação veio do 127.0.0.1 (host local). As solicitações provenientes do localhost não requerem autenticação. Felizmente, descobrimos que o IP de origem do socket é armazenado no stack em um deslocamento, que podemos sobrescrever com o stack overflow

Usando o stack overflow para substituir o IP do socket para 127.0.0.1, podemos fazer o servidor pensar que a solicitação foi gerada localmente, ignorar a autenticação e executar qualquer comando soap_serverd.

Essa vulnerabilidade por si só não é suficiente, porque geralmente estamos limitados a 0x800 (2048) e, portanto, a encadeamos com a vulnerabilidade anterior na porta TCP 5043 (SSL), que nos permitiu gravar mais dados no stack. A carga útil final que construímos foi:

payload = POST + SPACE + (“a” * [REDUCTED]) + SPACE + (“b” * [REDACTED]) + “127.0.0.1” + (“c” * [REDACTED])

POST: Método HTTP 

SPACE: Separador 

(“a” * [REDACTED]):  Caminho (URI)

SPACE: Separador

(“b” * [REDACTED]): Parte do protocolo (preenchimento)

127.0.0.1:  Parte do protocolo (dados para substituir no stack para ignorar a autenticação)

(“c” * [REDACTED]): Parte do protocolo (preenchimento)

POST Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8A… 6An7A127.0.0.1……cccc
Content-Length: 452
Cookie:token=bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbaa
Host: 127.0.0.1:1234
User-Agent: pynetgear
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
SOAPAction: urn:NETGEAR-ROUTER:service:DeviceConfig:1#GetConfigInfo
Cache-Control: no-cache
Content-Type: multipart/form-data
Content-Length: 452

<?xml version=”1.0″ encoding=”utf-8″ standalone=”no”?>
<SOAP-ENV:Envelope xmlns:SOAPSDK1=”http://www.w3.org/2001/XMLSchema
  xmlns:SOAPSDK2=”http://www.w3.org/2001/XMLSchema-instance
  xmlns:SOAPSDK3=”http://schemas.xmlsoap.org/soap/encoding/
  xmlns:SOAP-ENV=”http://schemas.xmlsoap.org/soap/envelope/“>
<SOAP-ENV:Header>
<SessionID>A7D88AE69687E58D9A00</SessionID>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

image.png

Usando o IP falso (127.0.0.1), como vemos na imagem “Depois” (After), somos capazes de ignorar a autenticação e chamar qualquer função que o soap_serverd expõe, como se estivéssemos totalmente autenticados. Resolvemos acionar o comando GetConfigInfo que retorna toda a configuração do roteador, incluindo serial do dispositivo, endereço MAC, senhas com hash e muito mais. 

4. CVE-2023-27370: Usando o desvio de autenticação do soap_serverd para redefinir a senha do administrador  

Ao configurar o roteador, os usuários devem inserir uma senha nova e exclusiva, e fornecer perguntas e respostas de segurança que permitirão restaurar a senha caso a esqueçam. As respostas a essas perguntas são armazenadas em texto simples (base64), na configuração do dispositivo. Para redefinir a senha do dispositivo, os usuários precisam do número de série do roteador e das respostas às perguntas de segurança. Portanto, ao obter a configuração bruta, usando as três vulnerabilidades acima, um invasor poderá redefinir a senha do administrador.

image.png
image.png

Usamos essa vulnerabilidade na competição Pwn2Own, para redefinir a senha de administrador do roteador e a encadeamos com CVE-2023-27367.

5. CVE-2023-27367: Burlando a autenticação para RCE usando Telnet mágico e injeção de comando

No passado, os pesquisadores descobriram um “pacote mágico”, que pode habilitar Telnet em roteadores Netgear, habilitando a porta 23 TCP no firewall. https://github.com/davejagoda/NetgearTelnetEnable

O roteador RAX30 não foi diferente. Descobrimos que ainda é possível enviar aquele “open-telnet-magic-packet”, com algumas mudanças em relação aos modelos anteriores, e abrir o Telnet.

O pacote é construído, utilizando:

  1. Endereço MAC do dispositivo;
  2. Nome de usuário;
  3. Senha;
  4. Hash SHA256 da senha usada para configurar o roteador.

Para construir a carga útil, utilizamos o seguinte (que agora temos, porque obtivemos uma cópia da configuração e redefinimos o hash do administrador):

  • secret key: “AMBIT_TELNET_ENABLE+” + sha256(password)
  • cleartext: MAC (preenchimento nulo 0x10) + nome de usuário (preenchimento nulo 0x10) + sha256(password) (preenchimento nulo 0x50)
  • hash: MD5(cleartext)
  • (hash + cleartext) (preenchimento nulo 0xb0)
  • Crie o pacote mágico – Use o algoritmo Blowfish para criptografar a carga útil com uma key secreta como chave.

Depois de enviar o pacote mágico, o dispositivo executará um servidor Telnet e abrirá a porta 23 TCP para novas conexões. No entanto, agora nos deparamos com uma nova questão: a interface Telnet está restrita a comandos específicos. Estávamos presos.

Então, tivemos que procurar outra vulnerabilidade, uma injeção de comando. Descobrimos que o comando TFTP não é filtrado antes de ser executado (CVE-2023-27370), o que significa que podemos executar qualquer comando usando essa interface.

tftp `ping -c 15 192.168.1.2`
image.png

Libcms_cli.so binário no deslocamento 0x5AD8

Isso significava que agora tínhamos acesso shell ao roteador (usando o serviço Telnet) e tínhamos a capacidade de executar comandos arbitrários.

Sumário: PoC PreAuth RCE Flow

  1. Usando o CVE-2023-27357 (Informações confidenciais expostas sem autenticação), recuperamos o número de série do dispositivo.
  2. Usando o CVE-2023-27369 (stack overflow de leitura SSL), fomos capazes de enviar uma carga HTTPs, sem restrições de tamanho.
  3. Usando o CVE-2023-27368 (sscanf stack overflow), pudemos gravar uma carga longa o suficiente para substituir o IP do socket, ignorar a autenticação e ler a configuração do dispositivo.
  4. Usando o CVE-2023-27370 (segredos de texto simples na configuração) para obter as perguntas e respostas de segurança em texto simples e o número de série que obtivemos anteriormente, pudemos alterar a senha do administrador.
  5. Depois de alterar a senha, pudemos enviar um pacote mágico para habilitar um servidor Telnet restrito no dispositivo.
  6. Usando o CVE-2023-27367 (shell escape restrito), obtivemos a execução de código remoto de acesso root no dispositivo.

Esses cinco CVEs podem ser encadeados a roteadores RAX30 afetados e comprometidos, o mais grave e os quais permitem a execução de código remoto de pré-autenticação no dispositivo. A Netgear recomenda que os usuários atualizem esses dispositivos imediatamente.