Session Fixation - El poderoso desconocido

Bueno, hace tiempo que no escribo nada para el foro y.. estube viendo que nunca aporte nada en defacing. En parte, nunca aporté nada pq no es lo que más me apasiona. Decidí escribir sobre esto pq poco y nada se habla y es una tecnica poderosa... ok, no tanto como sql inject o rfi, pero es muy util a la hora de vulnerar un objetivo concreto saber mas que las 2 tecnicas antes nombradas.

##### desde acá empiezo el texto, los comentarios tontos los pongo con "#" xD

Session Fixation Atacks

By MurdeR - www.thefreeks.com.ar

Session:

Las sesiones no son más que una "asociacion" entre el host y el cliente. Para no tener que estar recordando todo el tiempo la contraseña via html, se utiliza un sistema simple que consiste en asociar una cuenta con un numero "ID" y almacenando por un lado en temp y por otro en las cookies dicha sesion, posterior y constatemente el server comprueba que los numeritos coincidan hasta que finaliza la sesión y se destruye.
Hay muchos ataques destinados a obtener esos hermosos numeros aleatorios, los más comunes son tan simples como la fuerza bruta o la intercepción (via xss normalmente) y los mas complejos, los session fixation.

Session Fixation:

Este ataque consiste en establecer el numero de id antes de que el administrador se identifique, así luego no seria necesario obtenerlo-- pq seria el previamente establecido. Es sencillo, si le vendo una alarma a un señor y yo elijo el codigo, para mi no sería un problema hackearlo :D.. algo similar.
La mecanica del ataque varía según el sistema que utilice la aplicación web objetivo, normalmente es posible encontrarse con campos ocultos en los formularios, cookies o argumentos en la url.
Un ejemplo de una cookie en smf 1.1.2 es el siguiente:

PHPSESSID dac203acc5aeef19708c9ec19984c31e xxxxx.com / at end of session

Obviamente el id es "dac203acc5aeef19708c9ec19984c31e" y teniendo eso cargado en las cookies, tendremos total control de la cuenta.
Analizando un poco el funcionamiento del sistema (de smf..) se puede notar que el numero id se crea y carga como una variable que se pasa al server via url:

www.diosdelared.com/index.php/action=login&PHPSESSID=ads234sfd5dgf19708c9ec19984c345

Si enviaramos ese enlace a zeus, y el se identificara (bueno... y si este foro fuera smf 1.1.2), la sesión se crearía con su numero de ID.
Entonces solo faltaria crear una cuenta en este foro, identificarse, editar las cookies y cambiar el numero ID. Voilá ya estaría defaceado el foro xD.

En el ejemplo el numero se puede predefinir como un argumento en la url, lo cual es muy facil y a la vez muy cantoso. Tambien se puede dar que el id se cargue como un campo hidden en un form, en este caso sería necesario imitar la pagina de logon y alterar dicho campo, algo más complicado y que requiriía (aun más) ingenieria social.
En caso de que la session se cargue directamente en las cookies, es un poco más complicado. Hay (que yo sepa) dos formas de crear una cookie falsa a un cliente:
Via side-script (jscript..) o via el meta tag Set-Cookie. Paso a explicarlos:

Cross side scripting:

Suponiendo que tenemos un sistema que es vulnerable a session fixation y que encontramos una vulnerabilidad de XSS no sería necesario armar un sofisticado y lento proseso para robarle las cookies, podriamos crear una simple linea que creara la session falsa y usarla al instante.
En js tenemos la funcion document.cookie que permite crea numeros de id. Si www.diosdelared.com fuera vulnerable a algun xss solo tendriamos que hacer:

http://www.diosdelared.com/.sda

Conseguir que el administrador entre en esa url y ejecute el script es tan sensillo como enviar un enlace www.thefreeks.com.ar con un iframe a esa url y espera a que este entre :)

Una buena idea sería ponerle una fecha de expiración larga, por ejemplo el año 2099:

http://www.diosdelared.com/.sda

Así tendriamos control de la cuenta robada hasta muy viejos...

HTML Meta Injection:

Con html, la meta tag Set-Cookie tambien nos posibilita crear una sesion:

meta http-equiv=set-Cookie content="sessionid=asdasd123123"

Si tenemos una web que por casualidad es vulnerable a xss pero que tiene controlado el uso de < script > se puede intentar injectar el meta directamente:

http://www.diosdelared.com/< meta http-equiv=set-Cookie content="sessionid=asdasd123123" >.com

De esta forma obtendriamos el mismo resultado que en el caso anterior.


Otras ideas... DNS Poisoning :) mi muy mas que favorito.

Esto da para hacer otro post, es más, quizas lo haga... la idea es lograr penetrar en el server dns, añadir un registro en el dns a por ejemplo www.diosdelared.com que apunte a un servidor del atacante.
Luego poner en dicho servidor una web exactamente identica a la original y que solicite la identifiacion del usuario para luego hacer un redirect a la web original.


Espero haberme explicado con mas o menos claridad. Es un tema complicado y seguramente quedarán dudas. Si metí la pata en algo, diganmelo y lo corrijo.

Salu2 MurdeR^^

Insecure Cookie Handling

Tutorial realizado por InyeXion sobre Insecure Cookie Handling (inseguridad en el manejo de cookies) en realidad lo hizo porque no vio en la red un solo tutorial referencial a esta vulnerabilidad, asi que espera que se entienda y sino cualquier cosa preguntenle! (jajajajajaj)

Insecure Cookie Handling

#Explicación#

Insecure Cookie Handling (inseguridad en el manejo de cookies) esta vulnerabilidad la vemos cada ves mas en sitios de seguridad web(Seguridad en apps webs..), pero hay muchos que todavía no saben de que se trata, no saben como explotarla o no la entienden por diferentes motivos..., espero solventar las dudas que tengan con este tutorial.

Esta vulnerabilidad depende del perfil en la que la veamos puede parecer tonta o ingeniosa. Tonta diría por la forma en la que los programadores administran las cookies para restringir la sección de los usuarios no autorizados, e ingeniosa por la forma que los atacantes burlan la verificación...

Cookies: Las cookies forman parte del protocolo HTTP, este protocolo se usa para intercambiar mensajes entre el servidor y el cliente utilizando solicitudes y respuestas HTTP. El encabezado HTTP reservado para el uso de las cookies se denomina

Set-Cookie. Está compuesto por valores:

Set-Cookie: nombre=valor; domain=nombre de dominio; expires=vencimiento de la cookie; path=ruta donde la cookie sera validada; secure

Ejemplo:

Set-Cookie: admin=1; domain=www.web.com; expires=Friday, 2-Feb-2009 00:00:00 GMT; path=/; secure

Secure: Solo se usa si la cookie es enviada por conexion segura (SSL) y es opcional.

#Explotacion#

La explotación es muy fácil, creo que muchos ya se la están imaginando..., pondremos algunos ejemplos.

if(isset($_COOKIE['admin']) && $_COOKIE['admin'] == 1)
{
echo "Bienvenido a la administración...";

}else{

echo "No estas autorizado";

}
?>


En este caso tendríamos que crear una cookie con el valor 1. Lo haremos en JavaScript pero se puede hacer con un plugin de Firefox o cualquier herramienta, el objetivo es crear la cookie. Entonces ingresaremos en el sitio y previamente ponemos en la barra del navegador...

javascript:document.cookie="admin=1; path=/";


Ahora entramos nuevamente al login y tendrás acceso a la administración en este caso...

Otro ejemplo:
if($_COOKIE['user'] == 1 && $_COOKIE['pass'] == 1)
{
echo "Autorizado";
}else{
echo "No autorizado";
}
?>


Como en el caso anterior entramos a la web e insertamos..

javascript:document.cookie="user=1; path=/"; document.cookie="pass=1; path=/";

Ahí creamos 2 cookies la cual sirven para pasar la verificación. Entramos nuevamente a la web siendo ya autorizado.

Vamos con el ultimo ejemplo:

?

$user = md5(base64_encode("admin"));

if($_COOKIE['usuario'] == $user && $_COOKIE['pass'] == 1)
{
echo "Administración";
}else{
echo "Acceso Incorrecto";
}?>


Bueno hay que explicar unas cositas de este ejemplo, primero tenemos que saber como sacar el nombre del usuario para que posteriormente podamos encriptar primero en base64 y después en md5, como no somos magos como para adivinar el usuario tenemos que usar la lógica... bien puede ser un nombre de usuario por default (como admin, administrador etc..) o sino nos podemos fijar quien postea en la web, en la mayoria de los CMS dice el usuario que posteo. Supongamos que tiene como usuario "admin" (como el script de arriba) entonces encriptamos el usuario para que podamos crear la cookie con ese valor como muestro abajo:

javascript:document.cookie="usuario=db69fc039dcbd2962cb4d28f5891aae1; path=/"; document.cookie="pass=1; path=/";


#Posibles Soluciones#

Podemos utilizar cookies pero manejarlas de la forma correcta para que no puedan bypassear la verificación, con manejarla de la forma correcta me refiero a que no hagan una verificacion estatica, que sea dinamica depende del administrador, ejemplo que en la cookie guarde un usuario(elejido por el admin previamente) y la contraseña codificadas, entre otras posibilidades...
Tambien podemos combinar verificaciones ejemplo cookies y sessiones, queda a imaginacion de uno de como armar la verificacion siempre y cuando este seguro que la verificación sea segura...


#Links#:

https://addons.mozilla.org/addon/3829 <-- Live HTTP Headers 0.14
https://addons.mozilla.org/es-ES/firefox/addon/573 <-- Add N Edit Cookies 0.2.1.3



Autor: InyeXion
Web: Www.inyexion.net - Www.inyexion.com.ar




PDF - HTML

Saludos! Inyexion :P