Sequestro de sessão

Coluna do Alexandre Borges
COLUNA
Sequestro
de sessão
Alexandre Borges comemora em grande estilo seu aniversário
de 3 anos como colunista da Linux Magazine e presenteia o
leitor com o funcionamento do sequestro de sessões web.
N
as minhas últimas colunas, andei escrevendo sobre criptografia, que é, essencialmente, um assunto ligado à segurança. Então
vou continuar nesta linha e falar sobre algo muito
interessante: session hijacking (sequestro de sessão).
O que é o sequestro de uma sessão? De maneira
resumida, é a possibilidade de um cracker “sequestrar
a sessão” entre dois computadores através do roubo
do identificador de sessão (session ID) usado entre
estas duas máquinas. O início é muito similar ao TCP
hijacking, quando o cracker toma (ou sequestra) a
sessão TCP entre duas máquinas o que, infelizmente, é possível por causa de uma falha do protocolo
TCP e, pelo fato preponderante de que, na maior
parte das vezes, a autenticação somente ocorre no
início de cada sessão.
Espere aí: isto é spoofing? Não. Spoofing é iniciar
uma sessão com uma máquina ou site, se passando por
outro usuário. Hijacking é tomar uma sessão já ativa
onde, provavelmente, o usuário já efetuou autenticação.
Embora este ataque de sequestro de sessão seja
sofisticado, ele é muito simples de se implementar
por diversas razões: pela falha inerente do próprio
protocolo TCP, porque grande parte da comunicação
entre duas máquinas não é criptografada; pelo fato
de a maioria dos sites usarem sessions IDs muito pequenos e previsíveis; pelo frequente uso de sessions
IDs (ou cookies que os contêm) sem período de expiração; ou pela ausência de qualquer outro controle
de invalidação destes sessions IDs.
Por que o session ID é tão valioso em uma comunicação pela web? Simples: porque uma vez que o
cracker esteja com a posse deste, poderá fazer o que
desejar no site que o usuário está visitando, como
se fosse o próprio usuário. Isto é possível posto que
a interceptação ocorreu antes do login e o website
14
não gerou um novo session ID após a autenticação. Então, qual é o cenário geral no qual ocorre
este ataque? Novamente, de forma simplificada, o
cracker precisa, de alguma maneira, estar no meio
da comunicação entre a vítima e o site e depois
monitorar os pacotes enviados de um lado para o
outro a fim de conseguir o session ID, desconectar
o usuário do site e, por fim, assumir a sessão que
ele possuía (como se fosse o próprio usuário) e, daí
para frente, não há mais limitações quanto ao que
pode ser feito.
O leitor irá perguntar: é difícil, então, obter estes sessions IDs resultantes da comunicação com
um site? O que eu digo é que fácil não é, todavia
o cracker tem algumas alternativas para contornar
estes obstáculos.
Uma das opções é roubar o session ID da comunicação da sua máquina com o site. Para realizar esta
ação existem diversas técnicas, como:
a) o uso de trojans (onde o uso de um antivírus,
antispy ou mesmo um treinamento pode bloquear
este mecanismo);
b) através de um ataque por Cross Site Scripting
(XSS) onde, para lembrar o leitor, é possível executar
um código malicioso no cliente (neste caso, roubando o session ID e enviando para o cracker), mas que
foi injetado em um site qualquer;
c) através da interceptação dos dados usando algum tipo de sniffer (como o Wireshark);
d) tentando usar o cabeçalho de referência (http
refereer) do protocolo HTTP onde o cracker pode
tentar enganar o usuário para que ele clique em algum link que leve a vítima para um site sob o domínio do cracker;
e) lançando mão de um ataque Man-in-the-Middle,
onde o cracker se interpõe entre a vítima e o site fa-
www.linuxmagazine.com.br
zendo com que toda a comunicação passe por sua
máquina para depois ser direcionada ao site de destino.
Se a opção de roubar o session ID falhar, o cracker
pode tentar inferir o session ID tentando advinhar
seu mecanismo de geração (principalmente quando este session ID é pequeno). Isto é relativamente
fácil de ser feito capturando diversos sessions IDs e
fazendo uma análise para verificar se existe algum
padrão de criação destes.
Se não for possível fazer bom uso dos recursos
anteriores (roubo ou inferência do session ID),
o cracker pode dispor de métodos de força bruta
para consegui-lo.
Falhou? Outro ataque que permite transpor esta
dificuldade é o Session Fixation Attack que, ao invés
de roubar o session ID, define qual será utilizado
pelo usuário e, uma vez a autenticação tendo sido
feita no website, o cracker usa este mesmo session
ID para fazer o que desejar como se fosse o usuário
real. É simples executar este procedimento? Não,
pois o site precisa ser vulnerável a este tipo de exploração e, o cracker necessita ainda entender qual
é o padrão de geração destes sessions IDs.
Quais são as possíveis medidas preventivas contra este tipo de ataque? Cito algumas: transferir os
cookies (que incluem o session ID) de maneira
segura (usando o protocolo HTTPS) para evitar a
interceptação dos dados; gerar um novo session ID
após a autenticação do usuário; gerar sessions IDs
de maneira aleatória e com bom comprimento; reduzir a vida útil de um session ID (ou cookie) ou
mesmo invalidá-lo após o usuário realizar o logout;
fazer uso de um método de autenticação mais forte
como Kerberos ou, no caso de uma comunicação
empresarial, fazer uso de VPNs.
Como o leitor pôde perceber, estes conceitos de
segurança são fascinantes e eu pretendo explorá-los
melhor nas próximas colunas. Aliás, estou completando três anos nesta coluna e espero que neste período você tenha aproveitado alguma coisa dos meus
artigos. Até o mês que vem!. ■
Alexandre Borges ([email protected]) é instrutor independente e ministra
regularmente treinamentos de tecnologia Oracle (áreas de Solaris, LDAP, Cluster, Containers/OracleVM, MySQL, e Hardware), Symantec (Netbackup, Veritas
Cluster,Backup Exec, Storage Foundation e SEP) e EC-Council (CEH e CHFI), além
de estar sempre envolvido com assuntos relacionados ao kernel Linux.
Já chegou ao Brasil
a maior revista alemã
de informática e tecnologia
ogia
computação
e tecnologia
Adquira o seu exemplar
nas melhores bancas
ou pelo site
www.lnm.com.br/shopping
Linux Magazine #90 | Maio de 2012
15