Eu tentei PolarProxy para descriptografar o tráfego de malware e encaminhar o tráfego para um servidor falso. Eu estava seguindo o tutorial PolarProxy + INetSim. Eu estava usando PolarProxy em uma VM Ubuntu e o aplicativo com TLS em uma VM Windows. https://www.netresec.com/?page=Blog&month=2019-12&post=Installing-a-Fake-Internet-with-INetSim-and-PolarProxy
No tutorial, para a VM que tem PolarProxy, eu uso o seguinte comando:
$ sudo iptables -t nat -A PREROUTING -i <Ex. enp0s8> -p tcp --dport 443 -j REDIRECT --to 10443
$ sudo ./PolarProxy_1-0-0_linux-x64/PolarProxy -v -p 10443,80,80 -x polarproxy.cer --certhttp 10080 --pcapoverip 57012 -o . --terminate --connect <IP for Fakenet VM> --nosni nosni.polarproxy
Então, com comandos como os seguintes na máquina da vítima, o PolarProxy funciona corretamente descriptografando o tráfego e enviando-o para a VM fakenet.
$ curl.exe --insecure --resolve hello.com:443:<IP for PolarProxy VM> https://hello.com
No entanto, percebi que o PolarProxy descobre o servidor para redirecionar o tráfego inspecionando o campo SNI. Ele, portanto, fornece erros para os comandos como o seguinte, quando a máquina vítima se comunica diretamente com um IP sem especificar o nome do servidor:
$ curl.exe --insecure https://<IP for PolarProxy VM>
Erros de exemplo:
<4>[10443] Transparent TLS proxy System.IO.IOException (0x80131620) : Cannot determine the frame size or a corrupted frame was received.
<4>[10443] Transparent TLS proxy Socket error code HostNotFound System.Net.Internals.SocketExceptionFactory+ExtendedSocketException (0x00000005) : Name or service not known
Então, eu me pergunto se há ferramentas/maneiras de contornar esse problema para aplicativos que não usam DNS/nome do servidor e se comunicam diretamente usando um IP especificado? Estou me perguntando se há maneiras de deixar o PolarProxy encaminhar todo o tráfego descriptografado e corrigido para um IP especificado.
Não sei se preciso de ferramentas que possam adicionar SNI ou algo assim. (Além disso, para máquinas vítimas do Windows no VMware, modificar diretamente o gateway padrão para a VM PolarProxy causa alguns problemas de rede, então isso não parece ser uma solução para mim.)
Obrigado!
Obrigado por reportar esse problema! Parece haver um bug com relação ao manuseio do PolarProxy de
--nosni
em combinação com--terminate
. Estamos analisando como consertar isso para a próxima versão.ATUALIZAÇÃO (10 fev 2025) Agora lançamos o PolarProxy 1.0.2, onde esse bug foi resolvido. Veja a solução alternativa fornecida anteriormente abaixo se desejar usar uma versão mais antiga do PolarProxy (1.0.0 ou 1.0.1) para encerrar conexões TLS sem SNI.
A solução alternativa recomendada é usar um conjunto de regras. Os conjuntos de regras fornecem uma abordagem muito mais bem definida para controlar as ações do PolarProxy. Use a
--ruleset tls-termination.json
opção de linha de comando para que o PolarProxy carregue um conjunto de regras. O conteúdo do arquivo JSON deve ser o seguinte:Isso requer o PolarProxy 1.0.0 ou posterior.
Este conjunto de regras define a ação terminate, bem como o IP do servidor www, então você não precisa fornecer
--terminate
,--connect
ou mesmo--nosni
argumentos ao usar este conjunto de regras. Você precisa substituir 127.0.0.1:80 no JSON por qualquer IP e porta em que seu servidor www FakeNet esteja sendo executado.Aqui está um exemplo de comando que você pode usar:
./PolarProxy -v -p 10443,80,80 --pcapoverip 57012 -o . --ruleset tls-termination.json