Entendendo o Sequestro de Sessão (Session Hijacking)

Transcrição

1 Entendendo o Sequestro de Sessão (Session Hijacking) O seqüestro de sessão é sinônimo de uma sessão roubada, na qual um invasor intercepta e assume uma sessão legitimamente estabelecida entre um usuário e um host. A relação usuáriohost pode se aplicar ao acesso de qualquer recurso autenticado, como um servidor da Web, uma sessão Telnet ou outra conexão baseada em TCP. Os atacantes se colocam entre o usuário e o host, permitindo que eles monitorem o tráfego do usuário e lancem ataques específicos. Uma vez que aconteça um sequestro de sessão bem-sucedido, o invasor pode assumir o papel do usuário legítimo ou simplesmente monitorar o tráfego para injetar ou coletar pacotes específicos a fim de criar o efeito desejado. Session hijacking Em seu sentido mais básico, uma sessão é um período de tempo acordado em que o estado conectado do cliente e do servidor é vetado e autenticado. Isso simplesmente significa que tanto o servidor quanto o cliente sabem (ou pensam que sabem) quem são, e com base nesse conhecimento, eles podem confiar que os dados enviados de qualquer forma acabarão nas mãos da parte apropriada. Se um sequestro de sessão é realizado com êxito, qual é o

2 perigo? Vários eventos podem ocorrer neste momento, incluindo roubo de identidade e corrupção de dados. Em outras situações, os sequestradores de sessão criaram um mecanismo perfeito através do qual alguém pode sniffar seu tráfego ou registrar transações. Entender o que constitui uma sessão torna mais fácil ver como o sequestro de sessão pode ser extremamente eficaz quando todos os fatores estão configurados corretamente. Por exemplo, uma forma específica de sequestro envolve o uso de um sniffer antes e durante um ataque e você aprendeu sobre sniffers. Entender o TCP three-way-handshake ajudará muito a sua compreensão do sequestro de sessão TCP. Antes de nos aprofundarmos nos detalhes de cada ataque, vejamos como o sequestro de sessões é categorizado. Um atacante que realiza um sequestro de sessão está tentando assumir uma sessão para suas próprias necessidades. Uma vez que eles assumiram uma sessão, eles poderão roubar dados, enviar comandos, ou até mesmo cometer transações que eles não seriam capazes. Vamos explorar as várias formas de sequestro de sessão pode tomar e identificar os métodos que você pode usar para frustrar um sequestro de sessão. O TCP/IP é vulnerável e a maioria das contra medidas, exceto a criptografia, não funciona. Outros pontos também contribuem para o sucesso do sequestro de sessão: Nenhum bloqueio de conta para IDs de sessão inválidos Manuseio inseguro Algoritmo de geração de ID de sessão fraca Tempo de expiração da sessão indefinida Transmissão de texto claro IDs de sessões pequenas O sequestro de sessões normalmente pode ser dividido em uma das três técnicas principais: 1. Brute-forçando um ID Isto é feito adivinhando um ID;

3 Geralmente o invasor já tem algum conhecimento do intervalo de IDs disponíveis. O atacante pode ser auxiliado pelo uso de referências HTTP, sniffing, crosssite scripting ou malware. 2. Roubando um ID Se eles podem gerenciá-lo, um invasor vai roubar um ID usando sniffing ou outros meios. 3. Cálculo de um ID Um invasor tentará calcular um ID de sessão válido simplesmente olhando para um existente e depois descobrindo a sequência. Se estamos falando sobre uma aplicação ou uma rede, em ambos os casos é geralmente alguma forma de sequência alfanumérica que identifica exclusivamente uma conexão específica. Um ID de sessão pode parecer abcdef, por exemplo, mas geralmente com muito mais entropia ou aleatoriedade para evitar a capturar, adivinhação ou cálculo de um ID, o qual permite que o atacante possa assumir uma conexão ou sessão. Observe que IDs de sessão também são conhecidos como tokens de sessão. Spoofing vs. Sequestro Antes de continuarmos, você deve saber que spoofing e sequestro são dois atos distintos. Spoofing ocorre quando um atacante finge ser algo ou alguém, como um usuário ou computador. O atacante não assume qualquer sessão. No sequestro, o invasor assume uma sessão ativa existente. Neste processo, o atacante espera por uma parte autorizada estabelecer uma conexão com um recurso ou serviço e, em seguida, assume a sessão dele. O processo de sequestro de sessão se parece com isto: 1. Sniffing Este passo não é diferente do processo que exploramos quando discutimos sniffing. Você deve ser

4 capaz de farejar o tráfego na rede entre os dois pontos que têm a sessão que você deseja assumir. 2. Monitoramento Neste ponto, seu objetivo é observar o fluxo de tráfego entre os dois pontos com um olhar diferenciado para prever os números de sequência dos pacotes. 3. Dessincronização da sessão Esta etapa envolve interromper a sessão entre as duas partes. 4. Predição de ID de Sessão Neste momento, você prediz a própria ID de sessão para assumir a sessão. 5. Injeção de comando Nesta fase final, como atacante, você está livre para começar a injetar comandos na sessão. É importante que você entenda que o sequestro de sessão pode ocorrer em dois níveis inteiramente diferentes do modelo OSI, por isso é muito importante prestar atenção aos detalhes. Um sequestro de sessão pode ocorrer na camada de rede ou na camada de aplicação ou seja, um ataque pode direcionar TCP/UDP ou os protocolos muito mais altos na camada de aplicação, como HTTP ou FTP. Ataques Ativos e Passivos Você pode categorizar um ataque de sequestro de sessão como um ataque ativo ou um ataque passivo. Vejamos os dois: Ataque Ativo Um ataque de sequestro de sessão é considerado ativo quando o invasor assume a sessão como sua, assumindo assim a conexão do cliente legítimo com o recurso. Em um ataque ativo o atacante está ativamente manipulando e/ou cortando a conexão do cliente e enganando o servidor para pensar que eles são o usuário autenticado. Além disso, os ataques ativos geralmente envolvem um resultado DoS no cliente legítimo. Em outras palavras, o cliente é eliminado e substituído pelo atacante. A Figura 12.2 mostra como esse tipo de ataque se parece.

5 Ataque passivo Um ataque passivo concentra-se no monitoramento do tráfego entre a vítima e o servidor. Esta forma de sequestro usa um sniffer para capturar e monitorar o tráfego como ele vai através da rede. Um ataque passivo não altera a sessão de forma alguma. Ao contrário de um ataque ativo, o ataque passivo prepara o cenário para futuras atividades maliciosas. Um atacante tem uma posição estrategicamente vantajosa em um sequestro de sessão passiva; Eles podem capturar e analisar com êxito todo o tráfego das vítimas e progredir para uma posição de ataque ativa com relativa facilidade. Sequestro de sessão em aplicações Web O sequestro de sessão no nível da aplicação se concentra em obter acesso a um host ao obter IDs de sessão legítimas da vítima. Essencialmente, um ID de sessão (Session ID) é um

6 identificador que é aplicado à sessão de um usuário que permite que o servidor ou recurso da Web identifique a conversa que está tendo com o cliente. Então, por exemplo, digamos que você fez login em um site de vendas e está navegando no site dentro de um livro. Cada página para a qual você solicita do servidor web, você recebe a resposta e te encaminha-o para a próxima página sem que você precise fazer login repetidamente. O servidor é capaz de fazer isso porque ele identificou seu ID de sessão e assume que sabe quem você é neste momento. Os IDs de sessão, para nossos propósitos, vêm em três formas: Embutido em um URL Um aplicativo da Web usa o pedido GET para seguir os links incorporados em uma página da Web. Um invasor pode facilmente navegar pelo histórico de navegação da vítima e, muitas vezes, para obter acesso basta simplesmente digitar a URL de um aplicativo da Web previamente navegado. Embutido como um campo oculto Formulários para inserir dados do usuário muitas vezes incluem um campo oculto (hidden form) que é usado para enviar o ID de sessão de um cliente. O ID é enviado através do comando HTTP POST quando as informações são enviadas. Cookies Os cookies têm sido um meio potencial de exploração há algum tempo, e eles recentemente tomaram evidência para as questões de privacidade, como o rastreamento de atividades de compras ou armazenamento de dados sensíveis dos usuários. Um invasor pode obter informações de sessão de cookies que residem na máquina vítima. Vulnerabilidades de cookies persistentes ou sessões de subcodificação ou acesso mais fácil do cliente são algo que provavelmente todos tenham visto em algum momento. Considere, por exemplo, acessar uma página da web autenticada a partir do histórico do seu navegador, apenas para descobrir que você ainda está convenientemente conectado dias mais tarde.

7 Tipos de sequestro de sessão no nível de aplicação Ao tentar sequestrar uma sessão no nível do aplicativo, um hacker pode escolher entre um dos ataques: sniffing de sessão, previsão de tokens de sessão, man-in-the-middle e man-in-thebrowser. Vamos olhar para cada um. Sniffing de Sessão O sniffing de sessão é uma variação de sniffing. Nesta variação, você está procurando um destino específico, que é um token de sessão (também conhecido como ID de sessão). Uma vez que você, como atacante, encontrou este token, você usá-lo para obter acesso ao servidor ou outro recurso. Isso é como roubar as chaves de um carro que alguém alugou; Eles são o motorista autorizado, mas uma vez que você tem as chaves, você pode dirigi-lo, embora não esteja autorizado. Previsão de Tokens de Sessão A segunda maneira de obter um ID de sessão é prever ou fazer uma suposição sobre como um ID válido será. Como você faz isso? A maneira mais fácil e eficaz é reunir alguns IDs de sessão que já foram usados. Nesta lista de URLs, concentre-se na parte após a última barra: Vamos supor que estas são todas válidas, mas que expiraram, e queremos prever ou calcular uma nova. Se olharmos cuidadosamente, poderemos determinar um ID válido a ser usado. Você consegue ver o padrão? Eu vou quebrar cada um deles em

8 quatro pedaços. Parte 1 Parte 2 Parte 3 Parte 4 spo spo spo spo Olhe para os IDs e você deve ser capaz de determinar o padrão ou pelo menos como eles foram gerados. Você vê que as três primeiras letras permanecem as mesmas. Na parte 2, os números permanecem os mesmos também. A terceira parte muda, e se você olhar mais de perto você pode ser capaz de dizer alguma coisa. Neste caso, o segmento dá o tempo no formato de 24 horas, o que, por sua vez, dá-lhe uma visão dos segmentos 2 e 4. A parte 4 é o tempo em segundos. Se você olhar para a parte 2 você pode ver que é realmente a data, que neste caso é o 22 de fevereiro de 2005, ou Ataque Man-in-the-Middle Uma terceira maneira de obter um ID de sessão é através do ataque man-in-the-middle, que discutiremos nos ataques de rede. Ataque Man-in-the-Browser A quarta forma é o ataque man-in-the-browser, que é uma forma particularmente interessante de ataque. Os três formulários mais comuns são cross-site scripting, Trojans e JavaScript. Os mecanismos possíveis para realizar ataques man-in-thebrowser-based incluem o seguinte: Browser Helper Objects Bibliotecas dinamicamente carregadas pelo Internet Explorer durante a inicialização. Extensões O equivalente a objetos auxiliares do navegador

9 para o navegador Firefox. API Hooking A técnica usada por um ataque man-in-the-browser para executar seu ataque man-in-the-middle entre o EXE e suas bibliotecas (DLL). JavaScript Usando um worm Ajax mal-intencionado Cross-Site Scripting O cross-site scripting (XSS) é um tipo de ataque que pode ocorrer em muitos formulários, mas em geral ocorrem quando dados de algum tipo são inseridos em um aplicativo da Web por meio de uma fonte não confiável (na maioria dos casos, um pedido da Web). Normalmente, esses dados são incluídos como parte do conteúdo dinâmico que não passou por verificações de validação para garantir que é tudo confiável. Conteúdo dinâmico é qualquer tipo de conteúdo que é gerado onthe-fly ou sob demanda. Normalmente, isso significa que um usuário, navegador ou serviço faz uma solicitação, que é enviada para um servidor. O servidor interpreta a solicitação e retorna dados na forma de uma página da Web. Em muitos casos o conteúdo que faz com que o ataque ocorra vem na forma de JavaScript, mas não é restrito a este formato. Na verdade, ele poderia vir na forma de HTML, Flash ou outro código executável. Devido às enormes quantidades de código que podem ser executadas por um navegador da Web, as variações que esse tipo de ataque pode assumir são quase ilimitadas. Alguns dos objetivos mais comuns incluem ler ou roubar cookies, interferir com a informação da sessão, redirecionando para um local de escolha do atacante, ou qualquer outra tarefa. Ataques XSS armazenados e refletidos são as duas principais formas deste ataque, por isso vamos olhar para cada um: Ataques XSS armazenados (Stored XSS) Os ataques que caem nesta categoria tendem a ser o tipo mais perigoso. O ataque é

10 ativado por qualquer aplicativo da web que permite que um visitante armazene dados quando eles visitam o site. Na prática, uma aplicação web reúne a entrada de um visitante e armazena a entrada dentro da loja para posterior recuperação e uso. O processo fica errado quando um visitante malintencionado visita o site e sua entrada mal-intencionada é armazenada no armazenamento de dados. Uma vez que isso acontece, seus dados serão parte do site, e quando um visitante subsequente vem para o site, eles inadvertidamente executa os mesmos dados. Como o código é executado localmente, ele será executado com os privilégios do aplicativo cliente. Dependendo de como os dados são criados, o ataque pode realizar uma série de tarefas, incluindo estas: Sequestro do navegador de outro usuário Capturando informações confidenciais vistas pelos usuários do aplicativo Pseudo desfiguração da aplicação Varredura de portas de hosts internos (internos em relação aos usuários da aplicação web) Entrega direcionada de explorações baseadas em navegador Para adicionar perigo ao XSS armazenado, a vítima só precisa visitar a página com o ataque elaborado e não precisa clicar em um link. As fases a seguir referem-se a um cenário de ataque XSS armazenado típico: O atacante armazena código mal-intencionado na página vulnerável. O usuário autentica no aplicativo. O usuário visita uma página vulnerável. Código mal-intencionado é executado pelo navegador do usuário. O XSS armazenado é particularmente perigoso nas áreas de aplicação onde os usuários com privilégios altos têm acesso.

11 Quando esse usuário visita a página vulnerável, o ataque é executado automaticamente pelo navegador. Isso pode expor informações confidenciais, como tokens de autorização de sessão. Ataques XSS refletidos Estes ataques são um pouco mais complicado, pois o código injetado é rejeitado ou refletido fora de um servidor web na forma de uma mensagem de erro ou outro resultado. Normalmente, esses ataques fazem o seu caminho para a vítima na forma de um ou através de um servidor web diferente. Um usuário pode ser enganado para clicar em um link em uma página da web ou mensagem. Uma vez clicado, o link faria com que o usuário executasse o código. Na prática, o script cross-site refletido ocorre quando uma parte mal-intencionada injeta o código executável do navegador em uma única resposta HTTP. Como o código não é persistente e não é armazenado, ele só irá impactar os usuários que abrir um link especialmente projetado onde o ataque que faz parte da própria URL. Uma vez que o ataque é relativamente fácil de realizar em comparação com seu primo de procedimento armazenado, ele é encontrado com muito mais frequência do que ataques armazenados. Esse tipo de ataque normalmente aproveita JavaScript, VBScript ou outros idiomas de script apropriados. Nas mãos erradas, este tipo de ataque pode instalar loggers de chaves, roubar cookies da vítima, executar o roubo da área de transferência, ou mudar o índice da página (por exemplo, links de downloads). Em geral, as consequências do ataque XSS normalmente são as mesmas, independentemente da forma que o ataque leve: a divulgação do cookie de sessão do usuário ou permitir que um invasor segure a sessão do usuário e assuma a conta. Outros ataques prejudiciais incluem a revelação de arquivos do usuário final, a instalação de programas de cavalo de Tróia, o

12 redirecionamento do usuário para outra página ou site e a modificação da apresentação do conteúdo. Sugestões de livros: