Enquanto projetos, como o que mostrei neste post, deixam claro que há muitos recursos a serem explorados para encontrar o endereço IP real do usuário, outros, como o que falarei hoje, buscam a plena navegação anonima.
O questionamento em cima disso tudo é um só: Mas será que é possível navegar sem deixar deixando mínimos rastros?
Perdoe-me por estragar sua excitação pelo post mas… não, ainda não foi encontrado algo que possa desbancar os resultados apresentados por sistemas que usem Onion routing (ou pra ser mais direto, o Tor). Mas este termo merece nossa atenção.
Usando o princípio do Cross-Site Scripting (XSS) (carregar um payload em Java Script no navegador da vítima), a idéia do Cross-Site Scripting Anonymous Browser é, basicamente, usar esta interação para forçar a vítima a fazer requisições solicitadas pelo “hacker”, retornando o conteúdo do site desejado.
Apesar de não ser um assunto novo, já que há uma publicação de Fevereiro de 2005 que já fala de “XSS-Proxy” ( http://xss-proxy.sourceforge.net/Advanced_XSS_Control.txt ), o assunto é ainda discutido, e acredito que devem surgir ferramentas baseadas nesta teoria em breve.
Para obter o código HTML de um site, o Java Script após carregado no navegador da vítima cria um Iframe, e nele carrega o site solicitado. Após carregado, seu conteúdo é lido (usando InnerHTML), codificado (para transmissão via GET) e enviado, também por uma chamada em iframe, a um script que retornaria ao “hacker”.
Para facilitar as solicitações, o projeto XSS Tunnel e XSS Shell foram criados. O primeiro é um servidor proxy customizado, e o segundo é um gerenciador de “vítimas” (pessoas com o payload carregado). Nas configurações do XSS Tunnel, é possível especificar uma das vítimas, defini-lo como proxy em um navegador e navegar normalmente. Estes projetos tem como finalidade apenas demonstrar a técnica. Infelizmente, ano passado os testei, mas não tive bons resultados. Mais detalhes sobre estes projetos podem ser vistos em http://labs.portcullis.co.uk/application/xssshell/.
Apesar de ter permanecido um bom tempo sem grandes novidades, o XAB (Cross-Site Scripting Anonymous Browser) foi tema da palestra de Matthew Flick na Black Hat DC 2009. Seu paper pode ser baixado clicando aqui (recomendo!).
Nele, Matthew lista as maiores dificuldades existentes hoje para tornar esta idéia funcional:
O paper de Flick possui teorias interessantes para tentar chegar mais perto de driblar estes problemas, como, no caso do primeiro item, o uso de dns spoofing.
Por fim, o XAB, apesar de não ser recente, é hoje um desafio aos pesquisadores de segurança de WebApps, e merece nosso estudo.
E você, teria alguma solução ou idéia para torna-lo funcional?
Espero ter dado uma devida apresentação ao termo. Seguem links onde podem ser obtidas maiores informações:
Links:
http://www.blackhat.com/presentations/bh-dc-09/Flick/BlackHat-DC-09-Flick-XAB-wp.pdf
http://labs.portcullis.co.uk/application/xssshell/
http://xss-proxy.sourceforge.net/
Até a próxima 
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
Como bem diz o post, as enormes limitações nas técnicas atuais ainda tornam o uso real muito pouco prático, estável e durável, já que basta a vítima fechar o browser pra derrubar a conexão do hacker – se bem que esse último problema é o mais fácil de resolver, bastando que um gerenciador de proxies troque de vitima automaticamente e torne toda a operação transparente e suave para o atacante
Mas até lá, as melhores opções pra quem quer uma nevegação relativamente anônima ainda serão instalar proxies em máquinhas “ownadas”, explorar squids mal configurados ou mesmo usar esses free web proxies da vida.
[]‘s
No meu ponto de vista, penso que esse problema não se limita só a browsers como disse o K-max ai em cima, que basta a vitma fechar o browser e encerra o controle do hacker. Claro que está certo, a tecnica por cross-site scripting é no browser. Mas não é dificil o hacker ter um pouco de imaginação pra avançar para otros lugares do computador, não sendo só o browser.
A proposito, K-max você frequentava uma comunidade no orkut chamada Bugs no orkut?
obs: Pato, continue assim, estou acompanhando fielmente tudo, e gostando bastante. Espero por mais videos. parabens!
@K-Max e Renan. Obrigado pelo comentário!
Eu penso um pouco diferente de vocês. Acho que solucionando o problema de obter imagens e outros objetos que não sejam transmitidos como texto isso passa a ser útil. Vocês tocaram em um ponto que eu concordo, também: O fato de a vítima, ao fechar o navegador, cortar nossa conexão é sim importante. Mesmo tendo uma lista grande de zumbis com um XSS, e trocando de vítima facilmente, lembre-se que por se tratar de navegação feito pelo navegador da vítima, é ela quem está com o cookie e com o id da session. Em outras palavras, sua sessão atual expiraria. Não daria pra continua-la.
O renan tocou em outro ponto bacana. XSS ocorre em tudo que interpreta html\js… descobrindo uma falha em algum programa que o usuário praticamente deixe aberto, traria xss-proxys mais “estáveis” e “duradouras”. (Um exemplo de uma situação destas eu postarei em alguns dias aqui no blog, sobre uma falha que estou reportando hoje.)
Novamente, obrigado pelos comentários e elogios.
Abraços.
(descobrindo uma falha em algum programa que o usuário praticamente deixe aberto, traria xss-proxys mais “estáveis” e “duradouras”) podemos citar o winamp por exemplo, um programa que fica aberto por um bom tempo pelo menos em minha casa. hehehehe
É verdade, Renan.. já pensou uma falha que abra algo ali na Media Library do Winamp, que renderiza html? Funcionaria bem neste caso…
Pato, se não me engano, tem uma versão do winamp que rola um xss naquelas tags dos nomes das musicas. Só não sei bem onde é exatamente, mas depois da uma olhada mais a fundo nisso que você axa.