q
É fundamental realizar testes de invasão, assim como qualquer outra atividade, de acordo com métodos pré-definidos, de modo a permitir que diferentes pessoas alcancem resultados semelhantes, que possam ser reproduzidos.
Conforme já mencionado, um teste de invasão é um processo cíclico que envolve a execução de diversas atividades, como as ilustradas na Figura 2.1. Antes de prosseguir com o detalha- mento de cada uma delas, porém, vale justificar, por meio de uma analogia, a necessidade da repetição de algumas das tarefas que compõem um teste de invasão.
Imagine-se uma pessoa que queira escalar uma montanha e apreciar a vista privilegiada do topo. Inicialmente, ela deve reconhecer e mapear pontos intermediários que possam ser alcançados, limitando-se ao que é possível enxergar a partir da base. Em seguida, ela deve identificar caminhos que a conduzam aos lugares mapeados e percorrê-los para atingi-los. Nesta nova posição, tem-se uma vista maior do horizonte e a pessoa é capaz de vislumbrar novas regiões para as quais se dirigir, repetindo as etapas anteriores. Note-se que, a cada iteração, ela se aproxima mais e mais do cume e consegue ver muito mais do que circunda a montanha. Haverá vezes, porém, que a partir de certos lugares, não será possível progredir e ela terá de retornar um ou mais passos, para continuar. Tudo isso ocorre de maneira similar em um pentest! Documentação Apresentação de resultados Exploração de vulnerabilidades Reconhecimento Identificação de vulnerabilidades Mapeamento Definição de escopo e autorização
q
O primeiro passo, antes de iniciar qualquer teste de invasão, é obter do cliente, por escrito,
uma autorização para execução do teste e o escopo que será coberto pela atividade.
Normalmente, isso é feito por meio de um contrato assinado entre as partes, que define, também, o tipo de teste que será realizado, as premissas do trabalho (por exemplo, janelas técnicas que serão disponibilizadas) e os insumos que devem ser fornecidos pelo contratante, nos casos de testes caixa-cinza ou caixa-branca. Para estes últimos, é comum solicitar, além da documentação da aplicação, a criação de usuários com perfis comuns e a enumeração de um ou mais usuários privilegiados, para os testes de escalada de privilégios. Cabe ao cliente, por sua vez, definir se a equipe de segurança interna será avisada ou não sobre o pentest.
q
Outro ponto que deve ser considerado é se os testes serão realizados internamente, externamente ou a partir de ambos os posicionamentos.
Figura 2.1
Etapas de um teste de invasão.
Te st e d e I nv as ão d e A pl ic aç õe s W eb
No primeiro caso, a estação de teste deve ser colocada no mesmo segmento da rede em que ficam os usuários comuns da entidade, com o mesmo nível de acesso lógico e físico. Já no teste externo, o auditor recebe um acesso equivalente ao de um usuário remoto ou ao de um possível atacante, ou seja, todos os testes serão controlados por quaisquer mecanismos de proteção de perímetro, como firewalls e WAFs. Eventualmente, as regras desses ele-
mentos podem ser suavizadas para os endereços IP de origem, de modo a não bloqueá-los e impedir o andamento dos testes. Um exemplo de caso em que é necessário realizar testes internos e externos é o atendimento do requisito 11 do PCI DSS (PCI, 2009a).
q
O trabalho propriamente dito começa com a fase de reconhecimento, cujo objetivo é levantar qualquer tipo de informação que possa auxiliar no teste de invasão.
Assim, nesta etapa, o auditor busca identificar, por exemplo, servidores que suportam a aplicação, sistemas operacionais instalados, linguagens de programação empregadas, nomes de potenciais usuários do sistema, regras de formação de identificadores de usuário, configu- rações de softwares, convenção utilizada na atribuição de nomes de máquinas, dentre muitas outras informações. Todo esse levantamento é realizado de diversas maneiras, incluindo testes no próprio ambiente, testes indiretos e pesquisa em fontes de informação externas.
q
O próximo passo, o de mapeamento, consiste em relacionar tudo que foi coletado na etapa anterior e criar um mapa da aplicação, que reflita a estruturação dos arquivos componentes, as funcionalidades ofertadas, os pontos de entrada de informação e as tecnologias utilizadas. Para isso, as informações já coletadas devem ser complementadas com as páginas que compõem o sistema, que podem ser obtidas por métodos manuais ou automáticos. Em caso de teste caixa-preta, na primeira iteração, é comum que apenas algumas seções da aplicação sejam mapeadas, pois ainda não se tem acesso às áreas protegidas, que requerem autenticação do usuário. Tais regiões só podem ser alcançadas à medida que o teste avança, vulnerabilidades identificadas são exploradas e acesso é obtido.
q
A partir do mapa construído, deve-se proceder à descoberta de vulnerabilidades, nas diversas camadas que compõem a aplicação.
Por exemplo, imagine-se que uma aplicação de correio eletrônico está sendo testada e as únicas páginas mapeadas, inicialmente, são a de autenticação de usuário e a de recupe- ração de senha. Além disso, considere-se que na fase de reconhecimento, descobriu-se um diretório “conf” acessível via servidor web. No cenário exposto, a presença das seguintes fraquezas, pelo menos, deve ser verificada:
1Existência de arquivos interessantes no diretório “conf” que possam conter, por exemplo, identificadores de usuários válidos;
1Entropia baixa dos identificadores de sessão gerados pela aplicação;
1Possibilidade de enumeração de usuários na tela de autenticação;
1Perguntas fáceis de serem respondidas na página de recuperação de senha;
1Páginas de autenticação de usuário e de recuperação de senhas vulneráveis à injeção de SQL;
1Aceitação pela aplicação de identificadores de sessão fixados pelo usuário;
1Presença de parâmetros na requisição, que possam ser adulterados pelo auditor;
1Páginas diretamente acessíveis, sem a necessidade de autenticação.
O guia de testes do OWASP (Meucci et al., 2008), que é base do presente texto, enumera veri- ficações para cerca de setenta vulnerabilidades, agrupadas nas seguintes classes, as quais serão cobertas ao longo deste curso:
WAF
Web Application Firewall é um dispositivo que atua na camada de aplicação com o objetivo de identificar e bloquear tráfego malicioso direcionado a uma aplicação web. Por meio da definição de regras, é capaz de oferecer proteção contra ataques conhecidos, como Injeção de SQL e XSS, por exemplo, além de servir para aplicação de correções virtuais, para vulnerabilidades recém- descobertas e não previstas pelo sistema.
Ca pí tu lo 2 - R ec on he ci m en to e m ap ea m en to
1Levantamento de informações – culminam na revelação de informações relevantes a
um atacante. Exemplo: exibição de comando SQL ao usuário, devido a erro causado por sintaxe incorreta.
1Gerenciamento de configuração – parâmetros definidos de maneira insegura em
qualquer das plataformas que compõem a aplicação permitem subverter mecanismos de segurança ou obter acesso direto à infraestrutura subjacente. Exemplo: servidor SSL/TLS que aceita cifras nulas na proteção do canal.
1Autenticação – fraquezas que permitem que um atacante seja reconhecido como um
usuário legítimo do sistema, sem conhecimento prévio da senha. Exemplo: tela de auten- ticação vulnerável à injeção de SQL.
1Gerenciamento de sessões – tem origem no tratamento inseguro dos identificadores
de sessão em algum ponto do ciclo de vida deles, resultando em acesso não autorizado a funcionalidades e informações. Exemplo: uso de números sequenciais para identifica- dores de sessão.
1Autorização – vulnerabilidades que possibilitam que alguém sem os devidos privilégios
realize uma operação ou acesse uma informação. Exemplo: sistema que desabilita itens de menu de acordo com verificação inicial de privilégios, mas que não valida as requisi- ções, quando realizadas.
1Lógica de negócios – erros na implementação das regras de negócio fornecem um
caminho para que elas não sejam honradas por usuários maliciosos. Exemplo: loja de comércio eletrônico que não verifica se o preço de um produto é negativo.
1Validação de dados – esta classe engloba os problemas decorrentes do uso de infor-
mações fornecidas por usuários, sem as validações necessárias, e pode acarretar desde o vazamento de informações até o comprometimento de outros usuários do ambiente. Exemplo: informação é usada diretamente na construção de uma consulta SQL, permi- tindo a injeção de comandos arbitrários.
1Negação de serviço – falhas que podem ser usadas para impedir o uso da aplicação,
normalmente, pela exaustão de recursos. Exemplo: sistema que não verifica memória disponível antes de realizar alocação dinâmica.
1Web services e AJAX – de modo geral, são afetados por variações das vulnerabilidades
tradicionais, com algumas peculiaridades de cada tecnologia. Exemplo: web service que não valida se a mensagem é bem formada, antes de processá-la.
q
A última fase do ciclo compreende a exploração, quando possível, das vulnerabilidades encontradas, de modo a violar requisitos implícitos ou explícitos de segurança da aplicação. É importante notar que o processo não deve parar quando um ataque for bem-sucedido, pois, o objetivo do teste de invasão é encontrar o máximo de caminhos possíveis que possam levar a um comprometimento da aplicação, dos usuários ou do ambiente. Assim, tomando-se como base o último exemplo, mesmo que o analista execute com sucesso um sequestro de sessão,
devido à baixa entropia dos identificadores de sessão, ainda deverá testar outros ataques, como evasão da página de autenticação e acesso direto a recursos do sistema.
q
Claramente, após executada a etapa de exploração, é fundamental que o auditor de segurança tenha obtido um maior nível de acesso ao sistema ou uma melhor compre- ensão dele, que permita abordá-lo por outro ângulo.
Web service é um componente de software descrito em WSDL que fornece um serviço acessível pela rede a outros serviços e aplicações. Asynchronous JavaScript and XML (AJAX) compreende um conjunto de tecnolo- gias utilizadas com o objetivo de permitir a criação de aplicações interativas, que buscam informações no servidor de maneira assíncrona, por meio de Javascript. Estas podem ser formatadas como documentos XML ou HTML, por exemplo, e utilizadas para atualizar dinamica- mente a página com a qual o usuário está interagindo.
l
Sequestro de sessão
Ataque que permite tomar o controle de uma sessão estabelecida entre o usuário e um sistema.
Te st e d e I nv as ão d e A pl ic aç õe s W eb
De outro modo, não faz sentido iniciar uma nova rodada do ciclo, uma vez que nenhum avanço foi conseguido com a última iteração. Caso isso aconteça, a melhor estratégia é revisar tudo que foi encontrado até o momento, para detectar possíveis pontos que dei- xaram de ser explorados, antes de dar o teste por encerrado.
Embora a identificação de vulnerabilidades e a exploração possam ser realizadas conjun- tamente, e é assim que esses tópicos serão abordados neste curso, recomenda-se, nos primeiros testes, executá-los separadamente. A razão disso é evitar o excitamento natural que acomete uma pessoa frente a novas descobertas, que pode fazer com que o auditor foque somente o objetivo que considera o ideal e desconsidere diversos outros problemas existentes na aplicação.
q
Paralelamente a todas as atividades descritas, está o processo de documentação, que se inicia com o contrato formal e permeia as quatro etapas do ciclo de teste de invasão. Tudo que for encontrado deve constar no relatório que será entregue como resultado do trabalho, incluindo aquelas vulnerabilidades que não puderam ser exploradas. Os ataques realizados devem ser descritos de modo a permitir a reprodução pelo cliente, se desejado, e, assim, devem conter o máximo de detalhes, como pré-condições, ferramentas utilizadas e métodos empregados. Normalmente, inclui-se também uma recomendação geral indicando como o problema pode ser solucionado.
q
Por fim, e não menos importante, encontra-se a apresentação de resultados, que deve ser ajustada de acordo com as características da audiência.
Por exemplo, é aceitável incluir detalhes técnicos de cada exploração para o corpo técnico da empresa, mas não para membros da diretoria. Neste caso, normalmente, é melhor focar nos impactos decorrentes dos ataques possíveis, do que nos métodos que devem ser empregados para aproveitar-se das vulnerabilidades presentes no ambiente. Com- plementarmente, uma análise de risco quantitativa relacionada aos vetores de ataque é muito bem-vinda.