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^^