segunda-feira, 31 de julho de 2017

Invadiram o meu computador mas não conseguiram nada...



Infelizmente houve um acesso não autorizado na minha máquina. Por sorte não aconteceu muita coisa. Mas como isso aconteceu???

Apesar de todas as medidas de segurança que tomo para evitar problemas, no último domingo notei que algo estava errado quando a impressora imprimiu diversas folhas de modo bem estranho.

Gastou todo papel que estava na bandeja

A princípio pensei que fosse uma doideira no sistema da HP ou do Google, já que a minha atual impressora utiliza WiFi e todas as máquinas de casa podem imprimir diretamente na impressora.

Como não encontrei nada de errado fui dar uma olhada nos logs do CUPS e encontrei duas coisas estranhas nos últimos trabalhos de impressão. Justamente a impressão que gastou as folhas é que contem uma string semelhante a essa:

smbprn.00000053 Remote Downlevel Document 

E o usuário usado é totalmente diferente dos que normalmente são usado nas impressões. O que seria eu e a, minha esposa, Regiane. Mesmo assim ainda aparece mais o meu nome de usuário já que a Regiane usa um notebook a parte e a impressão é direto na impressora, sem passar pela minha máquina. Então o problema cai direto no Samba (por causa do smbprn). Mas como isso pode acontecer??

Normalmente as portas usadas pelo Samba e, por tabela, pelo sistema de compartilhamento do Windows são bloqueadas pelo Oi Velox já tem anos, juntamente com outras portas. Até aí nada demais e pode ser considerado até uma boa medida de segurança já que deixar um compartilhamento Windows exposto na rede externa é o mesmo que deixar a porta do galinheiro aberta para a raposa entrar. 

O resultado pode ser esse de cima

Claro que, a muitos anos atrás, foram feitos vários portscans e testes que mostraram que a porta 139, a responsável pelo método de compartilhamento do Windows e do Samba, estavam filtrados, o que deixava a minha máquina segura e, consequentemente, ficava tranquilo.

Mas, de alguma data desconhecida até o momento da publicação deste artigo, algum gerente de TI da Oi resolveu revisar os bloqueios e liberou as portas 137, 138, 139 e 445. Tudo isso sem nenhum aviso e em um momento bem perigoso por conta dos ataques que tiraram um monte de máquinas Windows do ar.

Será que foi algum estagiário? Não quero acreditar que a Oi colocou alguém desse tipo para fazer isso.

Como a liberação foi sem aviso prévio, parte dos compartilhamentos ficaram totalmente expostos na rede. Alguns compartilhamentos tinham senhas e nem foram afetados, outros eram somente leitura e havia um, onde guardo programas para instalar no notebook e nas máquinas virtuais, estavam com permissão total de leitura e escrita. É neste compartilhamento onde foi notado a maior alteração. Vários arquivos de instalação foram infectados com alguns malwares e outros apareceram para infectar qualquer máquina que tentar executar na rede.

Sem contar com o compartilhamento da impressora, que estava exposto. O invasor ou algum malware que esteja se espalhando, pensou que a minha máquina era mais uma Windows e enviou um malware, na esperança que o spooler do Windows rodasse e baixasse todos os componentes para que possa infectar ou sequestrar os arquivos, da mesma maneira que o WannaCry fez. Porém estava no Linux e o Samba repassou para o CUPS e o mesmo ignorou o arquivo e repassou para a impressora. O resto da história todo mundo já sabe.

Mas como saber se está em perigo??

Uma página que recomento é essa: https://www.grc.com/x/ne.dll?bh0bkyd2  Nesta página pode mostrar quais portas estão abertas e quais compartilhamentos estão expostas na rede.

O resultado que pode aparecer são esses:

Se o link 'File Sharing' mostrar a mensagem "Unable to connect with NetBIOS to your computer.", isso pode indicar:
  • Ou a sua máquina está protegida, o que significa que está seguro
  • Ou está atrás de um roteador, o que coloca uma barreira antes da sua máquina. Neste caso só deve se preocupar um pouco mais com a segurança do próprio roteador.
Agora se o mesmo link mostrar uma página dizendo o nome da sua máquina e os compartilhamentos, aí tem que se preocupar e muito. Qualquer um pode ver a sua máquina e fazer qualquer coisa para acessar os arquivos que estão nele.

Para evitar isso podemos fazer o seguinte:

No Windows:

Vá nas propriedades do adaptador de rede PPPOE e desmarque o 'Compartilhamento arquivos/impressoras para redes Microsoft'

Esse é um exemplo mostrando uma das placas de redes. Mas a primeira opção deve ser desmarcada caso seja a interface PPPOE

Feito isso refaça o teste e vai notar que os compartilhamentos não estão mais expostos na rede externa.

No Linux;

Esse foi o meu caso, onde o Samba deixou os compartilhamentos expostos. Para resolver isso edite o /etc/samba/smb.conf e adicione o seguinte, no final da seção [global]:

      bind interfaces only = yes
      interfaces = lo eth0
 

Assim, o Samba só vai deixar as portas abertas na interface local (do localhost) e na eth0. Deixando a interface ppp0 com menos falhas para explorarem e fazerem a maior bagunça.

O saldo final de tudo isso foram algumas folhas, que viraram rascunho, provavelmente alguns vídeos fotos e músicas foram copiados (Nada comprometedor já que os arquivos mais particulares estavam em áreas mais seguras do computador ou fora), e alguns instaladores danificados (isso é resolvido com um novo download). Nenhum rootkit foi encontrado, o que é uma notícia melhor ainda.

Isso ainda mostra que o Linux é seguro. Pode não ser totalmente seguro. Mas, mesmo com uma combinação de um descuido meu com uma pisada de bola da Oi, o estrago ficou restrito a apenas alguns compartilhamentos e só. Agora, se fosse uma máquina Windows que não estava totalmente atualizada e com as portas abertas:

Seria "NOW PANIC AND FREAK OUT"

Tenham uma boa semana.

segunda-feira, 3 de julho de 2017

Resolvendo os problemas do Guardião 30 Horas em qualquer sistema (Versão 2017)


Atualização 03/09/2021: Depois de muitos anos o Itaú resolve acabar com o acesso a quem não tem suporte ao Guardião.
Então é possível que esta publicação esteja inválida após o dia 21/09/2021 e sejamos forçados a instalar o Warsaw. Assim que descobrir uma nova forma de contornar isso farei uma nova publicação com o novo método. Por hora segue o texto atual.


Essa é uma atualização completa de http://www.adilson.net.br/2012/02/resolvendo-os-problemas-no-guardiao-30.html e as dicas, a seguir, vale tanto para Linux quanto para Windows, Mac, e qualquer outro sistema operacional. Isso é válido para o Itaú. Como ainda não testei na Caixa, não dá para garantir que esta dica vá funcionar do mesmo jeito.

Antes de mais anda me desculpe pela longa demora em criar algo novo aqui. Ainda tenho algumas idéias mas ainda não coloquei em prática. Como hoje tive problemas em usar o Itaú no celular, resolvi usar novamente no Desktop e aí é que os problemas apareceram:

Já faz algum tempo que o Java deixou de ser suportado na maioria dos navegadores modernos. E quem usa Linux, como eu e muitos por aí, ficaram preocupados já que a outra opção seria usar o Windows com um software muito complicado chamado Warsaw. Também conhecido como G-Buster e, nos sites dos bancos, como Guardião. Chamo de complicado porque ele já entrou em conflito com atualizações do windows, chegou a bloquear a conexão de máquinas utilizando o ipv6, além de deixar alguns processos rodando nos computadores que podem fazer qualquer coisa que não imaginamos o que poderia ser.

Sobre o uso do banco através de máquina windows ainda tem a outra ameaça:



E, consequentemente...


Nisso, o criador deste software complicado, a GAS Tecnologia, resolve portar o mesmo para o Linux. Tanto que, pelo menos nas distribuições Debian, Ubuntu e derivados, ao clicar em instalar o Guardião, ele baixa o pacote deb correspondente.

O que compensa é que os aplicativos para celular evoluíram tanto que vale mais a pena usar eles do que instalar este plugin.

Mas hoje tive um problema no acesso ao celular e, a alternativa, é usar o navegador. Porém não queria instalar o Warsaw na minha máquina principal e de confiança. Mas, como tenho uma máquina virtual com Ubuntu (Também tenho uma máquina virtual com Windows 10, mas não será usada pelos motivos mostrados anteriormente) então resolvi utilizar ela para acessar o banco. Afinal, cria-se um snapshot, instala o Warsaw, usa o banco e, depois restaura o estado anterior.

Então fiz o seguinte, acessei o Itaú, tanto pelo Chrome quanto no Firefox e me deparei com esta mensagem:


Cliquei em Instale agora, continuar e baixou o arquivo warsaw_setup_64.deb. Daí é feita a sua instalação, juntamente com qualquer dependência que solicitar.

Durante a instalação apareceu algo bastante estranho:

Configurando warsaw (1.3.0) ...
/var/tmp /
Generating RSA private key, 4096 bit long modulus
...........................................................................................................................................++
......................................++
e is 65537 (0x10001)
Generating RSA private key, 4096 bit long modulus
..........................................++
......................................++
e is 65537 (0x10001)
Signature ok
subject=/CN=127.0.0.1
Getting CA Private Key
certutil: could not find certificate named "Warsaw Personal CA": SEC_ERROR_BAD_DATABASE: security library: bad database.
Notice: Trust flag u is set automatically if the private key is present.
certutil: could not find certificate named "Warsaw Personal CA": SEC_ERROR_UNRECOGNIZED_OID: Unrecognized Object Identifier.
Notice: Trust flag u is set automatically if the private key is present.

Bad database? Unrecognized Object Identifier?

Será que isso influencia em algo?? Bom, os navegadores foram reiniciados e foi feito um teste inicial no Google Chrome. O resultado foi:


Não sei o porque do Chrome não detectar o Warsaw. Então fui no Firefox e:


Melhorou, então fui digitar a senha e...



Mas como pode isso??? Tudo foi instalado, a máquina virtual reiniciada e o erro permanece. Provavelmente pelos problemas de certificados que apresentou na instalação.

Fui ver os processos e encontrei isso:

adilsond@fett:~$ ps aux |grep warsaw
root       1039  0.0  1.0 742956 21704 ?        Sl   19:41   0:00 /usr/local/bin/warsaw/core
adilsond   2298  0.0  0.5 584392 10280 ?        Sl   19:43   0:00 /usr/local/bin/warsaw/core


Um dos processos roda com o usuário root.

O Warsaw roda como root!

O Warsaw roda como root!


O Warsaw roda como root!
Lembra que falei que não sabemos o que o Warsaw pode fazer numa máquina Windows? Pois bem, se no Windows ele pode fazer bagunça, imagina no Linux, e como usuário root que é o administrador do sistema. Tem que ter em mente como funciona o sistema de permissão do Linux. Um usuário comum pode não ter permissão para mexer e bagunçar o sistema por completo. Mas o usuário root é considerado um "Deus", ou seja, ele pode tudo. Imagina um rm -rf * na pasta raiz (/). Como usuário comum o estrago pode até ser minimo. Mas, como root, o estrago é total. Claro que existem softwares que rodam como root no Linux mas, boa parte deles, tem código fonte disponível, já foi auditado por muita gente ao redor do planeta e as falhas são sanadas rapidamente. Já o warsaw, acho que só tem aqui no Brasil, é de código fechado e ninguém sabe o que ele pode fazer se tiver algum exploit violento do tipo Zero Day(É o exploit que só se descobre depois que se ******). (OBS: Pior que já teve um caso assim).

O aplicativo para celular ainda estava com com problemas, o que foi confirmado posteriormente pelo Itaú:



Entrar no Windows estava fora de cogitação. Então, durante uma pesquisa no Google, encontrei algo que remonta o antigo problema da época do java.


No artigo anterior eu expliquei como alterar o User-Agent, para um outro navegador. Neste caso agora só precisa fazer com que o navegador finja que é um Firefox mais recente num sistema Solaris (Pode ser outro sistema operacional que não seja Windows, Linux ou Mac OS X).

Mozilla/5.0 (Solaris; Solaris x86_64; rv:54.0) Gecko/20100101 Firefox/54.0

Com essa alteração, acessei o Itaú, tanto pelo Firefox quanto pelo Chrome, o acesso foi normal e não apareceu nenhum aviso para instalar ou que está usando o Guardião.  Nos testes o Warsaw nem estava instalado ou rodando. Isso garantiu que eu fizesse as transações sem problema algum, apenas pedindo o código do token no celular.

Com isso foi mostrado que é possível acessar o Internet Banking do Itaú sem a necessidade deste plugin chato. Como a solução é via navegador, ele vale tanto para Linux, quanto para Windows, Mac e qualquer outro sistema onde este warsaw é utilizado.

Como falei, anteriormente, isso só foi testado no Itaú. Em outros bancos aonde o plugin é usado eu não fiz o teste e não há garantias que ele possa funcionar. Nas o ideal mesmo é que este plugin seja abandonado e que os bancos utilizem outras soluções menos invasivas para o usuário final.

Espero que isso seja de grande ajuda para quem tem problemas com este plugin. Vou ver se consigo voltar a publicar mais vezes já que tenho bastante material para publicar e tenham uma boa semana.