Por Marcelo Tavares de Santana*
Estatisticamente, dizemos que quanto mais complexo é um sistema, mais probabilidades de falhas ele tem. Isso nos faz lembrar de brincadeiras antigas quando se dizia que era possível consertar um Fusca com um grampo de cabelo (por ter uma mecânica simples). Isso era praticamente uma verdade com o povo brasileiro e sua avançada habilidade de fazer gambiarras. Mesmo em áreas complexas como a computação, essa habilidade também é notada e apreciada por fazer os sistemas funcionarem até a resolução definitiva de problemas técnicos.
Grandes projetos, como a Internet, estão sempre sujeitos a descobertas de novas falhas pontuais ou até mesmo falhas de projeto, sendo que este último pode não ter resolução pela tecnologia. Felizmente, com a cooperação e o compartilhamento de conhecimento da cultura do Software Livre, muitos desenvolvedores ao longo do tempo contribuíram para soluções complexas e confiáveis. Inclusive, tivemos e temos muitas pessoas altamente habilidosas auditando as tecnologias que usamos no dia a dia. Inclusive, a Automotive Grade Linux tem levado cada vez mais o Software Livre para soluções automotivas.
Na comunicação entre computadores, há uma falha de projeto que não pode ser resolvida apenas com criptografia, a menos que alguns cuidados extras sejam tomados. Trata-se do ataque Man-in-the-middle. A Figura 1 nos apresenta três cenários de comunicação de aplicação, que é como os programas de computador trocam dados em alto nível no modelo de comunicação de rede TCP/IP usado na Internet e em muitas organizações. Existem muitos equipamentos e tecnologias entre a comunicação de dois computadores, mas eles funcionam praticamente como se tivessem uma conexão direta, pois os intermediários basicamente replicam os bits ao longo do trajeto da comunicação. Na figura, os equipamentos remotos são identificados por letras e são os servidores de aplicação, enquanto os demais são os equipamentos dos usuários. O exemplo com o Servidor A representa o que ocorre na esmagadora maioria das comunicações da Internet. No caso do Servidor B, haveria um “grampo” na comunicação com um usuário malicioso copiando dados de comunicação, mas não haveria problema se a comunicação fosse criptografada, pois não adiantaria copiar dados que não podem ser compreendidos. No exemplo com os Servidores C e D, temos o modelo de comunicação do ataque Man-in-the-middle.
Figura 1: exemplos de comunicação de aplicação
Nesse tipo de ataque, um computador (Servidor C) se comunica de forma criptografada com outros equipamentos, simulando ser o usuário para um lado (Servidor D) e simulando ser o serviço acessado para o usuário. Para isso, as mensagens são descriptografadas, copiadas e novamente criptografadas para o outro lado, e assim ambas as pontas da comunicação imaginam que estão em uma comunicação segura. Esse computador intermediário pode entrar na comunicação tanto de forma física, o que é mais difícil, como de forma lógica, por direcionamento de rotas de comunicação, sem que seja necessária qualquer manipulação de equipamentos. Na forma física, alguém precisa literalmente colocar um equipamento no meio, podendo até ser dentro de um provedor de Internet, mas pela própria exibição da atividade suspeita e de um equipamento não esperado, é mais improvável que alguém faça a instalação e não seja percebido. Na forma lógica, alguns comandos podem redirecionar nossos dados para outro lugar e depois redirecioná-los para o verdadeiro local de destino. No entanto, existem tecnologias que impedem que isso seja feito com a facilidade de alguns comandos: as chaves criptográficas e os certificados digitais.
Nas matérias “Mapa de Segurança Digital” (11) e (12), são abordados o uso de chaves criptográficas e a formação de uma rede de confiabilidade, onde a checagem de fingerprints (impressões digitais) das chaves é um passo fundamental para a comunicação segura. Como duas chaves criptográficas não podem ser iguais nem ter a mesma fingerprint, independentemente do algoritmo, não é possível que um computador Man-in-the-middle possua a mesma chave que as pontas da comunicação. Na comunicação GPG ou por Signal, é mais comum fazermos a checagem das impressões digitais das chaves, mas quando costumamos fazer a checagem da fingerprint de uma instituição financeira ou loja virtual? Só o fato de haver um ícone de cadeado ao acessar um site é suficiente para considerá-lo confiável? Se formos pessoalmente falar com o gerente do banco e pedir a fingerprint da página de acesso às nossas contas, ele será capaz de fornecê-la? As respostas são: raramente ou nunca, não e provavelmente não. É nesse contexto que não há interesse em que as pessoas entendam o tipo de ataque mencionado nesta matéria, pois poderia inviabilizar o e-commerce, uma vez que as empresas, incluindo mega corporações e governos, não ajudaram a nos preparar para a segurança digital. No caso dos bancos, uma autenticação multifatorial bem feita resolve a questão, e é por isso que eu até gosto que o banco que uso me obrigue a liberar meus dispositivos tendo que ir pessoalmente a um caixa eletrônico dentro de uma agência da empresa. Algumas pessoas podem considerar antiquado não ser tudo digital, inclusive a identificação para criar uma conta bancária, mas é um equívoco pensar assim. No caso dos sites em geral, contamos com um elemento que nunca deveria ser utilizado em segurança: a sorte. No entanto, isso não é motivo para paranoia, como será explicado a seguir.
Quando baixamos um navegador Web, como o Firefox, ele vem com um banco de dados de Autoridades Certificadoras de diversos países. Essas autoridades criam, controlam, identificam, certificam e verificam certificados/fingerprints dos endereços digitais, e quando tudo está correto, o navegador nos mostra o ícone de cadeado. Portanto, se baixamos o programa navegador de um local mais confiável, podemos seguir em frente; se for um navegador de código aberto, melhor ainda. Por local confiável, entende-se um lugar onde as instalações são relativamente conhecidas, como nossa própria casa ou o Wi-Fi da empresa, por exemplo. Conheço apenas um caso em que o roteador Wi-Fi de um amigo foi invadido e teve dados substituídos, redirecionando-o para um site bancário falso, mas ele percebeu e formatou o roteador reinstalando o firmware do equipamento (veja ‘Uma busca por hardwares seguros’).
O maior problema dos sistemas de certificados digitais e autoridades certificadoras é a falta de participação da sociedade na rede de confiabilidade. Somos reduzidos a meros observadores dos ícones de cadeado quando deveríamos receber ou obter os fingerprints dos certificados com alguém e nos acostumar a checá-los. Vale lembrar que, na matéria ‘O elo mais fraco da autodefesa digital‘, é bem destacado que um hacker especialista em precauções de invasões de sistemas “em praticamente todas as estratégias de invasão de sistemas, há […] um momento em que ele precisa mandar um e-mail, uma mensagem, ligar ou mesmo visitar a pessoa ou empresa que será invadida”, ou seja, ele conta com o desconhecimento por parte da vítima.
Como essa cultura não existe, podemos fazer algumas coisas para entender melhor se um certificado é confiável e se estamos livres de um ataque Man-in-the-middle em nossa comunicação. Vamos a um exemplo prático usando o site da Caixa Econômica Federal (CEF), o navegador Firefox e o navegador Tor Browser. Este último é importante porque acessará o site da CEF virtualmente por outro país. No entanto, um erro absurdo aconteceu: foi proibido o acesso ao banco pelo Tor Browser, o que é um indício de que a equipe de segurança não é segura o suficiente para permitir o acesso pelo navegador. Ao tentar com o Banco do Brasil, ocorreu algum outro erro que não foi possível determinar, mas foi possível com o Nubank. Em ambos os navegadores, ao acessar o site, clicamos no ícone de cadeado, depois em “Conexão segura”, “Mais informações”, “Ver certificado” e conferimos as ‘Miniaturas de chave/Fingerprints’ do certificado. Na ocasião, o Tor Browser acessou o banco através da Alemanha. Como as impressões digitais eram iguais em dois navegadores diferentes, acessando por países diferentes, é praticamente nulo que haja algum tipo de violação na comunicação. Outras variações de testes simples podem ser feitas, como abrir o endereço na casa de um amigo, anotar o fingerprint e depois verificar em seus próprios equipamentos.
Para conhecer um pouco mais sobre certificados e disseminar uma cultura de verificação de segurança, usando o Firefox para computador, segue uma sugestão de atividades:
- Semana 1: conheça autoridades certificadoras em menu (três traços), Configurações, Privacidade e Segurança, Segurança, Ver Certificados, Autoridades;
- Semana 2: escolha alguns sites importantes para comunicação e finanças, vá em dois lugares distintos e anote os fingerprints deles;
- Semana 3: confira os fingerprints coletados em outros lugares nos teus equipamentos;
- Semana 4: mostre as autoridades certificadores e discuta o assunto com parentes e amigos.
O Firefox para smartphones não mostra os detalhes dos certificados. É preferível usar os aplicativos dedicados dos bancos nesse tipo de equipamento.
Esse assunto não seria exaustivo, mesmo que o artigo fosse dez vezes maior. Por isso, uma boa prática é usar preferencialmente programas livres de comunidades ativas, pois eles têm centenas e até milhares de auditores no próprio processo de desenvolvimento. Dessa forma, vamos construindo uma sociedade da informação com mais conhecimento e menos dependência da sorte.
Boa navegação a todos!
*Professor de Ensino Básico, Técnico e Tecnológico do Instituto Federal de São Paulo