A urna eletrônica já foi hackeada?
Quando falamos sobre segurança da urna eletrônica brasileira, a discussão quase sempre acaba virando política.
Mas existe uma abordagem muito mais interessante: tratar a urna como qualquer outro sistema crítico de segurança da informação.
Nenhum sistema sério deve ser considerado seguro simplesmente porque alguém afirma que ele é.
Ele precisa ser atacado.
Testado.
Auditado.
Falhas precisam ser encontradas, corrigidas e testadas novamente.
E é justamente isso que torna a história da segurança das urnas brasileiras interessante: pesquisadores realmente conseguiram quebrar algumas de suas proteções ao longo dos anos.
Isso não significa que uma eleição tenha sido fraudada.
Significa que vulnerabilidades existiram — e foram descobertas antes que pudessem permanecer escondidas.
Primeiro: qual seria o ataque?
Antes de dizer que alguém “hackeou a urna”, precisamos definir exatamente o que foi comprometido.
O sistema eleitoral não é uma única máquina.
Existe o software executado dentro da urna, o processo de preparação e assinatura desse software, mídias utilizadas pelos equipamentos, sistemas administrativos, infraestrutura do TSE e posteriormente os sistemas responsáveis pela transmissão e totalização.
Em segurança, isso é chamado de superfície de ataque.
Comprometer um servidor administrativo do TSE, por exemplo, não significa automaticamente comprometer o software executado dentro das urnas.
Da mesma maneira, encontrar uma vulnerabilidade no software da urna durante um teste controlado não significa que aquela vulnerabilidade tenha sido explorada durante uma eleição.
Essa distinção é essencial.
2012: pesquisadores conseguiram reconstruir a sequência dos votos
Um dos primeiros casos importantes ocorreu no Teste Público de Segurança de 2012.
Uma equipe de pesquisadores conseguiu reconstruir a sequência dos votos armazenados no Registro Digital do Voto (RDV).
O RDV deveria registrar os votos de maneira embaralhada justamente para impedir que fosse possível descobrir a ordem em que foram inseridos.
O grupo conseguiu quebrar esse mecanismo de embaralhamento e ordenar novamente os registros. Tribunal Superior Eleitoral
Isso representava uma vulnerabilidade relacionada ao sigilo do voto.
Porém, havia uma limitação importante: os pesquisadores não conseguiram obter a sequência de comparecimento dos eleitores.
Portanto, conseguiram descobrir a ordem dos votos, mas não conseguiram ligar cada voto a um eleitor específico. Tribunal Superior Eleitoral
Depois do teste, o mecanismo utilizado para embaralhar o RDV foi modificado.
É um exemplo clássico do funcionamento de segurança ofensiva:
encontrar → demonstrar → corrigir.
2017: o ataque tecnicamente mais interessante
O Teste Público de Segurança de 2017 provavelmente produziu os resultados mais interessantes do ponto de vista de cybersecurity.
Os pesquisadores receberam acesso privilegiado ao sistema justamente para tentar quebrá-lo.
Durante os testes, foram encontrados três problemas importantes:
- uma chave criptográfica das mídias presente no ambiente de inspeção;
- uma falha na verificação da assinatura digital de bibliotecas;
- duas bibliotecas sem assinatura digital complementar.
Combinadas, essas vulnerabilidades permitiram que pesquisadores modificassem o comportamento do software da urna durante os testes. Tribunal Superior Eleitoral
Isso é uma vulnerabilidade real.
Não é uma simulação teórica dizendo “talvez fosse possível”.
Houve exploração dentro do ambiente disponibilizado pelo TSE.
Outro grupo, liderado por um perito da Polícia Federal, também conseguiu extrair uma chave utilizada pelo sistema operacional da urna durante os testes. Tribunal Superior Eleitoral
É exatamente o tipo de resultado que um teste de segurança deveria produzir.
E então veio o reteste
Encontrar uma vulnerabilidade não encerra o processo.
Você precisa provar que a correção funciona.
O TSE modificou o sistema após os resultados de 2017. Entre as mudanças estavam correções na verificação de assinaturas, redução das bibliotecas utilizadas e retirada das chaves criptográficas do código-fonte. Tribunal Superior Eleitoral
Em maio de 2018, os grupos que haviam encontrado as vulnerabilidades foram convidados novamente.
A missão era simples:
repitam os ataques.
Dessa vez, os ataques anteriores não conseguiram ultrapassar as novas proteções. O Teste de Confirmação considerou os problemas encontrados anteriormente corrigidos. Tribunal Superior Eleitoral
Esse processo é muito parecido com um pentest seguido de remediation e retest.
E provavelmente é uma das partes mais importantes de toda a segurança do sistema.
2018: hackers realmente invadiram o TSE
Agora chegamos a um acontecimento completamente diferente.
Em 2018 houve acesso não autorizado a sistemas internos do Tribunal Superior Eleitoral.
Esse ataque existiu e posteriormente foi objeto de investigação da Polícia Federal. O próprio TSE reconheceu publicamente o incidente. Tribunal Superior Eleitoral
É daqui que surgem várias afirmações dizendo que:
“Hackers invadiram a urna em 2018.”
Mas tecnicamente isso mistura duas coisas diferentes.
O alvo foi infraestrutura interna do TSE, não uma invasão remota das urnas durante a votação.
Segundo o Tribunal, a investigação não encontrou evidência de que o incidente tenha causado modificação dos sistemas utilizados na eleição ou alteração dos resultados. Tribunal Superior Eleitoral
E existe uma diferença fundamental aqui.
Roubar código não significa conseguir executar código
Essa é uma distinção básica de segurança de software.
Possuir o código-fonte de um sistema pode facilitar enormemente a pesquisa de vulnerabilidades.
Mas:
ler código ≠ modificar produção.
Para transformar conhecimento do código em comprometimento real seria necessário encontrar uma vulnerabilidade explorável e depois ultrapassar outras camadas de segurança necessárias para colocar software modificado no ambiente real.
O software eleitoral passa por processos de geração de hashes, assinatura digital e lacração. A urna verifica essas assinaturas durante sua inicialização. Tribunal Superior Eleitoral
Isso cria outra barreira entre:
“eu encontrei um bug”
e
“eu consegui executar minha versão adulterada desse software em uma urna real”.
São problemas completamente diferentes.
A urna estar offline muda bastante o threat model
Existe ainda uma característica importante do sistema.
A urna utilizada para registrar os votos não fica conectada à internet durante a votação. Tribunal Superior Eleitoral
Isso elimina uma das maiores superfícies de ataque existentes em praticamente qualquer infraestrutura moderna: exposição direta à rede.
Você não pode simplesmente realizar um scan na internet, encontrar milhares de urnas e começar a procurar uma porta vulnerável.
Mas offline não significa invulnerável.
Um sistema isolado ainda pode ser atacado através de supply chain, acesso físico, mídias removíveis, comprometimento durante desenvolvimento, chaves criptográficas, insider threats e falhas no processo de preparação.
É por isso que olhar apenas para “tem internet ou não?” é uma análise pobre de segurança.
O problema real é:
quantas barreiras um invasor precisa ultrapassar para transformar uma vulnerabilidade em comprometimento real?
É nisso que defesa em profundidade importa.
O Teste Público de Segurança é basicamente Red Team
Talvez uma das características mais interessantes do modelo brasileiro seja justamente o Teste Público de Segurança.
Investigadores recebem acesso a equipamentos, software e documentação e tentam comprometer propriedades importantes do sistema.
O objetivo explícito inclui encontrar vulnerabilidades capazes de atingir integridade ou sigilo dos votos. Tribunal Superior Eleitoral
É praticamente a lógica de um programa de red team/pentest público aplicado a uma infraestrutura crítica.
E o fato de vulnerabilidades terem sido encontradas não deveria surpreender ninguém da área.
Na verdade, seria estranho realizar testes ofensivos durante anos e afirmar que absolutamente nenhum problema jamais existiu.
Segurança madura não é:
“Nosso sistema nunca teve vulnerabilidade.”
É:
“Procuramos vulnerabilidades continuamente e temos processos para corrigi-las antes que sejam exploradas.”
Então a urna é impossível de hackear?
Não.
Essa afirmação não faria sentido para praticamente nenhum sistema computacional.
Em cibersegurança não trabalhamos com “impossível”.
Trabalhamos com ameaças, probabilidades, privilégios necessários, superfície de ataque, impacto e camadas de mitigação.
A história dos testes das urnas deixa isso bastante claro.
Pesquisadores já encontraram vulnerabilidades.
Já conseguiram modificar comportamento de software em ambiente controlado.
Já recuperaram material criptográfico.
E a infraestrutura interna do próprio TSE já sofreu acesso indevido. Tribunal Superior Eleitoral
Ao mesmo tempo, esses fatos não demonstram que votos de uma eleição real tenham sido alterados.
São duas afirmações que podem ser verdadeiras simultaneamente:
o sistema já teve vulnerabilidades;
e
essas vulnerabilidades não são evidência de fraude eleitoral.
Essa talvez seja a distinção mais importante de todo o assunto.
Segurança não vem de acreditar que um sistema é perfeito
A parte mais interessante da urna eletrônica, olhando exclusivamente pela perspectiva de segurança, não é tentar provar que ela é “inhackeável”.
É justamente o contrário.
É assumir que falhas podem existir.
Permitir que pesquisadores procurem essas falhas.
Documentar o que encontraram.
Corrigir.
E colocar os mesmos pesquisadores na frente do sistema novamente para tentar quebrá-lo outra vez.
Porque uma das primeiras regras de cybersecurity continua sendo a mesma:
se a segurança de um sistema depende de ninguém encontrar suas falhas, ele provavelmente já começou errado.
E no caso de uma infraestrutura responsável por milhões de votos, continuar tentando quebrá-la é justamente uma das formas de torná-la mais difícil de quebrar.
