METODOLOGIA HACKING E INVASÃO DA WEB AULA 09 Segurança de Sistemas Gil Eduardo de Andrade

Transcrição

1 METODOLOGIA HACKING E INVASÃO DA WEB AULA 09 Segurança de Sistemas Gil Eduardo de Andrade O conteúdo deste documento é baseado nos livros Hack Notes Segurança na Web Mike Shema e Dossiê Hacker Wilson José de Oliveira. Introdução A parte revolução do slogan revolução da Internet não existe há tanto tempo quanto a própria Internet, cuja linhagem data da década de Embora os beneficiários da revolução sejam discutíveis, a quantidade de informação colocada na Web, é óbvio, tem crescido intensamente. Hoje, qualquer pessoa pode publicar histórias sobre seu animal de estimação, escrever artigos inteligentes, bater papo, vender bugigangas usadas entre outras coisas. Um dos fatores comuns entre essas atividades é o uso das aplicações Web. As aplicações Web podem ser arquivos HTML estáticos ou Web sites complexos, dinâmicos e baseados em banco de dados. Em todos os casos, a segurança é essencial para manter a integridade da aplicação, a privacidade dos seus usuários, a discrição dos seus dados e o funcionamento dos seus servidores. As próximas aulas descrevem as técnicas que você pode usar para avaliar a segurança (ou insegurança) de sua aplicação. Elas expõem as principais categorias dos ataques implementados por usuários maliciosos da Internet. Em alguns casos, o ataque pode parecer inofensivo, como coletar números 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 aplicação que permita acesso arbitrário às informações do banco de dados. Em qualquer caso, uma inspeção completa de uma aplicação Web requer uma abordagem metódica, como apresentado durante os estudos realizados nas aulas. Ameaças e Vulnerabilidades Há duas categorias nas quais as vulnerabilidades da Web podem ser classificadas. Uma categoria contém vulnerabilidades dentro da plataforma os componentes que muitas aplicações Web compartilham, como o Linux, Windows, Apache e Oracle. A outra categoria de vulnerabilidade visa a própria aplicação. Em outras palavras, erros de programação no Web site podem expor os detalhes do cartão de crédito de um usuário, permitir que um usuário malicioso execute consultas de banco de dados arbitrárias ou mesmo possibilitar acesso de linha de comando remoto ao servidor. Consequentemente, qualquer aplicação Web enfrenta uma série de ameaças. Existem muitas ferramentas para verificar vulnerabilidades em um sistema operacional ou servidor web, e é comum explorar código à procura dessas vulnerabilidades. Os ataques de aplicação, como injeção de SQL ou sequestro de sessão, são mais difíceis de serem automatizados, mas as vulnerabilidades mais comuns podem ser codificadas de modo que algumas linhas de Perl possam checar sua presença, como no caso da verificação básica de validação de entrada. Em suma, muitas vulnerabilidades de alto risco podem ser identificadas e exploradas mesmo por pessoas menos capacitadas. Isso não significa que outras vulnerabilidades de alto risco exijam uma capacidade privilegiada, mas simplesmente destaca que o maior denominador comum das ameaças

2 a uma aplicação Web possui um grande conjunto de ferramentas e informações disponíveis. Definindo o Perfil da Plataforma Uma aplicação Web consiste em mais do que um sistema de carrinho de compras, uma página de pesquisa de mercado e um gráfico animado para chamar sua atenção. A maioria das aplicações de comércio eletrônico usa uma arquitetura de três camadas. Portanto quando dizemos aplicação, estamos, na verdade, nos referindo a um ou mais servidores que desempenham as seguintes funções: Servidor Web: este componente serve páginas Web para o navegador do usuário. O Apache e o IIS são exemplos mais comuns. Todo o servidor Web possui uma série de vulnerabilidades. Servidor de aplicação: este componente manipula, interpreta e apresenta dados para o usuário. O servidor de aplicação pode ser parte do servidor Web, como no caso do PHP e Apache ou ASP.NET e IIS. Por outro lado, o servidor de aplicação pode ser um servidor fisicamente separado, como um mecanismo de servlet Tomcat. Todo o servidor de aplicação Web possui uma série de vulnerabilidades. Banco de Dados: este componente armazena todos os dados necessários pela aplicação. Embora os usuários interajam com a Web e is servidores de aplicação, eles geralmente não podem acessar o servidor de banco de dados. Na maioria das vezes, o servidor de aplicação intermedeia os dados entre o usuário e o banco de dados, formatando os dados para que sejam armazenados corretamente. Todo o servidor de banco de dados possui uma série de vulnerabilidades. Pode parecer tedioso repetir que cada componente tem um problema de segurança em potencial; entretanto, isso deve ilustrar o número de ameaças que uma aplicação Web enfrenta todas, antes mesmo que uma única linha de código tenha sido escrita. Varredura de Porta e identificação de serviço Essa é a fase principal em uma inspeção de segurança. Afinal, para testar um sistema, precisa haver um serviço (porta aberta) escutando. Existem vários scanners de porta para sistemas operacionais baseados em Windows e UNIX que não só funcionam como scanners de portas, mas também 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 Starting nmap V ( ) Interesting ports on target ( ): (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 seconds

3 Outros usos para o nmap incluem a identificação do sistema operacional, a capacidade de salvar a saída em diferentes formatos e uma ampla variedade de métodos de varredura (scanning) de portas. Figura 1: Exemplo de varredura de portas através do aplicativo nmap no Linux. Figura 2: Exemplo de descoberta de SO através do aplicativo nmap no Linux.

4 Quando começar a avaliação da aplicação, crie uma tabela semelhante à Tabela 1 para rastrear os dados que você adquirir. Tabela 1: Lista de verificação de perfil da plataforma. Definindo o Perfil da Aplicação O próximo passo é definir o perfil do Web site propriamente dito, catalogando sistematicamente todas as suas páginas, funções e parâmetros. É nesta fase que você será capaz de identificar problemas comuns, como validação de entrada deficiente, manipulação de sessão inadequada e outros erros de programação. Consequentemente, é importante manter um registro descritivo do site. É muito provável que você descubra algumas vulnerabilidades óbvias em nível de aplicação nesta fase.

5 Complete uma tabela semelhante à Tabela 2 enquanto visita cada página da aplicação. Tabela 2: Lista de verificação de definição do perfil da aplicação. Enumere a estrutura de diretórios e os arquivos De certa forma, esta etapa é banal, fácil de realizar e pode ser rapidamente automatizada. Afinal, para definir o perfil da aplicação, você precisa saber que arquivos compõem o Web site. A parte fácil é percorrer a aplicação e registrar cada nome de arquivo e seu caminho completo a partir da raiz Web. A outra parte da enumeração de diretórios envolve fazer suposições inteligentes sobre arquivos ou diretórios que possam existir. Para ser bem-sucedido no prognóstico de diretórios, é necessário um pouco de sorte e um olho aguçado para padrões. Por exemplo, pode ser que a aplicação tenha três diretórios a partir da raiz: /scripts, /users, /manage. Agora, se você vir os diretórios /users/includes e /scripts/includes, provavelmente será uma boa suposição que haja também um diretório /manage/includes. Muitas vezes, os subdiretórios possuem definições de autorização incorretas. Assim embora /manage possa estar protegido por senha, /manage/includes pode não estar.

6 Um bom exemplo é o portal de administração Web Real Networks RealServer 7. Existe um diretório admin que exige nome de usuário e uma senha para permitir acesso; entretanto, os arquivos no diretório /admin/docs/ podem ser acessados diretamente uma situação não ideal quando o arquivo default.cfg nesse diretório contém pelo menos um nome de usuário e uma senha em texto para o site. Essa vulnerabilidade mostra também que qualquer plataforma baseada na Web (servidor, aplicação ou mecanismo Web) é suscetível a esses tipos de vulnerabilidades. Uma ferramenta como o wget ou a função crawl do libwhisker é útil para esta fase, mas a interação manual oferece uma melhor ideia de como os programadores projetaram a aplicação. Identifique o mecanismo de autenticação Se a aplicação suportar usuários individuais, registre como os usuários precisam se autenticar na aplicação. Lembre-se de que os mecanismos de desafio/resposta não protegem senhas com segurança de 100%. Mesmo que a senha não seja enviada entre o cliente e o servidor, o hash passado pela desafio/resposta é suscetível a força bruta. Assim, qualquer mecanismo de autenticação de usuário deve também usar um canal criptografado. Em outras palavras, use SSL, independente de como os nomes e senhas dos usuários são submetidos à aplicação. Identifique mecanismos de autorização Em uma aplicação que emprega um modelo de usuário em camadas, procure efetuar o login com contas que tenham graus variados de acesso. Compare que funções estão disponível para diferentes funções de usuário. Além disso, registre que tokens mudam com base no usuário e função. Veja a tabela 3 para ter um exemplo. Nesse exemplo, temos vários ataques disponíveis, na atividade complementar de laboratório, realizaremos alguns deles como exemplos práticos da teoria apresentada neste documento. Usuário Jhon Paul George Ringo URL Proteja a autorização O gerenciamento de sessão e seu controle de autorização inerente são, definitivamente, o maior desafio para uma aplicação Web. A melhor defesa é monitorar o maior número possível de atributos de usuário no servidor. Por exemplo, se os parâmetros isadmin e menu do exemplo anterior tivessem sido monitorados em um banco de dados e verificados para cada requisição, então os ataques poderiam não ter sido bem-sucedidos. É claro, criar acesso baseado em função em uma tabela de banco de dados personalizada aumenta o overhead e a manutenção da aplicação; entretanto, os requisitos de segurança da aplicação podem exigir essa técnica. Apesar de tudo,

7 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 usuários deve ter um retorno melhor que se arriscar nas manchetes de jornal, como: números de cartão de crédito 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 são interpretados por filtros ISAPI específicos como.htr,.htx,.idc e.idq. Esses arquivos normalmente cotem informações de layout ou outros dados específicos do navegador, ou contêm uma breve lista de informações da aplicação. Embora possa haver um estouro de buffer contra o próprio filtro ISAPI (.ida, por exemplo), os arquivos raramente contêm valores ou dados que possam ser explorados. Entretanto, eles devem ser inspecionados quanto a presença de comentários dos desenvolvedores. Por outro lado, arquivos de suporte como global.asa e passwd.txt contêm credenciais de autenticação para a aplicação. Um dos arquivos de suporte mais conhecidos é o passwd.txt. Como sugere o nome, ele contém nomes de usuários e senhas, reside na raiz do documento Web (normalmente em / ou /wwwboard) e sua extensão (txt) significa que a maioria dos servidores Web prontamente deixará que os usuários o vejam em seus navegadores. O Nikito identificará esses arquivos comuns, mas apenas se eles estiverem em locais padrão. Identifique todos os arquivos include Os arquivos include geralmente não são chamados explicitamente pelo navegador do usuário. Em vez disso, eles são referências às páginas que o usuário visita. Por exemplo, um arquivo login.asp pode chamar dos arquivos include: footer.inc e validateuser.inc. Um usuário vê apenas uma requisição para login.asp; os dois arquivos include são chamados por um arquivo no servidor Web e executados no servidor Web. A maneira mais fácil de identificar um arquivo include é procurar a tag SSI (server side include include do lado servidor). Há dois tipos de referências SSI: Virtual: A SSI virtual usa um formato de caminho que começa 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 diretório atual. <!-- #include file = include/header.inc --> Nos dois casos, a SSI será visível no código-fonte HTML. Por outro lado, uma linguagem como php referencia arquivos include entre tags de linguagem. Portanto, você precisará tentar encontrar um diretório /include e deduzir alguns nomes de arquivos comuns. Além disso, certifique-se de verificar a existência de notas do programador com comentários caso haja arquivo include. Aqui está um exemplo de uma referência de arquivo include em PHP. Como está entre tags <??>, a referência não será visível na origem HTML disponível ao usuário. <?php include( $DOCUMENT_ROOT/include/db_connect.inc );

8 ?> include /include/db_connect.inc ; include $db_connect_file; Os arquivos include normalmente contêm referências a outros arquivos include, variáveis e constantes de aplicação, strings de conexão de banco de dados ou instruções SQL. Testes básicos de validação 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