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ário-host 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.

Ilustração de um sequestro de sessão

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 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; 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, cross-site 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 123456abcdef, 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 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.

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 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 sub-codificaçã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.

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-the-browser. 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:
www.ceh.net/app/spo22022005131020
www.ceh.net/app/spo22022005141520

www.ceh.net/app/spo22022005171126
www.ceh.net/app/spo22022005213111

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 quatro pedaços.

Parte 1   Parte 2        Parte 3    Parte 4
spo         22022005   1310        20
spo         22022005   1415        20
spo         22022005   1711        26
spo         22022005   2131        11

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 22022005.

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-the-browser-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 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 on-the-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 é 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 mal-intencionado 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:

  1. O atacante armazena código mal-intencionado na página vulnerável.
  2. O usuário autentica no aplicativo.
  3. O usuário visita uma página vulnerável.
  4. 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. 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 e-mail 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 redirecionamento do usuário para outra página ou site e a modificação da apresentação do conteúdo.

Sugestões de livros:

Sou bacharel em Sistemas de Informação pela Estácio de Sá (Alagoas), especialista em Gestão Estratégica da Tecnologia da Informação pela Univ. Gama Filho (UGF) e pós-graduando em Gestão da Segurança da Informação pela Univ. do Sul de Santa Catarina (UNISUL).
Certificações que possuo: CompTIA Security+, EXIN EHF, MCSO, MCRM, ITIL v3.
Tenho interesse por todas as áreas da informática, mas em especial em Gestão e Governança de TI, Segurança da Informação, Ethical Hacking e Perícia Forense.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Quer ficar atualizado?

Inscreva-se em minha newsletter e seja notificado quando eu publicar novos artigos de graça!