Mais de 170 mil firewalls SonicWall expostos a DoS

Resumo

Os dispositivos SonicWall de última geração (NGFW) série 6 e 7 são afetados por duas vulnerabilidades de negação de serviço não autenticadas com potencial para execução remota de código. A SonicWall publicou avisos para CVE-2022-22274 e CVE-2023-0656 com um ano de intervalo e relatou que nenhuma exploração foi observada na natureza; no entanto, uma exploração de prova de conceito para este último foi divulgada publicamente.
A pesquisa descobriu que os dois problemas são fundamentalmente os mesmos, mas podem ser explorados em diferentes caminhos HTTP URI devido à reutilização de um padrão de código vulnerável. A análise aprofundada do bug subjacente nos permitiu produzir um script de teste que pode determinar se um dispositivo é vulnerável sem travá-lo. Baixe aqui .
Usando dados de origem BinaryEdge, verificamos os firewalls SonicWall com interfaces de gerenciamento expostas à Internet e descobrimos que 76% (178.637 de 233.984) são vulneráveis ​​a um ou ambos os problemas.
O impacto de um ataque generalizado pode ser grave. Em sua configuração padrão, o SonicOS reinicia após uma falha, mas após três falhas em um curto período de tempo ele inicializa no modo de manutenção e requer ação administrativa para restaurar a funcionalidade normal. O firmware mais recente disponível protege contra ambas as vulnerabilidades, portanto, atualize imediatamente (e certifique-se de que a interface de gerenciamento não esteja exposta à Internet).

Background

Há alguns meses, o Watchtowr Labs publicou um artigo detalhando a pesquisa que levou à descoberta de nove novas vulnerabilidades que afetam os dispositivos SonicWall NGFW. Quando surge uma ameaça emergente como esta, a equipe Cosmos, da Bishopfox responde identificando rapidamente todos os dispositivos afetados ligados à Internet e notificando os clientes que estão vulneráveis. Este caso não foi diferente, mas também aproveitaram a oportunidade para revisar as vulnerabilidades históricas que afetam os produtos SonicWall para ver se algum bug esquecido poderia gerar uma pesquisa interessante.
Uma questão em especial nos chamou a atenção: CVE-2022-22274. De acordo com o comunicado do fornecedor, a vulnerabilidade era um buffer overflow não autenticado que afetava as interfaces de gerenciamento web NGFW. Eles atribuíram a ele uma pontuação CVSS de 9,4, indicando alta explorabilidade e impacto:

Uma vulnerabilidade de buffer overflow baseada em pilha no SonicOS via solicitação HTTP permite que um invasor remoto não autenticado cause negação de serviço (DoS) ou potencialmente resulte na execução de código no firewall….

A SonicWall PSIRT não está ciente da exploração ativa em estado selvagem. Nenhum relatório de PoC foi tornado público e o uso malicioso desta vulnerabilidade não foi relatado à SonicWall.

A pesquisa inicial confirmou a afirmação do fornecedor de que nenhuma exploração estava disponível; no entanto, assim que a equipe identificou o código vulnerável, a equipe descobriu que se tratava do mesmo problema anunciado um ano depois como CVE-2023-0656. SSD Labs publicou um artigo técnico do bug com uma prova de conceito, observando dois caminhos URI onde o bug poderia ser acionado. A equipe descobriu que CVE-2022-22274 foi causado pelo mesmo padrão de código vulnerável em um local diferente, e a exploração funcionou em três caminhos URI adicionais.

Análise de Vulnerabilidade

Para identificar o código vulnerável subjacente ao CVE-2022-22274, usamos Ghidra e BinDiff para comparar as diferenças entre as versões vulneráveis ​​e corrigidas do sonicosvbinário, que é responsável por lidar com solicitações HTTP para a interface de gerenciamento da web. Graças à análise do Watchtowr Labs (referenciada acima), a equipe já tinha uma boa noção da arquitetura SonicOS e um guia para acessar o sistema de arquivos, que exigia extrair chaves de partições LUKS criptografadas e descriptografá-las. Felizmente, durante esta fase da investigação, a Praetorian publicou um artigo que fornece uma análise detalhada do processo de desencriptação e lançou uma ferramenta para simplificar a extracção de chaves , o que acelerou significativamente os esforços.

Depois de comparar algumas funções que foram modificadas entre as versões de firmware NSv 6.5.4.4-44v-21-1452 e 6.5.4.4-44v-21-1519, foi encontrada uma que mostrava sinais claros de estar relacionada ao tratamento de solicitações HTTP, incluindo solicitação métodos, strings de consulta, código HTML e mensagens destinadas à exibição em um navegador da web. As funções descompiladas das duas versões revelaram as seguintes alterações no código-chave:

Vulnerável

Remendado

Este bloco de código envolveu duas chamadas sequenciais __snprintf_chk()com a saída da primeira chamada usada para determinar os argumentos da segunda. Na versão corrigida, a variável que armazena a saída da primeira chamada foi alterada de um inteiro assinado para um não assinado, uma verificação de limites foi adicionada antes de alimentar esse valor na segunda chamada de função e verificações adicionais foram adicionadas à entrada e saída da segunda chamada.

Neste ponto, a equipe estava confiantes de que havíamos encontrado o código vulnerável, mas para entender a lógica por trás do bug e como explorá-lo, tiveram que olhar a definição da função para __snprintf_chk(). De acordo com a especificação principal LSB:

int __ snprintf_chk(char * str, size_t maxlen, int flag, size_t strlen, const char * formato,…); …

A interface __ snprintf_chk() deve funcionar da mesma maneira que a interface snprintf(), exceto que __snprintf_chk() deve verificar se há estouro de buffer antes de calcular um resultado….Se um estouro for antecipado, a função deverá abortar e o programa chamará ele deverá sair.

Embora seja possível que os desenvolvedores do SonicWall tenham usado explicitamente o __snprintf_chk(), essa função geralmente é inserida no código C em tempo de compilação como um substituto para a snprintf()função se o _FORTIFY_SOURCEsinalizador estiver definido no nível necessário. Independentemente disso, os desenvolvedores pretendiam claramente proteger contra buffer overflows, mas cometeram um descuido crucial: presumiram que o valor de retorno de snprintf()ou __snprintf_chk()seria igual ao número de caracteres gravados no buffer de saída. Se olharmos a documentação do snprintf(), entretanto, este não é o caso quando o buffer de destino é muito pequeno:

As funções snprintf () e vsnprintf () não escrevem mais que sizebytes (incluindo o byte nulo de terminação (‘\0’)). Se a saída foi truncada devido a esse limite, o valor de retorno será o número de caracteres (excluindo o byte nulo de terminação) que teriam sido gravados na string final se houvesse espaço suficiente disponível. Assim, um valor de retorno igual size ou superior significa que a saída foi truncada .

Em outras palavras, quando a string de entrada passada snprintf()ou __snprintf_chk()é maior que o número de bytes solicitados para impressão, o valor de retorno é definido como o número de caracteres na string de entrada, não o número de caracteres que foram realmente gravados no buffer de saída. .

Para ilustrar, considere este código de exemplo:

#include <stdio.h>  
int principal() {  
  char buf[20];  
  int resultado = __snprintf_chk(buf,6,1,20,"olá mundo");  
  printf("buf: %s\nresultado: %d",buf,resultado);
}

A saída deste código é:

buf: olá  
resultado: 11

Observe que resultcontém o número de caracteres na string de entrada (11), não o número escrito em buf(5). 

A equipe acredita que os desenvolvedores do SonicWall presumiram que o valor de retorno corresponderia ao comprimento da string de saída e usaram isso para calcular o deslocamento do buffer de saída e o comprimento máximo da string para gravar ao chamar snprintf()ou __snprintf_chk()uma segunda vez. Vamos ver o impacto em cada um dos dois primeiros argumentos passados ​​para esta chamada de função:

• O primeiro argumento __snprintf_chk()é um ponteiro para o buffer onde a função gravará os dados. O valor passado para a segunda chamada de função é igual à primeira, apenas o ponteiro é incrementado pelo valor de retorno da primeira chamada. Os desenvolvedores claramente pretendiam que isso fizesse com que a segunda chamada de função acrescentasse dados ao mesmo buffer que a primeira, mas se o valor de retorno da primeira chamada for maior que o número de caracteres que foram realmente escritos, a segunda chamada receberá um ponteiro para algum local desconhecido na pilha (após o final do buffer) como seu primeiro argumento.
• O segundo argumento __snprintf_chk()é o tamanho máximo dos dados a serem gravados (em bytes) no buffer de saída, incluindo o terminador de string (um byte nulo). O valor passado para a segunda chamada de função é definido como 1024 menos o valor de retorno da primeira chamada. Os desenvolvedores parecem ter pretendido que seu código concatenasse duas strings formatadas, mas limitam o comprimento do resultado a 1.024 caracteres.

O primeiro problema com esta abordagem é que maxlenusa type size_t, que é equivalente a um número inteiro não assinado de 64 bits neste caso. Se o valor de retorno da primeira chamada for maior que 1.024, quando a segunda chamada subtrair esse valor de 1.024, o resultado retornará ao valor inteiro máximo em vez de se tornar negativo ( consulte esta discussão sobre estouro de número inteiro para obter mais detalhes ). Em outras palavras, a segunda chamada de função especifica uma quantidade extremamente grande de dados para gravar no buffer relativamente pequeno de 1.024 bytes.

Pode-se supor que a proteção contra estouro de buffer descrita na documentação  __snprintf_chk()impediria que esse estouro realmente ocorresse. Porém, essa proteção depende do strlenparâmetro ser configurado com um valor menor que o maxlenparâmetro. Na segunda chamada de função strlené definido como o valor máximo de um inteiro não assinado de 64 bits ( 0xffffffffffffffff), portanto, maxlennunca pode ser maior que strlene a proteção contra overflow se torna inútil. Isso sugere que os desenvolvedores escreveram seu código usando snprintf()em vez de e __snprintf_chk(), em seguida, ativaram proteções contra buffer overflow em tempo de compilação, fazendo com que o compilador substituísse snprintf()e __snprintf_chk()definisse o valor de strlenpara corresponder ao tamanho do buffer de saída. Como o tamanho do buffer de saída é dinâmico na segunda chamada de função e strlendeve ser declarado como uma constante, o compilador define strleno valor máximo possível em vez de um tamanho razoável (como 1024).

Para ilustrar, considere que os desenvolvedores provavelmente escreveram código assim:

n = snprintf(buf, 0x400, "%s", user_input);  
snprintf(&buf[n], 0x400-n, "%s", user_input);  

Então, em tempo de compilação, o compilador alterou o código para isto:

n=__snprintf_chk(buf, 0x400, 1, 0x400, "%s", user_input); //strlen=0x400  
__snprintf_chk(&buf[n], 0x400-n, 1, 0xffffffffffffffff, "%s", user_input); // sizeof(&buf[n]) só pode ser determinado em tempo de execução, então strlen=(size_t) -1

Para corrigir esse erro na versão corrigida do firmware, os desenvolvedores adicionaram uma verificação entre as duas chamadas snprintf()ou __snprintf_chk()para garantir que o valor de retorno da primeira chamada seja menor que 1024. Se a verificação falhar, a segunda chamada de função será ignorada e tratada da solicitação é encerrada. O patch restaura efetivamente a proteção contra buffer overflow sem modificar as chamadas reais para snprintf()ou __snprintf_chk().

Explorar o desenvolvimento

Tendo identificado o código vulnerável subjacente ao CVE-2022-22274, a equipe procedeu ao rastreamento através da fonte descompilada para entender como criar uma solicitação HTTP que pudesse alcançá-lo. A função do manipulador de solicitações continha ifinstruções que executavam uma série de comparações de strings com um buffer de origem desconhecida. O exame de cada uma dessas comparações revelou strings que pareciam ser caminhos de URI, portanto não foi exagero assumirmos que o envio de uma solicitação HTTP começando com o caminho de URI em uma ifinstrução específica nos levaria ao caminho de código correspondente, por exemplo:

Encontramos dois caminhos de URI que levam ao bloco de código vulnerável: /resources/e /%s/. A última era uma string de formato (não a mostrada acima) relacionada ao recurso Advanced Threat Protection (ATP). Quando ativado, esse recurso fica acessível em /atp/; quando desativado, pode ser acessado em  //.

Nesse ponto, a equipe sabia para onde enviar uma solicitação HTTP para acionar o bug, mas ainda precisávamos criar uma carga útil. Com base em nossa análise do código vulnerável, o caminho do URI na solicitação HTTP precisava ter mais de 1.024 bytes para criar as condições para um buffer overflow, mas também de uma string de entrada longa o suficiente para o código vulnerável. segunda chamada para __snprintf_chk(). Felizmente, a segunda chamada também obteve sua string de entrada da solicitação HTTP, mas em vez de ler o caminho do URI, ela leu a string da versão HTTP. Ficou claro, então, que as duas funções foram usadas para construir uma solicitação como esta:

• Primeira chamada para __snprintf_chk(): método de solicitação de gravação (por exemplo, GET) e caminho URI
• Segunda chamada para __snprintf_chk(): anexar versão HTTP

O segundo requisito para exploração, então, era uma string de versão HTTP extremamente longa. Usando esse conhecimento junto com a análise dinâmica para testar algumas de nossas suposições, a equipe escreveu a seguinte prova de conceito em Python:

importar soquete, ssl
ctx=ssl.SSLContext()
ctx.verify_mode=ssl.CERT_NONE
s=socket.create_connection(("192.168.250.152",443))
ss=ctx.wrap_socket(s)
dados=b'GET /recursos/' +b'A'*0x700 + b' HTTP/1.'+b'0'*0x4000+b'\r\n\r\n'
ss.enviar(dados)

A equipe testou a exploração em nossa instância NSv vulnerável e observamos que ela travou com uma falha de segmentação:

Com um pouco mais de testes, descobriu-se que o aplicativo usava canários de pilha e uma carga útil menor poderia produzir uma falha mais confiável, substituindo-os por valores diferentes de zero:

dados=b'GET /recursos/' +b'A'*0x400 + b' HTTP/1.1'+b'A'*0x4000+b'\r\n\r\n'

foi testado a exploração DoS com sucesso em dispositivos virtuais vulneráveis ​​das séries 6 e 7 e confirmado que ela falhou em versões de firmware corrigidas em ambas as séries.

(Re-)Descoberta de CVE-2023-0656

Durante a revisão das __snprintf_chk()chamadas de função sequenciais, a equipe notou que o mesmo padrão de código foi reutilizado em outros locais da função do manipulador da web. Ao repetir a análise anterior do caminho de ataque, descobriu-se caminhos URI adicionais exploráveis:

• /stats/
• /Security_Services
• /prefsProcessing.html(embora este caminho tivesse outras condições que a equipe não conseguiu satisfazer)

A equipe ficou entusiasmada ao descobrir que a exploração dos dois primeiros desses caminhos foi bem-sucedida não apenas contra os dispositivos NSv vulneráveis ​​ao CVE-2022-22274, mas também contra aqueles que foram corrigidos! Pouco tempo depois, porém, descobriu-se que, em vez de encontrar um zero day, foi validado independentemente o CVE-2023-0656. SSD Labs publicou um artigo sobre esta vulnerabilidade em abril de 2023 e lançou uma exploração de prova de conceito quase idêntica à da equipe Cosmos.
Até onde a equipe sabe, nenhuma pesquisa anterior foi publicada estabelecendo uma ligação entre CVE-2022-22274 e CVE-2023-0656. Claramente, ambas as vulnerabilidades compartilham o mesmo bug subjacente, mas o patch inicial apenas corrigiu o código vulnerável em um local, deixando as outras instâncias para serem encontradas e relatadas um ano depois.
 

Desenvolvimento de uma verificação de vulnerabilidade segura

Ser capaz de derrubar um alvo é muito bom, mas que tal identificar dispositivos vulneráveis ​​sem derrubá-los? Com base em nossa análise do bug,  o time Cosmos tentou criar um teste que pudesse dizer com segurança se um alvo específico foi afetado ou não. Provou ser bastante simples – se você se lembra, tivemos que satisfazer duas condições para acionar a falha usando uma solicitação HTTP:

1. O caminho do URI deve ter mais de 1.024 bytes
2. A string da versão HTTP deve ser longa o suficiente para causar uma substituição canário da pilha

Ao satisfazer a primeira condição, mas não a segunda, podemos obter respostas diferentes do alvo de maneira confiável, porque a verificação de buffer overflow em versões corrigidas faz com que a conexão seja interrompida sem resposta. Aqui está nossa prova de conceito modificada:

importar soquete, ssl
ctx = ssl.SSLContext()
ctx.verify_mode=ssl.CERT_NONE
s = soquete.create_connection(("192.168.250.152", 443))
ss = ctx.wrap_socket(s)
dados = b"GET /recursos/" + b"A" * 0x400 + b" HTTP/1.1\r\n\r\n"
ss.enviar(dados)
imprimir(ss.recv(1048))

E aqui estão as respostas que obtemos dos nossos alvos de teste:

• Vulnerável:b'HTTP/1.1 302 Found\r\nLocation: https:// 192.168.250.152/auth.html\r\n\r\n'
• Remendado:b''

• HTTP 302: vulnerável
• vazio (conexão interrompida): corrigido
• qualquer outro código de status HTTP: não afetado

A equipe testou isso em todos os cinco caminhos de URI e descobriu que a verificação de vulnerabilidade era confiável em uma ampla variedade de versões do SonicOS, por isso criou-se uma ferramenta Python fácil de usar para testar (e explorar, se desejado) facilmente qualquer alvo: baixe-a aqui .
 

Metodologia de digitalização

Tendo descoberto uma verificação de vulnerabilidade à prova de falhas, o time Cosmos perguntou: “Quantos dispositivos SonicWall na Internet são vulneráveis?” Para responder a esta pergunta, primeiro recorreu-se ao BinaryEdge para montar uma lista de alvos. Como o cabeçalho de resposta HTTP “Servidor: SonicWALL” está codificado em todos os dispositivos SonicWall NGFW, eles são facilmente identificáveis ​​na Internet:

Uma pesquisa rápida retornou aproximadamente 1,5 milhão de resultados, mas foi necessária alguma filtragem para garantir que obtivesse apenas dispositivos NGFW e, especificamente, a interface de gerenciamento web. Felizmente, isso foi tão simples quanto garantir que o cabeçalho de resposta “Servidor” fosse apenas “SonicWALL” e não, por exemplo, “SonicWALL SSL-VPN Web Server”, além de garantir que a conexão usasse encapsulamento TLS. Em todos os dispositivos das séries 6 e 7, a interface de gerenciamento web só permite acesso via HTTPS (embora você possa ativar o redirecionamento HTTP).

A equipe exportou todo o conjunto de dados do BinaryEdge, extraímos URLs HTTPS, a equipe filtrou a lista para IPv4 (para simplificar – foi uma diferença insignificante) e removeu-se entradas duplicadas. Em seguida, o time escreveu um script simples para testar a acessibilidade e verificar os cabeçalhos de resposta. Depois de filtrar nossos resultados dessa maneira, chegamos a um conjunto-alvo de 234.720 dispositivos.

Em seguida, o time  escreveu uma versão encadeada de verificação de vulnerabilidade para verificar rapidamente todos os cinco caminhos potencialmente vulneráveis ​​em todos os alvos. Ao incluir algumas otimizações (como minimizar o número de caminhos de teste para cada CVE), conseguiu-se reunir os resultados em poucas horas. Aqui está um exemplo do conjunto de resultados:

{"https://65.144.219.82:443": {"CVE-2022-22274": verdadeiro, "CVE-2023-0656": verdadeiro}}
{"https://65.141.205.218:8443": {"CVE-2022-22274": falso, "CVE-2023-0656": falso}}
{"https://65.144.97.218:443": {"CVE-2022-22274": verdadeiro, "CVE-2023-0656": verdadeiro}}
{"https://65.141.191.90:443": {"CVE-2022-22274": falso, "CVE-2023-0656": verdadeiro}}

Em alguns casos, os resultados incluíram portas diferentes no mesmo destino, por isso os o time Cosmos consolidou (resultando em 233.984 dispositivos únicos) e obtive os seguintes resultados:

Talvez o mais surpreendente tenha sido a descoberta de que mais de 146.000 dispositivos acessíveis ao público são vulneráveis ​​a um bug publicado há quase dois anos!

Conclusão

CVE-2022-22274 e CVE-2023-0656 representam a mesma vulnerabilidade em diferentes caminhos URI, um problema que é facilmente explorado para travar dispositivos vulneráveis. Agora que sabemos como realizar uma verificação de vulnerabilidade segura, teste todos os dispositivos SonicWall NGFW que você implantou em sua rede! Se você tiver um dispositivo vulnerável, há duas etapas que você deve seguir imediatamente:

1. Remova a interface de gerenciamento da web do acesso público.
2. Atualize o firmware para a versão mais recente disponível.

Neste momento, um invasor pode facilmente causar uma negação de serviço usando essa exploração, mas, como a SonicWall observou em seus comunicados, existe um potencial para execução remota de código. Embora seja possível criar uma exploração que possa executar comandos arbitrários, pesquisas adicionais são necessárias para superar vários desafios, incluindo PIE, ASLR e canários de pilha. Talvez um desafio maior para um invasor seja determinar antecipadamente quais versões de firmware e hardware um alvo específico está usando, já que a exploração deve ser adaptada a esses parâmetros. Como atualmente não se conhece nenhuma técnica para a impressão digital remota dos firewalls SonicWall, a probabilidade de invasores aproveitarem o RCE é, na estimativa da equipe, ainda baixa. Independentemente disso, tomar as precauções apropriadas para proteger seus dispositivos garantirá que eles não sejam vítimas de um ataque DoS potencialmente doloroso.