1. Introdução

Sistemas Web (online) são alvos fáceis e frequentes para os atacantes,principalmente por oferecerem serviços ligados diretamente à Internet[1, 2, 3, 4,5].Algumas pesquisas indicam que o número de vulnerabilidades e ataques é cada vez maior e mais frequente em serviços e sistemas Web[3,4, 5,6,7]. Mesmo aqueles sistemas que oferecem serviços onlinemenos atraentes são alvo de ataques, pois os servidores que hospedam os sistemas online vulneráveis servem para os atacantes como pontes para consequentesataques às vítimas mais visadas, como aquelas que possuem dados e informações financeiras de clientes. Logo, é visível a crescente necessidade de boas práticas de segurança no contexto de sistemas Web[8, 9]. Isso inclui, com especial atenção, a detecção e o diagnóstico de vulnerabilidades nos sistemas. Este é o primeiro passo para um bom ciclo de desenvolvimento, evolução e manutenção dos sistemas online. A detecção deve ainda considerar, nos processos de testes de segurança, casos em que o comportamento da aplicação seja imprevisível aos dados de entrada[10]. Esta característica torna os testes de segurança uma tarefa não trivial.

Testar manualmente todas as possíveis vulnerabilidades de sistemas Web é uma tarefa complexa e muito dispendiosa, sendo considerada como impraticável. Devido a esse fato pode-se observar, tanto no contexto científico quanto pro-fissional, a eminente necessidade de ferramentas de análise de segurança que executem testes automáticos, como os diferentes scanners de vulnerabilidades[1, 3, 5, 11, 12]. Boa parte dessas soluções são baseadas em banco de dados de vulnerabilidades conhecidas e utilizam rastreadores, também denominados decrawlers, para encontrar os links e subsistemas do sitio Web a ser analisado e diagnosticado.

A maioria das ferramentas existentes não é capaz de encontrar todas as vulnerabilidades dos sistemas online[11]. Os próprios resultados da varredura para um mesmo sistema alvo, na forma de dados estatísticos e relatórios, variam entre os diferentesscanners de vulnerabilidades[11, 12, 13]. Algumas dessas ferramentas detectam mais vulnerabilidades que outras, tanto em termos quantitativos para uma mesma vulnerabilidade, com múltiplas e diversificadas incidências num mesmo sistema, quanto em relação a variabilidade de defeitos detectáveis. Adicionalmente, estudos recentes demonstram que a média de detecção de vulnerabilidades das principais soluções existentes é relativamente baixa[11].

Boa parte dos scanners de vulnerabilidades atua na detecção devulnerabilidadescomo SQL Injection e Cross-site scripting (XSS)[2, 3, 14].Não obstante, a maior parte das ferramentasexistentessãocomerciais, levando a uma carência de ferramentaslivres/gratuitas eque sejam capazes de contribuir efetiva e eficazmente na tarefa de diagnosticar e melhorar a segurança dos sistemas Web[3,11].

Estudosmostramqueexistemdiferentestipos de ataques contra sistemas Web. Entre osmaisfrequentesestãoa inclusão remota de arquivos, SQL Injection e cross-scripting[15]. Não obstante, existem outros tipos de vulnerabilidades, comoformasavançadas e de segundaordem de XSS e SQL-i, variações de Cross-Channel Scripting eCross-Site Request Forgery, queaindaestãodescobertaspelasferramentasexistentes[11].Osresultadosde diferentes pesquisas[8, 9, 11, 12, 13] apontamqueaindaháespaçoparainvestigação, inovação e desenvolvimentona área de scanners de vulnerabilidadesvoltados paraaplicações Web.

Este artigoapresenta o desenvolvimento e os resultados de umscanner de vulnerabilidades livre e gratuito, denominado Uniscan[16], para ser utilizado por profissionais responsáveis pelo desenvolvimento ou segurança de sistemas Web. O objetivo da ferramenta éautomatizar o processo de detecçãoe diagnósticode vulnerabilidades nesses ambientes. Comoprincipais pontos positivos do scannerpodem ser destacados:

(a) uma ferramenta livre e gratuitamente disponível;

(b) uma arquitetura simples, modular e extensível, per-mitindo a rápida e dinâmica incorporação de novas funcio-nalidades;

(c) incorporação de plug-ins para detectar vulnerabilidades como RFI (Remote File Inclusion), LFI (Local File Inclusion), RCE (Remote Command Execution), SQL-i, XSS e Blind SQL-i;

(d) arquitetura multi-thread para acelerar o processo de análise e diagnóstico detalhado dos sitios Web alvos;

(e) configurabilidade, permitindo ao utilizador selecionar os plug-insde análise desejados para cada sistema alvo;

(f) módulo de stress para testar a resistência das aplicações Web em diferentes níveis, como a configuração dos servidores Web responsáveis por manter os sistemasdisponíveis; e

(g) utilização de metodologia híbrida, através da combina-ção de testes dinâmicos e estáticos.

Vulnerabilidades como RFI, LFI e RCE são pouco exploradas e analisadas pela maioria das soluções existentes. Sendo assim, detectar eficazmente essas três faltas, que podem colocar sistemas Web em risco, foi um dos objectivos primários do desenvolvimento do Uniscan. Consequente-mente, o scanner pode ser considerado uma iniciativa que contribui com o desenvolvimento de detectores de vulnerabi-lidades capazes de eficientemente detectar vulnerabilidades como LFI, RFI e RCE.

A maioria dos scanners existentes, diferentemente da ferramenta desenvolvida, não possuem uma arquitetura modular e nem suporte a uma metodologia híbrida, utilizando tanto testes estáticos quanto dinâmicos na varredura dos sistemas alvo.A arquitetura modular, flexível e extensível do Uniscanextendea sua utilização e extensão para diferentescenários e casos de aplicação.

Os resultados atingidos demonstram como a ferramenta desenvolvida contribui com o processo de detecção de vulne-rabilidades em sistemas reais. O Uniscan está disponível para downloadem http://sourceforge.net/projects/uniscan/.A fer-ramenta nasceu e evoluiu como resultado de um trabalho acadêmico de pesquisa e desenvolvimento. A versão 5.3 é constituída por cinco grandes módulos e vinte plug-ins.Até o momento da escrita deste artigo, foram registrados mais de 6.000 downloadsda ferramenta, tendo como origem mais de 100 paises[17].

O restante do artigo está organizado como segue. A próxima seção apresenta uma breve descrição e caracterização de vulnerabilidades e metodologias de detecção. Na sequência, seção III,sãodiscriminadas a arquitetura e a implementação da ferramenta.Os experimentos e resultados analíticos e estatísticos são apresentados e discutidos na seção IV. Por fim, as inferências finais compõe a última seção.

2. Vulnerabilidades e Metodologias de Detecção

Esta seção introduz as vulnerabilidades e metodologias de detecção. A primeira sub-seção apresenta exemplos concretos de vulnerabilidades em códigos PHP e Perl, que são alvos iniciais de investigação deste trabalho. A segunda sub-seção aborda as metodologias estática e dinâmica de varredura dos sitios alvo.

2.1. Vulnerabilidades em Códigos Web PHP e Perl

RFI, LFI e RCE são algumas das vulnerabilidades mais comuns que programadores tendem a inconscientemente implementar sem ter ciência dos riscos envolvidos tanto para as aplicações Web quanto para os dados e sistemas opera-cionais hospedeiros. Elas estão entre as vulnerabilidades presentes com relativa frequência em sistemas Web[15] e representam um nível de risco crítico[24].Conforme estatísticas do Zone-H[25], que registra ataques a servidores e sites na Internet, a maior parte dos servidores Web que foram invadidos em 2010 foi por meio de uma dessas três vulnera-bilidades. Isso evidencia e justifica a importância de detectar, diagnosticar e tratar, da melhor forma possível, tais vulnerabi-lidades.

A vulnerabilidade RFI ocorre quando a validação dos dados, em algumas funções e procedimentos dos códigos dos sistemas Web, inexiste ou está incompleta. Um exemplo de validação é o processo de verificar se o arquivo que está sendo incluído no código realmente está no diretório especificado pela aplicação Web. Arquivos, em códigos PHP, são comu-mentemente passados como parâmetros e utilizados em fun-çõescomo include(); include_once(); require(); e require_once(). Geralmente, quando alguma destas funções é uti-lizada, o objetivo é incluir um arquivo local, armazenado em algum diretório especifico, ao código fonte do PHP[24], agregando código externo.

A vulnerabilidade RFI pode ser explorada por um atacante quando os parâmetros do código PHP não estão sendo devi-damente verificados. Nesses casos, o atacante pode passarum arquivo qualquer como parâmetro. Como exemplo, considere o endereço eletrônico, conhecido como URL,http://www.exemplo.com/index.php?inc=topo.php.O atacante pode tentar manipular os dados que são passados como parâmetros para o arquivo index.php.Neste caso, ao invés de incluir o arquivo topo.phpno parâmetro inc, o atacante poderia incluir um endereço Web de um código malicioso, comoinc=http://www.sitecracker.com/cmd.txt?cmd=id.Logo,quando o inter-pretador PHP analizar o arquivo index.php, o arquivo cmd.txt, hospedado em www.sitecracker.com, será carregado e incluído no processamento do código. O próprio PHP cria e gerencia a conexão com o sitio malicioso para a download do arquivo remoto.

A Figura 1 ilustra o processo de exploração da vulnera-bilidade RFI. O cracker, atacante, pode utilizar tanto um navegador Web bem como exploits para conseguir explorar essa vulnerabilidade nos scripts PHP do site www.example.com, hospedados no servidor Web do respectivo domínio. Para isso ele necessitará de outro site (exemplo: www.sitecracker.com), hospedado em outro servidor Web, para disponibilizar o seu arquivo malicioso (exemplo: cmd.txt), que servirá para explorar a vulnerabilidade RFI. O resultado do processo é a abertura de uma linha de comando (uma espécie de shell) via navegador Web, onde, a partir da manipulação dos parâmetros, é possível a execução de comandos no sistema operacional do servidor Web a partir do código PHP.

Com frequência, os servidores Web executam em modo usuário, ou seja, não possuem privilégios para fazer qualquer coisa no sistema operacional hospedeiro. Mesmo assim, o atacante terá acesso a todas as informações que os níveis de permissão do servidor Web permitem ter acesso. Entretanto, no caso de o servidor Web estar executando em modo super-usuário (root) a situação se torna ainda mais crítica, pois todos os comandos que o atacante utilizar serão executados com permissões de root, tendo acesso completo e irrestrito ao sistema operacional. Em ambos os casos o atacante pode utili-zar o sistema local para atacar outros sistemas internos ou externos aos domínios da entidade sendo atacada.

A vulnerabilidade LFI, assim como a RFI, também é explorada através dos parâmetros de funções como include(), include_once(), require(), e require_once(). Contudo, diferen-temente da RFI, a inclusão é de arquivos locais e não de arqui-vos remotos. O resultado desta vulnerabilidade éo acesso a arquivos locais ao sistema operacional hospedeiro, como o arquivo /etc/passwd, que contém informações dos usuários do sistema GNU/Linux(index.php?inc=/etc/passwd).

A Figura 2 apresenta o processo de exploração da vulnera-bilidade de LFI. O atacante pode utilizar um navegador Web ou um exploit para explorar essa vulnerabilidade nos scripts PHP do site www.example.com. O cracker faz uma requisição GET index.php?inc=/etc/passwd para o endereço www. example.com, o que provoca a inclusão do arquivo passwdna execução do código PHP.

Figura 1. P rocesso de exploração da vulnerabilidade RFI

Figura 2. Processo de exploração da vulnerabilidade LFI

Através do processo ilustrado na Figura 2, um atacante pode explorar a vulnerabilidade de inclusão local de arquivos através de um simples navegador, digitando uma URL comohttp://www.example.com/index.php?inc=/etc/passwd. Com es-sa simples ação o conteúdo do arquivo /etc/passwd será incluído no arquivo index.phpe será exibido no navegador Web do atacante. Esses dados podem permitir, por exemplo, a um atacante lançar um ataque de força bruta para tentar descobrir (decifrar através de tentativa e erro) a senha de cada usuário listado no arquivo /etc/passwd.

Outro exemplo de como explorar a vulnerabilidade LFI é através da utilização dos recursos e arquivos de registro de atividades (logs) do servidor Web. O servidor Web Apache, assim como outros, pode registraros logs dos acessos. Uma forma de utilizar esse recurso é forçar a gravação de logs (comandos) que levarão, posteriormente, a execução de comandos pela inclusão do arquivo de log no cógido PHP. Uma forma de forçar o registro de comandos é pelo simples método de tentar acessar páginas inexistentes com os parâmetros desejados (exemplo: /arquivoXYZ.php?id=).Isto fará com que a requisição seja gravada no access_log do apache. A partir deste