Me dá um emprego?

A Câmara dos Deputados tinha um programa de estágio e nós acabamos contratando um estagiário para o time de segurança. Era um rapaz recém-formado em Ciência da Computação e que já tinha bons conhecimentos na área de segurança. Ele começou a trabalhar conosco e logo percebemos que tinha bastante habilidade para testar a segurança de sites. Decidimos então aproveitar essa habilidade e colocamos ele para testar vários dos sistemas internos desenvolvidos no Centro de Informática. Muitos desses sistemas nunca tinham passado por um teste de segurança.

O estagiário rapidamente começou a encontrar diversos problemas, tanto em sistemas internos quanto em alguns sistemas expostos externamente, principalmente aqueles utilizados por outros órgãos governamentais. Um desses sistemas já tinha quase 20 anos e, segundo nos disseram, havia sido desenvolvido seguindo as orientações da Microsoft da época. Ele apresentava uma vulnerabilidade clássica de injeção de SQL: a própria consulta era passada como parâmetro pelo browser para o servidor. Bastava manipular a requisição para alterar completamente o comportamento da consulta.

Nas conversas com o estagiário, ficou claro que ele gostava muito desse tipo de atividade e que testava a segurança de sites como hobby. Fazia sentido: aquela habilidade vinha, em parte, da prática. Ele continuou nos ajudando com os testes, mas também passou a atuar em outras atividades do time.

Um belo dia, o diretor do centro de informática ligou para o coordenador da área, que era o meu chefe, perguntando se uma determinada pessoa trabalhava no nosso time. Era o estagiário. O coordenador confirmou e foi chamado para uma conversa presencial. Havia chegado um e-mail de um diretor de TI da Catho, que na época era um dos principais sites de empregos do país, afirmando que o estagiário havia usado a rede da Câmara dos Deputados para invadir o site deles.

Meu chefe então ficou com a tarefa de conversar com o estagiário e entender o que havia acontecido. Ao mesmo tempo, me pediu para analisar os logs de firewall e de proxy para verificar se havia evidências de ataques ao site a partir da rede da Câmara.

Na conversa, o estagiário admitiu que havia encontrado uma falha no site da Catho, relacionada também ao WAF que eles utilizavam, da Imperva. Ele contou que, depois de identificar o problema, enviou um e-mail ao diretor de TI da empresa explicando a vulnerabilidade. No final da mensagem, comentou que estava procurando emprego, caso houvesse interesse em contratá-lo. Isso explicava como a empresa havia identificado quem ele era, mas ainda restava entender por que afirmavam que o acesso tinha partido da rede da Câmara.

O estagiário explicou que normalmente utilizava uma VPN para o seu computador pessoal em casa, de forma que suas conexões não aparentassem vir da rede da Câmara. Ao revisar os logs, encontramos um dia em que ele havia esquecido de ativar a VPN antes de testar se o problema já havia sido corrigido. Foi nesse momento que acabou expondo o endereço de origem da rede interna da Câmara.

Com a situação esclarecida, ficou evidente que ele não tinha intenção de explorar a falha para obter qualquer ganho indevido. Ele apenas tentou usar a descoberta como forma de chamar a atenção da empresa para uma possível oportunidade de trabalho. Ainda assim, tivemos uma conversa séria com ele. Deixamos claro que aquela seria a última vez que o defenderíamos em uma situação desse tipo e que, caso algo semelhante acontecesse novamente, as consequências seriam mais graves. Também reforçamos que, independentemente do uso de VPN, esse tipo de atividade não deveria ser realizado a partir das dependências da Câmara.

Mais ou menos nessa mesma época, a Câmara decidiu implantar o ponto eletrônico para todos os funcionários. Foi realizada uma licitação para aquisição de equipamentos baseados em leitura de impressão digital. Esse era um projeto que envolvia vários departamentos, incluindo o Centro de Informática e o RH. Quando fui chamado para participar, a licitação já havia sido concluída e estávamos na fase de homologação dos equipamentos melhor classificados.

Na prática, isso significava validar se os equipamentos atendiam aos requisitos definidos no edital. Organizamos uma sala e convocamos os fornecedores para demonstrarem suas soluções. Havia requisitos para os leitores biométricos, para leitores de smart cards — utilizados nos crachás — e também para mecanismos de proteção criptográfica dos dados, garantindo segurança e privacidade.

Esse projeto foi interessante porque me levou a revisitar e aprofundar conhecimentos sobre padrões de smart cards, especialmente no que diz respeito aos mecanismos criptográficos utilizados nesses dispositivos. Ao final do processo, tivemos que desclassificar o fornecedor que havia ficado em primeiro lugar, pois ele não conseguiu demonstrar conformidade com todos os requisitos. Eram falhas relativamente simples, mas que estavam explicitamente descritas nas especificações, o que nos obrigava a registrá-las como não-conformidades.

A empresa recorreu da decisão, e tivemos que justificar diversas vezes os motivos da desclassificação. Curiosamente, eles acabaram facilitando nosso trabalho, porque os argumentos apresentados no recurso demonstravam que eles não haviam compreendido corretamente os aspectos técnicos exigidos. Isso reforçou ainda mais a decisão de desclassificação, já que evidenciava a falta de domínio sobre a própria solução.

Esse episódio ilustra um problema recorrente nas licitações no Brasil: se as especificações não forem extremamente detalhadas, abre-se espaço para que empresas sem a devida capacidade técnica vençam apenas pelo menor preço. Isso coloca uma grande responsabilidade sobre quem elabora os requisitos, já que qualquer lacuna pode resultar na aquisição de soluções inadequadas. Não é raro que equipamentos comprados nessas condições acabem sendo subutilizados ou até abandonados.

Enquanto isso, o nosso time começava a perceber que precisava tratar melhor as situações de ataques contra os sistemas da Câmara. Mas essa já é uma história para o próximo capítulo.