DEFCON 20: "Blind XSS"

Nessa palestra, o Adam Baldwin mostrou alguns casos de Cross-Site Scripting1 em que o script invasor fica latente por dias, semanas ou mesmo meses no banco de dados ou retaguarda dos sistemas web antes de darem o efeito desejado – que em geral ocorre quando algum usuário privilegiado acessa alguma funcionalidade que executa o script latente no seu navegador, viabilizando ataques de sequestro de sessão ou algo do tipo.

O palestrante usou o seguinte exemplo: acessando o site-vítima como usuário normal, não-privilegiado, ele colocou scripts-isca em tudo quanto é campo de formulário que encontrou. O site tinha uma funcionalidade de chat com a equipe de suporte e, dias depois, conseguiu induzir um dos atendentes de suporte a escalar um chamado para o seu supervisor. Ao acessar a página do chamado, o supervisor, que tinha poderes de administrador no site, visualizou o campo de formulário onde estava o script-isca, fazendo que ele fosse executado no navegador e, assim, exportando o cookie de sessão para o site do atacante, viablizando o sequestro da sessão.

Aqui o autor usou o termo "blind" no sentido que o atacante joga a isca meio às cegas, sem ter nenhum feedback razoavelmente imediato se funcionou ou não – e, na realidade, apenas uma esperança meio vaga de que talvez possa vir a funcionar em algum ponto no futuro. Por isso, o palestrante arguiu, a perseverança é essencial par o sucesso: é preciso jogar a maior quantidade de iscas e deixar o site de pescaria no ar indefinidamente.

Nessa linha, o autor apresentou um site/ferramenta chamado xss.io (ainda fechado para o público, até o momento em que este artigo foi para publicação) que ajuda a gerar as iscas (gerando identificadores únicos para se saber de qual campo do site ele veio), identifica o site automaticamente pelo cabeçalho HTTP Referer, permite configurar o comportamento do redirect e salvar toda a requisição HTTP, inclusive, naturalmente, os preciosos HTTP Cookies que normalmente contêm os tokens de sessão. Senti falta de alguma funcionalidade para manter a sessão viva, mas não sei dizer se a ferramenta não tem ou se o apresentador apenas não teve tempo de mostrar.

O Aldo, que estava junto comigo assistindo a palestra, surrurrou um "Ah, blind XSS é só isso? Isso a gente já faz desde 2004!" Quando fomos jantar, engajamo-nos numa tremenda discussão filosófica sobre se todo "XSS" não é "blind", porque raramente o feedback é imediato. Aquiescemos reconhecendo que há casos e casos, dependendo do site específico, da popularidade da funcionalidade onde se planta a isca, o tipo de escalação de privilégio desejado (horizontal ou vertical) e concordando que,  em certos casos, pode levar semanas mesmo, como o palestrante disse. Nesses casos, o site dedicado, que fique no ar meses ou anos a fio, é muito melhor que as várias soluções "ad-hoc" (para não dizer "gambiarrescas") que fizemos ao longo do anos.

Apesar de eu ter gostado da ferramenta do cara, é claro que lá na Tempest não poderemos usá-la para nada que envolva nossos clientes: os Referers os identificariam , o que seria uma violação dos acordos de confidencialidade se a retaguarda estiver hospedada em um site fora do nosso controle – que é exatamente o caso do xss.io. Mas podemos usar o site dele como inspiração para criar o nosso próprio. (:

Enfim, mesmo tendo a palestra ter sido básica e sem nenhuma técnica nova, gostei da ferramenta e apresentação foi sóbria, direta ao ponto e bem humorada.



1 Que eu continuo dizendo que é um nome infeliz para "injeção de HTML/JavaScript" [ voltar ]

Partes anteriores

Próximas partes

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.