RELATÓRIO DE CONSULTORIA

Ministério Público Federal

Exercício 2020

16 de maio de 2020
Controladoria-Geral da União - CGU
Secretaria Federal de Controle Interno

RELATÓRIO DE CONSULTORIA
Órgão: MINISTÉRIO PÚBLICO FEDERAL
Unidade Examinada: SEC. DE TEC. DA INFORMAÇÃO E
COMUNICAÇÃO
Município/UF: Brasília/DF
Plano de Trabalho: #829797
Missão
Promover o aperfeiçoamento e a transparência da Gestão Pública, a
prevenção e o combate à corrupção, com participação social, por meio da
avaliação e controle das políticas públicas e da qualidade do gasto.

Consultoria
O serviço de consultoria é uma atividade de auditoria interna governamental
que consiste em assessoramento, aconselhamento e outros serviços
relacionados fornecidos à alta administração com a finalidade de respaldar
as operações da unidade. Em regra, é prestado em decorrência de solicitação
específica do órgão ou da entidade da Administração Pública Federal.

QUAL FOI O
TRABALHO
REALIZADO PELA
CGU?
Trata-se de trabalho de
consultoria, sob aspectos de
segurança da informação do
Sistema Votum, do Ministério
Público Federal, visando
identificar os controles
atualmente implementados,
as fragilidades e riscos
identificados que possam de
alguma forma comprometer a
integridade da votação e o
sigilo do voto, e apresentar
sugestões de melhorias.
POR QUE A CGU REALIZOU ESSE
TRABALHO?
Este trabalho teve origem em razão de
solicitação formal do MPF para auditoria
externa no sistema VOTUM de votação do
MPF.
As análises objetivaram responder se os
mecanismos de controle implementados no
processo de votação são suficientes para
suportar a salvaguarda das informações.
QUAIS AS CONCLUSÕES
ALCANÇADAS PELA CGU?
QUAIS AS RECOMENDAÇÕES
QUE DEVERÃO SER ADOTADAS?
Os testes realizados permitem concluir que a
aplicação possui razoável segurança contra
ataques oriundos de Agentes Externos, em
razão principalmente dos mecanismos de
defesa adotados da infraestrutura do MPF. Já
contra ataques originados de Agentes Internos,
pessoas que possuem acesso ao código fonte,
ambiente de desenvolvimento, banco de dados,
ou servidores que hospedam a aplicação, o
sistema Votum necessita de melhorias
contínuas e constante vigilância no sentido de
bloquear brechas para ações maliciosas ou no
mínimo permitir a rastreabilidade dessas ações,
quando ocorrerem.
SUMÁRIO
INTRODUÇÃO 5

RESULTADOS DOS EXAMES 8

1. Documentação de desenvolvimento do sistema deficiente 8

2. Ausência de controle de versão do sistema 9

3. Registro de eventos (log) da aplicação deficiente 12

4. Fragilidades nas credenciais para acesso ao ambiente de desenvolvimento e ao banco de

dados do sistema. 13

5. Fragilidades que podem comprometer o sigilo do voto 17

6. Outras cópias do sistema encontram-se instaladas. 18

7. Ausência de rotinas de testes periódicos de backup. 19

8. Risco de não garantir a autenticidade do eleitor 20

9. Aplicação se mostrou segura frente a testes básicos de ataques por agentes externos. 32

RECOMENDAÇÕES 42

CONCLUSÃO 44
INTRODUÇÃO
Este trabalho teve origem em razão de solicitação formal do MPF realizada por meio do
Ofício nº 415/2020- CHEFIAGAB/PGR que trata da solicitação de auditoria externa no
sistema VOTUM de votação do MPF.
O trabalho realizado pela CGU está classificado no Manual de Orientações Técnicas da
Atividade de Auditoria Interna Governamental (MOT) como um trabalho de Consultoria,
do tipo Aconselhamento. Os serviços de aconselhamento geralmente caracterizam-se pela
proposição de orientações em resposta a questões formuladas pela gestão. Os serviços
dessa natureza são os que geralmente mais se aproximam dos trabalhos de avaliação,
quando comparados com seu processo de operacionalização.

ESCOPO
O escopo da consultoria abrangeu o seguinte:
1. Análise dos mecanismos de controle no processo de desenvolvimento do software para
salvaguarda do código fonte.
2. Análise dos mecanismos de controle e gerenciamento das chaves de votação, aplicados
durante o processo de votação.
3. Testes básicos de invasão por meio da aplicação web.
4. Análise dos mecanismos de controle de acesso e salvaguarda dos ativos de software,
banco de dados e infraestrutura que suporta o pleito eleitoral.
A análise objetivou mostrar quais controles estão implementados atualmente, as
fragilidades e riscos identificados, que possam de algum modo vir a comprometer a
integridade da votação e o sigilo do voto, e apresentar sugestões de melhorias.
Essas análises objetivaram responder a uma questão de auditoria principal e subquestões
de auditoria:
Questão de Auditoria Principal:
Os mecanismos de controle implementados no processo de votação são suficientes para
suportar a salvaguarda das informações?
Subquestões de Auditoria:
1. Os mecanismos de controle implementados no processo de desenvolvimento do
software são suficientes para suportar a salvaguarda do código fonte?
2. Os mecanismos de controle implementados são suficientes para suportar a salvaguarda
das chaves de votação?
3. A aplicação web resiste a testes básicos de invasão?

5
4. Os mecanismos de controle de acesso e salvaguarda dos ativos de software, banco de
dados e infraestrutura são suficientes para não permitir o acesso indevido por agentes
externo e interno?
Vale ressaltar que se trata de um trabalho de cunho colaborativo prestado pela CGU, em
atendimento ao Ofício supra, no intuito de fornecer subsídios para apoiar a tomada de
decisões, considerando o pedido formal e as parcerias já estabelecidas entre o MPF e a
CGU no combate à corrupção, não se tratando de avaliação, certificação, ou interferência
nas ações desse MPF.
Destaca-se também que não foi franqueado acesso a diversos documentos solicitados pela
equipe de consultoria, impossibilitando a esta equipe opinar acerca de eventuais riscos
sobre esses aspectos.
• Políticas, normas e procedimentos relacionados a: Controle de Acesso;
autenticação e autorização de usuários ao Sistema Votum; gerenciamento de
senhas da organização e/ou do Sistema Votum; atualização de softwares e
ferramentas de segurança; backup utilizado pelo Sistema Votum e seu banco de
dados; o modo como a senha do worksapce apex_stic_voto e do esquema de banco
voto são passadas ao presidente da comissão eleitoral;
• Arquitetura de redundância do hardware e/ou software do banco de dados e
armazenamento do Sistema (ex: máquina virtual, servidor).
NÃO ESCOPO
Não fez parte do Escopo do trabalho a ser realizado pela CGU:
1. Análise de vulnerabilidades implementadas no código fonte.
Em razão da ausência de profissionais na CGU que trabalhem ou detenham conhecimento
necessário na plataforma APEX ORACLE, bem como da ausência de ferramentas para
análise de vulnerabilidades do código fonte.
2. Análise da integridade dos registros no banco de dados.
Em razão da ausência de profissionais na CGU que trabalhem ou detenham conhecimento
necessário em banco de dados ORACLE e na linguagem PLSQL.
3. Testes Avançados de Invasão.
Em razão da ausência de profissionais na CGU que trabalhem ou detenham conhecimento
necessário na plataforma APEX ORACLE, no Banco de dados ORACLE, na linguagem
PLSQL, bem como da ausência de ferramentas para testes de invasão. Poderão ser
realizados testes de invasão mais simples na aplicação web.
4. Monitoramento da aplicação na data do Pleito Eleitoral.
Em razão da ausência de profissionais na CGU que detenham conhecimento necessário
na plataforma APEX ORACLE, no Banco de dados ORACLE, na linguagem PLSQL,
bem como da ausência de ferramentas para monitoramento das aplicações e da
infraestrutura.

6
5. Emissão de opinião sobre a integridade do resultado do pleito eleitoral e do sigilo do
voto
Em razão dos inúmeros riscos relacionados a um processo eleitoral, que envolvem
possibilidade de ataques por agentes externos e internos, e pela ausência de profissionais
com conhecimento técnico necessário e ferramentas para realizar outros testes a opinião
sobre a integridade do resultado do pleito eleitoral e do sigilo do voto fica comprometida.
6. Certificação de segurança do software eleitoral.
Também não faz parte do escopo deste trabalho a emissão pela CGU de um certificado
de segurança do software eleitoral.
7. Inspeção física da infraestrutura.
Não será realizada inspeção física na infraestrutura de TI do MPF, em razão das restrições
impostas pela pandemia do Novo Coronavírus e do curto prazo definido para os trabalhos.
Os testes serão realizados sobre o controle lógico.

DEFINIÇÕES
Os ativos de informação a serem protegidos são:

1. Integridade do resultado da votação (Integridade)

2. Sigilo do voto (Confidencialidade)
3. Autenticidade dos registros (Autenticidade)
4. Disponibilidade do sistema (Disponibilidade)

Na avaliação de um sistema eleitoral, unicamente digital, há a necessidade de avaliar

riscos considerando duas formas de atacantes aos ativos de informação descritos
anteriormente:

Agente Externo: Indivíduo de fora da organização que tem interesse no resultado do

certame, para beneficiar ou prejudicar determinados candidatos, ou para travar o sistema,
prejudicando o pleito, ou expor os votos individuais, comprometendo a integridade da
votação ou sigilo do voto.

Agente Interno: Individuo de dentro da organização, que participou ou não do

processo de desenvolvimento do software, mas que possui acesso aos servidores, código
fonte e banco de dados e dados dos eleitores e que tem interesse pessoal ou de terceiro
nos ativos de informação. Recorrentemente, quando se fala em segurança da informação,
a figura do atacante interno é diminuída. Entretanto, quando se fala em pleito eleitoral,
esse atacante de potencial elevado de alterar qualquer resultado e apagar, ou não permitir
o registro de seus atos.

7
RESULTADOS DOS EXAMES
1. Documentação de desenvolvimento do sistema deficiente

Para um desenvolvimento de software seguro é necessário a adoção de uma série de

medidas que garantam a qualidade em todas as etapas do processo de
desenvolvimento. Uma das medidas necessárias é o gerenciamento seguro do código-
fonte.
Na Solicitação de Informações nª 001, enviada à unidade auditada, foram solicitados os
seguintes itens, com relação ao sistema VOTUM:
• disponibilização da documentação de desenvolvimento do sistema;
• informações sobre o ambiente de programação: log de alterações no código;
lista de pessoas que já trabalharam no desenvolvimento do sistema (nome e
login); se o ambiente de desenvolvimento é segregado ou compartilhado;
• informações acerca de como é feito o controle de versionamento do sistema;

Ao analisar a resposta da unidade auditada acerca dos itens acima, bem como nas
reuniões realizadas por meio de videoconferência com a equipe do MPF, percebe-se as
seguintes fragilidades no que diz respeito aos mecanismos de controle implementados
no processo de desenvolvimento do sistema VOTUM.

Com relação à documentação de desenvolvimento do sistema, a unidade informou o

seguinte:
“Não há documentação formal do sistema, apenas a documentação do
projeto, e os manuais de usuário; de desenvolvimento, existem comentários
nos códigos PL/SQL nos componentes do sistema e nas procedures de banco.
A aplicação utiliza a mesma base de dados do sistema anterior feito em
Coldfusion, e o modelo entidade-relacionamento contendo as tabelas e os
relacionamentos pode ser gerado sob demanda.”

Pela informação acima, percebe-se uma deficiência na documentação do

desenvolvimento do sistema, com a existência apenas de alguns comentários nos
componentes do sistema e nas procedures do banco de dados. Uma boa documentação
a nível de desenvolvimento deve conter todas as operações e informações necessárias
do software, facilitando seu uso e entendimento, sendo muito importante em futuras
manutenções e evoluções, proporcionando uma expansão do software de forma
sustentável e segura. Além disso, uma boa documentação minimiza possíveis
retrabalhos, principalmente, quando um novo desenvolvedor é incorporado à equipe,
já que se tem um nível de detalhamento do software suficiente para entender o que já
foi feito e evitar refazer funcionalidades já implementadas.

Cabe esclarecer que este ponto não está tratando sobre a documentação de requisitos,
apenas sobre a documentação a nível de código. Embora a unidade não tenha sido
questionada sobre esse ponto, cabe informar sobre a importância de uma análise de
requisitos consistente para a construção de um software com qualidade e segurança.

8
É importante destacar a seguinte diretriz que a Norma ABNT NBR ISO/IEC 27002:2013
define com relação à segurança em processos de desenvolvimento e de suporte de
sistemas de informação:

“14 Aquisição, desenvolvimento e manutenção de sistemas

14.1 Requisitos de segurança de sistemas de informação
Objetivo: Garantir que a segurança da informação seja parte integrante de
todo o ciclo de vida dos sistemas de informação. Isto também inclui os
requisitos para sistemas de informação que fornecem serviços sobre as redes
públicas.
14.1.1 Análise e especificação dos requisitos de segurança da informação
Controle
Convém que os requisitos relacionados à segurança da informação sejam
incluídos nos requisitos para novos sistemas de informação ou melhorias dos
sistemas de informação existentes.
Diretrizes para implementação
Convém que os requisitos de segurança da informação sejam identificados
usando vários métodos, como requisitos de conformidade oriundos de política
e regulamentações, modelos de ameaças, análises críticas de incidentes ou o
uso de limiares de vulnerabilidade. Convém que os resultados da identificação
sejam documentados e analisados criticamente por todas as partes
interessadas.
Convém que os controles e requisitos de segurança da informação reflitam o
valor da informação envolvida para o negócio (ver 8.2) e o seu potencial
impacto negativo, que possa resultar de uma falha da segurança da
informação.
Convém que a identificação e a gestão dos requisitos de segurança da
informação e os processos associados sejam integrados aos estágios iniciais
dos projetos de sistemas de informação. Considerações iniciais dos requisitos
de segurança da informação, por exemplo, na fase do projeto podem conduzir
a uma solução de custo mais eficiente e eficaz.”

Diante do exposto acima, considerando a criticidade do sistema Votum, por se tratar de

um sistema eleitoral do MPF, para escolha e proposição de membros para ocupação de
cargos com atribuições de suma importância para o País, entende-se que uma gestão de
requisitos eficiente, abrangendo aspectos de segurança do sistema, é crucial para se ter
um software com qualidade e seguro, nos que diz respeito à integridade do resultado
da votação, sigilo do voto, autenticidade dos registros de votação e disponibilidade do
sistema.

2. Ausência de controle de versão do sistema

O Sistema Votum não possui controle de versão da aplicação de modo a manter
registradas as alterações realizadas no sistema.

Em resposta à solicitação de informações acerca de como é feito o controle de

versionamento do sistema, a unidade auditada respondeu o seguinte:
“Pelo fato de não haver código-fonte acessível, não é feito controle de versão.
Uma forma alternativa que é feita pela equipe é a cópia de aplicações dentro
do mesmo workspace, de modo a armazenar diferentes versões da aplicação.”

9
Diferentemente das linguagens de programação baseadas em arquivos, na tecnologia
Oracle Application Express (APEX), utilizada no desenvolvimento do sistema Votum, as
definições de aplicativos são armazenadas como meta-dados dentro do banco de dados
Oracle. Essa característica torna mais difícil a integração da tecnologia com sistemas de
gerenciamento de código-fonte.

Entretanto, existe um artigo disponibilizado no próprio site da Oracle

(https://www.oracle.com/technetwork/developer-tools/apex/learnmore/apex-life-
cycle-management-wp-3030229.pdf) que fornece recomendações específicas para
otimizar o desenvolvimento e implantação de aplicativos Oracle Application Express ao
longo de seu ciclo de vida, incluindo o uso de sistemas de gerenciamento de código-
fonte de terceiros para manter o controle de versão.

Esse artigo recomenda, por exemplo, que os desenvolvedores implementem a maioria

da lógica de negócios do sistema em PL / SQL, ao invés de implementar dentro das
definições de aplicativo. Esses pacotes, funções, procedimentos etc. devem ser
mantidos em arquivos de script externos, fora do banco de dados Oracle, para que
possam ser facilmente mantidos em um repositório de código-fonte.

Outra recomendação do artigo é que Scripts SQL para criar ou atualizar objetos de banco
de dados, manipular dados e outros componentes externos devem ser verificados no
controle de versão separadamente da verificação nos aplicativos Application Express.
Por exemplo, para atualizar uma função PL / SQL, o desenvolvedor deve verificar o
arquivo de script SQL no controle de versão e atualizar o código no arquivo. Após a
conclusão das alterações no código, o script deve ser executado no ambiente de
desenvolvimento e então deve retornar ao controle de versão. Componentes externos,
como JavaScript, CSS, HTML e outros arquivos estáticos também devem ser gerenciados
como arquivos separados no sistema de controle de versão.

O referido artigo recomenda também que o desenvolvimento de uma aplicação APEX

siga as boas práticas do ciclo de vida de desenvolvimento de um software, como ter
ambientes diferentes para desenvolvimento, controle de qualidade / teste e produção.

A ideia é que os desenvolvedores só tenham permissão para fazer alterações em

aplicativos e objetos de banco de dados relacionados ao ambiente de desenvolvimento.
Para reforçar ainda mais essa política, é recomendável que se instale Application Express
"Apenas tempo de execução" nos ambientes de controle de qualidade / teste e
produção. Isso vai proibir os desenvolvedores de acessar o Application Builder e o SQL
Workshop nestes ambientes.

Essa recomendação também ajuda a garantir que os aplicativos criados nesses

ambientes são obtidos diretamente do repositório de código-fonte. Se um
desenvolvedor puder alterar uma aplicação no controle de qualidade / teste ou
produção, a manutenção do controle de versão pode se tornar difícil e não há garantias
de que a mesma alteração também será feita no ambiente de desenvolvimento,
correndo o risco de compilações subsequentes do ambiente de desenvolvimento
substituírem essas alterações ad-hoc, podendo ocasionar erros de aplicativos, perda de

10
código e instabilidade de código. Diante do exposto, fica claro que é possível que a
equipe de desenvolvimento do sistema Votum implemente um controle de
versionamento dos arquivos passíveis de serem gerenciados externamente, como
scripts SQL, componentes externos, etc.

É importante lembrar que o controle de versionamento faz parte do gerenciamento e

controle de mudanças de um software. Um adequado versionamento do sistema, além
de otimizar o processo de desenvolvimento, se apresenta como um fator importante de
proteção do código-fonte do sistema. Com o controle de versão, o desenvolvedor tem
acesso a todo o histórico de codificação de um determinado software ao longo do
tempo, sendo possível a recuperação de uma versão anterior do sistema, caso a versão
atual apresente algum problema.

A Norma ABNT NBR ISO/IEC 27002:2013 define uma diretriz sobre controle de mudanças
de sistemas, ainda no contexto sobre segurança em processos de desenvolvimento e de
suporte de sistemas de informação, a saber:
“14.2.2 Procedimentos para controle de mudanças de sistemas
Controle
Convém que as mudanças em sistemas no ciclo de vida de desenvolvimento
sejam controladas utilizando procedimentos formais de controle de
mudanças.
Diretrizes para implementação
Convém que os procedimentos de controle de mudanças sejam documentados
e reforçados para assegurar a integridade do sistema, das aplicações e
produtos, nos estágios iniciais dos projetos, através de um subsequente
esquema de manutenção. Convém que a introdução de novos sistemas e
mudanças maiores em sistemas existentes, siga um processo formal de
documentação, especificação, teste, controle da qualidade e gestão da
implementação.
Convém que este processo inclua uma avaliação de riscos, análise do impacto
das mudanças e especificação dos controles de segurança requeridos. Convém
que este processo também assegure que a segurança e os procedimentos de
controle atuais não sejam comprometidos, que os programadores de suporte
tenham acesso somente às partes do sistema necessárias para o cumprimento
das tarefas e que sejam obtidas concordância e aprovação formal para
qualquer mudança obtida.
Quando aplicável, convém que os procedimentos de controle de mudanças
operacional e de aplicação sejam integrados (ver 12.1.2). Convém que os
procedimentos de controle de mudanças incluam, porém não se limitem a:
a) manutenção de um registro dos níveis acordados de autorização;
b) garantia de que as mudanças sejam submetidas por usuários autorizados;
c) análise crítica dos procedimentos de controle e integridade para assegurar
que as mudanças não os comprometam;
d) identificação de todo software, informação, entidades em bancos de dados
e hardware que precisem de correções;
e) identificação e verificação do código crítico de segurança para minimizar a
probabilidade da ocorrência de fragilidades de segurança conhecidas;
f) obtenção de aprovação formal para propostas detalhadas antes do início
dos trabalhos;
g) garantia de que os usuários autorizados aceitem as mudanças antes da
implementação;
h) a garantia da atualização da documentação do sistema após conclusão de
cada mudança e de que a documentação antiga seja arquivada ou
descartada;

11
 i) a manutenção de um controle de versão para todas as atualizações de
software;
j) a manutenção de uma trilha de auditoria de todas as mudanças solicitadas;
k) a garantia de que toda a documentação operacional (ver 12.1.1) e
procedimentos dos usuários sejam alterados conforme necessário para se
manter adequado;
l) a garantia de que as mudanças sejam implementadas em horários
apropriados e não perturbem os processos de negócio envolvidos.”

3. Registro de eventos (log) da aplicação deficiente

O Sistema Votum carece de implementação de registros de eventos (log) que os usuários
praticam na aplicação de modo a permitir maior rastreabilidade das ações desses
usuários no sistema.

Ao ser questionada sobre a existência de logs a nível de desenvolvimento e de aplicação,

a unidade auditada informou o seguinte:

“O ambiente de administração do APEX fornece relatórios com estatísticas de

acesso e
alteração do sistema.”
“O sistema utiliza a mesma base de produção do sistema anterior feito em
Coldfusion. Havia triggers que efetuava registro das inserções e alterações
feitas nas tabelas de votos e de cédulas em tabelas de LOG criadas no
esquema admin, com acesso apenas dos administradores do banco de dados
ORACLE. Essas triggers estão sendo agora atualizadas para registrar o LOG no
esquema VOTO_AUDIT, criado especificamente para este propósito.”

Com relação ao log a nível de desenvolvimento, a tecnologia APEX registra informações

de acesso dos desenvolvedores e alterações nas páginas, já com relação ao log a nível
de aplicação, percebe-se uma deficiência no registro de eventos dos usuários.

Analisando as respostas acima e informações fornecidas nas reuniões realizadas por

meio de videoconferência com a equipe do MPF, bem como os relatórios enviados,
percebe-se que apenas alguns eventos são registrados, mais especificamente, o voto do
eleitor, registrando-se a data e hora em que votou. Não se identificaram registros
importantes como, data e hora de acesso ao sistema (log-on e log-off), bem como
eventos referentes a cadastros administrativos no sistema.

A Norma ABNT NBR ISO/IEC 27002:2013 dispõe o seguinte sobre registros de eventos:
“12.4.1 Registros de eventos
Controle
Convém que registros (log) de eventos das atividades do usuário, exceções,
falhas e eventos de segurança da informação sejam produzidos, mantidos e
analisados criticamente, a intervalos regulares.
Diretrizes para implementação
Convém que os registros (log) de eventos incluam, quando relevante:
a) identificação dos usuários (ID);
b) atividades do sistema;
c) datas, horários e detalhes de eventos-chave, como, por exemplo, horário de
entrada (log-on) e saída (log-off) no sistema;

12
 d) identidade do dispositivo ou sua localização, quando possível, e o
identificador do sistema;
e) registros das tentativas de acesso ao sistema, aceitas e rejeitadas;
f) registros das tentativas de acesso a outros recursos e dados, aceitas e
rejeitadas;
g) alterações na configuração do sistema;
h) uso de privilégios;
i) uso de aplicações e utilitários do sistema;
j) arquivos acessados e o tipo de acesso;
k) endereços e protocolos de rede;
l) alarmes provocados pelo sistema de controle de acesso;
m) ativação e desativação dos sistemas de proteção, como sistemas de
antivírus e sistemas de detecção de intrusos;
n) registros de transações executadas pelos usuários nas aplicações.
Os registros de eventos estabelecem o fundamento para os sistemas de
monitoramento automáticos, os quais são capazes de gerar relatórios
consolidados e alertas na segurança do sistema.
Informações adicionais
Os registros (log) de eventos podem conter dados confidenciais e informação
de identificação pessoal. Convém que medidas apropriadas de proteção de
privacidade sejam tomadas (ver 18.1.4).
Quando possível, convém que os administradores de sistemas não tenham
permissão de exclusão ou desativação dos registros (log) de suas próprias
atividades (ver 12.4.3).”

Como demonstrado, as boas práticas recomendam que registros (log) de eventos das
atividades do usuário, exceções, falhas e eventos de segurança da informação sejam
produzidos, mantidos e analisados criticamente, a intervalos regulares.

4. Fragilidades nas credenciais para acesso ao ambiente de

desenvolvimento e ao banco de dados do sistema.
Os testes realizados levaram à conclusão de que o controle de acesso ao ambiente de
desenvolvimento do software e ao banco de dados não são suficientes para garantir a
salvaguarda das informações, se o ataque partir de Agente Interno.

A aplicação do Sistema Votum é executada na plataforma APEX. Por meio da análise da

documentação enviada pelo MPF e da apresentação do sistema, realizada por
videoconferência, constatou-se que os desenvolvedores da aplicação possuem acesso
tanto ao Ambiente de Trabalho (Workspace) em que o sistema é desenvolvido,
como também acesso ao Ambiente de Administrador na plataforma APEX.

Essa prática dá poder aos desenvolvedores de alterarem tanto o código da aplicação,

como também os registros de logs do APEX, de maneira que seja impossível averiguar
se o código que foi usado em uma votação era de fato o que se encontrava na última
versão do Ambiente de Trabalho.

Conforme resposta, do MPF, item 1.3 do Ofício nº 113/2020/STIC, de 12/05/2020, os

servidores W. M e R. M. possuem contas distintas de administradores no ambiente de
desenvolvimento Apex.

13
 “O ambiente de administração do APEX fornece relatórios com estatísticas de
acesso e alteração do sistema. Têm acesso ao sistema o servidor responsável,
W. M. (e-mail) e o servidor R. M., que é chefe substituto da divisão responsável
pelo sistema e é o administrador do ambiente Apex no que tange ao
desenvolvimento (e-mail). O servidor W. também é administrador do
ambiente de desenvolvimento Apex. (...)

W.M - (e-mail) - desenvolvedor e administrador do ambiente APEX

Acesso de leitura e alteração em todos os objetos, componentes e código da
aplicação, incluisive com permissões para adicionar e excluir usuários e
desenvolvedores, nos bancos de homologacao, desenvolvimento e produção;

R.M (e-mail) - administrador do ambiente APEX

Acesso como administrador do APEX - Tem permissão para criar, alterar e
excluir qualquer usuario APEX, inclusive a si mesmo, de qualquer aplicação
nos ambientes de produção, homologação e desenvolvimento.”

Ocorre que, durante a apresentação do sistema, realizada pela equipe do MPF

identificou-se também o uso de usuário "ADMIN" de cunho geral, o qual representaria
uma conta de administração do Ambiente Apex. O acesso por meio dessa conta de nome
genérico “ADMIN” não permite identificar a pessoa por detrás das alterações e acessos
realizados.

Ressalta-se ainda que o item 9.4.3 Sistema de gerenciamento de senha da ISO/IEC

27002:2013 descreve que as senhas e usuários devem ser de uso individual, em
sua alínea a).

Já a NC 07/IN01/DSIC/GSIPR define que:

“6. DIRETRIZES PARA CONTROLE DE ACESSO LÓGICO

6.1 Quanto à criação e administração de contas de acesso:
6.1.1. A criação de contas de acesso aos ativos de informação requer
procedimentos prévios de credenciamento para qualquer usuário.
6.1.2. Disponibilizar ao usuário, que não exerce funções de administração
da rede local, somente uma única conta institucional de acesso, pessoal e
intransferível.”

Ademais, percebem-se, eventuais problemas relacionados à segregação de funções e

controle de acesso entre os membros da equipe do MPF. A segregação de funções,
quando realizada formalmente, possibilita a visualização da relação entre
conhecimentos e privilégios. Em termos de segurança, visa a aumentar o grau de certeza
na responsabilização por danos, intencionais ou não, bem como por invasões externas
e internas à organização.

A fim de aumentar a garantia de confiabilidade e integridade dos dados, as informações

persistidas em banco de dados devem ser vistas como um ativo que pode ser acessado
por determinados grupos com permissões de acesso, as quais determinam o que pode
ser feito ou não com tais ativos.

No caso analisado, não há perfis diferenciados para desenvolvedores ou

administradores na plataforma APEX.

14
Como apresentado, há apenas um desenvolvedor (W.M) e um chefe substituto (R. M),
os quais, apesar de configurarem um relacionamento hierárquico, possuem ambos os
mesmos privilégios de administrador relacionados aos dados persistidos pela aplicação.
Sem mencionar a existência da conta genérica “ADMIN”. Esse cenário se agravaria com
a entrada de um segundo desenvolvedor, que teria um terceiro perfil administrador,
caso a mesma configuração fosse seguida. Uma responsabilização por supostos danos
relacionadas às informações persistidas envolverá não apenas intenções de usuários
específicos, mas de delegações inapropriadas.

Exemplo de possíveis riscos associado a essa prática poderiam ser:

Cenário 1
1. Agente Interno altera o código da aplicação pra computar votos de maneira a
favorecer um determinado candidato.
2. Votação é realizada com o código malicioso.
3. Após a votação, o Agente Interno retorna a aplicação ao seu estado original.
4. O Agente Interno remove os logs de alterações realizados nos itens 1 e 3, pois
possui acesso de administrado da plataforma e o sistema não possui controle de
versionamento.

O risco apresentado no Cenário 1 torna extremamente difícil comprovar qualquer

fraude no processo realizada por Agente Interno. Ademais, seria impossível para o
Eleitor, mesmo que desejando abrir mão do sigilo do voto, verificar se o sistema
computou corretamente seus votos.

Uma alternativa conhecida para tentar detectar essa possibilidade de fraude seria a
verificação de logs do Banco de Dados, caso esses logs registrem todos os comandos
executados, tanto de DDL (Data Definition Language ou Linguagem de Definição de
Dados. São comandos desse tipo o CREATE, o ALTER e o DROP) como de DML (Data
Manipulation Language, ou Linguagem de Manipulação de Dados. São comandos do
DML o INSERT, UPDATE e DELETE) e desde que esses registros não possam ser também
alterados.

Além do exposto, delimitar contas, também no banco de dados, para administradores,

usuários e desenvolvedores eleva o nível de proteção de dados compartilhados entre
aplicações, tais como dados de autenticação, por exemplo. O sistema Votum possui
tabelas que contém dados sensíveis, tais como senhas de votação e resultados de
votações. Esses dados devem ser protegidos com permissões de acessos específicas,
como forma de proteção de sua integridade.

O acesso ao banco de dados ORACLE da aplicação também é franqueado apenas a esses

dois usuários, os quais possuem perfil de leitura e escrita no banco de dados, segundo
informado em entrevista com a equipe técnica.

Em virtude dos referidos aspectos do banco de dados, foi questionado ao MPF, no item
4.2 da Solicitação de Informações 1, acerca das medidas adotadas de controle de acesso
ao banco de dados do Sistema Votum, sendo a resposta apresentada a seguir:

15
 “A senha do esquema do banco de dados é de conhecimento apenas dos
servidores R.M e W.M A Divisão de Banco de Dados da STIC não tem
conhecimento dela, podendo, entretanto, alterá-la com os privilégios de
administrador geral do banco de dados.”

É importante destacar também que foi solicitada a política de senhas da organização na

Solicitação de Informações nº 1, item 4.1, no entanto, a PGR informou que há uma
Política de Senhas no MPF, porém não disponibilizou o documento para a análise desta
equipe de consultoria, inviabilizando a análise do documento e impossibilitando
verificar outros aspectos como os requisitos de qualidade das senhas empregadas, em
conformidade com o Item 9.4.3 “Sistema de gerenciamento de senha” da ISO/IEC
27002:2013.

Além dos pontos apresentados, não foi esclarecido o modo como as senhas do
workspace “apex_stic_voto” e do esquema de banco “voto” são transferidas ao
Presidente da Comissão Eleitoral na data do pleito eleitoral. A transferência dessas
senhas, se realizadas sem o devido cuidado, apresenta um risco de segurança, pois uma
pessoa de posse delas poderia comprometer a integridade da votação, haja vista que,
ao que foi informado, o servidor W. M repassa sua própria senha à Comissão Eleitoral,
senha essa com perfil de administrador como já mostrado. A ISO/IEC 27002:2013 no
item 9.4.3 Sistema de gerenciamento de senha, alínea i estabelece que as senhas devem
ser armazenadas e transmitidas de forma segura.

Como controles a serem estabelecidos, sugeridos pelas Normas Técnicas, pode-se

adotar algumas das seguintes práticas:

1. Segregação de Funções
Funções conflitantes e áreas de responsabilidades devem ser segregadas para reduzir
oportunidades de modificação não autorizada ou não intencional , ou uso indevido dos
ativos da organização. ISO/IEC 27001/2013 Anexo A - A.6.1.2

2. Política de Controle de Acesso.

Uma política de controle de acesso deve ser estabelecida, documentada e analisada
criticamente, baseada nos requisitos de segurança da informação e do negócio. ISO/IEC
27001/2013 Anexo A - A9.1.1.

3. Registros e Monitoramento
Ainda que não seja possível segregar funções em um espectro amplo, devido a fatores
como escassez de pessoas e habilidades, o investimento em controles que minimizem
os riscos de impossibilidade de rastreamento de responsabilidades sobre danos
iniciados pela má utilização dos dados persistidos, deve ser avaliada. Registros de
eventos (logs) ocorridos em dados críticos e/ou sensíveis devem ser construídos e
monitorados regularmente, por um agente empossado para essa função.

Registros de eventos (log) das atividades do usuário, exceções, falhas e eventos de

segurança da informação, devem ser produzidos, mantidos e analisados criticamente, a
intervalos regulares. ISO/IEC 27001/2013 Anexo A - A.12.4.1

16
As informações dos registros de eventos (log) e seus recursos devem ser protegidos
contra acesso não autorizado e adulteração. ISO/IEC 27001/2013 Anexo A - A.12.4.2

As atividades dos administradores e operadores dos sistemas (logs) devem ser

registradas e os registros (logs) devem ser protegidos e analisados criticamente, a
intervalos regulares. A.12.4.3

5. Fragilidades que podem comprometer o sigilo do voto

Em análise aos procedimentos e funções do banco de dados utilizado no sistema Votum,
destaca-se o trecho da função “aleatório” que tem a finalidade de gerar o número de
cédula do eleitor:

SEMENTE := TO_NUMBER(TO_CHAR(SYSDATE,'YYYYDDMMSS'));
DBMS_RANDOM.initialize (val => semente);
RETORNO := DBMS_RANDOM.value(low => 1, high => 99999999);
DBMS_RANDOM.terminate;

O código demonstra a utilização de uma “semente” (seed) para inicializar a função

DBMS_RANDOM. Essa semente é formada pelos componentes ANO, DIA, MÊS e
SEGUNDO ('YYYYDDMMSS') da data de execução da função.

Entretanto, conforme a documentação do Oracle, as funções SEED e INITIALIZE

encontram-se obsoletas e somente deve ser utilizada se for desejável sempre gerar uma
mesma sequência de números aleatórios.

“DBMS_RANDOM can be explicitly initialized, but does not need to be initialized

before calling the random number generator. It will automatically initialize with
the date, userid, and process id if no explicit initialization is performed.
If this package is seeded twice with the same seed, then accessed in the same
way, it will produce the same results in both cases.
In some cases, such as when testing, you may want the sequence of random
numbers to be the same on every run. In that case, you seed the generator with
a constant value by calling one of the overloads of DBMS_RANDOM.SEED. To
produce different output for every run, simply to omit the call to “Seed” and the
system will choose a suitable seed for you.
https://docs.oracle.com/cd/B19306_01/appdev.102/b14258/d_random.htm”

Ocorre que a data e hora da votação de cada eleitor é armazenada na tabela de eleitores
(campo ELTR_DT). Assim, um Agente Externo ou Agente Interno poderia utilizar a data
e hora da votação para descobrir o número da cédula e o voto registrado,
comprometendo o sigilo do voto.

Por exemplo, considerando o trecho supracitado e a data/hora de votação como

15/05/2020 10:20:59:
• A semente utilizada será 2020150559
• A data/hora do voto será 15/05/2020 10:20:59, salva na tabela do
eleitor.

17
Assim, o atacante pode consultar a data/hora do voto de determinado eleitor e utilizá-
la como semente. Com essa semente, a função DBMS_RANDOM gerará um número que
será o número da cédula do eleitor, comprometendo o sigilo do voto.

Cabe mencionar ainda que a data e hora de votação é divulgada no Relatório “Lista de
Votantes” ao final da eleição, como no exemplo a seguir:

Outro ponto que merece destaque é que o ambiente APEX, de modo geral, armazena os
dados da sessão de cada usuário da aplicação na regra de formulação da URL como
demonstrado na figura a seguir:

Fonte: https://www.oracle.com/technetwork/pt/articles/apex/regra-formação-url-apex-
4422800-ptb.html

O número da sessão que no exemplo da figura anterior corresponde a sequencia

numérica "2010875792236801" é gerado automaticamente pela engine do Apex e é
utilizada para o gerenciamento da sessão na aplicação: valores de componentes, usuário
logado, dentre outros. Esses dados de sessão também podem ser explorados por
Agentes Internos, para tentar identificar o voto de cada eleitor, o que coloca em risco o
sigilo do voto.

6. Outras cópias do sistema encontram-se instaladas.

Conforme apresentado pela equipe do MPF em reunião por meio de videoconferência
realizada me 07/05/2020, há no mínimo nove cópias do sistema em execução em três
servidores: desenvolvimento, homologação e produção. Um dos objetivos dessa prática
é o de garantir a disponibilidade do sistema no momento das eleições.

Entretanto, não consta do processo eleitoral meios de aferir se o resultado publicado da

eleição foi realmente originário da mesma aplicação em execução no dia da eleição. Um
possível risco dessa multiplicação de sistemas em atividade poderia ser, por exemplo, a

18
eleição ter sido realizada na aplicação “A”, mas o resultado da eleição é extraído da
aplicação “B” que já constava com banco de dados preenchido.

Pela análise dos documentos encaminhados, observou-se que no Relatório de Resultado

das eleições, gerado pela aplicação, não consta o código da URL (Uniform Resource
Locator) da aplicação em que ocorreu a eleição. É necessária a inserção desses dados no
Relatório para que a Comissão Eleitoral, ou outro partícipe, tenha o mínimo de
condições de confirmar que o resultado apresentado proveio da mesma aplicação usada
na data do pleito eleitoral.

A regra de formação da URL para acesso às aplicações da tecnologia APEX Oracle é a

seguinte:

Fonte: https://www.oracle.com/technetwork/pt/articles/apex/regra-formação-url-apex-
4422800-ptb.html

Os valores que ficam separados por ":" após o trecho "f?p=" da URL. Repare que, na
figura acima, logo após o trecho "f?p=" há o número 9829. Este número é o número da
aplicação. Ele deve ser único dentro de uma instância do Apex. Pode-se utilizar o apelido
da aplicação em vez do número.

7. Ausência de rotinas de testes periódicos de backup.

Durante as análises não foram identificadas rotinas de testes periódicos dos backups
realizados. O objetivo do Backup é que, em caso de qualquer eventualidade, seja
possível manter a disponibilidade dos serviços e evitar ao máximo a interrupção das
operações. Dentre as etapas, a mais crítica é a restauração do Backup, já que ao efetuar
essa tarefa significa que algum problema ocorreu e a organização depende das cópias
que fez para essa situação.

A rotina de Backup é essencial para manter a segurança da informação de uma

organização diante das mais diversas ameaças, como ataques de hackers ou catástrofes.
Tão crítica quanto manter essa rotina ativa é realizar a recuperação de Backup.

Nesse sentido a rotina de Backup é composta por 3 etapas: 1. a criação das cópias, 2. o
armazenamento e 3. a restauração. Nesse contexto, uma vulnerabilidade crítica que
pode se apresentar para o MPF é caso o Backup do Sistema Votum ou de seu banco de
dados não esteja funcional devido alguma situação que possa ter corrompido os dados
ou até mesmo inviabilizado as cópias por falhas nos sistemas, no momento de uma
eleição. Por isso, a importância de se manter testes de recuperação.

A aplicação dos testes de recuperação também demonstra o que deve ser melhorado
na rotina de criação do Backup e seu armazenamento, como o tempo de
indisponibilidade dos serviços até a total restauração. Dessa forma, de posse dos dados
levantados nesses testes de recuperação, é possível verificar quais são as principais

19
fragilidades da rotina de Backup e permite-se buscar soluções que eliminem as
vulnerabilidades encontradas.

Nesse sentido a ISO/IEC 27002:2013, no item 12.3.1 Cópias de segurança das

informações, alínea e), afirma que:

“Controle
Convém que cópias de segurança das informações, softwares e das imagens
do sistema, sejam efetuadas e testadas regularmente conforme a política de
geração de cópias de segurança definida.
(...)
e) convém que as mídias de backup sejam regularmente testadas para
garantir que elas são confiáveis no caso do uso emergencial; Convém que isto
seja combinado com um teste de restauração e checado contra o tempo de
restauração requerido. Convém que os testes da capacidade para restaurar
os dados copiados sejam realizados em uma mídia de teste dedicada, não
sobrepondo a mídia original, no caso em que o processo de restauração ou
backup falhe e cause irreparável dano ou perda dos dados;” (sublinhado
acrescido)”

Portanto, a ausência de testes periódicos nos backups da aplicação de banco de dados

do sistema Votum representa um risco elevado à disponibilidade dos sistemas que
suportam a eleição, apresentando o risco em potencial de colocar em risco os certames
no âmbito do Ministério Público.

8. Risco de não garantir a autenticidade do eleitor

No contexto de um sistema de votação, uma das formas de proteger a integridade do
processo de votação e seu resultado é salvaguardar a autenticidade do voto, ou seja,
buscar garantir que cada voto computado seja legítimo.

Mediante a implantação de um ou mais medidas de segurança, o sistema deve buscar a

garantia de que cada usuário é de fato um eleitor legítimo, bloqueando ainda o acesso
de pessoas indevidas que utilizem técnicas de personificação ou impostor.

A Norma Complementar NC 07/IN01/DSIC/GSIPR, de 15/07/2014, dispõe sobre

diretrizes para implementação de controles de acesso relativos à segurança da
informação e comunicações nos órgãos da Administração Pública Federal, direta e
indireta. Essa norma adota como principal referência as boas práticas dispostas nas
Normas Brasileiras NBR ISO/IEC 27001:2013 (Sistema de Gestão de Segurança da
Informação) e NBR ISO/IEC 27002:2013 (Código de Práticas para a Gestão da Segurança
da Informação).

Segundo o item 2.1 da NC 07/IN01/DSIC/GSIPR, o objetivo do controle de acesso é

sistematizar a concessão de acesso, a fim de evitar a quebra de segurança da informação
e comunicações.

20
Cenário atual
Para o levantamento da situação atual dos fatores ou medidas de segurança
implantados no controle de acesso do módulo de votação do sistema Votum, foram
utilizadas informações repassadas pela equipe do MPF:
• Anexo do Ofício nº 415/2020-CHEFIAGAB/PGR, de 29/04/2020, que contém um
descritivo de informações técnicas sobre o sistema Votum do MPF.
• Anotações feitas após a reunião, mediante videoconferências ocorridas nas
datas de 05, 07 e 11/05/2020, entre a equipe de auditores da CGU e a equipe de
TI do MPF (STIC).
• Respostas à Solicitação de Informações nº: 001, de 07/05/2020. Ofício nº
113/2020/STIC, de 12/05/2020, do MPF.
• Respostas à Solicitação de Informações nº: 002, Oficio nº 114/2020/STIC, de
14/05/2020
Assim, a partir do relato oral e de demonstrações do funcionamento do sistema,
mediante videoconferências, e por Ofício, foi possível identificar que o controle de
acesso ao módulo de votação adota as seguintes medidas de segurança ou fatores de
autenticação:

Fator 1
Solicitação de login/senha LDAP (Lightweight Directory Access Protocol). Os usuários
utilizam o login e a senha de rede para acesso ao módulo de votação.

Fator 2
Autenticação do acesso por Certificado Digital, emitido oficialmente pelo ICP-Brasil
ou por uma Autoridade Certificadora interna ao MPF (AC interno).

Fator 3
Disponibilização ao usuário de um código para efetivar a votação (Senha de
Votação).

Em resumo, o controle de acesso do módulo de votação adota “autenticação de

multifatores”, conforme descrito no item 4.3 da Norma Complementar NC
07/IN01/DSIC/GSIPR, de 15/JUL/2014.

Nesse aspecto, a Norma Complementar - NC 07/IN01/DSIC/GSIPR, que apresenta

diretrizes para a implementação de controles de acesso relativos à segurança da
informação e comunicações nos órgãos e entidades da Administração Pública Federal,
direta e indireta - APF, traz as seguintes definições:

“4.3. Autenticação de multifatores: utilização de dois ou mais fatores de

autenticação para concessão de acesso a um sistema. Os fatores de
autenticação se dividem em: algo que o usuário conhece (senhas, frases de
segurança, PIN, dentre outros); algo que o usuário possui (certificado digital,
tokens, códigos enviados por SMS, dentre outros); algo que o usuário é
(aferível por meios biométricos, tais como digitais, padrões de retina,
reconhecimento facial, dentre outros).

21
 (...)
6.1.7. Recomenda-se a utilização de autenticação de multifatores para o
controle de acesso lógico, a fim de autenticar a identidade de um usuário e
vinculá-lo a uma conta de acesso a ativos de informação”

A seguir, encontram-se os aspectos relevantes acerca de cada um desses fatores:

Fatores de autenticação Características e outros aspectos

relevantes
Login/senha LDAP
• O usuário eleitor efetua o login
na aplicação.
• O sistema verifica as permissões
de acesso via rotina LDAP.
• O login/senha da aplicação é o
mesmo utilizado para acesso,
pelo usuário, à intranet e aos
demais recursos da rede
institucional do MPF.
• O MPF não apresentou a política
formal que estabeleça diretrizes e
regras sobre quais tipos de
usuário (ativo, inativo,
aposentado, usufruindo de
licença legalmente instituída etc.)
podem obter acesso ao módulo
de votação. Consequentemente,
não foi possível verificar se o
controle de acesso bloqueia
usuários sem privilégios de
acesso, com base nessa política.

Certificado digital
• O acesso à aplicação é permitido
por certificado digital.
• O certificado é emitido pela
Autoridade Certificadora ICP-
Brasil ou por AC interno ao MPF.
• O certificado deve ser instalado
na máquina do usuário/eleitor.
• As características apresentadas
indicam que o certificado
adotado pelo MPF é do “tipo A1”,
que utiliza chave de criptografia
de 1.024 bits.

22
 Segundo o Instituto Nacional de
Tecnologia da Informação – ITI[1], órgão
que gerencia a cadeia certificadora do
ICP-Brasil:
• O certificado digital ICP-Brasil
funciona como uma identidade
virtual que permite a
identificação segura e inequívoca
do autor de uma mensagem ou
transação feita em meios
eletrônicos, como a web.
• As regras do ICP-Brasil são
estabelecidas por um comitê
gestor. Os certificados contêm os
dados de seu titular.
• No procedimento de emissão do
certificado do ICP-Brasil, são
verificadas características
pessoais de cada adquirente, no
mínimo, nome completo e data
de nascimento.
• Contudo, as principais
informações que constam em um
certificado digital ICP-Brasil são:
• chave pública do titular,
• nome e endereço de e-
mail,
• período de validade do
certificado,
• nome da Autoridade
Certificadora - AC que
emitiu o certificado,
• número de série do
certificado digital,
• assinatura digital da AC.
• A assinatura digital utilizada pelo
ICP-Brasil agrega autenticidade,
integridade, confiabilidade e a
propriedade de não-repúdio.

Senha de votação • O sistema gera uma senha de

votação associada a cada
usuário/eleição.
• Após sua geração, o hash (MD5)
da senha de votação é gerado e

23
 armazenado na tabela
“Eleitores”.
• A senha de votação é um código
formado apenas por números
(dez dígitos com espaços em
branco entre grupos de três
dígitos – ex.: 139 371 431 5).
• A senha, em seu formato original
(não cifrado), é enviada por e-
mail mediante uma rotina de
banco (procedure) embutida
dentro do código-fonte.
• Dentro da aplicação no Oracle
Apex, um JOB é acionado (a cada
10 segundos) para, em blocos de
dez (10), enviar os e-mails aos
usuários contendo as senhas de
votação geradas.
• No envio dos e-mails contendo a
senha, não é necessário informar
uma conta de correio válida.
• Os e-mails enviados não ficam
armazenados em um repositório
temporário (ex.: “Caixa de itens
enviado”, “Caixa de saída”.
• Os servidores efetivos da DISEGI
– Divisão de Segurança da
Informação e da DISE– Divisão de
Infraestrutura de Serviços
possuem acesso ao servidor de e-
mail.
• De acordo com informações
repassadas na reunião de
11/05/2020, as contas de correio
eletrônico do MPF são
criptografadas.
• As senhas expiram quando
utilizadas pelo usuário, naquela
eleição específica.
• Na página de votação deve-se
fornecer a senha de votação
gerada de forma exclusiva para o
eleitor naquela eleição.
• O uso indevido da senha de
votação por outro eleitor, que
não o verdadeiro destinatário,

24
 impede que o eleitor legítimo
possa realizar seu voto.
• O não recebimento do e-mail
contendo a senha de votação é
percebido apenas se o próprio
eleitor informar o não
recebimento.

Fonte: informações apresentadas pela equipe do MPF.

Segundo a NC 07/IN01/DSIC/GSIPR, de 15/07/2014, item 4.3, os fatores de

autenticação adotados pelo sistema podem ser assim classificados:
• Algo que o usuário conhece (Login/senha LDAP e senha de votação); e
• Algo que o usuário possui (certificado digital);

Análise técnica dos fatores

O escopo da análise aqui consignada consiste em apontar vulnerabilidades ou potenciais

brechas de segurança no controle de acesso do módulo de votação do Sistema VOTUM.
Estão fora do escopo controles que mitigam o vazamento das chaves de votação a partir
de ataque cibernético, de origem interna ou externa, aos servidores de aplicação e
dados (Oracle Apex) e ao servidor de correio eletrônico.

A princípio, quando analisados em conjunto, os fatores de segurança podem ser

considerados adequados. Entretanto, cabe mencionar que:
• Não foram implementados fatores descritos na NC 07/IN01/DSIC/GSIPR, de
15/07/2014, item 4.3, do tipo “algo que o usuário é”, aferível por meios
biométricos, tais como digitais, padrões de retina, reconhecimento facial, dentre
outros.
• Como mencionado, no sistema Votum são adotados dois fatores de segurança
do tipo “algo que o usuário conhece” e um fator do tipo "algo que o usuário
possui"
Uma análise individual de cada fator permite identificar e apontar algumas
vulnerabilidades ou oportunidades de melhoria:

Fatores de autenticação Vulnerabilidades percebidas

Login/senha de rede
(algo que o usuário conhece)
• Há o risco de que eventuais
brechas de segurança no serviço
LDAP (ex.: Active Directory do
Windows) se estendam ao
controle de acesso ao sistema,
permitindo que pessoas
indevidas possam acessar o
sistema (ex.: vazamento de dados
de usuário LDAP).

25

Certificado digital
(algo que o usuário possui)
Senha de votação
(algo que o usuário conhece)
• O uso de LDAP para controle de
acesso dificulta a adoção de
políticas de acesso mais
restritivas e específicas para o
sistema de votação (ex.: bloqueio
de acesso a usuários com senha
desatualizada).
• O sistema não bloqueia o acesso
simultâneo de várias pessoas que
tentam utilizar o mesmo
login/senha de usuário.
• Como o certificado digital é
instalado no desktop do eleitor,
qualquer pessoa que tenha
acesso franqueado ao
computador desse servidor (ex.:
secretária, esposa, filho etc.),
local ou remotamente, pode
contornar esse controle.
• O certificado pode ser instalado
em diversas máquinas.
• Um mesmo certificado, instalado
em mais de uma máquina, pode
ser utilizado simultaneamente.
• A senha de votação é enviada por
e-mail, em seu formato original
(texto não cifrado), permitindo
sua leitura a partir de um ataque
do tipo “man-in-the-middle”[2] ou
de um ataque direto ao servidor
de correio.
• Considerando a informação
apresentada pela equipe do MPF
no Ofício MPF nº 113/2020/STIC,
de 12/05/2020 de que “O uso
indevido por outro eleitor, que
não o verdadeiro destinatário da
mensagem que contém a senha,
impede que o eleitor legítimo
possa realizar seu voto.” , há o
risco de que um eleitor (ou grupo
de eleitores) seja impedido de
votar, caso ocorra a descoberta
26
 ou o vazamento, intencional ou
não, de sua senha de votação (ou
de várias senhas de votação).
Dada a capacidade de impactar
significativamente nos rumos do
processo, essa brecha pode
mudar o resultado da eleição,
comprometendo sua integridade.
• As senhas de votação
permanecem válidas até que o
usuário/eleitor registre o seu
voto. Nessas condições, um
atacante pode ter tempo mais do
que suficiente para descobrir a
senha.
• A geração manual das senhas de
votação, por parte de uma
terceira pessoa (o
“Administrador” de sistema),
majora o risco de quebra de
segurança.
• O armazenamento de senhas
válidas em uma tabela no banco
de dados da aplicação, mesmo
que cifradas (hash), majora o
risco de quebra de segurança.
• A senhas de votação são geradas
por meio de uma biblioteca do
banco Oracle que simula
aleatoriedade, como qualquer
código randômico.

Fonte: Análise da equipe da CGU.

Vale mencionar trazer ainda as boas práticas dispostas na Norma ABNT NBR ISO/IEC
27002:2013, que é um Código de Prática para controles de segurança da informação,
em seu Item 9.4.2, traz a seguinte diretriz para implementação de procedimento
seguros de entrada em sistema:

“9.4.2 Procedimentos seguros de entrada no sistema (log-on)

Controle
Convém que, onde aplicável pela política de controle de acesso, o acesso aos
sistemas e aplicações sejam controlados por um procedimento seguro de
entrada no sistema (log-on).
Diretrizes para implementação
Convém que uma técnica de autenticação adequada seja escolhida para
validar a identificação alegada de um usuário.

27
 Onde é requerida a verificação de identidade e uma forte autenticação,
métodos alternativos de autenticação para as senhas, tais como, meios
criptográficos, smart cards, tokens ou biometria, sejam usados. (sublinhado
acrescido).
Convém que o procedimento para entrada no sistema operacional seja
configurado para minimizar a oportunidade de acessos não autorizados.
Convém que o procedimento de entrada (log-on) revele o mínimo de
informações sobre o sistema ou aplicação, de forma a evitar o fornecimento
de informações desnecessárias a um usuário não autorizado.
Convém que um bom procedimento de entrada no sistema (log-on):
a) não mostre identificadores de sistema ou de aplicação até que o processo
tenha sido concluído com sucesso;
b) mostre um aviso geral informando que o computador seja acessado
somente por usuários autorizados;
c) não forneça mensagens de ajuda durante o procedimento de entrada (log-
on) que poderiam auxiliar um usuário não autorizado;
d) valide informações de entrada no sistema somente quando todos os dados
de entrada estiverem completos. Caso ocorra uma condição de erro, o sistema
não indique qual parte do dado de entrada está correto ou incorreto;
e) proteja contra tentativas forçadas de entrada no sistema (log-on);
f) registre tentativas de acesso ao sistema, sem sucesso e bem sucedida;
g) comunique um evento de segurança caso uma tentativa potencial ou uma
violação bem sucedida de entrada no sistema (log-on), seja detectada;
h) mostre as seguintes informações quando o procedimento de entrada no
sistema (log-on) finalizar com sucesso:
1) data e hora da última entrada no sistema (log-on) com sucesso;
2) detalhes de qualquer tentativa sem sucesso de entrada no sistema (log-on)
desde o último acesso com sucesso;
i) não mostre a senha que está sendo informada;
j) não transmita senhas em texto claro pela rede;
k) encerre sessões inativas após um período definido de inatividade,
especialmente em locais de alto risco, tais como, locais públicos, ou áreas
externas ao gerenciamento de segurança da organização ou quando do uso
de dispositivos móveis;
l) restrinja os tempos de conexão para fornecer segurança adicional nas
aplicações de alto risco e reduzir a janela de oportunidade para acesso não
autorizado.”

Oportunidades de melhoria

A partir das vulnerabilidades individuais apontadas no quadro anterior, são sugeridos

os seguintes aperfeiçoamentos:
Fatores de autenticação
Login/senha de rede
(algo que o usuário conhece)
Oportunidades de melhoria
• Solicitar que seja feita uma
varredura (scanner) no servidor
LDAP em busca das
vulnerabilidades mais recentes.
• Instituir formalmente uma
política mais restritiva para

28
 acesso ao módulo de votação do
sistema VOTUM, para
conhecimento pelos usuários e
comissões eleitorais, de medidas
de segurança a serem adotadas.
• Implementar mecanismos mais
restritivos, tais como permissão
de acesso ao módulo de votação
apenas para usuários com senha
atualizada recentemente (dentro
de um prazo estabelecido na
política de acesso).
• Bloquear o acesso simultâneo de
várias pessoas que tentam utilizar
o mesmo login/senha de usuário.

Certificado digital
(algo que o usuário possui) • Expedir orientação aos
usuários/eleitores acerca do
procedimento de instalação dos
certificados, de maneira que
estes sejam instalados com “alto
nível de risco”.
Obs.: Esse nível requer do usuário o
cadastro de uma senha adicional, que
será solicitada todas as vezes que uma
aplicação Web tentar acessar os dados
do certificado.
• Avaliar a oportunidade e
conveniência de adotar
certificado digital do tipo A3,
considerado mais seguro, uma
vez que adota chave de 2048 bits,
podendo ser instalado em um
dispositivo token.
• Verificar a possibilidade da
assinatura digital do eleitor ser
utilizada para assinar o voto,
como um fator a mais, ou como
substituto da própria senha de
votação.

Senha de votação
(algo que o usuário conhece) • Abster-se de armazenar a senha
de votação em tabela de banco
de dados, excetuando-se o

29
 armazenamento temporário para
fins de processamento.
• Abster-se de gerar manualmente
a senha de votação, a partir de
terceiros (Administrador do
sistema). O evento de geração
deve ser disparado a partir de
uma ação do usuário diretamente
na aplicação
• Abster-se de enviar a senha de
votação em texto puro e por e-
mail.
• Limitar a quantidade de
tentativas de inserção da senha
de votação.
• Bloquear a tela de votação, após
sucessivas tentativas frustradas
de inserção da senha de votação.
• Registrar o uso indevido de senha
de votação, para posterior
auditoria.
• Implementar mecanismo de
geração automática de senha de
votação, que dificulte a
descoberta do código por
eventual atacante, interno ou
externo, e que facilite o seu
trânsito da origem (MPF) até o
destino (usuário).
A título de sugestão, poderá ser utilizado
QrCode na geração e transmissão das
senhas de votação, podendo ser
seguidos os seguintes passos:
• Gerar automaticamente a
senha de votação, após o
registro do voto por parte
do usuário (na tela
seguinte), apresentado o
código em formato
QrCode.
• Por meio de aplicativo
mobile (um App),
previamente habilitado, o
usuário/eleitor decodifica
o QrCode e insere a senha
no campo específico na
tela de votação.

30
 • A senha de votação deve
expirar após um curto
período sem utilização
(ex.: 15 ou 20s), sendo
necessária solicitar a
geração de uma outra
senha a partir da mesma
tela.

Obs. (1): Implementar aplicativo mobile

para instalação no celular do
usuário (App), com a finalidade
única de realizar a leitura do
QrCode na tela. Na habilitação
do conjunto “aplicativo+celular”
do usuário/eleitor, podem ser
utilizados seus dados cadastrais
ou até mesmo biometria (fator
classificado como “algo que o
usuário é”).

Obs. (2): Caso o usuário/eleitor ainda

não tenha o conjunto
“aplicativo+celular” habilitado
para leitura do QrCode, o
sistema pode oferecer uma
alternativa (segunda opção),
enviando a senha de votação,
em formato não cifrado,
diretamente para o celular do
usuário/eleitor, por SMS.
Sugestões de melhoria técnica para o
algoritmo de geração da senha de
votação:
• Incluir uma semente na geração
randômica da senha de votação,
uma vez que códigos randômicos
simulam aleatoriedade, tratando-
se de algoritmos determinísticos.
A semente pode ser um dado
cadastral único, relacionado ao
usuário/eleitor, tais como CPF ou
outro atributo, associado a
outros dados que não sejam de
conhecimento público,
considerado adequado à função.

31
 • Acrescentar um Salt à geração do
hash MD5, evitando ataques de
Força Bruta ou de uso de
Rainbow Tables.
• Utilizar algoritmos de hash
recomendados pela norma
ISO/IEC 10118-3.

Sugere-se ainda como controles adicionais:

• Verificar a possibilidade de emitir um comprovante de votação, com um
número único que pode ser validado pelo eleitor junto ao sistema para atestar
que ele realmente participou de uma eleição específica. Deve haver meios de
o comprovante de votação chegar ao eleitor por formas diversas, como e-
mail e SMS. Vale lembrar que tal comprovante não pode permitir identificar
o voto do eleitor. Isso difere da publicação da Relação de Votantes na
medida em que permite uma contestação imediata de algum eleitor que não
tenha participado da eleição, mas receba uma confirmação de votante.
• Implementar controles de acesso e logs específicos para as tabelas que
contém dados referentes aos votos ou às Senhas de Votação.

[1]
https://www.iti.gov.br/perguntas-frequentes/41-perguntas-frequentes/130-sobre-a-icp-brasil
[2]
Forma de ataque em que os dados trocados entre duas partes são, de alguma forma, interceptados,
registrados e possivelmente alterados pelo atacante sem que as vítimas percebam.

9. Aplicação se mostrou segura frente a testes básicos de

ataques por agentes externos.
Partindo de ambiente externo ao sistema Votum, realizou-se um escaneamento de
vulnerabilidades da aplicação. O dado de entrada passado para o escaneamento foi o link
para login no sistema Votum (https://portal.mpf.mp.br/intranet/apex/f?p=voto). A partir
desse escaneamento foram encontradas as informações da Tabela 1.1 a seguir.

Ressalta-se que, a exceção das informações listadas a seguir, de modo geral a aplicação
web do Sistema Votum se comportou de forma segura diante de ataques automatizados
como fuzzing de diretórios, força bruta e injeção de SQL. Isso se deve à presença de
controles implementados por ferramentas de segurança, como Firewall de Aplicação
Web.

Informação Impacto Links afetados Descrição Solução

Injeção SQL pode Alto https://portal.mp Parâmetro Utilizar uma
ser possível no f.mp.br/intranet/ p_app_id pode procedure de
parâmetro apex/wwv_flow.js ser manipulado sanitização ou
p_app_id _messages?p_ap na url, tratamento dos
p_id=%&p_lang=p possibilitando a parâmetros do link
t- revelação de afetado.

32
 br&p_version=5.1 informações
.4.00.08- potencialmente
249744855881 sensíveis.
O cabeçalho anti- Médio https://portal.mp O cabeçalho X- Verificar nos links
clikjacking X- f.mp.br/intranet/ FrameOptions afetados se a
FrameOptions apex/f?p=302:101 ajuda a prevenir opção de
não está presente ::::::&notification ataques de cabeçalho X-
_msg=RXJybyBhb carregamento de FrameOptions está
yByZWFsaXphciBs frames maliciosos presente e
b2dpbi4gVXN14XJ na página web. configurada nos
pbyBlL291IFNlbm valores
hhIGluduFs%7B% SAMEORIGIN,
7DaWRvcy48ZGl2 DENY ou ALLOW-
IGlkPSJhcGV4X2x FROM
vZ2luX3Rocm90d
GxlX2RpdiI-
QWd1YXJkZSA8%
7B%7Dc3BhbiBpZ
D0iYXBleF9sb2dp
bl90aHJvdHRsZV9
zZWMiPjU8L3Nw
YW4-
IHNlZ3Vu%7B%7D
ZG9zIHBhcmEgZ
WZldHVhciBsb2ct
aW4gbm92YW1lb
nRlLjwvZGl2Pg,,%
2F_o79Wf4HO-
biABkaSu_8f4Wp
OAcXYK-
xFrBLN4FKQ5xEK
Uvy5Z6DL1_waxf
kscB4LrdPhUtzen
AoZHX4_4Q2dw
Estouro de Buffer Médio https://portal.mp Parâmetro p_lang Utilizar uma
no parâmetro f.mp.br/intranet/ pode ser procedure de
p_lang apex/wwv_flow.js manipulado sanitização ou
_messages?p_ap gerando erro de tratamento dos
p_id=302&p_lang Buffer Overflow e parâmetros do link
=pt- potencialmente afetado.
br&p_version=5.1 sobrescrevendo
.4.00.08- áreas de memória
249744855881 da aplicação.
Erros podem Médio https://portal.mp Erros do banco de Implementar rotina
revelar f.mp.br/intranet/ dados aparecem de tratamento de
informações apex/f?p=302:1:2 junto à aplicação erros para os links
sobre a aplicação 09269758412376: web (ORA- afetados.
:::: 20009), podendo
revelar

33
 informações
sensíveis.
https://portal.mp
f.mp.br/intranet/
apex/f?p=302:1:2
03553293622600:
::::
Ausência de Baixo https://portal.mp Ausência de Usar pacotes anti-
Tokens Anti-CRSF f.mp.br/intranet/ tokens Anti-CRSF CSRF.
em formulários apex/f?p=302:1:2 facilita ataques de
HTML 03553293622600: Cross-Site
:::: Request Forgery,
em que um
atacante recebe
https://portal.mp as requisições do
f.mp.br/intranet/ usuário no lugar
apex/f?p=302:LO do site
GIN_DESKTOP:::::: autorizado.

Cabeçalho HTTP Baixo https://portal.mp Se o controle de Sempre que

sem controle de f.mp.br/intranet/ cache estiver possível, verificar
cache ou com apex/f?p=302:101 ausente ou se o cabeçalho
controle de cache ::::::&notification desabilitado no HTTP está
incompleto _msg=RXJybyBhb cabeçalho HTTP, configurado com as
yBvYnRlciBlbnRyY pode permitir ao flags no-cache, no-
WRhIExEQVA6IEV navegador ou store e must-
tYWlsIG7jbyBsb2 proxy do cliente revalidate.
NhbGl6YWRv%7B fazer cache do
%7DLjxkaXYgaWQ conteúdo de
9ImFwZXhfbG9na resposta, o que
W5fdGhyb3R0bG nem sempre é
VfZGl2Ij5BZ3Vhc desejável.
mRlIDxzcGFu%7B
%7DIGlkPSJhcGV4
X2xvZ2luX3Rocm
90dGxlX3NlYyI-
NTwvc3Bhbj4gc2
VndW5kb3Mg%7
B%7DcGFyYSBlZm
V0dWFyIGxvZy1p
biBub3ZhbWVud
GUuPC9kaXY-
%2FWqhkWxk3ue
rFyXHFlhuZO-
4PJIsda0_iYx-
TNJ99EoTHrsbun

34
 MbCMx9QdMWx
GXmXYuxWmp2K
dO3hThzhrmCffQ

https://portal.mp
f.mp.br/intranet/
apex/f?p=302:1:2
09269758412376:
::::
Vazamento via Baixo https://portal.mp A aplicação web Configurar o
campo de f.mp.br/intranet/ está vazando servidor web para
resposta HTTP “X- apex/f?p=302:1::: informação omitir a
Powered-By” ::: através do campo informação de
“X-Powered-By” cabeçalho "X-
(Servlet/3.0 Powered-By".
https://portal.mp JSP/2.2). Este
f.mp.br/intranet/ vazamento pode
apex/wwv_flow.a fornecer
ccept informações que
facilitem a um
atacante
https://portal.mp identificar
f.mp.br/intranet/ frameworks e
apex/wwv_flow.js versões de
_messages?p_ap componentes
p_id=302&p_lang utilizadas pelo
=pt- sistema.
br&p_version=5.1
.4.00.08-
249744855881

https://portal.mp
f.mp.br/intranet/
apex/f?p=302:1:2
03553293622600:
::::

https://portal.mp
f.mp.br/intranet/i
/libraries/apex/mi
nified/legacy.min.
js?v=5.1.4.00.08

https://portal.mp
f.mp.br/intranet/i

35
 /libraries/font-
apex/1.0/fonts/fo
nt-
apex.woff2?v1.0

https://portal.mp
f.mp.br/intranet/i
/libraries/apex/mi
nified/widget.stic
kyWidget.min.js?
v=5.1.4.00.08

https://portal.mp
f.mp.br/intranet/i
/libraries/apex/mi
nified/widget.stic
kyTableHeader.mi
n.js?v=5.1.4.00.08

Falta do Baixo https://portal.mp O cabeçalho Anti- Incluir cabeçalho

cabeçalho X- f.mp.br/intranet/ MIME X-Content- Anti-MIME X-
Content-Type- apex/f?p=302:LO Type-Options não Content-Type-
Options GIN_DESKTOP:::::: foi configurado Options
para ‘nosniff’. Isso configurado para
possibilita a um ‘nosniff’.
https://portal.mp atacante realizar
f.mp.br/intranet/ MIME-sniffing no
apex/f?p=302:1:2 corpo de
09269758412376: resposta, o que
:::: pode ajudá-lo a
obter
informações
https://portal.mp potencialmente
f.mp.br/intranet/ relevantes.
apex/f?p=302:1:2
03553293622600:
::::

https://portal.mp
f.mp.br/intranet/i
/libraries/apex/mi
nified/legacy.min.
js?v=5.1.4.00.08

36
https://portal.mp
f.mp.br/intranet/i
/libraries/apex/mi
nified/widget.stic
kyTableHeader.mi
n.js?v=5.1.4.00.08

https://portal.mp
f.mp.br/intranet/i
/libraries/font-
apex/1.0/css/font
-
apex.min.css?v=5.
1.4.00.08

https://portal.mp
f.mp.br/intranet/i
/libraries/apex/mi
nified/desktop.mi
n.js?v=5.1.4.00.08

https://portal.mp
f.mp.br/intranet/i
/libraries/apex/mi
nified/widget.stic
kyWidget.min.js?
v=5.1.4.00.08

https://portal.mp
f.mp.br/intranet/i
/libraries/apex/mi
nified/widget.ape
xTabs.min.js?v=5.
1.4.00.08

https://portal.mp
f.mp.br/intranet/i
/libraries/font-
apex/1.0/fonts/fo
nt-
apex.woff2?v1.0

37
Cookie Baixo https://portal.mp A ausência da flag Quando um cookie
IPCZQX03a24349 f.mp.br/intranet/ segura facilita o guardar
80 criada sem flag apex/wwv_flow.js acesso desse informações
segura _messages?p_ap cookie por sensíveis ou
p_id=302&p_lang agentes não valores de sessão,
=pt- autorizados, verificar se o canal
br&p_version=5.1 especialmente se está criptografado
.4.00.08- a conexão não e se a flag segura
249744855881 estiver está habilitada
criptografada.
Cookie Baixo https://portal.mp Um cookie sem a Certificar-se de que
IPCZQX03a24349 f.mp.br/intranet/ flag HttpOnly a flag HttpOnly
80 criado sem flag apex/f?p=302:LO habilitada pode esteja habilitada
httponly GIN_DESKTOP:::::: ser acessado via para todos os
código JavaScript. cookies.
Se for possível
https://portal.mp rodar código
f.mp.br/intranet/ JavaScript na
apex/wwv_flow.a página ele poderá
ccept acessar o valor
deste cookie. Se
for um cookie de
https://portal.mp sessão, um
f.mp.br/intranet/i atacante pode ser
/libraries/font- capaz de
apex/1.0/css sequestrá-la.

https://portal.mp
f.mp.br/intranet/i
/libraries/font-
apex/1.0/fonts/fo
nt-
apex.woff2?v1.0

https://portal.mp
f.mp.br/intranet/i
/libraries/apex/mi
nified/desktop.mi
n.js?v=5.1.4.00.08

https://portal.mp
f.mp.br/intranet/i
/libraries/apex/mi
nified/widget.stic
kyTableHeader.mi
n.js?v=5.1.4.00.08

38
Cookie Baixo https://portal.mp A ausência do Certificar-se de que
IPCZQX03a24349 f.mp.br/intranet/ atributo SameSite o atributo
80 sem o atributo apex/wwv_flow.a para este cookie SameSite está
SameSite ccept possibilita utilizá- configurado como
lo em requisições ‘lax’ ou ‘strict’.
vindas de outros
https://portal.mp sites, facilitando
f.mp.br/intranet/ ataques de CRSF
apex (Cross-site
Request Forgery).

https://portal.mp
f.mp.br/intranet/i
/libraries/font-
apex/1.0
Cookie Baixo https://portal.mp Um cookie sem a Certificar-se de que
ZNPCQ003- f.mp.br/intranet/ flag HttpOnly a flag HttpOnly
32313300 sem apex/f?p=voto habilitada pode esteja habilitada
flag HttpOnly ser acessado via para todos os
código JavaScript. cookies.
Se for possível
rodar código
JavaScript na
página ele poderá
acessar o valor
desta cookie. Se
for um cookie de
sessão, um
atacante pode ser
capaz de
sequestrá-la.
Cookie Baixo https://portal.mp A ausência da flag Quando um cookie
APEX_INTRANET_ f.mp.br/intranet/ segura facilita o guardar
SERVERID criada apex/f?p=voto acesso desse informações
sem flag segura cookie por sensíveis ou
agentes não valores de sessão,
autorizados, verificar se o canal
especialmente se está criptografado
a conexão não e se a flag segura
estiver está habilitada
criptografada.
Cookie Baixo https://portal.mp A ausência da flag Quando um cookie
ORA_WWV_APP_ f.mp.br/intranet/ segura facilita o guardar
302 criada sem apex/f?p=302:1::: acesso desse informações
flag segura ::: cookie por sensíveis ou
agentes não valores de sessão,
autorizados, verificar se o canal
https://portal.mp especialmente se está criptografado
f.mp.br/intranet/ a conexão não

39
 apex/wwv_flow.a estiver e se a flag segura
ccept criptografada. está habilitada
Cookie Baixo https://portal.mp A ausência do Certificar-se de que
ORA_WWV_APP_ f.mp.br/intranet/ atributo SameSite o atributo
302 sem o apex/f?p=302:101 para este cookie SameSite está
atributo SameSite ::::::&notification possibilita utilizá- configurado como
_msg=RXJybyBhb lo em requisições ‘lax’ ou ‘strict’.
yBvYnRlciBlbnRyY vindas de outros
WRhIExEQVA6IEV sites, facilitando
tYWlsIG7jbyBsb2 ataques de CRSF
NhbGl6YWRv%7B (Cross-site
%7DLjxkaXYgaWQ Request Forgery).
9ImFwZXhfbG9na
W5fdGhyb3R0bG
VfZGl2Ij5BZ3Vhc
mRlIDxzcGFu%7B
%7DIGlkPSJhcGV4
X2xvZ2luX3Rocm
90dGxlX3NlYyI-
NTwvc3Bhbj4gc2
VndW5kb3Mg%7
B%7DcGFyYSBlZm
V0dWFyIGxvZy1p
biBub3ZhbWVud
GUuPC9kaXY-
%2FWqhkWxk3ue
rFyXHFlhuZO-
4PJIsda0_iYx-
TNJ99EoTHrsbun
MbCMx9QdMWx
GXmXYuxWmp2K
dO3hThzhrmCffQ
Cookie Baixo https://portal.mp A ausência da flag Quando um cookie
AAAA03a2434980 f.mp.br/intranet/ segura facilita o guardar
criada sem flag apex/f?p=voto acesso dessa informações
segura cookie por sensíveis ou
agentes não valores de sessão,
autorizados, verificar se o canal
especialmente se está criptografado
a conexão não e se a flag segura
estiver está habilitada
criptografada.
Cookie Baixo https://portal.mp A ausência da flag Quando um cookie
ORA_WWV_RAC_ f.mp.br/intranet/ segura facilita o guardar
INSTANCE criada apex/f?p=302:1::: acesso desse informações
sem flag segura ::: cookie por sensíveis ou
agentes não valores de sessão,
autorizados, verificar se o canal
especialmente se está criptografado

40
 a conexão não e se a flag segura
estiver está habilitada.
criptografada.
Cookie Baixo https://portal.mp A ausência do Certificar-se de que
ORA_WWV_RAC_ f.mp.br/intranet/ atributo SameSite o atributo
INSTANCE sem o apex/f?p=302:1::: para este cookie SameSite está
atributo SameSite ::: possibilita utilizá- configurado como
lo em requisições ‘lax’ ou ‘strict’.
vindas de outros
sites, facilitando
ataques de CRSF
(Cross-site
Request Forgery).
Tabela 1.1. Informações dos scanners de vulnerabilidade

41
RECOMENDAÇÕES
(Item 1) Documentação de desenvolvimento do sistema deficiente
1. Implementar melhorias na documentação de desenvolvimento do sistema VOTUM,
buscando registrar todas as regras de negócio nas funções correspondentes existentes na
aplicação.

(Item 2) Ausência de controle de versão do sistema.

2. Implementar controle de versão do software de votação, avaliando as ferramentas
disponíveis no mercado, para gerenciar os scripts SQL e componentes externos da
aplicação.

(Item 3) Registro de eventos (log) da aplicação deficiente.

3. Implementar melhorias no registro (log) de eventos do sistema VOTUM, tanto no
módulo administrativo, quanto no módulo de eleição, de forma a guardar informações
importantes sobre atividades executadas pelos usuários, seguindo, no que couber, o que
dispõe o item 12.4.1 da Norma ABNT NBR ISO/IEC 27002:2013.

(Item 4) Fragilidades nas credenciais para acesso ao ambiente de desenvolvimento e ao

banco de dados do sistema.
4. Segregar os perfis de acesso de desenvolvedor e administrador da Plataforma APEX e
no banco de dados do sistema de Votação.

5. Prover meios de registro contínuo e persistente das operações realizadas no sistema de

Votação e no banco de dados.

6. Evitar o uso de usuários genéricos do tipo “ADMIN” para os quais não se possa
personificar o real usuário e adotar credenciais de segurança individuais e intransferíveis,
sempre que possível, em conformidade com a ABNT NBR ISO/IEC 27002:2013.

7. Abster-se o desenvolvedor de repassar a própria senha aos membros da Comissão

Eleitoral, criando um perfil individual para um ou mais membros.

(Item 5) Fragilidades que podem comprometer o sigilo do voto.

8. Atualizar a função randômica que gera o número da cédula de votação para funções
mais atuais do APEX e abster-se de utilizar como semente apenas dados de data e hora,
que podem ser obtidos por meio de relatórios gerados pelo próprio sistema.

(Item 6) Outras cópias do sistema encontram-se instaladas.

9. Apresentar em cada relatórios de resultados das eleições o identificador único da
aplicação usada no dia do pleito eleitoral.

10. Entregar à Comissão Eleitoral, após o pleito eleitoral, o Log de Sessão da Aplicação
em Execução, gerado automaticamente pela Plataforma APEX, para que possa servir de
insumos em eventual cotejamento da relação de votantes.

(Item 7) Ausência de rotinas de testes periódicos de backup.

42
11. Instituir e manter rotina de testes periódicos dos backups dos ativos que suportam o
Sistema Votum, tais como: banco de dados, ambiente de desenvolvimento, servidores de
aplicações. De acordo com os preceitos da ISO/IEC 27002:2013, Seção 12.3.

(Item 8) Risco de não garantir a autenticidade do eleitor.

12. Avaliar as oportunidades de melhorias descritas no item específico do relatório,
relacionadas para cada um dos fatores de autenticação atualmente implementados.

(Item 9) Aplicação se mostrou segura frente a testes básicos de ataques por agentes
externos.
13. Implementar rotina de testes periódicos de invasão nos ativos que suportam o Sistema
Votum.

43
CONCLUSÃO
As análises realizadas objetivaram responder a quatro subquestões de auditoria e uma
questão de auditoria principal.

Em relação às Subquestões de Auditoria:

1. Os mecanismos de controle implementados no processo de desenvolvimento do

software são suficientes para suportar a salvaguarda do código fonte?

Pelos testes realizados conclui-se que os mecanismos de controle implementados no

processo de desenvolvimento do software não são suficientes para suportar a salvaguarda
do código fonte.

Foram identificadas as seguintes fragilidades no processo de desenvolvimento do sistema

Votum:
(Item 1) Documentação de desenvolvimento do sistema deficiente, contendo apenas de
alguns comentários nos componentes do sistema e nas rotinas do banco de dados. Uma
boa documentação a nível de desenvolvimento deve conter todas as operações e
informações necessárias do software, facilitando seu uso e entendimento, sendo muito
importante em futuras manutenções e evoluções, proporcionando uma expansão do
software de forma sustentável e segura.

(Item 2) Ausência de controle de versão do sistema. O Sistema Votum não possui controle
de versão da aplicação de modo a manter registradas as alterações realizadas no sistema.
O controle de versão faz parte do gerenciamento e controle de mudanças de um software.
Um adequado versionamento do sistema, além de otimizar o processo de
desenvolvimento, se apresenta como um fator importante de proteção do código-fonte do
sistema.

(Item 3) Registro de eventos (log) da aplicação deficiente. O Sistema Votum carece de

implementação de registros de eventos (log) que os usuários praticam na aplicação de
modo a permitir maior rastreabilidade das ações desses usuários no sistema. As boas
práticas recomendam que registros (log) de eventos das atividades do usuário, exceções,
falhas e eventos de segurança da informação sejam produzidos, mantidos e analisados
criticamente, a intervalos regulares.

2. Os mecanismos de controle implementados são suficientes para suportar a

salvaguarda das chaves de votação?
Os testes realizados permitiram concluir apenas que há riscos nos controles
implementados atualmente para suportar a salvaguarda das chaves de votação e outros
riscos relacionados com autenticidade do eleitor. Não foi possível simular efetivamente
o voto de um eleitor usando a senha de votação de outro eleitor, em razão da não
disponibilização em tempo hábil de credenciais de acesso à aplicação de votação.

Os riscos identificados estão descritos em:

(Item 8) Risco de não garantir a autenticidade do eleitor. Identificou-se que essas chaves
de votação são enviadas por e-mail, em seu formato original (texto não cifrado) e
armazenadas no banco de dados de modo cifrado. O envio das chaves de votação em texto

44
livre por e-mail abre brechas para leitura a partir de um ataque do tipo “homem do meio”
ou de um ataque direto ao servidor de correio. Já o armazenamento de senhas válidas em
uma tabela no banco de dados da aplicação, mesmo que cifradas, majora o risco de quebra
de segurança para atacantes internos com acesso ao banco e conhecimento da cifra.
Outrossim, a ausência de uma política de alterações periódicas de senhas de rede, para
acesso ao sistema de votação, e de disseminação de padrões mais restritivos do uso do
certificado digital também interferem negativamente nos controles de autenticidade dos
eleitores.

3. A aplicação web resiste a testes básicos de invasão?

A aplicação se mostrou segura frente a testes básicos de ataques por agentes externos
(Item 9). Ressalta-se que, a exceção das informações listadas no relatório, de modo geral,
a aplicação web do sistema Votum se comportou de forma segura diante de ataques
automatizados de nível básico. Isso se deve à presença de controles implementados por
ferramentas de segurança, como Firewall de Aplicação Web. Vale lembrar que não foi
objeto do escopo deste trabalho a realização de testes avançados de invasão.

4. Os mecanismos de controle de acesso e salvaguarda dos ativos de software, banco

de dados e infraestrutura são suficientes para não permitir o acesso indevido por
agentes externo e interno?
Os testes realizados levaram à conclusão de que o controle de acesso ao ambiente de
desenvolvimento do software e ao banco de dados não são suficientes para garantir a
salvaguarda das informações, se o ataque partir de Agente Interno.

Foram identificadas as seguintes fragilidades:

(Item 4) Fragilidades nas credenciais para acesso ao ambiente de desenvolvimento e ao
banco de dados do sistema.
A ausência de segregação de funções entre os perfil de desenvolvedor e administrador,
bem como a identificação de usuário genérico com perfil de administrador da plataforma
de desenvolvimento, dá condições para que alterações indevidas, realizadas por Agente
Interno, tanto na aplicação como nos dados armazenados, possam ser ocultadas.

(Item 5) Fragilidades que podem comprometer o sigilo do voto.

A função randômica que gera o número da cédula de votação está obsoleta, segundo
documentação da própria fabricante da plataforma de desenvolvimento. Ademais, a
semente utilizada para gerar os números aleatórios utiliza dados que podem ser obtidos
por meio de relatórios publicados pelo próprio sistema.

(Item 6) Outras cópias do sistema encontram-se instaladas.

Há no mínimo nove cópias do sistema em execução em três servidores: desenvolvimento,
homologação e produção. Um dos objetivos dessa prática é o de garantir a disponibilidade
do sistema no momento das eleições. Entretanto, não consta do processo eleitoral meios
de aferir se o resultado publicado da eleição foi realmente originário da mesma aplicação
em execução no dia da eleição.

(Item 7) Ausência de rotinas de testes periódicos de backup.

A rotina de Backup é essencial para manter a segurança da informação de uma
organização diante das mais diversas ameaças. Tão crítica quanto manter essa rotina ativa
é realizar a recuperação de Backup. A ausência de testes periódicos nos backups da

45
aplicação de banco de dados do sistema Votum representa um risco elevado à
disponibilidade dos sistemas que suportam a eleição.

Em relação à Questão de Auditoria Principal: Os mecanismos de controle implementados

no processo de votação são suficientes para suportar a salvaguarda das informações?

Considerando que o Sistema Votum se mostra como um sistema de suma importância

para o MPF, entende-se que os controles atualmente aplicados precisam ser aprimorados
e constantemente revisados para suportar a salvaguarda das informações.

Os testes realizados permitem concluir que a aplicação possui razoável segurança contra
ataques oriundos de Agentes Externos, em razão principalmente dos mecanismos de
defesa adotados da infraestrutura do MPF. Já contra ataques originados de Agentes
Internos, pessoas que possuem acesso ao código fonte, ambiente de desenvolvimento,
banco de dados, ou servidores que hospedam a aplicação, o sistema Votum necessita de
melhorias contínuas e constante vigilância no sentido de bloquear brechas para ações
maliciosas ou no mínimo permitir a rastreabilidade dessas ações, quando ocorrerem.

Cabe mencionar que este trabalho não tem o intuito de questionar a ética e boa fé das
poucas pessoas envolvidas no desenvolvimento e sustentação do sistema de votação, até
por que se mostraram abertos e solícitos à equipe da CGU, entregando as informações
possíveis de serem entregues na medida das limitações impostas pela cenário atual de
pandemia, por questões tecnológicas e pelo curto prazo para realização dos trabalhos.
Contudo, sendo um sistema Votum, um sistema criado para atender a objetivo primordial
do MPF, as vulnerabilidades inerentes à atuação de Agentes Internos se mostraram
necessárias de serem apresentadas para que o próprio MPF atue no sentido de estabelecer
controles constantes para mitigar os riscos ou conter os danos causados por essas
vulnerabilidades internas.

Cabe lembrar também que a identificação de riscos ao sistema de votação, tampouco ao

processo eleitoral do MPF como um todo, não se exaure com esse trabalho. Não se
mostrando suficiente apenas resolver as fragilidades apresentadas, mas há a necessidade
de um esforço constante do MPF, para identificação de outros riscos e nos ajustes e
monitoramentos no ativos que suportam a informação, envolvendo mais pessoas da área
de tecnologia da informação, com vistas a preservar a integridade da votação e sigilo do
voto.

46