Suas aplicações são seguras?

Conheça a Conviso!

Entendendo a técnica de Strokejacking

Este artigo também disponível em versão pdf no Scribd.

 

Introdução

Em março de 2010, o pesquisador Michal Zaleswki publicou uma prova de conceito para uma falha encontrada no WebKit [1], que possibilitava a execução de um ataque que ele chamou de strokejacking. Esta falha permitia a mudança de foco durante o tratamento do evento onkeydown, fazendo com que a tecla pressionada fosse redirecionada para um outro componente antes do disparo do evento onkeyup [2].

Com isso um atacante poderia construir uma página maliciosa contendo um frame oculto, e caso a tecla pressionada pelo usuário na página fosse interessante, mudar o foco para o frame oculto, efetivamente redirecionando a tecla pressionada. Para facilitar o entendimento do funcionamento desse ataque, segue uma versão bem simplificada da prova de conceito apresentada por Zalewski que funciona no Firefox 3.6.3:

<html>
<script>
function change_focus(e) {
var keynum = e.which;
var keychar = String.fromCharCode(keynum);
document.getElementById(“google”).focus();
document.getElementById(“texto”).value += keychar;
setTimeout(“document.getElementById(‘texto’).focus();”, 1);
}
</script>
<body onload=document.getElementById(‘texto’).focus()”>
Escreva algo aqui:<br>
<input type=“text” onkeydown=“change_focus(event)”
id=“texto”><br><br>
<iframe src=http://www.google.comwidth=“80%” height=60%”
id=“google”></iframe>
</body>
</html>

Esta página contém uma caixa de texto e um frame que carrega a página de busca do Google. Quando é carregada, o evento onload da tag body coloca o foco na caixa de texto chamada texto. e quando o usuário pressiona qualquer tecla, a função change_focus() é chamada através do evento onkeydown. Primeiro, essa função pega o código da tecla pressionada e busca o caractere correspondente através da função String.fromCharCode().

Note que nesta versão simplificada nenhuma tentativa é feita para saber qual tecla foi pressionada e se a letra era minúscula ou maiúscula. Após detectar a letra, a função muda o foco para o frame, visando que a letra digitada seja assim colocada. Antes de finalizar, a função ainda envia uma cópia da letra digitada para a caixa de texto da página principal e agenda uma mudança de foco, que é feita quase que imediatamente.

Indo além do WebKit

Inicialmente Zaleswki pensou que a falha afetava apenas o WebKit, mas depois percebeu que o mesmo problema ocorria no Firefox 3.6 [3], o que foi corrigido pela equipe responsável com o lançamento da versão 3.6.4, que adicionou verificações para bloquear a mudança de foco durante eventos iniciados pelo usuário. O problema também foi corrigido no WebKit, e não afeta o Safari a partir da versão 5.0 [4] assim como os navegadores Internet Explorer e Opera, que implementam mecanismos para impedir a aplicação do strokejacking [5].

O pessoal do Attack and Defense Labs também demonstrou, em abril de 2010, uma exploração engenhosa de uma vulnerabilidade de XSS especial usando strokejacking [6]. Nós preparamos uma demonstração mostrando como habilitar o encaminhamento de email para usuários do Hotmail, que foi testada no Firefox 3.6.3 rodando sobre um Windows XP SP3. Usamos strokejacking para preencher o campo com o email do atacante e clickjacking para forçar o clique no botão “Salvar”.

Um detalhe interessante é que a página de encaminhamento de email do Hotmail não coloca o foco na caixa de texto do email quando é carregada, diferentemente da página de busca do Google. Para lidar com isso, induzimos o usuário a clicar no campo, colocando-o transparente por cima da mosca. Depois de cinco segundos, criamos um campo para preenchimento de texto na página maliciosa , filtrando as letras digitadas pelo usuário, selecionando apenas aquelas que formam o email do atacante e redirecionando-as para a página do Hotmail.

Ao mudarmos o foco da caixa de texto da página maliciosa para o frame, automaticamente este irá para a caixa de texto do email, pois esse foi o último componente a ter o foco dentro do frame.

Conclusões

Caso você ainda esteja se perguntando: “Bom, para que usar strokejacking se eu posso simplesmente ocultar a caixa de texto que aparece dentro do frame, colocando-a totalmente transparente por cima de uma caixa de texto visível na página principal, da mesma forma como é feito com os botões na técnica clickjacking?”.

A resposta é que quando você somente inclui o campo, você deve fazer o usuário digitar exatamente o texto esperado pela página alvo carregada no frame, o que no exemplo do encaminhamento de email seria equivalente a induzir o usuário a digitar diretamente o email do atacante. Com o strokejacking, o atacante pode pedir que o usuário digite teclas em uma ordem aparentemente sem qualquer relação com um endereço de email e filtrá-las para montar o email desejado.

Além disso, Zalewski publicou em seu blog [7], em junho de 2010, que a técnica poderia ser usada de outra forma. Um frame malicioso colocado em uma página legítima poderia tirar o foco desta durante todo o tempo, mas devolver o foco em certos momentos para manter o cursor na página legítima, copiando todos os dados digitados pelo usuário. A prova de conceito apresentada funcionava apenas no WebKit, mas Zalewski diz que o ataque pode ser executado no Internet Explorer de uma forma mais limitada.

Apesar das falhas que possibilitaram o desenvolvimento da técnica strokejacking já estarem corrigidas, é importante lembrar que nem sempre estamos com os navegadores devidamente atualizados e podemos ficar expostos ataques desta natureza. Além disso, novas falhas podem ser descobertas no gerenciamento de eventos dos navegadores e poderão ser usadas para habilitar o strokejacking.

Sobre o Autor

Gabriel Quadros começou a estudar segurança da informação em 2003, com interesse principal em engenharia reversa, pesquisa de vulnerabilidades e desenvolvimento de exploits. Atualmente cursa o último ano do Bacharelado em Ciência da Computação na Universidade Estadual do Sudoeste da Bahia – UESB e atua na Conviso IT Security como pesquisador do Conviso Security Labs. Pode ser contatado pelo e-mail gquadros@conviso.com.br.

Originalmente postado no Blog da Conviso Application Security – Siga-nos no Twitter @conviso Google+

Tags

Deixe uma resposta

Seu endereço de e-mail não será publicado.

topo