Hoje eu vou comentar sobre o relatório do Ministério da Defesa, que saiu no dia 09/11, sobre as eleições e o sistema de votação.
Como esse é um tema muito polêmico, eu já vou deixar o disclaimer de que minha função aqui não é questionar nada. Eu só vou destacar alguns trechos que eu considero relevantes e pontuar a minha visão técnica sobre os pontos levantados no relatório. Eu não vou falar do relatório todo, nem vou colocar ele aqui na íntegra, mas vocês encontram a versão completa com facilidade na internet.
O meu destaque vai especialmente para o item II – ACESSO AO CÓDIGO-FONTE:
No desenvolvimento de softwares, quando se está trabalhando com uma equipe de programadores, nós utilizamos sistemas de versionamento de software, pode ser o GitHub, o GitLab, o Subversion, existem vários sistemas para fazer esse controle de versão, dependendo muito de qual linguagem de programação que está sendo utilizada. Mas o que foi falado aqui é uma coisa bem séria porque, quando você está fazendo uma auditoria, precisa ter acesso a última versão do código-fonte e, pelo que está constando no relatório, foi apresentada uma cópia estática do código e não foi dado acesso ao sistema de controle de versão. Então não tem como afirmar em nenhum momento que o código que estava sendo auditado é o mesmo utilizado para gerar o build final que foi pras urnas. É o que está dizendo aqui o relatório, “isso quer dizer que não há certeza de que o código presente nas urnas é exatamente o que foi verificado.” Esse é o primeiro ponto importante porque, se o processo é transparente e é auditável, por que é que não pode auditar se o código que está sendo verificado é a última versão que foi enviada pro repositório?
Vamos pro próximo ponto:
Para entender o que são bibliotecas terceiras, eu vou dar um exemplo bem simples: vamos dizer que eu quero que o sistema gere um arquivo de PDF, que é um sistema proprietário da Adobe. Então a Adobe fornece uma DLL ou um arquivo de extensão que é inserido dentro do código-fonte e ele passa a ter acesso às bibliotecas internas geram esse PDF. A partir do momento que tem uma série de imports dentro do sistema, mas você não consegue visualizar essas importações, pode ser injetado um código malicioso dentro desses pacotes terceiros que pode mudar o comportamento do sistema.
E aí eu vou cita uma organização super reconhecida, a OWASP, que lista as falhas de seguranças mais comuns de sistemas, no caso eles focam em aplicações web, mas essas falhas se aplicam também a sistemas de desktop, e uma das vulnerabilidades que está no top10 é o uso de bibliotecas terceiras que podem conter algum tipo de vulnerabilidade. Teria que ser possível olhar esses códigos e fazer uma comparação de checksum dessas bibliotecas terceiras com as versões disponibilizadas pelos proprietários e, caso o checksum do arquivo que está sendo utilizado no build seja diferente do emitido pela desenvolvedora, pode ser que essa biblioteca tenha sido alterada, e isso é uma falha de segurança gravíssima.
Vamos ao próximo:
O TSE permitiu que as Forças Armadas auditassem o sistema, mas apenas com papel e caneta para analisar 17 milhões de linha de código, sem acesso ao sistema de controle de versão, sem a possibilidade de auditar as bibliotecas terceiras. Eles colocam no relatório que foi enviada uma solicitação de esclarecimento e o TSE negou. Isso está no final do relatório, no anexo G, é possível verificar que foi solicitado esclarecimento sobre a operação de compilação.
Esse pedido foi protocolado no TSE, que respondeu que não fazia parte do que eles poderiam ter acesso, basicamente foi essa a resposta, “a auditoria não contempla essas informações”.
Vamos revisar: Não tiveram acesso ao Git, que é o sistema de versionamento, não tiveram acesso à máquina que realiza o build, questionaram sobre questões de segurança tanto física quando digital do processo de build, tiveram apenas acesso a um código-fonte estático, que não dá para dizer que é o mesmo código que foi que foi instalado na urna, sendo assim, não tem como confirmar que a assinatura é do mesmo software que foi auditado. Em resumo, não tem como fazer a auditoria. É basicamente isso. Porque não tiveram acesso a todo o processo importante para poder fazer a auditoria.
E ainda, os builds posteriores que possam ter ocorrido, podem conter modificações pelos próprios funcionários do TSE, adicionando algum tipo de código malicioso no processo, ou a máquina pode estar infectada com algum tipo de software que vai fazer a alteração durante o processo de build, as DLLs terceiras que são utilizadas podem ter algum tipo de injection, mas nada pode ser auditado porque não foi permitido acesso a três coisas que são fundamentais para poder fazer a análise e comprovação da integridade. Então o software que está lá na ponta já pode ter sido infectado muito tempo antes, pode ter sido infectado dentro do repositório, um programador subiu um código e quando foi gerado o build esse código vai junto, e os arquivos de onde foi feita a cópia auditada não servem de nada, na pratica é isso.
E aí eles colocam aqui as considerações:
É obvio isso, você tem que ter acesso ao Git e ter ferramentas para poder analisar, são 17 milhões de linhas, é impossível fazer isso com papel e caneta.
O relatório é bem grande e tem bastantes considerações técnicas, então eles colocam um resumo a partir da página 17, eles colocam aqui “Óbices” e “Oportunidades de melhoria”:
Isso é o básico para qualquer auditoria de código-fonte, sem isso não tem como atestar a autenticidade do software, não tem como fazer uma auditoria e falar que o código fonte que está na urna é o mesmo que o que foi auditado por eles.
Depois, na Cerimônia de assinatura digital e lacração dos sistemas:
O que eles estão falando aqui é que o código vai para um servidor de build, mas ninguém viu se esse servidor tem alguma vulnerabilidade, e eles fazem uma sugestão de melhoria, que é o seguinte: “Ampliar a verificação do perímetro de segurança cibernética do local de infraestrutura de TI”. Isso é, essa máquina que faz o build, além de ela propriamente ter que ser olhada para ver se tem alguma vulnerabilidade, se tem algum vírus, o local onde ela está tem que ter o acesso controlado com câmera de monitoramento, tem que ter log de quem está acessando essa sala e que tipo de procedimento foi executado durante a presença dessa pessoa, porque essa máquina é de extrema importância, ela é a máquina mais importante durante o processo, ela que vai gerar a versão final que vai ser introduzida nas urnas.
Eles ainda colocam: “O processo de inspeção do código-fonte não contempla a análise do seu histórico de modificações.” Então, de uma forma mais simples, estão auditando o código, mas não se tem certeza se essa é a última versão, ele pode ter sido mexido depois, então não tem como atestar que esse é o mesmo código que está na urna. Além disso, de nada vale o certificado digital e a assinatura digital, porque não tem como atestar que aquele software está íntegro. Fazer a assinatura digital de um software íntegro e não íntegro é a mesma coisa porque, como não tem o código-fonte para poder gerar o build e fazer o checksum, não tem como validar se aquele software foi criado a partir do código-fonte. Essa é a premissa básica de qualquer auditoria de código, quando você compila o mesmo código duas vezes, ele tem que gerar o mesmo checksum. Se não gerou o checksum igual, é porque teve alguma modificação do código ao longo do processo, seja por causa de modificações no Git ou seja porque teve modificações durante o processo de build, e se você não tem como ter acesso ao código-fonte e gerar o build, então o processo de assinatura digital não vale de nada.
Continuando, fizeram teste de integridade, fizeram projeto-piloto de biometria, verificação de correlação de contabilização de voto. Todas as outras coisas não tiveram nenhuma anomalia, e aí muita gente pode concluir que se não teve anomalia, não tem nenhum problema, mas, vamos lá, se você faz um sistema pra poder fraudar uma votação, obviamente também vai fazer com que esses sistema consiga identificar se ele está sendo analisado, isso é bem básico. O ponto que é importante levantar aqui é que, caso haja algum tipo de manipulação por causa dessas possíveis falhas no servidor de build e não ter acesso ao código de commit, é tudo interno, não tem a possibilidade de uma pessoa externa acessar fazer modificação, é muito difícil de isso acontecer. Precisaria de uma série de informações, conseguir brecha de segurança, ter backdoor, é muito complicado, teria que ter sido feito dentro do TSE. Caso haja algum tipo de alteração no código-fonte, esse relatório não tem como chegar numa conclusão, porque não tiveram acesso às informações, é simples. Eu só estou colocando as hipóteses aqui. Numa hipótese de, caso tenha algum tipo de manipulação, isso foi feito internamente por quem teve acesso ao servidor do build, ou algum commit posterior à cópia que foi apresentada para a auditoria.
E se as outras empresas de auditoria passaram por esse mesmo processo de restrição, de não poder usar nenhum tipo de software, de ter que fazer com papel e caneta, essas auditorias não valem de nada, porque elas não comprovam a veracidade de nada. Precisaria ser refeito tendo acesso ao código-fonte de fato e tendo acesso ao software instalado nas urnas. No meu ponto de vista, cada dia que passa isso se torna mais complicado de ser feito porque, depois que a eleição passou, esse software pode ter sido deletado, esse build que foi feito e utilizado na votação pode ter sido apagado, já podem ter sido feitas modificações no Git, então essa auditoria teria que ter sido feita no processo onde foi gerado o build. Onde que precisa ter a auditoria de fato? Olhou o código fonte, teve acesso aos commits, dali pra frente, não se alteramais nada; Gera-se o build, faz a validação do checksum; No dia da eleição, verifica se as urnas estão com o mesmo checksum computado no dia que foi gerado o build. Esse seria o processo ideal pra poder se comprovar que o software está 100% íntegro, senão qualquer auditoria que for feita não vai valer de nada, é simples assim. É um assunto bem técnico, é bem complicado de entender, mas quem tem conhecimento de desenvolvimento de software sabe. Enfim, não vou me aprofundar mais, mas eu achei bem complicadas as ponderações.
Inclusive eu vi aqui uma chamada aqui da Gazeta do Povo, no perfil oficial no Instagram, que o Ministro da Defesa não apontou diretamente fraudes, mas citou risco e sugeriu investigação. A notícia diz: “Paulo Sérgio Nogueira encaminhou, nessa quarta-feira, dia 09, ao presidente do Tribunal Superior Eleitoral, Alexandre de Moraes, o relatório de fiscalização do sistema eletrônico de votação. No documento técnico, militares não apontam indícios de fraude nas urnas eletrônicas, disseram que o objetivo do trabalho não era apurar crimes eleitorais. Por outro lado, aponta a possibilidade de relevante risco à segurança na fase de compilação dos programas instalados na máquina, pela possibilidade de acesso à rede dos computadores usados nesse processo. Além disso, a pasta afirma que no teste de integridade das urnas realizado no dia da eleição, não é possível afirmar que o sistema eletrônico de votação está isento de influências de eventuais códigos maliciosos que possam alterar seu funcionamento. Neste ano o TSE atendeu a uma das sugestões das Forças Armadas ao realizar o teste com biometria com eleições reais, perto e dentro das seções de votação. Ao encaminhar o relatório a Moraes, Paulo Sérgio comunicou a sugestão dos técnicos militares de realizar uma investigação técnica para melhor conhecimento do ocorrido na compilação do código-fonte e de seus possíveis efeitos. Além disso, promover analise minuciosa dos códigos binários que efetivamente foram executados nas urnas eletrônicas. Boa parte do relatório diz que não é possível aos técnicos examinar de forma abrangente e aprofundar em todo o sistema na preparação das urnas.”, que é justamente o que eu estou falando aqui.
Vamos ver o que isso aí vai dar. Realmente essa parte é bem preocupante porque, de novo, se todas as auditorias das urnas foram feitas dessa forma, não tem como se comprovar a integridade do software, que pode ter sido rompida no processo de compilação do software e no servidor de build, e, para fazer isso, teria que ser alguém dentro do TSE.
Eu também fiz uma auditoria independente dos Boletins de Urna do primeiro turno das eleições. Vou deixar o post fixado aqui:
O conteúdo deste post foi retirado do vídeo “Comentando o relatório do Ministério da Defesa”:
