la especificación de las cookies

---

A cuento del post de hace un mes y algo sobre las cookies y sus tamaños, os dejo un post rapidito para mencionar un artículo muy bueno sobre las debilidades en la especificación de las cookies HTTP, en el blog de lcamtuf.

Nos cuenta sobre los orígenes de las cookies, de sus flags más conocidos, y una serie de problemillas de seguridad muy interesantes que surgen debido a la forma en que se especificó su uso. Para no perdérselo.

---

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS o seguirlo en Twitter...

I like it

---

Me ha gustado este ejemplo, publicado hace unos días en el diario de SANS sobre Clickjacking.

El Clickjacking es una técnica cuyo objetivo es engañar al usuario, haciéndole creer que pulsa en un determinado enlace, cuando en realidad está utilizando otro completamente diferente. En este caso, una página maliciosa usa esta técnica para agregarse a un sitio determinado al feisbuk del usuario, mediante el plugin "Like". Para ello, se situa mediante javascript un iframe completamente invisible por encima del enlace de la página legítima, y que contiene un enlace apuntando al plugin "Like" de Facebook con la url del site malicioso como parámetro. A continuación el usuario pincha en el enlace que ve, o eso cree, porque en realidad lo hace en el enlace malicioso que tenemos en el frame oculto... Lo cuenta también Social Hacking en More recent problems in Facebook platform, así como SpamLoco, Sophos, el CCN-Cert...

Buscando medidas de defensa contra este problema, veo que se proponen medidas de frame-busting (código javascript escrito en nuestra página, con el fin de evitar que esta pueda ser colocada en un iframe), así como el uso de una cabecera no-estándar, X-FRAME-OPTIONS, que propuso Microsoft como una de las medidas de seguridad de IE8. Podemos encontrar esto en la web de Owasp, aunque me parece un resumen escaso, porque no explica bien estas dos medidas.

Este paper de la universidad de Stanford detalla muchísimo mejor un buen número de medidas de frame-busting propuestas, cómo un atacante podría saltarselas, y cuál es la forma que los autores recomiendan. Habla también de X-FRAME-OPTIONS. Además, también se mencionan algunas medidas de defensa a nivel de navegador, que es útil conocer (al final del doc, son sólo un par de líneas). Me llama la atención el que algunas medidas de seguridad, como el filtro anti-XSS de IE8, o el atributo "sandbox" de la etiqueta iframe en Html5, pueden ser usadas para cargarse precisamente la medida de frame-busting, puesta también por seguridad.

Slds!

---

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

la ola de google

---

Todos llevamos algún tiempo oyendo hablar de Google Wave, la última innovación de Google para darnos a todos más capacidad de comunicación y de subir contenido a la red. De momento, está en fase beta y sólo accesible con invitación, pero ya ha dado mucho de qué hablar (aquí dos enlaces: alt1040 y El País).

Como es de ley, ya se le ha empezado a sacar problemas de seguridad. En TheHarmonyGuy nos cuentan que su autor ha probado Beef en Google Wave, con éxito, lo que podría convertirlo en una buena herramienta para hax0rs.

Slds

---

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

Para saber si el navegador del usuario está virtualizado

---

Aquí va una entrada, a modo de apunte rápido, sobre cómo emplear los recursos del navegador para detectar si un usuario está navegando o no desde un entorno virtualizado. Jeremiah Grossman escribía sobre esto hace unas semanas.

J.G nos sugiere dos trucos para detectar entornos virtualizados: ver el tamaño de la ventana del navegador mediante Javascript, y ver la dirección MAC del equipo. El tamaño de la ventana puede obtenerse mediante Javascript, y al parecer, en el caso de entornos virtualizados suelen obtenerse tamaños un tanto extraños. La dirección MAC del equipo no puede obtenerse mediante Javascript, pero sí mediante un applet Java, y ocurre que los primeros octetos de la dirección MAC son fijos, e identifican al fabricante (por ejemplo VMWare).

Además de saberse si un navegador se encuentra virtualizado, también es posible saber por ejemplo si está usando el modo “privado” del navegador (“InPrivate” de IE8, “Private Browsing” de Firefox, o “Incognito” en Chrome). Un usuario empleará este modo en el caso de que se encuentre usando un equipo público, por ejemplo un PC de un cibercafé. Le permite controlar la información que se guarda en el histórico del navegador, cookies, etc. Una última utilidad interesante podría ser conocer si el usuario está usando plugins de seguridad como Noscript.

La conocida herramienta “beef”, que permite explotar vulnerabilidades en los navegadores, incorpora un módulo para detectar si el navegador Internet Explorer está o no virtualizado, mirando la dirección MAC mediante Javascript.

Slds!

---

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

Handbook de seguridad en el navegador

---

Vía Blog de un informático, me entero de la existencia de este Browser Security Handbook, un manual recopilatorio de las medidas de seguridad existentes en los navegadores web más utilizados, creado por Michael Zalewski.

Pensado para desarrolladores y todos aquellos dedicados a la seguridad informática, describe conceptos básicos sobre navegadores (URLs, DOM, etc), las medidas de seguridad que tienen los distintos navegadores analizados, y mecanismos de seguridad experimentales o desfasados.

Tiene buena pinta :)

---

Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...

Abusos sobre HTML5 client-side storage

---

Las nuevas soluciones de almacenamiento en el navegador de web, que aparecerán en HTML 5, son un caldo de cultivo muy bueno para ataques en el lado del cliente. Lo cuenta Alberto Trivero, en un artículo que ha enviado a varias listas de distribución de correo sobre seguridad. Se puede descargar en su sitio.

Me ha venido genial, porque ahora no empleo tanto tiempo como antes en aprender novedades de programación y hacking [ :( ] por cuestiones de trabajo. Muy ilustrativo, cuenta las novedades en HTML 5 (en fase de draft) respecto a cómo almacenar datos en el lado de cliente, que ahora tendrá tres tipos de almacenamiento diferentes:

• session storage: para guardar los datos propios de la sesión del usuario en la aplicación
• local storage: para guardar datos persistentes, es decir, que no se borren al cerrar la aplicación o el navegador
• database storage: ahora se tendrá la posibilidad de guardar datos en una bbdd relacional propia del navegador

Alberto explica la manera (código demo incluido) en que estas novedades amplian enormemente las posibilidades de un XSS, o que algunos problemas (SQL Injection) que antes afectaban al lado servidor de una aplicación de web, ahora afectarán también al lado cliente. Además, las enormes espectativas que estas novedades en HTML5 han despertado entre los desarrolladores web (lógicas, por otra parte), hace pensar que serán ampliamente utilizadas, sean seguras o no.

Lectura interesantísima :)

Receta para el DNS rebinding

---

Conocido hace 10 años, y de actualidad de un año a esta parte, debido a vulnerabilidades en los plugins de los navegadores, es el llamado "DNS rebinding". El ataque, en concepto, es muy sencillo, este post es una sencilla receta para introducirlo.

---

Objetivo del ataque: el navegador del usuario, y más exactamente, alguna de sus extensiones (Flash, Java, ...). Se pretende que haga peticiones a un sitio web distinto al que el navegador cree que está llamando realmente, cosa en principio no posible porque tiene su protección para ello.

Esta protección es el llamado DNS pinning: consiste en que el navegador guarda una base de datos, caché o como lo quieras llamar, con pares nombre-de-host <--> IP, durante un tiempo determinado fijo o hasta que se cierre el navegador. La idea original era que se llamara siempre al mismo servidor, mientras tuviera su entrada en esta "pin-cache". Esta medida completaba a la política de "same-origin-policy", cuyo objetivo es evitar que un script cargado al acceder a un dominio, intente acceder a elementos de otro.

Se puede conseguir no sólo acceder a otro sitio web, sino a cualquier otro tipo de aplicación de internet, como puede ser un servidor SMTP, usando como plataforma de lanzamiento el navegador del usuario. Esto es porque un plugin dispone de la capacidad de crear sockets a pelo.

Ingredientes para ejecutarlo:

• un servidor de web, con alguna aplicación especialmente preparada
• un nombre de dominio que se pueda controlar, en tu propio DNS, o por ejemplo, en dyndns.org
• un medio de conseguir que las víctimas invoquen a la aplicación web, como puede ser un banner en otros sitios web, o un poco de ingeniería social
  
• algo de información extra, dependiendo de qué se pretenda hacer
  

Elaboración:

Prepara el servidor de web con la aplicación maliciosa, y sácalo a Internet, o a donde pueda ser alcanzable por quienes quieres (no olvides securizarlo en condiciones, no vaya a ser que alguien más listo que tú y yo haga cosas malas con él ;) ).

Crea el nombre de dominio para la aplicación en el servidor DNS, y asígnale al menos dos direcciones IP: la IP real de tu servidor, y la IP a la que quieres que el cliente llegue. La segunda dirección IP puede depender de esa información que hay que saber antes, por ejemplo, si lo que se pretende es acceder a un servidor web de intranet, de acceso restringido a equipos de la red interna de una organización, pues eso, hay que saber antes su dirección.

Ahora el navegador de la víctima llamará al sitio web malicioso (engañado de alguna manera), y el DNS le devolverá la primera dirección IP, la del servidor con la aplicación víctima. El servidor de web devolverá el código malicioso. Acto seguido, se deberá cerrar el acceso al mismo, por ejemplo, aplicando una regla de denegación de acceso en el firewall.

Este código que descargue deberá esperar algo de tiempo, y luego invocar de nuevo al sitio web del atacante. Al encontrar que no está accesible, usará la segunda dirección IP suministrada por el DNS. ¡Bingo!. Accede al servidor deseado por el atacante.

Por supuesto, la gracia, el truco del almendruco, es tener a mano el script maligno ;)

---

Este problema, que tuvo sus variantes hace años, ha vuelto a la actualidad debido a la implementación de los plugins que llevan los navegadores. Y es que tienen una caché con pares nombre-de-host <--> IP, distinta a la que tiene el navegador en sí. Además, reimplementan las medidas de seguridad que traían ya los navegadores. Por ejemplo, en la página de Adobe se habla de una actualización para Flash Player, corrigiendo un problema de este tipo.

Las posibilidades de este tipo de ataque son elevadas: desde acceder a sitios restringidos, al envío de spam, explotación de vulnerabilidades... todo usando el navegador del usuario como plataforma de lanzamiento.

Leo además en OpenDNS que ofrecen una solución en su servicio. Se habla también de un plugin de Firefox para evitar este problema, llamado LocalRodeo (no lo he probado).

Algunos enlaces (buscando en Google, salen de los primeros):
SecurityFocus
dark reading
hackszine
investigación de la Universidad de Stanford: presentación completa de toda la problemática, objetivos que pretende un atacante (extenso), soluciones (aún más extenso), referencias a otros trabajos...
blog de Christian: explica bastante bien qué es el DNS pinning, por qué apareció, cómo evolucionó, etc. Con gráficos y todo.