Whateversec: Iframe Injection - De Phishing a XSS

Muy buenas a todos,

hoy quería explicar un fallo de seguridad que encontré hace unos días, y que posible explotación tendría esta vulnerabilidad. Yo he llamado a esta vulnerabilidad como "Iframe Injection", ya que no se si tenía ya un nombre antes.

Esta vulnerabilidad ocurre cuando puedes modificar el source de un iframe a tu antojo, pudiendo cargar un contenido de una página maliciosa. En la POC partiremos de una aplicación no vulnerable a XSS. Os voy a dejar el código vulnerable aquí.

<html>
<head>
<title>Mensaje de ayuda</title>
</head>
<body>
<h1>Este es el menu de ayuda</h1>
<?php
$mensaje_ayuda = htmlentities($_GET['ayuda']);
$errors = array("javascript");
foreach($errors as $error) {
$res = strpos($mensaje_ayuda, $error);
if ($res !== false){
header('location: error.html');
}
}
echo '<iframe src="' . $mensaje_ayuda . '"></iframe>';
?>
<form method="GET" action="ayuda.php">
<p>NUMERO DE AYUDA</p>
<input name="ayuda">
<button type="submit">ENVIAR</button>
</form>
</body>
</html>

Como vemos lo que tenemos es una supuesta página de ayuda, dependiendo de la página que queramos ver se enviará por parámetro y lo introducirá dentro de un iframe, así quedaría un ejemplo legítimo.

El problema surge cuando la aplicación no controla que el contenido introducido en el iframe pertezca a su propio dominio, el ejemplo más típico sería introducir la URL de nuestra página maliciosa donde tendríamos alojado un phishing para que el usuario introdujera sus datos.

A partir de aquí se podrían enviar correos electrónicos de Phishing más sofisticados ya que la URL introducida tendría el dominio legítimo.

Bypasseando filtros con diferentes URIS

Ahora vamos a imaginar que para evitar esta vulnerabilidad el programador pone algunos filtros que "evitan" que podamos introducir sources externos al dominio.

¿Que formas tenemos de introducir URIs completas para poder jugar con los diferentes filtros que pueda crear un programador?

$errors = array("javascript", "http");

Podemos introducir la URL con o sin http indiferentemente, el navegador de ambas formas no lo interpretará como nosotros queremos.

$errors = array("javascript", "http", "//");

Podemos usar los símbolos "/" y "\" indistintamente y cuantas veces queramos, el único requisito es que sean mínimo dos.

En caso de que la aplicación tenga una regex que busque los símbolos "\" y "/" seguido de "dominio.int" podemos añadir los caráctares ":@" o tan solo "@" al inicio del dominio.

Jugando con otras URIS

Además de "http" existen otros tipos de URIs con las que podemos jugar, aconsejo mirar aquí y ver si hay algo que pueda resultar interesante, yo voy a mostrar aquí un par de ideas.

Se podría abrir el correo electrónico con la URI mailto, encargada de enviar correos electrónicos de la siguiente forma: "mailto:correo@electronico?body=mensaje"

Se podría ejecutar código JavaScript gracias a la URI data, la cual simplemente responde con el contenido especificado en la propiar URI, podríamos hacerlo de la siguiente forma: data:text/html,<script>alert("XSS")</script>

NOTA: Si se introduce JavaScript dentro del servidor Web malicioso no se podrá interactuar con el padre por las CORS, que es lo que nos interesa para poder robar cookies o realizar otros ataques, de esta forma el código si será ejecutado en el padre.
Para entender un poco mejor las CORS aconsejo leer este post https://www.whateversec.com/2019/03/jugando-con-xss-cookies-y-cors.html

Por hoy ya he terminado, podeis seguir jugando con tras URIs diferentes que seguro que sale algo interesante, para cualquier duda o búsqueda de más información podeis comentar.

También me podéis seguir en Twitter para ver nuevos Posts y así echarme de paso una manita.

Saluti.

Lah vulnerabilidadeh de cliente molan tela.

Whateversec

lunes, 25 de marzo de 2019

Iframe Injection - De Phishing a XSS

No hay comentarios: