Coluna do Alexandre Borges
COLUNA
Ataque de fixação
de sessão
Como a captura e uso de identificadores de sessão podem ser
utilizados por crackers para tomar a identidade de um usuário.
H
á duas colunas atrás, expliquei o ataque de sequestro de sessão e expus o porquê de ele ser tão
perigoso. Na ocasião, ficou claro que o session
ID (identificador de sessão) do usuário é uma informação valiosa e, sem dúvidas, seria o alvo da busca de um
cracker. O sequestro de sessão tem por característica ser
um ataque realizado após o usuário (através do navegador) realizar um login (autenticação) em um serviço web
(uma loja virtual, por exemplo), onde o cracker sequestra
aquela sessão específica (se, em um momento posterior,
ele realizar o sequestro de uma nova sessão, necessitará
executar um novo ataque), muito fácil de manter (uma
vez que a sessão foi conquistada, não é preciso realizar
qualquer procedimento adicional) e onde é possível utilizar diversas técnicas para realizá-lo, tais como obter o
session ID do cabeçalho Referer do protocolo HTTP,
capturar o session ID através do uso de um sniffer (como
o Wireshark) ou ainda através do uso de um ataque de
cross-site scripting (XSS), para citar apenas alguns.
Dado o exposto acima, é curioso perguntar: e se o
ataque, ao contrário do sequestro de sessão, ocorresse
antes de o usuário autenticar-se em um site? De fato,
como muitos analistas de segurança estão preocupados em não deixar que um cracker intercepte o session
ID (que muitas vezes está embutido no cookie), nem
o adivinhe (eventualmente aproveitando a formação
de um session ID curto ou previsível) ou ainda lance
um ataque de força bruta, ocasionalmente os crackers
escolhem um caminho mais interessante, que é impor
para a vítima o session ID que será utilizado e, com
isto, não ter o trabalho de capturá-lo novamente depois
que a sessão já estiver estabelecida. Mais fácil? Não necessariamente. Talvez apenas uma outra maneira de
conseguir acesso sem autenticação, usando as mesmas
credenciais da vítima e estando livre para fazer o que
bem entender. Este ataque é chamado de Fixação de
Sessão (session fixation attack).
14
Uma das vulnerabilidades que possibilitam este ataque
de fixação de sessão é o fato de que muitos servidores
(ou aplicativos) web atribuem um session ID (através
da URL, formulários ocultos ou cookies) para o usuário
no início da sessão e, após este usuário autenticar-se,
manterem este session ID (que acaba servindo como
credencial de login) inalterado, ao invés de criar um
novo que represente a sessão do usuário após o login.
Pior ainda: muitos profissionais acreditam que a criptografia é uma saída para deter um ataque de fixação
de sessão. Não é, pois o cracker não está interessado
em roubar ou ver (através de um sniffer) o session ID e
sim impor um session ID de sua conveniência, e para
fazer isso, tanto faz se a sessão está criptografada ou não.
O cracker executa um ataque de fixação de sessão
impondo um session ID ao usuário antes que ele realize
a autenticação em um site. Basicamente, o cracker pode
se autenticar no site-alvo com seu próprio login e senha,
e com isso, obter um session ID. Depois disso, a tarefa
do cracker é impor este session ID (que é válido) para o
navegador da vítima. Assim, quando a vítima se conectar
ao site, abrirá uma sessão usando o session ID que foi imposto pelo cracker, faz a autenticação (usuário e senha),
o que fatalmente irá vincular o status “autenticado” ao
session ID fornecido pelo cracker (possivelmente através
de um cookie) e pronto, o ataque já foi feito! Lembre-se
de que o cracker impôs o session ID à vítima antes de ela
estabelecer a sessão e, por isso, basta que o cracker use o
mesmo session ID e se conecte ao site-alvo. Como este
session ID já representa alguém (a vítima) autenticado,
o cracker poderá fazer qualquer coisa como se fosse a
vítima, sem a necessidade de autenticar-se.
Este ataque é muito interessante e vistoso, entretanto
preciso fazer algumas obervações úteis. O cracker não
necessita ter um login e senha válidos no site-alvo. Ele
poderia tentar inferir como o session ID é criado e moldar uma credencial de autenticação apropriada para a
www.linuxmagazine.com.br
situação, contudo isso dá muito trabalho e nem sempre
é possível (imagine um session ID de formato muito
longo). Outro problema desta abordagem é que muitos
servidores web não aceitam um session ID imposto, e
sim apenas um que anteriormente já tenha sido criado
pelo próprio servidor. Depois que este obstáculo foi superado, o cracker deve lembrar que muitos session ID
estão sujeitos a timeout (expiração) por inatividade, o que
forçará o cracker a ter que utilizar algum método para
“quebrar” esta ociosidade e manter o session ID válido.
Outro ponto que surge como dúvida é: como o cracker pode impôr o session ID para a vítima? Por diversos
meios: enviando um e-mail para a vítima com um link
(http://www.exemplo.com.br/auth.asp?session=8549) e
enganando-a para que que ela clique no link e autentique-se por ele (tome como exemplo os spams que você
recebe diariamente usando a mesma técnica). Outro
modo de se atingir o mesmo objetivo é enviando um
link modificado, porém realizando um ataque de XSS
e, com isso, executando no ambiente do usuário um
script que apresenta para o usuário um formulário com
campos de usuário e senha para o site-alvo (obviamente,
com o session ID associado a um campo oculto). Aliás,
mais fácil ainda é, através do mesmo ataque de XSS,
Linux Magazine #90 | Maio de 2012
executar um ataque que cria um cookie persistente na
máquina do usuário (por quanto tempo for necessário),
contendo o session ID desejado e ainda válido para todo
o domínio-alvo, e não apenas para aquela página em
específico). Definitivamente, existem outras formas de
realizar o mesmo ataque, todavia acredito que o leitor
já tenha compreendido a ideia.
Existem maneiras de impedir este ataque? Claro!
Como já mencionei, uma delas é trocar o session ID
após o usuário autenticar-se. Outra excelente opção é
estabelecer um timeout para cookies. Uma outra medida de proteção é forçar que os servidores web somente
aceitem cookies gerados anteriormente por eles mesmos, sem permitir que sejam impostos pelo navegador
e ainda dentro de uma faixa de tempo. E, por fim, certamente o método mais importante é educar os usuários com medidas básicas de segurança para evitar que
qualquer ataque tenha sucesso ou chance de evoluir.
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.
15