Possível tendência para realização de ataques: 'Phishing sem websites'

Recentemente foi publicado um novo artigo que descreve uma técnica para a realização de ataques de Phishing Scam sem a necessidade de hospedar a página do phishing em servidores web, utilizando o URI (Uniform Resource Identifier) data: e o "encurtador de URLs" TinyURL.com.

O título do artigo analisado é "Phishing by data URI" (de autoria do Henning Klevjer) e pode ser acessado na URL listada a seguir:

Embora este artigo descreva um ataque cujas contramedidas ainda nos parecem pouco efetivas, acreditamos que a comunidade de segurança da informação e os leitores do blog em geral ganhem mais sabendo que ele existe e como funciona que ignorando essas informações.

É importante comentar que o ataque utilizando links/URIs não é novo, sendo conhecido pelo menos desde 2007, onde foram realizados ataques semelhantes contra os navegadores Internet Explorer 6 e 7 (conforme descrito neste artigo).

O grande diferencial do novo artigo ("Phishing by data URI") publicado, entretanto, é o fato do autor ter demonstrado a utilização do "encurtador de URL" TinyURL.com para inserir os dados contidos no URI data:.

Entre outros benefícios para o atacante, a utilização de um encurtador de URL torna mais fácil o envio de um link curto tradicional (ou seja, que utiliza o URI http://). Essa característica torna mais fácil a disseminação do conteúdo malicioso e mais difícil a detecção do ataque por parte das vítimas.

ALERTAS

É importante ressaltar desde já que esta técnica pode vir a se tornar uma "tendência" para realização de ataques de Phishing Scam.

Essa possibilidade existe uma vez que a utilização da nova técnica pode dificultar sensivelmente a realização de takedown (retirada de operação) de conteúdo de Phishing Scam, bem como tornar virtualmente impossível que os navegadores web consigam alertar os usuários sobre o acesso a conteúdo possivelmente fraudulento.

As vantagens imediatas dessa técnica em relação ao envio de Phishing Scam tradicional (hospedado em servidores web) podem ser resumidas conforme descrito a seguir:

  • Não há mais necessidade do atacante hospedar suas páginas de Phishing Scam em um servidor web confiável (seja ele um servidor de propriedade do atacante ou que tenha sido previamente invadido):

Uma conseqüência imediata é que as empresas afetadas pelos ataques de Phishing Scam não podem realizar o takedown dessa "página", uma vez que o conteúdo malicioso não está hospedado na Internet.

  • Os navegadores web, até o momento, não têm como detectar e alertar o usuário que o conteúdo inserido dentro de um URI data: é um provável ataque de Phishing Scam.

Isto não será possível em virtude do conteúdo não estar armazenado em uma URL localizada na Internet (http://, por ex.), as quais são verificadas pelos navegadores web contra blacklists de Phishing Scam atualizadas rotineiramente.

DESCRIÇÃO DA VULNERABILIDADE

O URI data: foi concebido originalmente para possibilitar a apresentação de mídia/conteúdo em navegadores web sem a necessidade deste conteúdo estar hospedado em servidores na Internet. Existem muitos propósitos legítimos para essa funcionalidade, tais como, entre outros, o download de conteúdo decodificado/decifrado dinamicamente através de páginas HTML ou o envio de qualquer conteúdo dentro do próprio link/URI data:

Apesar dos propósitos legítimos, a vulnerabilidade reside justamente no fato de que conteúdo HTML também pode ser enviado dentro de um link/URI data:, fazendo com que o navegador renderize este conteúdo como uma página HTML que estivesse hospedada normalmente em um servidor web na Internet.

O formato geral de um URI data: está listado a seguir:

data:[<mediatype>][;base64],<data>

Onde [mediatype] é o tipo de mídia que se está transmitindo. Esse tipo pode ser, entre outros, text/plain e text/html, opcionalmente codificados pelo algoritmo base64.

Um exemplo de conteúdo text/plain (sem codificação base64) está exibido a seguir:

data:text/plain;,hello

O mesmo conteúdo ("hello") em formato text/plain pode ser codificado em base64, conforme ilustrado a seguir:

data:text/plain;base64,aGVsbG8=

Caso os links/URIs data: listados acima sejam digitados (ou 'copiados e colados') na barra de endereços do seu navegador web, será exibido o texto "hello".

Como pode ser percebido, seria trivial inserir (em formato text/html) uma página HTML completa simulando, por exemplo, o website da instituição atacada. A codificação base64 poderia ser utilizada apenas para "ofuscar" que o verdadeiro conteúdo sendo acessado é uma página HTML.

A seguir, é exibido um screenshot de um exemplo de conteúdo HTML codificado em base64 que foi extraído do artigo "Phishing by data URI":

Como pode ser visto em um dos destaques em vermelho na figura acima, o conteúdo do link/URI data: foi codificado em base64. Após ser copiado e colado na barra de navegação, o navegador web Mozilla Firefox renderizou e exibiu o conteúdo HTML, que simulava a página web de logon da Wikipedia.

Nos outros destaques em vermelho, é possível perceber que a senha fornecida no formulário de logon do usuário foi capturada por código JavaScript e exibida na tela do usuário. O usuário e senha fornecidos, entretanto, poderiam ter sido enviados para um servidor sob controle do atacante.

Esse servidor, entretanto, seria responsável apenas por "receber os dados" das vítimas do ataque, tornando a possibilidade de takedown (retirada de operação) muito mais difícil de ser realizada, em virtude de não estar sendo hospedado nenhum conteúdo malicioso propriamente dito.

Além disso, existe a possibilidade de que os fraudadores viessem a utilizar scripts para realizar o envio dos dados da vítima através de conexões TCP arbitrárias, do protocolo SMTP ou mesmo através de simples requisições DNS "especialmente configuradas" para transferir os dados da vítima dentro da própria requisição em si. A utilização dessas técnicas poderia tornar ainda mais difícil o processo de takedown dos servidores utilizados pelos atacantes.

OUTROS CENÁRIOS DE ATAQUE

Uma outra possibilidade analisada pela equipe da Tempest (proposta pelo Michal Zalewski e descrita aqui) é a utilização de um URI data: sem codificação base64, porém com vários espaços inseridos entre o início dos dados e o conteúdo malicioso em si, em conjunto com a utilização de Unicode homographs para "forjar" determinados caracteres.

Um Proof of Concept disponibilizado por Zalewski foi ligeiramente adaptado pela Tempest e pode ser acessado na URL listada a seguir:

OBS: O mesmo ataque exemplificado nesta URL poderia ser disparado através do envio de e-mails tradicionais de Phishing Scam, onde bastaria que a vítima 'clicasse' no botão contido no corpo do e-mail.

A seguir, é exibido um screenshot após o acesso à URL acima e clique no botão "Show me the thing":

Como pode ser visto no destaque em vermelho na figura acima, a URL começa com o URI data: mas logo em seguida possui a string https:// (na verdade, os caracteres "/" são homógrafos Unicode, ou seja, caracteres bastante semelhantes ao caractere "/" original).

Pra piorar, é exibido um cadeado na imagem "favicon.ico", o que tende a fazer com que mais usuários se tornem vítimas desse ataque, acreditando que estão realmente visitando o website https://www.bancoxyz.b.br/.

Isto poderia acontecer porque a página/conteúdo exibido aparenta possuir vários identificadores de segurança (que, na verdade, são falsos):

  • Utilização do protocolo https;
  • Ícone do cadeado;
  • Domínio .b.br de sua instituição financeira.

Tal como descrito na URL contendo o Proof of Concept, esse ataque funciona melhor contra o navegador Mozilla Firefox e o Opera, mas também pode ser implementado com alguma eficácia contra o Internet Explorer.

Vale lembrar, entretanto, que isto é apenas uma extensão da realização de ataques de Phishing Scam sem a necessidade de hospedar a página do phishing em servidores web, conforme descrito ao longo desta publicação. O ataque utilizando o link/URI data: sem utilização de homógrafos Unicode funciona contra o Mozilla Firefox, Opera, Chrome e Safari, e pode ser implementado (utilizando outro URI) contra o Internet Explorer.

CONCLUSÕES

Através da utilização do link/URI data:, é possível a realização de ataques de Phishing Scam com as seguintes vantagens sobre os ataques tradicionais:

  • Não há mais necessidade do atacante hospedar suas páginas de Phishing Scam em um servidor web confiável (seja ele um servidor de propriedade do atacante ou que tenha sido previamente invadido):

Uma conseqüência imediata é que as empresas afetadas pelos ataques de Phishing Scam não podem realizar o takedown dessa "página", uma vez que o conteúdo malicioso não está hospedado na Internet.

  • Os navegadores web, até o momento, não têm como detectar e alertar o usuário que o conteúdo inserido dentro de um URI data: é um provável ataque de Phishing Scam.

Isto não será possível em virtude do conteúdo não estar armazenado em uma URL localizada na Internet (http://, por ex.), as quais são verificadas pelos navegadores web contra blacklists de Phishing Scam atualizadas rotineiramente.

  • Conforme descrito na seção "OUTROS CENÁRIOS DE ATAQUE", outros tipos de ofensivas podem ser realizados contra os navegadores Mozilla Firefox e Opera, que tornam ainda mais fácil fazer com que usuários acreditem que estão visitando um website legítimo quando estão, na verdade, acessando conteúdo fraudulento que sequer está hospedado em servidores web.

Comentários
Aceita-se formatação à la TWiki. HTML e scripts são filtrados. Máximo 15KiB.

 
Enviando... por favor aguarde...
Comentário enviado com suceso -- obrigado.
Ele aparecerá quando os moderadores o aprovarem.
Houve uma falha no envio do formulário!
Deixei uma nota para os admins verificarem o problema.
Perdoe-nos o transtorno. Por favor tente novamente mais tarde.
Renato Campachi | 2012-10-08 18:31:17 | permalink | topo

Já é!

http://blog.detectify.com/post/32947196572/universal-xss-in-opera

Tímido Visitante Anônimo | 2012-09-23 22:06:38 | permalink | topo

Bem bolado!