A [in]Segurança dos Sistemas Governamentais Brasileiros: Um Estudo de Caso em Sistemas Web e Redes Abertas

09/13/2021
by   Marcus Botacin, et al.
Universidade Federal do Paraná
0

Whereas the world relies on computer systems for providing public services, there is a lack of academic work that systematically assess the security of government systems. To partially fill this gap, we conducted a security evaluation of publicly available systems from public institutions. We revisited OWASP top-10 and identified multiple vulnerabilities in deployed services by scanning public government networks. Overall, the unprotected services found have inadequate security level, which must be properly discussed and addressed.

READ FULL TEXT VIEW PDF

page 4

page 7

06/25/2020

Usability, Accessibility and Web Security Assessment of E-government Websites in Tanzania

In spite of the fact that e-government agency (ega) in Tanzania emphasiz...
10/12/2020

Security and Privacy Considerations for Machine Learning Models Deployed in the Government and Public Sector (white paper)

As machine learning becomes a more mainstream technology, the objective ...
09/06/2019

Security Requirements of Commercial Drones for Public Authorities by Vulnerability Analysis of Applications

Due to the ability to overcome the geospatial limitations and to the pos...
12/03/2020

A Study of Password Security Factors among Bangladeshi Government Websites

The Government of Bangladesh is aggressively transforming its public ser...
02/22/2018

Shared Services Center for E-Government Policy

It is a general opinion that applicative cooperation represents a useful...
02/26/2018

Distributed Random Number Generation for the Needs of Public Governance

We propose distributed protocol for generation of random numbers via com...
03/23/2022

Measuring the Impact of Taxes and Public Services on Property Values: A Double Machine Learning Approach

How do property prices respond to changes in local taxes and local publi...

1 Introdução

Um dos principais agentes da vida cotidiana a se beneficiar das plataformas computacionais modernas, como a web e a Internet, são os órgãos governamentais, que agora oferecem serviços online aos cidadãos através das plataformas de governo eletrônico (e-gov) [Campos:2007:EFE:1352694.1352704]. Embora eficientes e práticas, a adoção de plataformas de e-gov também traz novos desafios, como a manutenção de níveis de segurança, um requisito fundamental para sistemas que lidam com dados sensíveis, como as informações dos cidadãos. A manutenção dos níveis de segurança requer um nível alto de maturidade das práticas de desenvolvimento e de proteção de sistemas, que devem ser constantemente avaliadas.

Apesar dos riscos envolvidos na operação de sistemas do tipo e-gov já terem sido apontados pela literatura acadêmica internacional [Prandini:2011:SCA:2072069.2072119], ainda são raras as iniciativas voltadas para a avaliação da seguranças dos serviços de e-gov no Brasil, uma clara lacuna de desenvolvimento de impacto não desprezível. Em realidade, pode-se observar na prática o impacto de vazamentos de dados, como os que afetaram os milhares de usuários cadastrados no Procon [procon]. Dados do CTIR.gov mostram números não menos alarmantes sobre a quantidade de ataques recebidos por órgãos governamentais [ctir].

Desta forma, visando dar início a estudos que possam suprir esta lacuna de conhecimento, este trabalho se propõe a conduzir uma avaliação preliminar da segurança da infraestrutura dos sistemas computacionais que suportam os serviços providos por órgãos governamentais e traçar um panorama das práticas sendo atualmente adotadas. Mais especificamente, focamos na avaliação da segurança dos serviços web e na infraestrutura de rede acessíveis via Internet, dois pontos extremamente críticos e reconhecidos pela comunidade como propensos a apresentar vulnerabilidades. Para a avaliação da segurança web, realizamos uma busca web por serviços indexados que apresentassem vulnerabilidades conhecidas categorizadas pelo projeto OWASP top10 [owasp], uma ferramenta padrão para a realização deste tipo de avaliação. Para a avaliação da infraestrutura de rede, realizamos um escaneamento da redes cujos endereços IPs são associados a órgão governamentais.

Nossos resultados indicam que o nível de proteção provido pelos serviços e redes governamentais está abaixo do adequado. Pudemos identificar a ocorrência das principais vulnerabilidades OWASP em serviços web colocados em produção pelos órgãos governamentais. Fomos capazes até mesmo de recuperar o arquivo de senhas de um dos servidores através de uma vulnerabilidade do tipo directory traversal. Mais ainda, o escaneamento das redes indicou que muitos servidores ainda se limitam a aceitar tráfego não-cifrado, tanto para serviços web, quanto para serviços de e-mail e nomes de domínio. Esperamos que os resultados aqui apresentados possam servir de indicadores e guias para a melhoria dos níveis de segurança dos serviços providos pelos órgãos governamentais. É importante destacar que estas falhas não ocorrem apenas em sistemas computacionais governamentais, mas acreditamos que a investigação desses seja essêncial devido ao alto impacto de eventuais brechas.

Em resumo, este trabalho apresenta as seguintes contribuições: (i) Uma revisão das principais vulnerabilidades OWASP ilustradas através de exemplos reais encontrados em sites e serviços governamentais; (ii) Uma análise das principais vulnerabilidades de rede encontradas através de scans em larga escala das redes públicas governamentais; e (iii) Uma discussão crítica do estado atual da segurança da infraestrutura computacional governamental e possíveis ações de melhoria.

2 Trabalhos Relacionados: Contextualização

Sistemas de governo eletrônico (e-gov) tem apresentado uma grande evolução ao longo do tempo [Campos:2007:EFE:1352694.1352704], permitindo que governo disponibilizem aos seus cidadãos os mais diversos tipos de serviço. A possibilidade de agendar eventos ou mesmo realizar tarefas sem sair de casa torna este tipo de plataforma muito popular, independente da sua área de abrangência. Atualmente, plataformas de e-gov estão disponíveis até mesmo em regiões rurais africanas [Abid:2013:CES:2591888.2591957]. Como esperado, a tendência de adesão e migração para plataformas de e-gov também chegou ao Brasil, de modo que o governo federal apresenta seu próprio portal de serviços eletrônicos disponíveis para os cidadãos [egovbr].

Ao mesmo tempo em que traz benefícios, plataformas de e-gov também trazem novos riscos, sobretudo de violações segurança. Eventos como vazamentos de dados podem violar a privacidade e até mesmo colocar em risco milhares ou milhões de cidadãos. Apesar disto, pouco tem se falado da necessidade de se proteger estes tipos de sistemas. Tipicamente, a segurança de sistemas governamentais tem se voltado para questões de espionagem [Verble:2014:NES:2684097.2684101]. Contudo, neste novo cenário, governos devem também se preocupar contra ataques oriundos de agentes internos além dos usuais agentes externos, e esperamos que possamos salientar esta necessidade através deste trabalho.

Poucos trabalhos encontrados na literatura acadêmica versam sobre a segurança em sistemas e-gov (e.g., veja um bom exemplo em [Prandini:2011:SCA:2072069.2072119]). Dentre estes, nenhum menciona o cenário Brasileiro, sendo esta uma lacuna de desenvolvimento que pretendemos suprir através deste trabalho. No contexto brasileiro, a segurança de alguns serviços públicos que afetam uma grande massa de usuários começou a ser sistematicamente avaliada recentemente. Como resultado significativo, muitas vulnerabilidades e más decisões de projeto foram encontradas em aplicações bancárias [Botacin:2019:IBI:3339252.3340103, raju]. Neste trabalho, estendemos estas avaliações para os serviços públicos disponibilizados via Internet.

3 Metodologia: Como agem os atacantes?

A avaliação foi dividida em duas etapas: (i) inicialmente, procedemos ao entendimento das principais vulnerabilidades, suas origens e implicações; (ii) posteriormente, realizamos uma busca, em maior escala, para identificar a ocorrência destas na prática.

Entendendo Vulnerabilidades. Para o entendimento e caracterização das vulnerabilidades, adotamos o framework OWASP top10 [owasp], que identifica as vulnerabilidades mais comuns no desenvolvimento de sistemas web. O framework OWASP tem se mostrado efetivo na identificação e mitigação de vulnerabilidades em casos reais, sendo adotado tanto academicamente quanto pela indústria [Thai:2019:FWS:3348445.3348456].

Buscando Vulnerabilidades. Para a identificação das vulnerabilidades na prática, buscamos simular o comportamento de um atacante, que buscaria, primariamente, por vulnerabilidades conhecidas. Para tanto, primeiramente realizamos uma busca por strings associadas a vulnerabilidades; por exemplo, buscamos por login.php para a identificação de formulários de login acessíveis sem nenhuma proteção. Este tipo de busca é conhecido como google dorks e tem sido frequentemente utilizado por atacantes para a exploração em cenários reais [Catakoglu:2017:ALD:3019612.3019796]. Pode-se encontrar na Internet coleções de dorks para a identificação de diferentes vulnerabilidades [dorks]. Para a identificação das vulnerabilidades de rede, realizamos um escaneamento das redes cujos IPs são mapeados para órgãos governamentais através da ferramenta shodan [shodan]. Esta é uma plataforma de indexação e busca de dispositivos e serviços expostos na Internet, utilizada tanto por acadêmicos para a realização de escaneamentos direcionados [Wang:2017:CMP:3078505.3078524], quanto por atacantes para a identificação de seus alvos.

Reportando Vulnerabilidades. Devemos deixar claro que todos os testes conduzidos tiveram fins puramente acadêmicos e que nenhuma vulnerabilidade foi ativamente explorada de modo a comprometer os sistemas envolvidos. Mais ainda, contatamos todos os administradores dos sistemas analisados de modo a reportar as vulnerabilidades identificadas. O contato foi realizado com antecedência em relação a escrita deste artigo, de modo a garantir tempo hábil para que os administradores corrigissem as falhas apontadas. Lamentamos que nem todos os envolvidos tenham nos contatados em busca de maiores informações ou para confirmação das correções.

4 Vulnerabilidades OWASP: Ocorrências na Prática

Nesta seção, discutimos cada uma das principais vulnerabilidades identificadas pelo projeto OWASP top-10 e exemplificamos a ocorrência destas em serviços reais de órgãos governamentais brasileiros expostos à Internet. Destaca-se que múltiplas instâncias dessas vulnerabilidades foram encontradas (por exemplo, o Google apresenta mais de 100 mil e 600 mil resultados para páginas contendo os scripts admin.php e login.php em domínios .gov.br), sendo as apresentadas abaixo selecionadas para serem aqui descritas devido ao caráter didático destas.

Ataques de Injeção são vetores populares de infecção de sites e serviços web. Eles derivam da ausência ou falha na implementação de mecanismos de validação de campos de entrada de dados, sejam de forma explícita ou implícita, de modo a permitir que um atacante insira um comando ou trecho de código sob seu controle no fluxo de execução original do serviço atacado. No passado, os ataques de injeção mais populares eram as injeções SQL [Zhang:2018:SIA:3207677.3277958], na quais consultas as base de dados eram abusadas para se obter informações privilegiadas (violação de confidencialidade) ou mesmo para executar comandos de administração, o que poderia resultar até mesmo na remoção da base de dados (violação de integridade). Ao longo do tempo, ataques de injeção também se tornaram populares em outras tecnologias web, como em scripts.

Ataques de injeção do tipo XSS e CSRF são os tipos mais populares de ataques de injeção de código script atualmente, dado a popularidade destas tecnologias em aplicações web modernas. Em particular, a injeção de código Javascript é prevalente dentre os tipos de injeção. Em ataques XSS, o atacante insere, por exemplo, um script em um formulário de texto persistente de modo que, quando o site for apresentado para os demais usuários, o script inserido entre em execução [Gupta:2015:PPM:2742854.2745719]. A ocorrência deste tipo de ataque foi identificada na prática, por exemplo, no site de uma a prefeitura. O Código 1 ilustra que, quando da tentativa de acesso ao site original, o script malicioso inserido na página redireciona o usuário para uma página sob controle do atacante (botsqq). Note que o script presente na página controlada pelo atacante (x.php) recebe o endereço da página original como parâmetro, permitindo ao atacante contabilizar o número de “vítimas” e redirecioná-las de acordo com a origem, promovendo ataques direcionados.

1Request URL: http://www.xxxxxxxxxxxx.yyy.gov.br/8vLC8QVTzS
2Status Code: 302 Found (MOVED) location:
3http://botsqq.com/x.php?www.xxxxxxxxxxxx.yyy.gov.br/8vLC8QVTzS
Código 1: Ataque de injeção de script em página web. O script inserido redireciona o usuário da página original para uma página sob controle do atacante.

Além do controle de origem no servidor de destino, descobrimos que o script do atacante também realiza o controle de origem na página atacada, de modo a ocultar a infecção. Notamos que o script não é ativado quando o site é acessado diretamente, mas apenas quando o visitante é oriundo de outra página. Em termos técnicos, a ativação do script só ocorre quando o cabeçalho referer do protocolo HTTP está definido, como mostrado no Código 2.

Código 2: Ativação do script malicioso. O script só realiza o direcionamento quando o cabeçalho referer do protocolo HTTP esta presente.

O cabeçalho referer é usualmente setado para usuários provenientes de mecanismos de busca, de modo que infecção pode ser observada em buscadores como o Google, como mostrado na Figura 1. Neste caso, o atacante redireciona os usuários para uma página de conteúdo adulto.

Figura 1: Infecção indexada no Google. Usuários são redirecionados para uma página de conteúdo adulto.

Falhas de mecanismos de autenticação e de controle de acesso são vulnerabilidades graves que permitem que um usuário acesse recursos não autorizados, o que frequentemente implica na escalada de privilégios. Estas vulnerabilidades são frequentemente exploradas através de ataques de injeção de código ou de outras falhas de verificação de entradas. Um tipo de ataque que possibilita violação de princípios de controle de acesso e autenticação é o path traversal, no qual falhas na verificação das URLs permitem acesso a arquivos internos do servidor. Na prática, este tipo de ataque foi encontrado no site da prefeitura de uma cidade do Sul do Brasil. O script download.php não trata adequadamente o parâmetro de entrada file e o servidor web não está confinado para rodar em um diretório especial, sendo executado, portanto, através da raiz (/) do sistema. Deste modo, podemos atravessar a árvore de diretórios até acessar os arquivos de senhas shadow e passwd (https://www.xxxxxxxxx.yy.gov.br/data/download.php?file=../[...]/../etc/passwd). Deste modo, um atacante poderia ter acesso a todos os usuários da máquina e decifrar suas senhas em um ataque de força bruta, ganhando completo acesso ao sistema. Não exibiremos o arquivo shadow, mas o arquivo passwd é ilustrado no Código 3.

1SSH:/var/empty/sshd:/sbin/nologin
2dovecot:<range>:Dovecot IMAP
3root:x:<range>:root:/root:/bin/bash
4cpaneleximfilter:x:<range>::/var/cpanel/userhomes/cpaneleximfilter:/usr/local/cpanel/bin/noshell
5postfix:x:<range>::/var/spool/postfix:/sbin/nologin
6postgres:x:<range>:PostgreSQL Server:/var/lib/pgsql:/bin/bash
7<USERNAME>:x:<range>::/home/<USERNAME>:/bin/bash
Código 3: Arquivo de senhas passwd. Um atacante poderia se utilizar destas informações para ganhar acesso completo ao sistema.

É importante ressaltar que a correção do problema passa pela adotação de práticas de confinamento (jail) do servidor web e da correta filtragem de parâmetros via script. Muitas implementações, contudo, optam por apenas mascarar a vulnerabilidade através de rotinas de ofuscação. O Código 4 ilustra o caso de site de câmara de vereadores de uma cidade no Sudeste do Brasil, no qual o script de download aceita parâmetros em base64, tornando menos evidente o acesso à um diretório. Contudo, a decodificação do mesmo ilustra que o script aceita endereços de arquivo como parâmetro.

1base64 -d http://www.zzzzzzzzzzzzzzzzzz.yy.gov.br/_download.php?file=
2aHR0cDovL2NhbWFyYWNhc2NhbGhvcmljby5tZy5nb3YuYnIvdXBsb2Fkcy9kb2N1bWVud
3GFjYW8vQXRhLzIwMTcvQXRhLTAxNS5wZGY=
4http://zzzzzzzzzzzzzzzzzz.yy.gov.br/uploads/documentacao/Ata/2017/Ata-015.pdf
Código 4: Caminho do arquivo codificado em base64. Estratégia de ofuscação não elimina a vulnerabilidade.

Exposição de dados sensíveis é um resultado frequente da exploração de vulnerabilidades de implementação ou da ausência de mecanismos de autenticação e de controle de acesso. Na prática, podemos observar este caso em servidores de dados do tipo FTP expostos à Internet, como no caso de outra prefeitura de cidade do Sul do país (http://ww2.yyyyyyy.zz.gov.br:8181/), como mostrado na Figura 3.

Figura 2: FTP de Prefeitura de cidade no Sul do país. Dados estão acessíveis sem qualquer mecanismo de autenticação ou controle de acesso.
Figura 3: Scanner de Vulnerabilidades Web. Um escaneamento típico revelaria as múltiplas vulnerabilidades conhecidas presentes no serviço.

No caso de órgãos governamentais, é difícil avaliar se os dados foram intencionalmente disponibilizados ou não, pois governos seguem políticas de dados abertos [dados1] e de transparência [transp1]. Desta forma, muitos órgãos disponibilizam seus próprios dados em servidores FTP (e.g., http://xxxxxxxx.xxxxxxx.xx.gov.br/ftp/, www.yyyyyyy.yy.gov.br/arquivos/ftp, ftp.zzzzzzzzzzzz.zzz.gov.br), o que é uma boa prática quando estes servidores são bem configurados. Contudo, a mistura entre arquivos de sistema, dados de séries históricas e de licitações correntes mostram a ausência de políticas claras para a classificação de informações.

Falhas de configuração de mecanismos de segurança são um agravante frequente dos incidentes de exploração de vulnerabilidade web, uma vez que a correta configuração destes poderia ter impedido ou mitigado os efeitos das explorações. Dentre as falhas mais comuns estão a ausência de cabeçalhos que estabeleçam proteções, o uso de configurações padrão não otimizadas, a expiração e invalidação de certificados SSL, entre outros. Na prática, todas essas práticas foram encontradas no site de uma prefeitura de Estado do Sudeste. Uma varredura de vulnerabilidades típica [onlinescan] seria capaz de identificá-las, como mostrado na Figura 3.

De um modo geral, as falhas de configuração em mecanismos de segurança ocorrem por que estas costumam ser o último fator a ser considerado nos processos de desenvolvimento [sdl]. Contudo, em muitas vezes, até mesmos as etapas de desenvolvimento apresentam falhas significativas. Não é raro encontrar arquivos de desenvolvimento deixados no servidor após o lançamento da aplicação. Fomos capazes de encontrar até mesmos esquemas de tabelas de banco de dados (http://www.aaaaaaa.aa.gov.br/wp-content/uploads/database.sql).

Componentes Vulneráveis. A atualização de componentes de software é um requisito básico para a manutenção da segurança de qualquer sistema, pois além de novos recursos e funcionalidades, atualizações implementam a correção de falhas para impedir a exploração de vulnerabilidades. Vulnerabilidades em software se popularizam rapidamente via Internet, de modo que atacantes estão sempre aptos a explorar sistemas que apresentem vulnerabilidades conhecidas por não terem sido atualizados. Na prática, contudo, ainda podemos encontrar sistemas defasados expostos na Internet, como mostrado na Figura 5. O site de uma agência de fiscalização de um Governo de Estado do Sudeste, além de vulnerável, apresenta todas as versões dos serviços em execução por não ter removido o arquivo de informações do php (https://bbbbbbbbbbbbb.bbbbbb.bb.gov.br/info.php). Isto permite que um atacante identifique, com precisão, quais vulnerabilidades estão presentes naquele servidor.

Figura 4: Agência de fiscalização governamental. Sistemas defasados e vulneráveis são mantidos online expostos a ataques.
Figura 5: Portal de Transparência de Estado do Centro-Oeste. Parâmetro de redireção na URL não tratado permite embutir qualquer outro site no corpo do site original.

Requisições e Redirecionamentos Não Validados. Serviços e websites modernos são construídos de forma modular, de modo que é comum se encontrar nestes diversos pontos de redirecionamento, o que permite a comunicação entre componentes e a obtenção de dados de diferentes origens. O maior desafio deste tipo de construção é garantir, através de processos de validação, a origem legítima dos dados. Caso garantias de validade das requisições não sejam oferecidas, redirecionamentos podem levar a qualquer outro endereço que não o originalmente previsto e dados de diferentes fontes podem ser incorporados ao serviço original. Estas possibilidades são especialmente interessantes à agentes maliciosos, pois permitem redirecionar o usuário para páginas sob controle do atacante e/ou injetar código nos sites vulneráveis. Este tipo de vulnerabilidade é exemplificada, na prática, pelo redirecionamento não tratado no site do portal da transparência de Estado do Centro-Oeste. Como se pode observar na requisição http://www.ccccccccccccc.cc.gov.br/externo.php?pagina=site.com.br, o código php responsável pelo tratamento do redirecionamento não valida o parâmetro passado, permitindo que qualquer site especificado na URL seja incorporado ao corpo do site principal, tal como ilustrado na Figura 5.

Log e Monitoração Insuficientes A implementação de mecanismos de monitoração é essencial para o estabelecimento de processos seguros, sendo que o uso de logs pode se dar de forma proativa ou responsiva. No primeiro caso, pode-se detectar varreduras, ataques de força bruta, e similares, o que permite a identificação do componente sob ataque. No último, pode-se identificar quais sistemas foram comprometidos e/ou que senhas foram vazadas, por exemplo, permitindo a resposta ao incidente. A verificação externa da abrangência e correta implementação dos mecanismos de log é extremamente dificultada, devendo, portanto, ser realizada prioritariamente de modo interno ao sistema avaliado. Podemos, contudo, realizar algumas inferências sob o estado atual dos sistemas governamentais de resposta a incidentes como um todo. Apesar de estarmos constantemente realizando varreduras nas redes destes órgãos e seguidas tentativas de conexão a diversos servidores, não recebemos nenhuma notificação de nenhum destes órgãos, o que pode indicar que o nível de monitoração não esteja adequado. Nossa hipótese é reforçada pelo fato de que recebemos notificação da RNP/CSIRT local por sermos origem deste tipo de ação na rede, o que indica que o efetivo monitoramento das redes seria capaz de denunciar a ação de um atacante. Mais alarmante ainda, não recebemos nenhuma notificação mesmo quando acessamos o arquivo de senhas shadow de alguns servidores, o o que pode indicar que o acesso à estes arquivos não eram monitorados a despeito da importância destes.

5 Uma Visão Geral dos Serviços de Rede

Para prover uma visão geral das práticas de segurança adotadas pelos órgãos governamentais, estendemos nossa avaliação para incluir o deploy e a configuração de serviços de rede, além das aplicações web. Realizamos uma varredura dos servidores expostos à Internet através da solução shodan e mapeamos os principais serviços disponibilizados e as configurações utilizadas por estes. Devido ao grande número de hosts conectados à Internet brasileira, limitamos nossas analises aos 1617 domínios presentes na lista de domínios .br do portal de dados abertos [listadom]. A Figura 6 sumariza os serviços e protocolos identificados.

Figura 6: Serviços e protocolos identificados. Muitos servidores ainda estão configurados de forma insegura, permitindo apenas tráfego não-cifrado (HTTP na porta 80) ou o encaminhamento de e-mails de qualquer origem (SMTP na porta 25).

De um modo geral, a maioria dos hosts expostos à Internet implementa servidores web, o que é esperado, dado a necessidade de prover informações a população. Contudo, esperava-se que a maioria destes servidores implementassem mecanismos de comunicação segura HTTPs, o que não foi observado na prática. Nota-se que o número de servidores aceitando conexões do tipo HTTP é muito superior ao número de servidores aceitando HTTPs, de modo que, mesmo se desconsiderarmos os servidores que implementam apenas a redireção de tráfego HTTP para HTTPs na porta 80, ainda temos um número expressivo de servidores que aceitam apenas conexões não criptografadas. Ressaltamos que, de acordo com os padrões atuais [https1, https2], mesmo informações disponíveis publicamente e do tipo somente-leitura são consideradas sensíveis, pois a simples informação de qual usuário acessou qual tipo de dado pode revelar informações significativas sobre este. Infelizmente, os erros de configuração não se limitam apenas a falta de suporte ao tráfego cifrado, mas estão pŕesentes também quando este suporte é implementado. Dentre os servidores configurados para aceitar conexões criptografadas, 10% tinham os certificados SSL vencidos na data de escaneamento (Outubro/2019).

Além de servidores de páginas web, outros serviços também são afetados por má práticas de configuração. Dentre os servidores disponibilizando serviços de e-mail, 50.7% aceitam conexões externas não-autenticadas na porta 25. Desde 2012, recomenda-se o bloqueio da porta 25 para o envio de emails por parte dos clientes para se evitar a propagação de mensagens spam [spam]. Apesar disso, pudemos nos conectar normalmente a estes servidores. De modo similar, dentre os servidores provendo serviços de nomes de domínios (DNS), 47% respondem a requisições externas, o que pode propiciar ataques do tipo amplificação [amplif]. Finalmente, 90.5% dos servidores de acesso remoto via SSH estavam configurados na porta padrão e aceitando autenticação por senha e não por chave pública, sugerindo que estes estariam sendo executados com as configurações padrão.

6 Discussão

Adotar as melhores práticas de desenvolvimento de sistemas é essencial para torná-los mais robusto e menos suscetíveis a falhas e a apresentar vulnerabilidades. Deve-se, por exemplo, verificar e validar todas as entradas providas, uma prática não exaustiva nos sistemas avaliados. Além disso, deve-se utilizar mecanismos de segurança explícitos, como recursos de controle de acesso e autenticação para acesso a arquivos, e não mecanismos de segurança por obscuridade, como a codificação de URLs, como observado em diversos casos.

Adotar as melhores práticas de deployment de sistemas é essencial para não tornar serviços vulneráveis. Deve-se evitar usar configurações padrão, não otimizadas para o caso de uso específico. Deve-se, ainda, remover componentes não utilizados, diminuindo, assim, a superfície de ataque.

Realizar testes de segurança periódicos é fundamental para a identificação tanto de novas vulnerabilidades oriundas de novas descobertas quando da introdução de falhas de configuração oriundas da atualização de serviços. A execução deste tipo de deste poderia ter identificado as vulnerabilidades apontadas neste trabalho.

Antecipar-se aos novos vetores de ataque é essencial para manter a segurança dos sistemas governamentais a longo prazo. Enquanto os sistemas atuais se mostram frágeis mesmo em relação à ameaças conhecidas, novos ataques vem sendo constantemente desenvolvidos. Atualmente, ataques do tipo XSS, por exemplo, tem evoluído para ataques do tipo data-only [Lekies:2017:CAW:3133956.3134091], sendo ainda mais difíceis de serem prevenidos, detectados e eliminados.

Avaliar a maturidade das práticas de segurança nas diferentes esferas governamentais é essencial para um melhor entendimento de quais pontos precisam ser fortalecidos e quais práticas devem ser prioritariamente adotadas. Empiricamente, dado o número de vulnerabilidades encontradas em nosso estudo, acreditamos que as esferas municipais tem serviços mais vulneráveis do que as esferas estaduais e federal. Um hipótese plausível para suportar este fato seria os diferentes patamares de investimento em cada uma destas esferas. A verificação desta percepção e hipótese é deixada como trabalho futuro.

Limitações. Este trabalho se propõe a apresentar um panorama da segurança dos serviços de rede, portanto, particularidades e vulnerabilidades outras que as presentes no framework OWASP não são reportadas, ainda que estas possam ter impactos significativos na segurança dos sistemas. Ademais, por este trabalho ser suportado pelos resultados providos pelas ferramentas de escaneamento, a identificação de hosts também é limitada pela capacidade destas.

Trabalhos Futuros. Acreditamos que a avaliação contínua dos níveis de segurança é essencial para a melhoria das condições operacionais dos sistemas por prover feedback sobre a eficácia das configurações implementadas. Desta forma, para o futuro, planejamos repetir estas análises periodicamente de modo a acompanhar a evolução dos sistemas. Desejavelmente, o escopo das avaliações será ampliado para a identificação de outros erros de configurações e falhas.

7 Conclusão

Neste trabalho, avaliamos a segurança dos serviços e da infraestrutura das redes governamentais expostas na Internet. Revisitamos as principais vulnerabilidades OWASP e identificamos a ocorrência destas em aplicações implementadas por diferentes órgãos, o que indica que muitos destes ainda são incapazes de se proteger mesmo contra ataques e vulnerabilidades conhecidas. Realizamos também um escaneamento das redes e identificamos que grande parte dos servidores ainda se limita a aceitar dados não-criptografados, seja em serviços web, seja em serviços de e-mail e nomes de domínio. Diante destas descobertas e da crescente dependência do meio digital, recomendamos que as ações de segurança sejam priorizadas e as medidas tomadas revisadas para a melhoria da segurança dos serviços providos pelos órgão públicos e, consequentemente, dos cidadãos.

Referências