FHTTP + Shodan = Proxy List :P

Cazando proxy list con Shodan y FHTTP

Primero necesitamos agregar el soporte para shodan:

https://sourceforge.net/projects/fhttp/files/Extra/

se bajan los modulos en la carpeta del FHTTP y esa es toda la instalacion.

Tambien tenemos un ejemplo usando ese modulo:

http://sourceforge.net/projects/fhttp/files/Extra/Examples%20-%20Shodan/finder.pl/download

Vamos a usar ese script.
Pero antes vamos a explicar un poco el funcionamiento, no del modulo de shodan, del script.

Inicializamos:

my $shodan = shodan->new();

$shodan->login($user,$password);

como tal no es necesario logearse, pero lo hacemos para que de mas resultados (mas de 1 pagina).

y buscamos:

my @tmpenlaces = $shodan->buscar($busqueda,$page);

$page es el numero de pagina que queremos que nos retorne.

($proto,$host,$hostheader,$path,$puerto) = &tools::parseurl($enlace);

$sock = IO::Socket::INET->new(PeerAddr => $host,

	PeerPort => $puerto,

	Timeout => 1,

	Proto => 'tcp');

if(!$sock) {

	$i = 2;

	$down++;

	next;

}

Parseamos los enlaces y armamos un socket, en caso de que falle lo registramos como "caido".

$maketunnel = tools::maketunnel($sock,$hosttest,$porttest,0,0);

Nota: los dos ultimos valores son: debug (0 o 1) y version (version de HTTP)

Intentamos crear un tunnel HTTP (mediante "CONNECT"), tools lo hace todo automatico para nosotros ;)... $maketunnel sera 1 si se creo correctamente, 0 si no y 2 si hay un 404 (que esta tomando CONNECT como GET y puede ser un honneypot :P).

De otro modo cerramos el socket, no nos sirve bajarnos a ese nivel para probar un proxy normal.

$paquete = http->new("GET","http://".$hosttest.(($puerto != 80 ) ? (":".$puerto) : "")."/","1.1");

$paquete->agregarencabezados(0,@encabezados);

my %resp = $paquete->enviar($host,$puerto);

Usamos el generador de peticiones (http.pm) y finalmente lo demas es cosa de checar los encabezados/contenido y determinar si el proxy hizo la conexion correctamente (para eso se usa el argumento regex).


Ahora a jugar...

linux-7nli:/home/xianur0/fhttp-v1.3 # perl finder.pl squid "" "" google.com 80 Google

Comprobando dependencias...

Felicidades: FHTTP funcionando al 100%!

Tunnel: google.com:80

Target: 9

[x] No se puede crear el tunnel: HTTP/1.0 403 Forbidden!

[x] No se puede crear el tunnel: HTTP/1.0 403 Forbidden!

[!] Proxy HTTP: 209.xxx.1x1.xxx:xx

[x] No se puede crear el tunnel: HTTP/1.0 400 Bad Request!

[x] No se puede crear el tunnel: HTTP/1.0 400 Bad Request!

[!] Proxy HTTP: 222.xxx.1x1.xxx:xxx

[x] No se puede crear el tunnel: HTTP/1.1 501 Not Implemented!

[x] No se puede crear el tunnel: HTTP/1.1 501 Not Implemented!

[x] No se puede crear el tunnel: HTTP/1.0 403 Forbidden!

[x] No se puede crear el tunnel: HTTP/1.0 403 Forbidden!

[!] Proxy HTTP: 189.xxx.x68.xxx:xxx

[x] No se puede crear el tunnel: HTTP/1.0 403 Forbidden!

[x] No se puede crear el tunnel: HTTP/1.0 403 Forbidden!

[!] Proxy HTTP: 186.xxx.2x2.xxx:xxx

[x] No se puede crear el tunnel: HTTP/1.0 407 Proxy Authentication Required!

[x] No se puede crear el tunnel: HTTP/1.0 407 Proxy Authentication Required!

[x] No se puede crear el tunnel: HTTP/1.0 403 Forbidden!

[x] No se puede crear el tunnel: HTTP/1.0 403 Forbidden!

[!] Proxy HTTP: 203.xxx.1x9.xxx:xxx

[x] No se puede crear el tunnel: HTTP/1.0 403 Forbidden!

[x] No se puede crear el tunnel: HTTP/1.0 403 Forbidden!

[!] Proxy HTTP: 202.xxx.17x.xxx:xxx

[x] No se puede crear el tunnel: HTTP/1.0 403 Forbidden!

[x] No se puede crear el tunnel: HTTP/1.0 403 Forbidden!

[!] Proxy HTTP: 186.xxx.15x.xxx:xxx

Down: 1

Honeypot: 0

CONNECT: 0

Others: 7

FHTTP Cheat Codes

Para los que no estén enterados hoy agregamos soporte multi-idioma a #FHTTP la cual pueden encontrar en el sourceforge oficial: FHTTP.

my @cheats = ("--proxy","--tunnel-http","--proxy-list","--crlf-req","--crlf-res","--verbose","--lang");

Bueno ahí están los "Cheat Codes", vamos desde lo simple a lo complicado:

--crlf-res=CRLF - En este podemos especificar los caracteres que se van a usar en lugar del CRLF en las respuestas del proxy al navegador (por ejemplo: CR sin LF, LF sin CR o LF+CR).
--crlf-req=CRLF - Lo mismo que el de arriba pero en los request's.
--proxy=ip:puerto - El proxy o primer nodo del encadenamiento a usar.
--proxy-list=archivo.txt - El proxy list (solo útil en encadenamientos).
--tunnel-http=1 - Al darle el valor de 1 va a intentar crear encadenamiento (si hay proxy list) o un tunnel simple (usando el valor de --proxy) mediante el metodo CONNECT de modo que es requerido que los nodos especificados soporten CONNECT (y los puertos a usar), otra cosa que hay que tener en cuenta es que se requiere especifica --proxy al realizar encadenamientos es decir, el valor de dicho "cheat code" se utilizara como el primer nodo del encadenamiento y el resto se tomara del proxy-list.
--lang=en - Le decimos que establezca por defecto el idioma en (ingles) o es (español), para agregar mas lenguajes tienen que editar dic.pm (en la versión multi-idioma).
--verbose=0 - Establecemos el modo verboso (solo valido por el momento en el modulo de proxy) en 0, de momento los valores soportados son: 0-3.

Otros "cheat codes" sirven para desactivar o "forzar activar" ciertos módulos del interprete, por ejemplo trabajar sin Gtk2 o sin IO::Socket::SSL o incluso sin soporte para compresiones.

Ejemplo:
perl fhttp.pl no-Gtk2 --lang=en

Por otro lado para volver a activar se quita el no.

perl fhttp.pl Gtk2

Estos últimos cheat's no llevan el "--" y son "recursivos" es decir solo basta agregarlos 1 vez como argumento y se guardara en "config.fhttp" y se usara para la siguiente "ejecución".

Todos estos argumentos se deberán usar después de los argumentos que se le pasan al modulo a usar por ejemplo:

perl fhttp.pl 0 http://google.com.mx/ 0 --lang=en

Dudas o comentarios: xianur0.null[at] gmail.com

Saludos!

FHTTP Hacking - Cap 1

Hey creo que comenzare a necesitar alguien que ayude a traducir las publicaciones por que de ahora en adelante van a ser bastantes y la idea es tener un publico "global" xD...

Vamos a comenzar a tirar algunas ideas un poco extrañas pero que en la practica pueden ser de utilidad.

Convirtiendo la FHTTP en un link spider.

Para que un link-spider? la duda surge... no ya enserio un link spider que pueda ir junto con la navegación del "usuario" (no nos complicaremos con términos xD) puede ser algo interesante, es decir si tienes todo lo que se esta enviando al navegador del usuario no tienes que preocuparte tanto por un armar un sistema que se encargue de desarmar la web como la leería el navegador, es decir si nosotros nos topamos con una web que utiliza ajax para cargar las paginas... o peor aun al weybmaster se le dio por armarla en flash :S... es difícil que un spider común extraiga los enlaces... pero si lo combinamos con un proxy, de un modo u otro vamos a pescar los enlaces que se vayan a cargar :D...

Antes de continuar es recomendable que previamente conocieran el motor avanzado del proxy

Comenzamos:

La FHTTP tiene algunas opciones muy curiosas entre las que se encuentra un simple script para extraer los enlaces, entre las ventajas que tiene dicho script es que corrige path transversal y otras trampas usadas para "saltar" los link spiders, en caso de que eso no sea suficiente pueden editarlo manualmente :P.

sub geturls($html,$proto,$host,$path);

Ese es el "proto" de dicha función, pero realmente nada mas es necesario pasar html, lo demás se usa para auto-completar url's (relativas) y obtener las completas.

Vamos a lo simple:

sub spider {

my $rcontenido = $_[0];

my $paqenvio = $_[1];

my %links = tools::geturls($rcontenido);

while(my ($link,$veces) = each(%links)) {

open LOG, ">reportes.txt";

print LOG $links."\n";

close(LOG);

}

return $rcontenido;

}

Pero si no nos gusta tener solo las url's relativas... podemos jugar un poco mas:

sub spider {

my $rcontenido = $_[0];

my $paqenvio = $_[1];

my @lineas = split(/[\r\n]+/,$paqenvio); # $lineas[0] = req line

my ($method,$url,$version) = split(/\s+/,$lineas[0]);

my ($proto,$host,$hostheader,$path,$puerto) = tools::parseurl($url);

my %links = tools::geturls($rcontenido,$proto,$hostheader,$path);

while(my ($link,$veces) = each(%links)) {

	open LOG, ">reportes.txt";

	print LOG $links."\n";

	close(LOG);

}

return $rcontenido;

}

Pero... aun no siento que sea un spider completo... digo ya extrae los links... pero que hay de las imágenes?

Como saber cuando el navegador esta cargando una imagen y no un enlace?... la forma mas fácil sería tomarla del código fuente como hacemos con los enlaces o no?... pero no quiero, quiero atrapar las imágenes al vuelo :P, siendo un poco mas claro atrapar la consulta a la imagen, no el html que tiene el enlace a la imagen, el por que?, como dije al inicio las webs no siempre van a estar en simple html, también se puede integrar ajax (JS xD) o flash que va a hacer la labor de cargar las imágenes pero sin que nosotros podamos ver en plano la dirección en el código fuente (html) por ello vamos a hacer un pequeño "hack" (por así llamarle) al funcionamiento del navegador, como distinguimos un request a un archivo de texto/html de otro a una imagen?.

Accept: image/*

Al leer ese encabezado con dicho valor... queda bastante claro que la prioridad del navegador es bajar una imagen, desde luego el valor puede variar pero casi siempre comienza de esa forma (image/).

	

sub spider {

my $rcontenido = $_[0];

my $paqenvio = $_[1];

my @lineas = split(/[\r\n]+/,$paqenvio);

	if($paqenvio =~ /[\r\n]+Accept: image\//i) { # buscamos el header

		my ($url) = ($lineas[0] =~ /^\w+([\s\t]+)([^\s\t]+)/); #extraemos la url

		foreach $header (@lineas) { # recorremos los headers

			if(($header =~ /Host:\s+([^\r\n]+)/)) { #buscamos el header host y su valor :P

				$host = $1;

				last;

			}

		}

		if($url !~ /^http/) { # en caso de que no sea una url completa, agregamos lo que falta

			$url = "http://".$host.(($url !~ /^\//) ? "/" : "").$url;

		}

		open IMAGENES,">>imagenes.txt"; # abrimos el log

		print IMAGENES $url."\n"; # guardamos

		close(IMAGENES); # cerramos

	}

return $rcontenido;

}

Desde luego nos falta conectar nuestra función a la FHTTP, tan simple como:

my @rcontenidocallbacks = (

                           rcontenidocall,

                           spider,

                       );

Happy Hacks!

FHTTP MN != Slowloris

Últimamente me preguntan mucho si el modulo MN (DoS Tool) de la FHTTP es lo mismo que Slowloris... y no, no es así xD...

Como funciona Slowloris?

Esta herramienta (desarrollada por RSnake) traba de la siguiente forma:
Cliente -> Servidor (Establece la conexión).
Cliente -> Servidor (Envía parte del encabezado)
Ejemplo:
GET / HTTP/1.1
Host: google.com
x-a: 1
(Espera cierto tiempo y continua)
x-a1: 2
(Espera cierto tiempo y continua)
x-b2: 7
(etc...)

Es decir el servidor esta recibiendo de forma parcial el request, por lo cual se mantiene activa la conexión, slowloris en este caso lo que tiene que hacer es crear múltiples conexiones y hacer lo mismo, de modo que se satura el servidor (tendrá muchas conexiones activas al mismo tiempo).

Desventajas:
Al enviar contenido parcial no es muy factible usar un Proxy HTTP convencional para "esconder" (es decir hacer ligeramente mas difícil que nos localicen xD), debido a que muchos (proxy's) intentan leer todo el request (hasta recibir doble LF/CRLF) de modo que al no terminar de recibir no establece la conexión con el servidor y nuestro ataque se queda en el proxy, y bien pueden DoSear al proxy xD.
Solución: usar una VPN xD...
Ademas esta el hecho de que tu también mantienes un numero igual de conexiones a las que mantiene el servidor.

Como funciona MN?
Que pasa cuando enviamos un GET o un HEAD al servidor?
En el caso del HEAD:

HEAD / HTTP/1.1
Host: destino

HTTP/1.0 200 OK
Date: Tue, 09 Aug 2011 02:51:47 GMT
Server: Apache/2.2.8 (Unix) PHP/5.2.12
X-Powered-By: PHP/5.2.12
Set-Cookie: PHPSESSID=a3afdbf074f0d0ef7a6782962455468d; path=/
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Last-Modified: Tue, 09 Aug 2011 02:51:48 GMT
Content-Type: text/html; charset=UTF-8
Connection: close


Me viene a la mente... y esa cookie?, obviamente no la genero apache, es decir es una "session" PHP, por lo cual quiere decir que PHP esta trabajando al hacer el HEAD... pero no se genera de forma autónoma, por lógica la genero el index, en otras palabras se esta procesando el index (todo para generar los headers), lo cual quiere decir que si no queremos que el servidor nos responda todo el contenido (no gastar nuestra banda) pero que aun así procese el archivo únicamente tenemos que enviar HEAD's.

Pero eso nos basta para denegar un servidor?, lamento decirles que no xD...

Conexiones Persistentes y Pipelining:

Que es exactamente conexiones persistentes?
una conexión persistente o keep-alive quiere decir que podemos realizar varios request en la misma conexión sin cerrarla y volver a establecerla.

Que significa Pipelining?
Significa que podemos enviar múltiples request "concatenados" sin esperar que el servidor nos responda previamente.
Ejemplo:

GET / HTTP/1.1
Host: google.com

GET / HTTP/1.1
Host: google.com

HTTP/1.1 301 Moved Permanently
[...]

HTTP/1.1 301 Moved Permanently
[...]


Como podrán notar nos respondió a las dos consultas que enviamos en el orden que las enviamos, pero después de que nosotros termináramos de enviar todas las consultas.

Lo que va haciendo es como vaya terminando de procesar nos va a enviar las respuestas... o no?, al menos eso debería pero por lo menos apache no lo hace... y no tengo tiempo de listar todos los demás servidores que no lo hacen :P.
A que nos lleva esto?
Enviamos una serie de request concatenados por una sola conexión (pipelining), pero cortamos la conexión antes de que nos termine de responder el servidor.
O bien podemos enviar masivo los paquetes y ver cuantos nos llegan xD...
Pero eso no es todo ;)...
Que le pasa a apache cuando recibe cierto numero de consultas?, despliega hilos, es decir hilos listos para procesar las consultas... pero si el usuario solo realizo una conexión pero envió... digamos 300 consultas... que le pasara a apache? lo que tenemos es que el mismo apache se ahoga en hilos :P

Ah se me pasaba, no es solo cuestión de apache, funciona igual con IIS y una infinidad de servidores web mas... a decir verdad nunca me he encontrado con un servidor que no sea vulnerable... por lo que esto es un problema bastante grave :P...
Como podemos hacer aun mas grande el dolor de cabeza del administrador?
Combinando el potencial :D...

Fastidiando un poco mas:

HEAD /$file HTTP/1.1
Host: $host
User-Agent: Mozilla/5.0
CLIENT-IP: $ipinicial
X-Forwarded-For: $ipinicial
If-None-Match: ThisWebSuck!-Todo-dicho! xD
If-Modified-Since: Fri, 1 Dec 1969 23:00:00 GMT
Accept: */*
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
Content-Length: 0
Connection: Keep-Alive

Primero se resalta el uso de los encabezados CLIENT-IP y X-Forwarded-For, lo cuales en una infinidad de CMS's se toman como la "verdadera ip" del visitante, por lo cual se usan en muchas consultas a base de datos, en el caso de Joomla y SMF es sorprendente la cantidad de consultas adicionales que se realizan a base de datos cuando el valor de CLIENT-IP/X-Forwarded-For cambia :P... ademas de que al registrar las IP's de los visitantes se generan registros extra.
También podemos ver encabezados para fastidiar un poco a la cache...
y Accept-Encoding: gzip,deflate, el cual lo agregue con la idea de forzar un poco mas al servidor, que pasa cuando enviamos un request al servidor sin dicho encabezado?, ignora la compresión (normalmente) lo cual son menos recursos (procesamiento) del servidor consumidos, al agregar dicho encabezado el servidor debería realizar la compresión... pero espera... que no usamos HEAD?, Para que comprimir lo que no se va a enviar?, para gastar recursos obviamente :P...

Bueno ahora les agradecería no volvieran a preguntar si MN es lo mismo que Slowloris gracias :P...

Saludos!

FHTTP v1.3 Liberada

Por fin les puedo decir que me complazco en anunciar la versión 1.3 de esta herramienta :P
Esta vez si es funcional xD...

Cambios (mayores):
* Se corrigieron bugs de manejo del url encode en el proxy (se realizaba decode de forma innecesaria).
* Se re-diseño por completo el motor del proxy para acelerar su funcionamiento.
* Se agregaron reglas.
* Se eliminaron fugas de memoria (no se cerraban a tiempo las conexiones entre otras cosas).
* Funciona en cualquier plataforma con Perl (tiene la capacidad de trabajar aunque no tenga todas las dependencias, es decir trabaja adaptándose a lo que se tiene).
* Se agregaron muchas funciones que en publicaciones siguientes comentare :P...

Créditos:
@LightOS (Roberto Salgado) por ayudarme como betatester a encontrar una infinidad de bugs :P.
@angelusniger (Angelus Inflectum) por aguantarnos en su casa (y alimentarnos cuando llegamos sin avisar) xD.
@lil_lilitu por prestarnos sus equipos para... casi romperlos haciendo pruebas xD...
Seguramente se me esta pasando agregar a muchas personas a la lista sin las cuales esta herramienta no sería lo que es. A todos ellos Gracias!


Descargar