Quick Talk

Resumo: procure por malware na máquina.

O cliente ligou à tarde dizendo que desde o início do dia não conseguia transmitir nenhuma NF-e para a Secretaria da Fazenda. E para atender as regras desse nosso país corrupto os caminhões de mercadorias estavam parados na porta da fábrica sem poder sair. O suporte do desenvolvedor do programa já havia olhado o problema e dito que me chamassem porque “algo estava bloqueando o envio”.

Logo que a funcionária do faturamento me mostrou o problema e eu vi a mensagem “403: Forbidden” eu já fiquei achando que o problema não era o que o suporte estava dizendo. Não se tratava de “bloqueio” porque “forbidden” quer dizer “proibido”. A SEFAZ estava recusando a operação.

Uma pesquisa rápida com o Google me levou a esta página. Todas as possíveis razões tinham a ver com certificado digital, mas uma delas mencionava SSL. Data e hora da máquina estavam corretas e desativar o anti-virus não surtia efeito, então decidi procurar por malware na máquina.  Como vocês podem lembrar do que escrevi no meu post sobre o Superfish, malware parasitando o protocolo SSL se tornou algo comum.

No Gerenciador de Tarefas já dava para perceber algo errado. Rodei JRT e Adwcleaner e ambos encontraram porcarias, mas nada “diferente” do que eu estava acostumado. Rodei o Autoruns e uma entrada estranha me levou até Arquivos de Programas, onde encontrei os dois diretórios mostrados na imagem abaixo. Perceba que os dois programas parecem ter a mesma origem (mesmos arquivos) e ambos fazem uso da biblioteca OpenSSL.

Quando eu vi o primeiro diretório pensei que poderia ser algo do desenvolvedor do emissor de NF-e, porque alguns arquivos começam com “nf”. Mas ao encontrar o outro diretório ficou estranho demais. Agora eu estou convencido de que “nf” é a abreviação de “net filter”. Ora… a única razão que eu conheço para um programa desconhecido querer usar OpenSSL é parasitar a conexão de outros programas.

Os dois diretórios foram renomeados no modo de segurança (o “_” inicial foi acrescentado por mim) porque não podiam ser apagados no modo normal do Windows e por precaução eu dei um reset no protocolo TCP-IP com o comando “netsh int ip reset”. Mas o log do netsh não mostrou nada particularmente estranho por isso tenho razoável certeza de que a culpa era desses dois programas, porque depois disso o emissor de NF-e passou a funcionar normalmente.

Aparentemente a SEFAZ é capaz de perceber que algo parasitava a conexão SSL. Eu não cheguei a testar se os certificados da empresa funcionavam em outros lugares. Eu não lembro os detalhes do funcionamento do protocolo SSL, mas se o servidor for capaz de checar toda a cadeia de certificação até a raiz (e não se contentar apenas o fato de que “alguém” está atestando a validade do certificado cliente) ele pode detectar que um ataque MITM está em andamento ao encontrar um certificado que não deveria estar ali e abortar a conexão.