DNS Spoofing en Android (CVE-2012-2808)

Ayer se publicó una vulnerabilidad de DNS Spoofing (CVE-2012-2808) que afecta a todos los dispositivos Android con versiones del sistema operativo 4.0.4 y anteriores (la última versión 4.1.1 Jelly Bean que a día de hoy tan sólo usa el Nexus 7 no es vulnerable a este ataque).

El ataque consiste en el uso de un algoritmo de generación de números pseudoaleatorios (PRNG) débil para calcular el puerto de origen del paquete que realiza la consulta DNS y el identificador TXID de dicha petición.

Recordando cómo funciona el protocolo DNS, cada vez que se realiza una consulta DNS se genera un paquete que tiene un identificador único, el TXID, y se envía desde un puerto origen diferente cada vez. Ambos valores deben de ser aleatorios para evitar que un posible atacante pueda responder al cliente antes de que lo haga el servidor DNS legítimo.

Ambos valores tienen una longitud de 32 bits que "asegura" que no se pueden predecir, pero investigadores de IBM han determinado que, con el algoritmo que utiliza Android, tan sólo 21 de esos bits son realmente aleatorios. La causa, que se utiliza la hora en milisegundos del dispositivos como una de las bases para generar el valor final. Esto unido a que cada consulta DNS tiene dos valores aleatorios (el TXID y el puerto) es relativamente sencillo estimar uno a partir del otro.

Es más, depués de un determinado tiempo (en la PoC que han realizado es de unos 10 minutos), es posible predecir con una certeza suficientemente alta los próximos valores. A partir de ese momento es cuando se produciría el ataque DNS Spoofing ya que el atacante podría comenzar a responder al dispositivo móvil con el TXID y en el puerto origen correctos.

Os dejo el vídeo con la PoC y el enlace con el advisory oficial: 

Resumen: http://blog.watchfire.com/wfblog/2012/07/android-dns-poisoning-randomness-gone-bad-cve-2012-2808.html
Paper: http://blog.watchfire.com/files/androiddnsweakprng.pdf

Client Side Attacks (IV): Clickjacking

  ****************************************************
    Client Side Attacks (I): Introducción
    Client Side Attacks (II): Infectando Navegadores
    Client Side Attacks (III): Sacando provecho
    Client Side Attacks (IV): Clickjacking
  ****************************************************

Cerrando el tema que empecé hace ya tiempo sobre ataques del lado del cliente, hoy os voy a hablar del Clickjacking. Un concepto acuñado a finales de 2008 a partir de un paper publicado por Jeremiah Grossman y Robert Hansen.

El concepto de Clickjacking es bastante sencillo, tan sólo consiste en incluir una página (vulnerable) dentro de otra (que trata de sacar provecho de la primera) por medio de un iframe.

Imaginad una página web en la que se realice una determinada tarea pulsando sobre tres botones numerados del 1 al 3. Un sitio malicioso podría incluir en un iframe a la página anterior y situar sobre el mismo iframe un panel que lo oculte con un contenido atractivo que haga que el usuario pulse en los botones en el orden que debe de hacerlo.

Para seguir con el ejemplo, se podría solicitar al usuario que pulsara sobre los tres robots por orden: azul, rojo, verde (una vez se cuadraran ambos marcos):

Ejemplo de Clickjacking.

Como os decía, el concepto es muy simple, el problema es llevarlo a la práctica ya que no basta con identificar sitios vulnerables, sino crear un contenido que resulte interesante a una posible víctima para que caiga en el engaño y ejecute la tarea oculta.

Algunos ejemplos de posibles usos son hacer que se pulse sobre anuncios de publicidad (muchas empresas de publicidad pagan por pulsaciones), sobre botones "+1" o "Me gusta" (lo que se conoce como Likejacking), etc.

Un ejemplo más interesante es el del siguiente vídeo, que bien podría ser un jueguecillo de matar marcianos, bastante cutre, en el que hay que ir pulsando sobre cada una de las naves que van apareciendo de manera aleatoria en el espacio:

Ahora vemos lo que realmente está sucediendo cada vez que el usuario hace un click sobre cada una de las naves:

Como veis, lo que el usuario está realmente haciendo es:

1. Habilitar el chat de iGoogle
2. Agregar un nuevo contacto que ya le había mandado una invitación previa (éste sería el atacante).
3. Abrir un chat con el contacto que acaba de añadir.
4. Invitarle a realizar una video-llamada, lo que automáticamente acaba encendiendo la web cam del usuario cuando el atacante acepta la llamada.

Todo ello transcurre sin que el usuario sea consciente de lo que está haciendo...

Por desgracia, poca gente toma en serio esta vulnerabilidad y aun menos webmasters implementan medidas para evitarla (que pasa por incluir la cabecera HTTP X-Frame-Options en las URLs que se desean proteger).


¿A vosotros también os parece una vulnerabilidad que menospreciar?