METODOLOGIA HACKING E INVASO DA WEB AULA 09 Segurana de Sistemas Gil Eduardo de Andrade

O contedo deste documento baseado nos livros Hack Notes Segurana na Web Mike Shema e Dossi Hacker Wilson Jos de Oliveira.

Introduo

A parte revoluo do slogan revoluo da Internet no existe h tanto tempo quanto a prpria Internet, cuja linhagem data da dcada de 1960. Embora os beneficirios da revoluo sejam discutveis, a quantidade de informao colocada na Web, bvio, tem crescido intensamente. Hoje, qualquer pessoa pode publicar histrias sobre seu animal de estimao, escrever artigos inteligentes, bater papo, vender bugigangas usadas entre outras coisas. Um dos fatores comuns entre essas atividades o uso das aplicaes Web. As aplicaes Web podem ser arquivos HTML estticos ou Web sites complexos, dinmicos e baseados em banco de dados. Em todos os casos, a segurana essencial para manter a integridade da aplicao, a privacidade dos seus usurios, a discrio dos seus dados e o funcionamento dos seus servidores. As prximas aulas descrevem as tcnicas que voc pode usar para avaliar a segurana (ou insegurana) de sua aplicao. Elas expem as principais categorias dos ataques implementados por usurios maliciosos da Internet. Em alguns casos, o ataque pode parecer inofensivo, como coletar nmeros de linha de mensagens de erro ou identificar todos os campos <form> de um Web site. Por outro lado, o atacante pode encontrar a fenda na armadura da aplicao que permita acesso arbitrrio s informaes do banco de dados. Em qualquer caso, uma inspeo completa de uma aplicao Web requer uma abordagem metdica, como apresentado durante os estudos realizados nas aulas.

Ameaas e Vulnerabilidades

H duas categorias nas quais as vulnerabilidades da Web podem ser classificadas. Uma categoria contm vulnerabilidades dentro da plataforma os componentes que muitas aplicaes Web compartilham, como o Linux, Windows, Apache e Oracle. A outra categoria de vulnerabilidade visa a prpria aplicao. Em outras palavras, erros de programao no Web site podem expor os detalhes do carto de crdito de um usurio, permitir que um usurio malicioso execute consultas de banco de dados arbitrrias ou mesmo possibilitar acesso de linha de comando remoto ao servidor. Consequentemente, qualquer aplicao Web enfrenta uma srie de ameaas. Existem muitas ferramentas para verificar vulnerabilidades em um sistema operacional ou servidor web, e comum explorar cdigo procura dessas vulnerabilidades. Os ataques de aplicao, como injeo de SQL ou sequestro de sesso, so mais difceis de serem automatizados, mas as vulnerabilidades mais comuns podem ser codificadas de modo que algumas linhas de Perl possam checar sua presena, como no caso da verificao bsica de validao de entrada. Em suma, muitas vulnerabilidades de alto risco podem ser identificadas e exploradas mesmo por pessoas menos capacitadas. Isso no significa que outras vulnerabilidades de alto risco exijam uma capacidade privilegiada, mas simplesmente destaca que o maior denominador comum das ameaas a uma aplicao Web possui um grande conjunto de ferramentas e informaes disponveis.

Definindo o Perfil da Plataforma

Uma aplicao Web consiste em mais do que um sistema de carrinho de compras, uma pgina de pesquisa de mercado e um grfico animado para chamar sua ateno. A maioria das aplicaes de comrcio eletrnico usa uma arquitetura de trs camadas. Portanto quando dizemos aplicao, estamos, na verdade, nos referindo a um ou mais servidores que desempenham as seguintes funes:

Servidor Web: este componente serve pginas Web para o navegador do usurio. O Apache e o IIS so exemplos mais comuns. Todo o servidor Web

possui uma srie de vulnerabilidades.

Servidor de aplicao: este componente manipula, interpreta e apresenta dados para o usurio. O servidor de aplicao pode ser parte do servidor Web, como no caso do PHP e Apache ou ASP.NET e IIS. Por outro lado, o servidor de aplicao pode ser um servidor fisicamente separado, como um mecanismo de servlet Tomcat. Todo o servidor de aplicao Web possui uma srie de vulnerabilidades.

Banco de Dados: este componente armazena todos os dados necessrios pela aplicao. Embora os usurios interajam com a Web e is servidores de aplicao, eles geralmente no podem acessar o servidor de banco de dados. Na maioria das vezes, o servidor de aplicao intermedeia os dados entre o usurio e o banco de dados, formatando os dados para que sejam armazenados corretamente. Todo o servidor de banco de dados possui uma srie de vulnerabilidades.

Pode parecer tedioso repetir que cada componente tem um problema de segurana em potencial; entretanto, isso deve ilustrar o nmero de ameaas que uma aplicao Web enfrenta todas, antes mesmo que uma nica linha de cdigo tenha sido escrita.

Varredura de Porta e identificao de servio Essa a fase principal em uma inspeo de segurana. Afinal, para testar um sistema, precisa haver um servio (porta aberta) escutando. Existem vrios scanners de porta para sistemas operacionais baseados em Windows e UNIX que no s funcionam como scanners de portas, mas tambm possuem bastante funcionalidade extra. O nmap provavelmente o scanner de porta mais conhecido. Ele compila praticamente em todos os sistemas operacionais UNIX e, h alguns anos, foi portado para a plataforma Windows.

[localhost:~]% namp 192.168.0.43

Starting nmap V. 3.20 (www.insecure.org/nmap/ ) Interesting ports on target (192.168.0.43): (The 1596 ports scanned but not shown below are in state: closed) Port State Service 22/tcp open ssh 80/tcp open http Nmap run completed 1 IP address (1 host up) scanned in 0.481 seconds Outros usos para o nmap incluem a identificao do sistema operacional, a capacidade de salvar a sada em diferentes formatos e uma ampla variedade de mtodos de varredura (scanning) de portas.

Figura 1: Exemplo de varredura de portas atravs do aplicativo nmap no Linux.

Figura 2: Exemplo de descoberta de SO atravs do aplicativo nmap no Linux.

Quando comear a avaliao da aplicao, crie uma tabela semelhante Tabela 1 para rastrear os dados que voc adquirir.

Tabela 1: Lista de verificao de perfil da plataforma.

Definindo o Perfil da Aplicao

O prximo passo definir o perfil do Web site propriamente dito, catalogando sistematicamente todas as suas pginas, funes e parmetros. nesta fase que voc ser capaz de identificar problemas comuns, como validao de entrada deficiente, manipulao de sesso inadequada e outros erros de programao. Consequentemente, importante manter um registro descritivo do site. muito provvel que voc descubra algumas vulnerabilidades bvias em nvel de aplicao nesta fase.

Complete uma tabela semelhante Tabela 2 enquanto visita cada pgina da

aplicao.

Tabela 2: Lista de verificao de definio do perfil da aplicao.

Enumere a estrutura de diretrios e os arquivos De certa forma, esta etapa banal, fcil de realizar e pode ser rapidamente automatizada. Afinal, para definir o perfil da aplicao, voc precisa saber que arquivos compem o Web site. A parte fcil percorrer a aplicao e registrar cada nome de arquivo e seu caminho completo a partir da raiz Web. A outra parte da enumerao de diretrios envolve fazer suposies inteligentes sobre arquivos ou diretrios que possam existir. Para ser bem-sucedido no prognstico de diretrios, necessrio um pouco de sorte e um olho aguado para padres. Por exemplo, pode ser que a aplicao tenha trs diretrios a partir da raiz: /scripts, /users, /manage. Agora, se voc vir os diretrios /users/includes e /scripts/includes, provavelmente ser uma boa suposio que haja tambm um diretrio /manage/includes. Muitas vezes, os subdiretrios possuem definies de autorizao incorretas. Assim embora /manage possa estar protegido por senha, /manage/includes pode no estar. Um bom exemplo o portal de administrao Web Real Networks RealServer 7. Existe um diretrio admin que exige nome de usurio e uma senha para permitir acesso; entretanto, os arquivos no diretrio /admin/docs/ podem ser acessados diretamente uma situao no ideal quando o arquivo default.cfg nesse diretrio contm pelo menos um nome de usurio e uma senha em texto para o site. Essa vulnerabilidade mostra tambm que qualquer plataforma baseada na Web (servidor, aplicao ou mecanismo Web) suscetvel a esses tipos de vulnerabilidades. Uma ferramenta como o wget ou a funo crawl do libwhisker til para esta fase, mas a interao manual oferece uma melhor ideia de como os programadores projetaram a aplicao.

Identifique o mecanismo de autenticao Se a aplicao suportar usurios individuais, registre como os usurios precisam se autenticar na aplicao. Lembre-se de que os mecanismos de desafio/resposta no protegem senhas com segurana de 100%. Mesmo que a senha no seja enviada entre o cliente e o servidor, o hash passado pela desafio/resposta suscetvel a fora bruta. Assim, qualquer mecanismo de autenticao de usurio deve tambm usar um canal criptografado. Em outras palavras, use SSL, independente de como os nomes e senhas dos usurios so submetidos aplicao.

Identifique mecanismos de autorizao Em uma aplicao que emprega um modelo de usurio em camadas, procure efetuar o login com contas que tenham graus variados de acesso. Compare que funes esto disponvel para diferentes funes de usurio. Alm disso, registre que tokens mudam com base no usurio e funo. Veja a tabela 3 para ter um exemplo. Nesse exemplo, temos vrios ataques disponveis, na atividade complementar de laboratrio, realizaremos alguns deles como exemplos prticos da teoria apresentada neste documento.

Usurio URL Jhon https://website/index.php?id=john&isadmin=false&menu=basic Paul https://website/index.php?id=paul&isadmin=false&menu=basic George https://website/index.php?id=george&isadmin=true&menu=full Ringo https://website/index.php?id=ringo&isadmin=true&menu=full

Proteja a autorizao O gerenciamento de sesso e seu controle de autorizao inerente so, definitivamente, o maior desafio para uma aplicao Web. A melhor defesa monitorar o maior nmero possvel de atributos de usurio no servidor. Por exemplo, se os parmetros isadmin e menu do exemplo anterior tivessem sido monitorados em um

banco de dados e verificados para cada requisio, ento os ataques poderiam no ter sido bem-sucedidos. claro, criar acesso baseado em funo em uma tabela de banco de dados personalizada aumenta o overhead e a manuteno da aplicao; entretanto, os requisitos de segurana da aplicao podem exigir essa tcnica. Apesar de tudo, processadores velozes e hardware de computador se tornaram, principalmente, uma mercadoria. Portanto, acrescentar outros cinco ou dez servidores a um Web farm para se manter altura da demanda de usurios deve ter um retorno melhor que se arriscar nas manchetes de jornal, como: nmeros de carto de crdito roubados.

Identifique todos os arquivos de suporte Na maioria das vezes, os arquivos de suporte podem ser identificados, registrados e ignorados. Alguns exemplos desses arquivos incluem folhas de estilos (.css) e arquivos do IIS que so interpretados por filtros ISAPI especficos como .htr, .htx, .idc e .idq. Esses arquivos normalmente cotem informaes de layout ou outros dados especficos do navegador, ou contm uma breve lista de informaes da aplicao. Embora possa haver um estouro de buffer contra o prprio filtro ISAPI (.ida, por exemplo), os arquivos raramente contm valores ou dados que possam ser explorados. Entretanto, eles devem ser inspecionados quanto a presena de comentrios dos desenvolvedores. Por outro lado, arquivos de suporte como global.asa e passwd.txt contm credenciais de autenticao para a aplicao. Um dos arquivos de suporte mais conhecidos o passwd.txt. Como sugere o nome, ele contm nomes de usurios e senhas, reside na raiz do documento Web (normalmente em / ou /wwwboard) e sua extenso (txt) significa que a maioria dos servidores Web prontamente deixar que os usurios o vejam em seus navegadores. O Nikito identificar esses arquivos comuns, mas apenas se eles estiverem em locais padro.

Identifique todos os arquivos include Os arquivos include geralmente no so chamados explicitamente pelo navegador do usurio. Em vez disso, eles so referncias s pginas que o usurio visita. Por exemplo, um arquivo login.asp pode chamar dos arquivos include: footer.inc e

validateuser.inc. Um usurio v apenas uma requisio para login.asp; os dois arquivos include so chamados por um arquivo no servidor Web e executados no servidor Web. A maneira mais fcil de identificar um arquivo include procurar a tag SSI (server side include include do lado servidor). H dois tipos de referncias SSI:

Virtual: A SSI virtual usa um formato de caminho que comea com a raiz do documento Web.

<!-- #include virtual = /html/include/header.inc -->

Arquivo: A SSI de arquivo usa o formato de caminho que relativo ao diretrio atual.

<!-- #include file = include/header.inc --> Nos dois casos, a SSI ser visvel no cdigo-fonte HTML. Por outro lado, uma linguagem como php referencia arquivos include entre tags de linguagem. Portanto, voc precisar tentar encontrar um diretrio /include e deduzir alguns nomes de arquivos comuns. Alm disso, certifique-se de verificar a existncia de notas do programador com comentrios caso haja arquivo include. Aqui est um exemplo de uma referncia de arquivo include em PHP. Como est entre tags <? ?>, a referncia no ser visvel na origem HTML disponvel ao usurio.

<?php include($DOCUMENT_ROOT/include/db_connect.inc); include /include/db_connect.inc; include $db_connect_file; ?>

Os arquivos include normalmente contm referncias a outros arquivos include, variveis e constantes de aplicao, strings de conexo de banco de dados ou instrues SQL. Testes bsicos de validao de entrada costumam produzir erros que revelam arquivos include; e at mesmo erros internos mostram esses arquivos:

Warning : main( include /config.inc) [ function.main ]: Failed to create stream: No such file or directory in /home/snews/documents/ Include /page_headers.inc on line 10

Warning : Supplied argument is not a valid MySQL-Link Resource in /usr/local/apache/include/db.inc on line 67