Algunos ejemplos y defensas contra el clickjacking

ElevenPaths    29 octubre, 2013
El clickjacking fue descubierto por
Jeremiah Grossman y Robert Hansen en 2008. También se le conoce como UI
redressing. El concepto es sencillo, y las técnicas para conseguirlo
no son difíciles de implementar. Se podría
decir que la técnica se basa en un fallo de diseño de HTML y por tanto toda web es “vulnerable” por
defecto.
Las soluciones hasta ahora son en realidad “parches” aplicados tanto al protocolo como a los navegadores, que han aparecido para intentar
mitigar el problema.
El fin
del clickjacking es conseguir que un usuario pulse en un enlace (y realice una acción) sin que lo
sepa, o creyendo que lo hace en otro enlace con otro fin, con todas las consecuencias que eso puede acarrear. Puede ser un enlace de votación (que vote a alguien que no desea), seguir
a alguien en Twitter, un “Me gusta” de Facebook… El atacante
“disfraza” un enlace no deseado, volviéndolo atractivo para la víctima.
Para conseguirlo, se basa en el juego de capas que se puede conseguir con HTML
e “iframe”
. Iframe es una (anticuada en cierta forma) técnica para
cargar una web dentro de otra. Clickjacking está basado normalmente en el iframe.



Para una
explicación de cómo realizar este ataque, se debe entender el funcionamiento
por capas intrínseco al HTML. Una web maliciosa (roja, en la figura) debe cargar una web legítima (gris) delante pero , de forma transparente (con opacidad cero). La web roja consistirá en un mensaje atractivo, en el
que el usuario desee pinchar. La web legítima será la “víctima” en
el sentido de que el usuario realmente pulsará sobre ella sin quererlo. Además, será víctima del ataque porque permite que se “abuse” de ella
(veremos cómo evitarlo). Si se posiciona correctamente un enlace sobre otro, y
se cuadran las capas, el efecto puede ser el del “secuestro” del
clic del ratón.



Para
preparar la página maliciosa, el atacante debe contar con dos componentes
básicos:
  • Un
    iframe a cualquier otra página
    , que en este caso será la “víctima”, o
    en rigor, la página que será finalmente pulsada, sin que lo sepa el usuario.
  • Este iframe debe servirse desde la página maliciosa aplicando un estilo
    concreto que permita que sea transparente y quede posicionada por delante, en el punto
    correcto. Por ejemplo

El “style” definirá el ataque.

  • opacity:0. Vuelve transparente al elemento. Su valor va de 1 (totalmente opaco)
    a 0, transparente e invisible.
  • position:
    El elemento se coloca en relación a su primera posición (no estática) elemento
    antecesor.
  • top:0px;left:0px;width:99%;height:95%;margin:0px;padding:0px. Estos
    parámetros permiten tomar todo el ancho de una página y que se acople a sus
    márgenes para que la cubra totalmente
  • z-index:1. Permite que se posicione por delante/encima de cualquier otro elemento. Si este
    número se incrementa (puede valer 100, por ejemplo), se posicionará delante de
    todo lo que tenga un z-index menor. Si el número es negativo, se posicionará
    por detrás.
El ataque
completo, podría ser algo así:

Y cuando el usuario crea pulsar sobre un enlace muy
atractivo o conveniente para él, en realidad puede que esté realizando una
transferencia, por ejemplo.
Una
ventaja de esta técnica que la diferencia del CRSF (cross site
request forgery), es que con ella se sigue disponiendo del token válido en el caso de páginas que necesiten sesión, y si el usuario está presentado en la web
“víctima”, lo hará con el mismo token y como si realmente la acción se hubiera
realizado desde la página original.
Pero se
puede ir más allá. El problema inicial se definió en 2008 con este vídeo, en el
que se presentaba un ejemplo en el que la víctima activaba inadvertidamente su
cámara web al presionar botones en la propia página de Adobe.
Un ejemplo concreto

Imaginemos un sistema de votación
muy sencillo, alojado en un dominio culaquiera, en la web vulnerable.php.

El atacante utiliza test.html, que carga mediante un iframe la página vulnerable.php de forma transparente con opacidad 0. La carga “por delante” de test.htm, pero al ser transparente, el usuario solo visualiza el contenido de test.html. En ella propone votar a otra web cualquiera, por ejemplo elladodelmal.com. Este es el reclamo. Pero el usuario que pulse sobre el botón, realmente estará votando a elevenpaths.com.
La última secuencia muestra una imagen de la aplicación test.htm con opacidad 1, lo
que significa que se puede ver la aplicación vulnerable.php y test.php claramente una sobre la otra.
Evitar el ataque: en un sitio web
¿Qué
puede hacer una página para que no sea utilizada como víctima del clickjacking?
No puede hacer mucho más que evitar que se cargue ella misma dentro de un iframe. Así ningún
atacante podrá ponerla “invisible” y sobre otra que el propio atacante ha creado. Una de las soluciones “antiguas”
era la de evitar con JavaScript que una página no estuviera siempre en el
“top”.

Se
debería incluir este código en cada página. Pero estas técnicas podían, a su
vez, ser evitadas por el atacante.
Como
solución más práctica, se ideó añadir al protocolo HTTP una cabecera llamada X-Frame-Options.
Las páginas que envíen estas cabeceras al navegador, pretenden protegerse de
aparecer en un iframe. Se propusieron varios métodos más o menos flexibles para intentar ayudar a las que legítimamente necesitaran incluirse dentro de un iframe. Sus valores son:
  • DENY,
    el navegador evita que la página sea renderizada si está contenida
    dentro de un iframe
  • SAMEORIGIN, la página solo puede ser mostrara en un frame que provenga del mismo origen que la propia página.
  • ALLOW-FROM uri, el navegador bloqueará la
    renderización sólo si el origen de nivel superior está en un contexto de
    navegación que es diferente al valor uri proporcionado en la directiva 
Los usuarios deben confiar en que las páginas las envíen, y que su navegador las interprete correctamente. Esto último hace tiempo que ya lo implementan la mayoría. Por ejemplo, Chrome desde su versión 4.1.249.1042, Firefox desde 3.6.9,
Internet Explorer desde la 8, Opera desde la 10.5…
Evitar el ataque: desde el
cliente
Pero aunque la mayoría de
páginas  ya se aprovechan de estas cabeceras, ¿qué pasa con las que no?
El usuario debe protegerse.
Ciertos antivirus detectan en el navegador comportamientos
“extraños” de este tipo, y les han asignado firmas. Por ejemplo
Avira, lo detecta como 
HTML/Infected.WebPage.Gen2. 



Otro método para protegerse es utilizar la funcionalidad “clearclick” del conocido plugin NoScript, que ofrecerá protección al usuario para FireFox.

Ejemplos de alertas sobre ClickJacking. Fuente: http://blogs.computerworld.com/sites/default/themes/cw_blogs/cache/files/u91/noscript_clickjack.jpg 

Fuente: http://hackademix.net/2008/10/08/hello-clearclick-goodbye-clickjacking/

Ricardo Martín Rodríguez
ricardo.martin@11paths.com

Comentarios

  1. Y un trojano en el cliente que modifique por ejemplo la ruta de submit de una pagina que el cliente esta viendo y nos envíe los datos de logueo a un servidor falso donde los guardemos ? Seria parecido?

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *