Tempo de leitura: 3 minutos

Session Hijack é, literalmente, sequestrar a sessão válida de um usuário para, então, acessar a conta deste. Quando se tem os dados da sessão, o hacker apenas precisa precisa editar os valores da própria sessão e pronto: a partir deste momento, se tem acesso a conta da vítima sem precisar saber usuário e nem senha dela. Esta forma de dominar a conta de um terceiro era bastante usada por sua simplicidade! Veja no vídeo acima como é fácil após termos os dados da sessão! Mas como se consegue esses dados? Calma. Primeiro vamos falar como se conseguia em um passado não tão distante.

XSS – Cross-Site Scripting

Uma vulnerabilidade que há pouco tempo permitia muitos roubos de contas e dados era o XSS (Cross-Site Scripting). Através desta vulnerabilidade, o hacker conseguia executar códigos client-side na máquina de um usuário legítimo. E por que isso poderia ser um problema? Porque o administrador do site não saberia o que aconteceu, já que se passou na máquina do usuário; o usuário não ficaria sabendo porque seria invisível qualquer ação para ele; o hacker poderia executar praticamente qualquer comando no contexto do usuário e, finalmente, o hacker poderia facilmente roubar a sessão do usuário (session hijack).

Para exemplificar o que estou falando, cito este exemplo: No final de 2005, o hacker Samy Kamkar descobriu uma vulnerabilidade de XSS na rede social MySpace e escreveu um inofensivo worm para demonstrar a falha. O Worm se chamava “samy”. Este worm tinha a seguinte ação: ele escrevia “but most of all, samy is my hero” (mas acima de tudo, samy é meu herói) no perfil do usuário e enviava uma solicitação de amizade para o Samy. Assim que qualquer pessoa visualizasse o perfil de alguém infectado, automaticamente se infectava e realizava estas ações descritas.

Em apenas 20 horas, samy já havia infectado mais de 1 milhão de usuários do MySpace, tornando-se o worm de propagação mais rápida da história da computação (e fez Samy Kamkar o homem mais popular do MySpace =D)

Em 2002, para diminuir a gravidade do XSS e não permitir que sessões válidas fossem roubadas, os engenheiros da Microsoft criaram uma flag adicional nos cabeçalhos HTTP chamada HTTPOnly. Esta flag impede que cookies protegidos sejam acessados por scripts client-side. O primeiro navegador a suportar esta flag foi o Internet Explorer 6. Hoje basicamente todo navegador suporta esta flag.

Portanto os sistemas mais seguros definirão esta flag em cookies importantes de sessão e os navegadores não liberarão a visualização/edição destes cookies por scripts client-side.

MITM – Man In The Middle

Se não se consegue acesso aos dados da sessão por scripts, então pegamos quando o navegador enviar estes dados ao servidor! Apenas será necessário interceptar esse pacote! Bingo!

Como se fazia então? Poderia ser utilizado um destes métodos:

1. O hacker poderia arrumar uma forma de se tornar um servidor proxy. Assim, todo pacote que saísse do navegador da vítima teria que passar pelo hacker
2. O hacker poderia se passar pelo gateway da rede enganando a máquina da vítima e se passar pela máquina da vítima para o gateway real através de um ARP Spoofing. Assim, todo o pacote que a máquina da vítima enviasse para o gateway, iria para a máquina do hacker na realidade e este reencaminharia para o gateway. Também todo pacote do gateway para a máquina da vítima seria enviado para o computador do hacker e este reencaminharia para seu destino verdadeiro.

O segundo método era o mais usado porque não precisava de nenhuma interação com a vítima. Na realidade a vítima sequer perceberia o que estava acontecendo! E se estivéssemos em uma rede wifi aberta? Seria ainda mais fácil:

MITM em Rede Wireless Aberta

Quando se usa uma rede wireless, todos os pacotes são enviados pelo ar (literalmente)! Qualquer um que esteja dentro do raio de cobertura desta rede pode ler os pacotes que chegarem até a placa de rede dele! E se essa rede estiver sem criptografia… Isso agrava bastante as coisas!

Em 2010 aproximadamente, foi desenvolvido uma extensão para Firefox que tornava tudo isso automático! O “FireSheep”. Veja o funcionamento desta extensão no vídeo abaixo:

Este ataque foi dificultado quando vários sites adotaram SSL para todas as conexões por padrão.

Então hoje não é mais possível Session Hijack?

Isto significa que não é mais possível sequestrar sessões? Não. Não é isso. Só significa que para alguns sistemas, será necessário uma forma diferente para fazer isto.

No vídeo do início desta matéria eu demonstro um método que desenvolvi que torna possível o “session hijack” mesmo com os cookies de sessão sendo definidos como HTTPOnly e com SSL ativo.

Ainda é possível roubar sessões, apenas o método precisará ser diferente.