Archive

Archive for the ‘Web Applications’ Category

XSScrapy para procesos de crawling e identificación de vulnerabilidades

marzo 12, 2015 Deja un comentario

Scrapy es un framework que cuenta con varias utilidades para crear spiders y crawlers, se ha vuelto bastante popular y en cada nueva versión es mucho más estable y robusto. Hace algún tiempo comentaba en un vídeo de la serie de Hacking con Python los elementos que a mi parecer eran los más interesantes de Scrapy y cómo se puede utilizar desde cualquier script en Python. Dado que este tipo de actividades casi siempre suelen ir de la mano con procesos de minería y extracción de datos, a lo mejor no resulta tan llamativo para un pentester/hacker (o si), pero cuando hablamos de ejecutar un proceso de crawling no solo para extraer información, sino para detectar vulnerabilidades en aplicaciones web, seguro que más de uno comienza a ver que se pueden hacer cosas muy interesantes.
Si has visto como funciona un spider y la cantidad de elementos involucrados en un proceso de crawling, casi seguro que alguna vez te habrás preguntado ¿Y cómo puedo utilizar esto para ejecutar tareas de pentesting? Creo que es una pregunta bastante lógica, ya que además de visitar enlaces y analizar la estructura de un sitio web, también estás jugando con cabeceras HTTP, parámetros en el cuerpo de la petición o directamente en la URL, formularios, diferentes tipos de “content-types” y un largo etc. Son muchas las posibilidades que tienes a tu disposición.
Ahora bien, imaginar por un segundo que esto lo aplicamos no solamente a aplicaciones web en Internet, sino también a servicios ocultos del tipo HTTP en la red de TOR. A mi personalmente me ha parecido una idea de lo más interesante y ahora mismo me encuentro desarrollándola para la próxima versión Tortazo, algo de lo que pienso hablaros en un próximo articulo.

Si quieres utilizar Scrapy directamente y realizar pruebas de pentesting contra todos los enlaces encontrados y procesados por un Spider, no hay demasiados impedimentos para hacerlo, sin embargo existe una herramienta que ya lo hace por ti, dicha herramienta es XSScrapy.

  1. Instalación y uso de XSScrapy

XSScrapy es una aplicación fácil de instalar y de usar, como ya os imaginaréis se basa en Scrapy y permite encontrar vulnerabilidades del estilo XSS (tanto reflejado como almacenado) y también vulnerabilidades del tipo SQLi. El proyecto se encuentra alojado en el siguiente repositorio de GitHub https://github.com/DanMcInerney/xsscrapy y para instalarlo basta con utilizar el comando “pip” junto con el fichero de dependencias.

>git clone https://github.com/DanMcInerney/xsscrapy.git && cd xsscrapy

>pip install -r requirements.txt

A continuación se puede comenzar a probar la aplicación, que sobresale por su simplicidad.

>./xsscrapy.py -h

usage: xsscrapy.py [-h] [-u URL] [-l LOGIN] [-p PASSWORD] [-c CONNECTIONS]

[-r RATELIMIT] [–basic]

optional arguments:

-h, –help show this help message and exit

-u URL, –url URL URL to scan; -u http://example.com

-l LOGIN, –login LOGIN

Login name; -l danmcinerney

-p PASSWORD, –password PASSWORD

Password; -p pa$$w0rd

-c CONNECTIONS, –connections CONNECTIONS

Set the max number of simultaneous connections

allowed, default=30

-r RATELIMIT, –ratelimit RATELIMIT

Rate in requests per minute, default=0

–basic Use HTTP Basic Auth to login

Evidentemente la opción que resulta más interesante es en la que se puede definir la URL (-u/–url) del objetivo y a partir de allí, comenzar a ejecutar el procesamiento de enlaces y peticiones/respuestas HTTP. Otra opción interesante es la que permite establecer el número de conexiones simultaneas máximo contra el sitio web en cuestión (-c/–connections) algo que resulta muy practico para evitar que un WAF detecte el ataque y bloquee las peticiones desde la IP donde se realizan. Además, en el caso de que el sitio web requiera autenticación (digest o basic) es posible indicar un usuario y una contraseña con los interruptores -l y -p.
Ahora que tenemos una imagen general del funcionamiento del programa, podemos comenzar a utilizarlo con una aplicación web vulnerable. Existen aplicaciones web para realizar pruebas de penetración de todos los gustos y colores, algunas de ellas ya las he mencionado y explicado en varias ocasiones en este sitio, tales como DOJO InsecureWebApp, Hacme Casino, DVWA (Damn Vulnerable Web Application), WebGoat, etc. En esta ocasión vamos a utilizar Django-Moth, una aplicación web vulnerable escrita en Django que puedes descargar libremente desde aquí: https://github.com/andresriancho/django-moth pero si lo prefieres puedes utilizar cualquier otra, a efectos prácticos da un poco igual.

Después de descargar el proyecto del repositorio GitHub, se puede iniciar la aplicación Django de la siguiente forma:

>python manage runserver 8080

Performing system checks…

System check identified no issues (0 silenced).

February 18, 2015 – 17:05:08

Django version 1.7.1, using settings ‘djmoth.settings’

Starting development server at http://127.0.0.1:8080/

Quit the server with CONTROL-C.

El puerto por defecto es el 8000, pero como se puede apreciar se puede cambiar por cualquier otro. Recordar que se trata de una aplicación web con vulnerabilidades fáciles de explotar, evitar utilizarla en Internet y mucho menos, utilizar un puerto como el 80 que requiere privilegios de root.

Todas las vulnerabilidades de Django Moth se encuentran separadas por secciones, pero aun así, el crawler de XSScrapy, a la fecha de redactar este articulo, no permite establecer reglas para indicar en qué momento debe detenerse el ataque y cuales son los enlaces que se permite visitar. Tal falta de control es un problema a la larga, ya que muchas páginas tienen enlaces a otros dominios y es fácil que el proceso recursivo termine llevando al crawler a sitios que no deberían analizarse, así que hay que estar atentos a las trazas que arroja el programa en todo momento. Ahora se puede ejecutar algo como lo siguiente:

./xsscrapy.py -u http://localhost:8080/audit/os_commanding/blind_osc.py?cmd=ls

Se podrán ver varias trazas y los elementos que la herramienta va analizando en cada iteración. En el caso de interrumpir el proceso manualmente o que termine debido a que ya se han recorrido todos los enlaces, se genera automáticamente un fichero con nombre: “xsscrapy-vulns.txt” el cual contiene todos los resultados encontrados. Incluye cosas como las vulnerabilidades encontradas, puntos de inyección, parámetros utilizados, la petición y respuesta del servidor, etc.

Una herramienta interesante con mucho potencial y aunque a mi juicio se puede explotar mucho más el framework de Scrapy, puede resultar muy instructiva para aprender detalles avanzados del framework, eso si, solamente si estas dispuesto a ver el código y entender cómo funciona, algo que desde luego te recomendaría ya que tiene detalles técnicos muy valiosos y que te ayudarán a aprender ciertos “trucos” a la hora de crear tus propias herramientas.

Un saludo y Happy Hack!
Adastra.

Conceptos básicos de HSTS y configuración en Apache

febrero 19, 2015 1 comentario

HSTS o Http Strict Transport Security es un mecanismo que intenta mitigar los ataques de MITM sobre SSL obligando a los clientes a utilizar únicamente conexiones cifradas con TLS/SSL. Su funcionamiento no es demasiado complicado y aporta un mecanismo de defensa adicional que a día de hoy, es prácticamente imprescindible para mantener un buen nivel de seguridad en el canal de comunicación.
HSTS es un mecanismo que se encuentra soportado por los principales servidores web modernos, tales como Apache o NGNIX y además, navegadores a la altura de Firefox, Opera o Chrome soportan las cabeceras HTTP necesarias para obligar el uso de HSTS en el lado del cliente.
Si un servidor web soporta HSTS, todas las respuestas emitidas a los clientes contendrán la cabecera HTTP “Strict-Transport-Security”, lo cual le indica al cliente que todas las peticiones que se realicen contra el servidor web deben utilizar un certificado valido y todas las conexiones se deben realizar utilizando el protocolo HTTPS únicamente. El comportamiento de los clientes que soportan la política HSTS es bastante simple y muy efectivo ante ataques de MITM. En primer lugar, se encargan de cambiar el esquema “http://” por “https://” de todos los enlaces que hacen referencia al servidor web con HSTS y por otro lado, si la existe cualquier problema con el canal de comunicación, la comunicación es cortada automáticamente, como por ejemplo el caso típico en el que el certificado que se presenta al usuario es auto-firmado o de una identidad no verificada.
En este articulo se explicará cómo se puede habilitar HSTS en un servidor web Apache y se inspeccionarán las cabeceras de las peticiones enviadas por los clientes y las respuestas del servidor, de esta forma quedará mucho más claro el funcionamiento de HSTS en un servidor web.

Habilitando HSTS en Apache

Habilitar HSTS en un servidor web Apache es algo que inicialmente puede parecer trivial, ya que solamente es necesario cargar el módulo “headers” y utilizar la directiva “Header” con el valor HSTS correspondiente, sin embargo, algo que hay que tener presente es que los navegadores web ignoran la cabecera “Strict-Transport-Security” si no hace parte de una conexión HTTPS. Dicho de otra forma, si un cliente realiza una petición HTTP a un servidor y la respuesta de dicho servidor contiene la cabecera “Strict-Transport-Security”, dicha cabecera no tendrá ningún valor para el cliente y sera ignorada, ya que los navegadores deben recibir la cabecera “Strict-Transport-Security” en una conexión HTTPS para que la apliquen sobre el dominio en cuestión.

Dicho esto, queda claro que habilitar HSTS es solamente una pequeña parte de una configuración segura, ya que será necesario habilitar el módulo de SSL/TLS en un VirtualHost del servidor web. En un articulo de hace algún tiempo, ya hablaba sobre cómo hacer esto, así que te recomiendo visitar el siguiente enlace. El fichero de configuración completo, que se puede utilizar para habilitar HTTPS y HSTS puede ser la siguiente:

ServerAdmin debiadastra@thehackerway.comServerName Galileo:80

ServerRoot “/opt/httpd-2.4.10″

ErrorLog “logs/error_log”

LogLevel warn

Listen 80

Listen 443

LoadModule authz_core_module modules/mod_authz_core.so

LoadModule headers_module modules/mod_headers.so

LoadModule unixd_module modules/mod_unixd.so

LoadModule ssl_module modules/mod_ssl.so

<IfModule unixd_module>

User adastra

Group adastra

</IfModule>

<IfModule alias_module>

ScriptAlias /cgi-bin/ “/opt/httpd-2.4.10/cgi-bin/”

</IfModule>

<Directory “/opt/httpd-2.4.10/cgi-bin”>

AllowOverride None

Options None

Require all granted

</Directory>

<IfModule ssl_module>

SSLRandomSeed startup builtin

SSLRandomSeed connect builtin

</IfModule>

<VirtualHost *:443>

Header always set Strict-Transport-Security “max-age=63072000; includeSubDomains”

DocumentRoot “/opt/httpd-2.4.10/htdocs/hstsTesting”

SSLEngine on

<Directory /opt/httpd-2.4.10/htdocs/hstsTesting>

Options Indexes FollowSymLinks

SSLRequireSSL

</Directory>

SSLCertificateFile /opt/httpd-2.4.10/webserver.crt

SSLCertificateKeyFile /opt/httpd-2.4.10/webserver.key

<IfModule mime_module>

AddType application/x-x509-ca-cert .crt

AddType application/x-pkcs7-crl .crl

</IfModule>

</VirtualHost>

Si el usuario intenta visitar el servidor utilizando el protocolo HTTPS, verá la siguiente pantalla de error indicando que la conexión no es segura y por ese motivo se ha cancelado la navegación.

hsts1

El motivo de esto, es que los certificados utilizados por el servidor web no han sido emitidos por una CA de confianza para el cliente y dado que se ha indicado que la comunicación debe realizarse con HSTS, la comunicación entre el cliente y el supuesto servidor no puede continuar llevándose a cabo. Esto evita que se realicen ataques de “SSL Stripping” con herramientas tan conocidas como SSLStrip.

Esta configuración del lado del servidor es vital para mantener sitios web con un nivel de seguridad añadido. Por otro lado, desde el cliente también es posible habilitar este “opt-in” de seguridad para determinados dominios, de tal forma que aunque el servidor no incluya explícitamente la cabecera estándar HSTS, el navegador por si solo bloqueará cualquier intento de conexión no segura, evitando problemas con el canal de comunicación. Un buen ejemplo de configuración de HSTS en el lado del cliente se encuentra en el navegador Chrome, el cual permite gestionar dóminos personalizados que deben seguir la norma HSTS. Para entrar a esta interfaz de administración del navegador, es necesario ingresar a la siguiente ruta: chrome://net-internals/#hsts

Una vez allí, Chrome enseñará la interfaz que se puede ver en la siguiente imagen para la gestión de dominios con HSTS.

hsts2

Por otro lado, si la configuración anterior no se ha aplicado para un dominio concreto y aunque dicho dominio tenga HSTS habilitado, si las peticiones iniciales se realizan utilizando HTTP, aun cabe la posibilidad de utilizar una herramienta como “sslstrip” para realizar un ataque de “hijacking”. Por ejemplo, una configuración bastante común consiste en redireccionar todo el trafico por HTTP a HTTPS, es decir, en el caso que el usuario solicite el sitio web “http://example.com”, automáticamente se realizará la redirección a “https://example.com” y dado que la petición inicial ha sido utilizando HTTP, aun existe la posibilidad de llevar a cabo un ataque. Por este motivo, navegadores como Chrome y posteriormente otros como Firefox y Opera implementan un mecanismo conocido como “HSTS Preload List” o lista de dominios HSTS precargada. Dicho mecanismo, como su nombre lo indica, carga una lista de dominios que deben cumplir con la normativa HSTS en el momento en el que el navegador arranca, de esta forma si el usuario solicita el recurso “http://example.com” la comunicación automáticamente será cortada, obligando al usuario a ingresar en la versión segura con HTTPS. Para tener los valores adecuados en dicha lista, se utiliza un algoritmo de rastreo en busca de la cabecera HSTS en múltiples sitios en Internet, además, cualquiera puede enviar una solicitud para que su sitio web sea incluido en dicha lista (la cual es compartida entre Chrome, Safari y Firefox). Para realizar dicha solicitud, basta con ingresar el dominio en cuestión en el siguiente sitio: https://hstspreload.appspot.com/
Este articulo ha sido una introducción al funcionamiento de HSTS y en uno próximo, veremos en detalle el funcionamiento de “sslstrip2”.

Un Saludo y Happy Hack!

Adastra.

Implementando WebSockets con Tornado

enero 29, 2015 Deja un comentario

En un articulo anterior he hablado sobre la librería Tornado y cómo se puede utilizar para implementar servidores y clientes TCP asíncronos. Además, también he hablado sobre algunas de las vulnerabilidades más comunes en WebSockets, una de las características más interesantes en la especificación HTML5. En esta ocasión veremos cómo utilizar los módulos disponibles en Tornado para crear un servidor web básico que soporte WebSockets para poder realizar pruebas de concepto rápidas y comprender el comportamiento tanto en clientes como servidores de los websockets.

Tornado es una librería que solamente se encuentra disponible para máquinas basadas en Unix, por este motivo, en un próximo articulo hablaré sobre otra implementación independiente de plataforma basada en Java llamada websocket4j. Otra buena solución cuando queremos realizar pruebas con un sistema basado en Windows.

  1. Implementación de un cliente utilizando la API de WebSockets

Antes de comenzar a implementar el servidor, vamos a comenzar creando un cliente básico que servirá posteriormente para probar cualquier implementación de un servidor con WebSockets. Para implementar un cliente, basta con utilizar la API en Javascript que se encuentra habilitada en prácticamente todos los navegadores modernos que soportan HTML5, como es el caso de Firefox, Opera o Chrome.

test.html

<!DOCTYPE html>
<html>
    <head>
        <meta charset="utf-8">
    <script type="text/javascript">
        function WebSocketTest() {
                var ws = new WebSocket("ws://localhost:8888/ws?Id=123456789&name=Adastra&continue=Yes");
        if (ws != null && ws.readyState == WebSocket.OPEN) {
          ws.send("Data from the client to the server!");
        }
                ws.onopen = function() {
                    ws.send("Opening connection!");
                };
                ws.onmessage = function (evt) { 
                    var received_msg = evt.data;
                    alert("Message received... " + received_msg);
                };
                ws.onclose = function() { 
                    alert("Connection is closed...");
                };
        }
        </script>
    </head>
    <body>
        <a href="javascript:WebSocketTest()">Run WebSocket</a>
    </body>
</html>

En la página HTML se puede apreciar que la función “WebSocketTest” contiene todos los elementos necesarios para establecer una comunicación con el servidor web y posteriormente, enviar y recibir mensajes de forma asíncrona. Esto último es lo que hace tan interesantes los WebSockets, ya que después de establecer el handshake, tanto cliente como servidor pueden enviarse mensajes sin necesidad de esperar a que la otra parte conteste y el servidor, puede enviar datos sin necesidad de que exista una petición previa por parte del cliente.

Ahora bien, después de tener preparada la pieza de código correspondiente al cliente, lo siguiente consistirá en crear un servidor que se encargue de procesar las peticiones y manejar todas las conexiones utilizando el protocolo de WebSockets.

  1. Implementación del un servidor utilizando la API de WebSockets y la librería Tornado

Como comentaba anteriormente, Tornado cuenta con varias clases y funciones que permiten crear diversos tipos de elementos de red, tanto síncronos como asíncronos. En este caso concreto nos centraremos en el módulo que permite la creación de servidores y aplicaciones web con Tornado. Esto será útil para realizar pruebas de concepto y entender el funcionamiento de ciertas características propias en entornos web.
El siguiente programa permitirá la creación de un servidor web básico utilizando Tornado, el cual aceptará conexiones en HTTP normales si el usuario solicita el recurso “/” y conexiones utilizando el protocolo de WebSockets si el usuario solicita el recurso “/ws”.

serverTornado.py

</pre>
<pre>import tornado.ioloop
import tornado.web
import tornado.websocket
from tornado.options import define, options, parse_command_line
class Client:
    def __init__(self, clientId, name, cont, connection):
        self.id = clientId
        self.name = name
        self.cont = cont
        self.connection = connection 

clients = []
class IndexHandler(tornado.web.RequestHandler):
    def get(self):
        self.render("test.html")

class WebSocketHandler(tornado.websocket.WebSocketHandler):
    def open(self, *args):
        self.id = self.get_argument("Id")
        self.name = self.get_argument("name")
        self.cont = self.get_argument("continue")
        newclient = True
        for client in clients:
            if client.id == self.id:
                client.connection.write_message("Hello Again %s !" %(client.name))
                newclient = False
                break
        if newclient:
            clientRef = Client(self.id, self.name, self.cont, self)
            clients.append(clientRef)
            self.write_message("Hello %s !" %(self.name))
           

    def on_message(self, message):        
        for client in clients:
            if client.id == self.id:
                print "Message from %s received : %s" % (client.name, message)
    
      
    def on_close(self):
        for client in clients:
            if self.id == client.id:
                clients.remove(client)
                break

define("port", default=8888, help="run on the given port", type=int)
app = tornado.web.Application([
    (r'/', IndexHandler),
    (r'/ws', WebSocketHandler),
])

if __name__ == '__main__':
    parse_command_line()
    app.listen(options.port)
    tornado.ioloop.IOLoop.instance().start()

Los elementos más importantes del programa anterior son los siguientes:
– Objeto del tipo “
tornado.web.Application” el cual se encarga de definir las URI disponibles para el servidor web. En este caso concreto, se ha definido que el usuario podrá acceder a la ruta “/” y “/ws”. Si el usuario solicita el recurso “/” el servidor se encargará de ejecutar el handler “IndexHandler” y si el usuario solicita el recurso “/ws” el servidor se encargará de ejecutar el handler “WebSocketHandler”.

– IndexHandler: Clase que hereda de la clase “tornado.web.RequestHandler” y que se encarga de procesar las peticiones HTTP realizadas por los clientes que emplean el método GET. En este caso, la case se encarga simplemente de responder al cliente con la página “test.html”, la cual incluye el contenido que se ha explicado anteriormente en el la primera parte de este articulo, es decir, la página HTML con los elementos necesarios para interactuar con el servidor web.

– WebSocketHandler: Clase que hereda de la clase “tornado.web.WebSocketHandler” y que se encarga de procesar las peticiones entrantes que utilicen el protocolo de WebSockets. La clase incluye los métodos “open”, “on_message” y “on_close”, los cuales son invocados automáticamente cuando se abre una conexión, se recibe un mensaje y se cierra una conexión existente, respectivamente.

– Finalmente, la definición propiamente dicha del servidor web viene dada por una instancia de la clase “tornado.ioloop.IOLoop”, la cual se encarga de crear un hilo de ejecución que se mantendrá en funcionamiento de forma indefinida y que utilizará las opciones por línea de comandos que se han definido por medio de la función “tornado.options.define”.

Con todos lo anterior, ahora es posible ejecutar el servidor web y probar los métodos de los dos handlers definidos.

>python serverTornado.py

Si el usuario solicita el recurso “/”, el servidor se encargará de responder con la página “test.html” tal como se enseña en la siguiente imagen.

En enlace que se puede ver en la imagen, se encarga de invocar a una función en Javascript que permite interactuar con el servidor web y enviar mensajes utilizando el protocolo WebSockets, tal como se puede apreciar en la siguiente imagen.

Se trata de un ejemplo muy simple y que no solo permite conocer cómo funcionan los websockets, sino que también explica como utilizar Tornado para crear un servidor que los soporte. No obstante, tal como mencionaba anteriormente, Tornado solamente funciona para sistemas basados en Unix, con lo cual, en el próximo articulo hablaré sobre otra librería basada en Java llamada websockets4j.

Un Saludo y Happy Hack!
Adastra.

Registro y análisis de emociones con Wefeelfine – Ingeniería social automatizada

diciembre 9, 2014 3 comentarios

El campo de la psicología y todo lo relacionado con los fenómenos socio-culturales siempre me han parecido muy interesantes en los que creo que hay mucho por hacer, especialmente desde el punto de vista de la informática, ya que estamos hablando de un campo del conocimiento que aun no ha alcanzado el grado madurez que tienen otros campos del conocimiento humano. No obstante, existen muchos documentos y herramientas que permiten comprender mejor la naturaleza de las emociones humanas y la forma en la que pueden afectar el comportamiento de una persona. La ingeniería social es una de dichas herramientas y se basa en una serie de principios generales que son transculturales y que suelen aplicar a un porcentaje de la población bastante alto, sin embargo su enfoque, como seguramente ya lo sabes, consiste principalmente en detectar las vulnerabilidades que pueda tener una persona en varios niveles, así como también para la detección del engaño. Los ingenieros sociales suelen conocer bastante bien los principales rasgos psicológicos y culturales de las personas con las que tratan, tal es su conocimiento sobre el comportamiento y la psique humana que son capaces de “cambiar” su modo de hablar, de expresarse y de transmitir ideas a las personas con las que se comunican con el fin de generar un sentimiento de confianza y conexión a su interlocutor. Se trata de una habilidad que en muchas ocasiones es innata en una persona, es simplemente su forma de ser y suelen generar un ambiente amigable y jovial allí donde vayan. Muchas personas son así por naturaleza, inmediatamente nos generan sentimientos agradables y nos sentimos más relajados y dispuestos a transmitir información. Los mejores ingenieros sociales son aquellos no fuerzan las cosas y que con una habilidad asombrosa controlan el flujo de los acontecimientos y las conversaciones, dando lugar a situaciones que les resultan favorables y muy ventajosas. Si bien suelen ser habilidades que son innatas en la mayoría de ingenieros sociales, no significa que no puedan ser desarrolladas comprendiendo cada uno los puntos vitales del Social Engineering Framework, solamente hace falta practica y mucha paciencia, pero al hablar de practica, no me refiero a utilizar SET desde casa y crear el típico Applet malicioso, me refiero a hablar con la gente que te rodea y tratar de conocer su “mindset” o conjunto de habilidades, características y rasgos psicológicos.

Ahora bien, como resulta evidente, las emociones juegan un papel central cuando hablamos de relaciones humanas. Lo que sentimos por otras personas impactan directamente en nuestro comportamiento y además, con el tremendo auge de las redes sociales, parece ser que hoy en día todo el mundo se siente mucho más a gusto expresando lo que piensan o sienten en Facebook, Twitter o otro cualquier sitio en Internet como blogs o foros que hablando personalmente con la gente. Es algo que siempre me ha parecido de lo más curioso y desde hace varios años, aprovechando la abrumadora cantidad de frases cargadas con diferentes tipos de sentimientos de personas que escriben en Internet, se ha creado un proyecto que desde mi punto de vista es uno de los mejores proyectos informáticos relacionados con el estudio y categorización de las emociones humanas, se trata de wefeelfine.org

Wefeelfine es una plataforma muy completa que se encarga de analizar blogs, foros, redes sociales con perfiles públicos y otros tipos de espacios personales en los que las personas transmiten sus ideas y se expresan, se trata de una herramienta de exploración de emociones a escala global. Además de recolectar información, su plataforma puede ser consultada en cualquier momento y admite varios tipos de filtros relacionados con el genero de las personas, edad, ciudad, o incluso una serie de emociones muy concretas, tal como se puede apreciar en las siguientes imágenes.

feeling1

Nube de sentimientos recolectados por wefeelfine.org

feeling2

Aplicando los filtros: Sentimiento=tense, Genero=Femenino, Edad=Entre 30 y 39 años, Condiciones climáticas=Todas, País=España, Fechas=Todas

Por otro lado, cuenta con varias vistas que permiten visualizar la información de la forma en la que resulte más cómoda para el usuario, tal como se indica en el apartado “movements”: http://wefeelfine.org/movements.html

Personalmente, la característica que me parece más interesante de la plataforma son los servicios REST que se encuentran definidos para que cualquier desarrollador pueda consultarlos. La API para poder invocar a dichos servicios de forma correcta se encuentra definida en el siguiente enlace: http://www.wefeelfine.org/api.html y no requiere ningún tipo de autenticación y/o autorización, son servicios abiertos que cualquiera puede utilizar en un momento dado.

Tal como se aprecia en la siguiente imagen, es posible utilizar un navegador web para invocar a cualquiera de los servicios disponibles e inspeccionar la respuesta para ver los datos que ha devuelto.

feeling3

Invocación a la API de wefeelfine desde un navegador web

Ahora bien, lo más común es crear rutinas que invoquen a dichos servicios para automatizar el proceso de consulta y en ese sentido, es posible utilizar cualquier lenguaje de programación ya que solamente es necesario realizar una petición HTTP y parsear la respuesta. El siguiente script es un buen ejemplo del uso de Python para consultar y parsear algunos de los servicios disponibles en la API de wefeelfine.

import requests 
from bs4 import BeautifulSoup 
def search(api, text): 
    response = requests.get(api) 
    soup = BeautifulSoup(response.content, 'lxml') 
    feelings = soup.feelings.find_all(&quot;feeling&quot;) 
    print text 
    for feeling in feelings: 
        if feeling.has_key(&quot;feeling&quot;): 
            print &quot;[*] Sentimiento: %s &quot; %(feeling['feeling']) 
        if feeling.has_key(&quot;sentence&quot;): 
            print &quot;[*] Sentencia: %s &quot; %(feeling['sentence'])                
        if feeling.has_key(&quot;postdate&quot;): 
            print &quot;[*] Fecha: %s &quot; %(feeling['postdate'])                
        if feeling.has_key(&quot;posturl&quot;): 
            print &quot;[*] URL Origen: %s &quot; %(feeling['posturl'])                
        print &quot;\n&quot; 
search(&quot;http://api.wefeelfine.org:8080/ShowFeelings?display=xml&amp;returnfields=imageid,feeling,sentence,posttime,postdate,posturl,gender,born,country,state,city,lat,lon,conditions&amp;limit=10&quot;,&quot;[*] Consultando los ultimos 10 sentimientos registrados&quot;) 


search(&quot;http://api.wefeelfine.org:8080/ShowFeelings?display=xml&amp;returnfields=imageid,feeling,sentence,posttime,postdate,posturl,gender,born,country,state,city,lat,lon,conditions&amp;feeling=sad&amp;city=madrid&amp;limit=10&amp;gender=female&quot;, &quot;[*] Consultando los ultimos 10 sentimientos registrados de personas con genero 'femenino' que se sienten 'felices'&quot;) 

La función “search” es la que se encarga de utilizar la librería “requests” para ejecutar una petición HTTP contra el servicio REST indicado y parsear la respuesta utilizando la librería BeautifulSoup, la cual se encuentra en formato XML.

Es un script muy simple y que refleja la cantidad de información que se puede extraer de la plataforma. Aunque muchos de los sentimientos registrados se encuentran en ingles, los sentimientos expresados en castellano en blogs, redes sociales y cualquier otro sitio web en Internet, quedan prácticamente excluidos de la plataforma, ¿Acaso os estoy dando ideas para un próximo proyecto? ;-).
Es una plataforma muy interesante y el estudio realizado por los investigadores que han montado la plataforma es simplemente brillante y para aquellas personas a las que nos interesan los temas relacionados con la informática, el hacking y las ciencias humanas como la filosofía y la psicología, puede resultar muy entretenido. Os recomiendo su lectura: http://wefeelfine.org/wefeelfine.pdf

Un Saludo y Happy Hack!

Creando sitios ocultos en TOR de forma programática con TxTorCon

diciembre 4, 2014 1 comentario

Anteriormente he hablado sobre el uso de Stem para controlar instancias de TOR, una potente librería que no solamente se aprovecha del protocolo de control de TOR para la administración remota de una instancia en ejecución, sino que también cuenta con algunas utilidades para arrancar una nueva instancia con configuración personalizada, descargar y parsear los descriptores emitidos por las autoridades de directorio, entre muchas otras funcionalidades útiles. Es una librería que se explota bastante bien en Tortazo, una de las herramientas que he escrito para realizar pruebas de penetración contra repetidores de salida y servicios ocultos en la red de TOR.
Aunque Stem es una librería muy potente, existen otras alternativas que cuentan con las mismas capacidades y en esta ocasión, voy a hablar sobre TXTORCON.

¿Por qué TxTorCon? Porqué se trata de una implementación del protocolo de control de TOR basada en Twisted y a diferencia de Stem, TxTorCon es una implementación asíncrona. Una librería como TxTorCon permitirá crear programas reactivos que se encargarán de ejecutar acciones sobre una o varias instancias de TOR ante una lista de eventos predefinidos.

En esta entrada se verá cómo se puede utilizar TxTorCon para crear servicios ocultos en TOR de forma programática y aunque lo que se verá a continuación también se puede hacer con Stem, se trata de un ejercicio practico muy interesante que servirá para conocer los elementos básicos y la “metodología” que se debe seguir cuando se programa con esta librería.

Antes de continuar, se recomienda al lector tener claros los conceptos básicos sobre la configuración de una instancia de TOR y conocer bastante bien las propiedades admitidas en el fichero “torrc”, aunque crear un servicio oculto no es una tarea compleja ya que solamente es necesario definir la opción de configuración “HiddenService” en el fichero de configuración “torrc” tantas veces como servicios ocultos se desee crear, lo que si que puede ser complicado es mantener el servicio oculto correctamente securizado, pero eso es un tema del que se hablará en un próximo artículo.

En primer lugar, es importante conocer el uso de la clase “txtorcon.TorConfig” ya que en dicha clase es donde definen todos los elementos de configuración de una instancia de TOR y dicho elemento puede ser utilizado para levantar la instancia de forma programática utilizando TxTorCon.

import txtorcon
config = txtorcon.TorConfig()
config.SOCKSPort = 9051
config.ORPort = 4443
…..
config.save()

La clase “txtorcon.TorConfig” maneja un diccionario interno con las propiedades que se pueden definir en un fichero de configuración de TOR, con lo cual el programador debe definir cada propiedad como un atributo de instancia.

Ahora bien, para definir uno o varios servicios ocultos, es necesario crear un listado de instancias de la clase “txtorcon.HiddenService”. Dicho listado se almacenará en la variable “HiddenServices” de la instancia de “txtorcon.TorConfig” creada previamente.
La siguiente función servirá para definir los detalles de configuración básicos para iniciar una instancia de TOR con un servicio oculto.

import txtorcon
import functools
import tempfile
import os
from twisted.internet import reactor 

def createTemporal():
    tempDir = tempfile.mkdtemp(prefix='torhiddenservice')
    reactor.addSystemEventTrigger('before', 'shutdown',
functools.partial(txtorcon.util.delete_file_or_tree, tempDir))
    return tempDir 

def configuration(hiddenserviceDir, serviceInterface,
servicePort=8080, hiddenservicePort=80):
    if hiddenserviceDir is None:
        print "[+] HiddenServiceDir not specified... Generating
a temporal file."
        hiddenserviceDir = createTemporal()
    if os.path.exists(hiddenserviceDir) == False:
        print "[+] The HiddenServiceDir specified does not
exists... Generating a temporal file."
        hiddenserviceDir = createTemporal()
    config = txtorcon.TorConfig()
    config.SOCKSPort = 9051
    config.ORPort = 4443
    config.HiddenServices = [txtorcon.HiddenService(config,
hiddenserviceDir, ["%s %s:%s" %(str(hiddenservicePort),
serviceInterface, str(servicePort))] )]
    config.save()
    return config 

configuration('/home/adastra/Escritorio/django-hiddenservice',
'127.0.0.1')

La función “configuration” se encarga de recibir como argumento todos los elementos necesarios para establecer un servicio oculto en la configuración definida en el objeto “txtorcon.TorConfig” y posteriormente dicho objeto es retornado. Por otro lado, la función “createTemporal” es invocada internamente por la función “configuration” con el fin de devolver un directorio temporal para el servicio oculto en el caso de que el directorio indicado por parámetro sea invalido.

Ahora que la configuración se encuentra preparada, el siguiente paso consiste en utilizarla para iniciar la instancia de TOR en cuestión.

import txtorcon
import functools
import tempfile
import os
from twisted.internet import reactor 

def createTemporal():
    tempDir = tempfile.mkdtemp(prefix='torhiddenservice')
    reactor.addSystemEventTrigger('before', 'shutdown',
functools.partial(txtorcon.util.delete_file_or_tree, tempDir))
    return tempDir 

def configuration(hiddenserviceDir, serviceInterface,
servicePort=8080, hiddenservicePort=80):
    if hiddenserviceDir is None:
        print "[+] HiddenServiceDir not specified... Generating a temporal file."
        hiddenserviceDir = createTemporal()
    if os.path.exists(hiddenserviceDir) == False:
        print "[+] The HiddenServiceDir specified does not exists... Generating a temporal file."
        hiddenserviceDir = createTemporal()
    config = txtorcon.TorConfig()
    config.SOCKSPort = 9051
    config.ORPort = 4443
    config.HiddenServices = [txtorcon.HiddenService(config,hiddenserviceDir, ["%s %s:%s" %(str(hiddenservicePort),serviceInterface, str(servicePort))] )]
    config.save()
    return config 

def updates(prog, tag, summary):
    print "%d%%: %s" % (prog, summary) 

def setup_complete(config, proto):
    print "TOR Instance started!" 

def setup_failed(arg):
    print "SETUP FAILED", arg
    reactor.stop() 

def startTor(config):
    d = txtorcon.launch_tor(config, reactor,progress_updates=updates)
    d.addCallback(functools.partial(setup_complete, config))
    d.addErrback(setup_failed)
    reactor.run()
torrc = configuration('/home/adastra/Escritorio/hidden_service_django','127.0.0.1')
startTor(torrc)

En esta nueva versión del script se ha incorporado la función “startTor”, la cual se encarga de utilizar la configuración retornada por la función “configuration” para iniciar TOR. Como se puede apreciar, dicha función emplea la utilidad “txtorcon.launch_tor” enviando como argumentos, la configuración de TOR, el reactor de Twisted y una función de callback para procesar cada uno de los eventos producidos durante proceso de inicio. Finalmente, se adicionan dos funciones más en el caso de que el proceso de arranque haya ido bien o en el caso de fallo.

Después de ejecutar el script anterior, se podrá ver por consola algo muy similar a lo que se enseña en la siguiente imagen.

txtorcon1

El script puede parecer complejo pero tal como se ha explicado anteriormente, si se conoce el funcionamiento de Twisted y las funcionalidades básicas de TxTorCon, no resulta tan complicado de comprender.
Hasta este punto se asume que en la máquina local se encuentra un servicio levantado y esperando conexiones, más concretamente en el puerto “8080”. Evidentemente, dado el escenario anterior es necesario levantar un servidor web con Tomcat, una aplicación con Django o cualquier otro servicio en dicho puerto, pero dadas las características de Twisted, también es posible crear un servidor web simple directamente desde el script y de esta forma, se contará con una herramienta completamente funcional que puede levantar un servicio oculto sin depender de ningún programa externo (excepto el propio ejecutable de TOR).

import txtorcon
import functools
import tempfile
import os
from twisted.web import static, resource, server
from twisted.internet import reactor
from twisted.internet.endpoints import TCP4ServerEndpoint 

def createTemporal():
    tempDir = tempfile.mkdtemp(prefix='torhiddenservice')
    reactor.addSystemEventTrigger('before', 'shutdown',
functools.partial(txtorcon.util.delete_file_or_tree, tempDir))
    return tempDir 

def configuration(hiddenserviceDir, serviceInterface,
servicePort=8080, hiddenservicePort=80):
    if hiddenserviceDir is None:
        print "[+] HiddenServiceDir not specified... Generating a temporal file."
        hiddenserviceDir = createTemporal()
    if os.path.exists(hiddenserviceDir) == False:
        print "[+] The HiddenServiceDir specified does not exists... Generating a temporal file."
        hiddenserviceDir = createTemporal()
    config = txtorcon.TorConfig()
    config.SOCKSPort = 9051
    config.ORPort = 4443
    config.HiddenServices = [txtorcon.HiddenService(config,hiddenserviceDir, ["%s %s:%s" %(str(hiddenservicePort),serviceInterface, str(servicePort))] )]
    config.save()
    return config 

def updates(prog, tag, summary):
    print "%d%%: %s" % (prog, summary) 

def setup_complete(config, proto):
    print "TOR Instance started!" 

def setup_failed(arg):
    print "SETUP FAILED", arg
    reactor.stop() 

def startTor(config):
    #Starting a simple web site.
    root = static.File('/opt/WebSite')
    site = server.Site(root)
    hs_endpoint = TCP4ServerEndpoint(reactor, 8080,interface='127.0.0.1')
    hs_endpoint.listen(site)
    d = txtorcon.launch_tor(config, reactor,progress_updates=updates)
    d.addCallback(functools.partial(setup_complete, config))
    d.addErrback(setup_failed)
    reactor.run() 

torrc =configuration('/home/adastra/Escritorio/django-hiddenservice','127.0.0.1')
startTor(torrc)

El programa anterior solamente añade los elementos necesarios para declarar un servidor web cuyo directorio raíz es “/opt/WebSite”. Dicho servidor web se levantará en el puerto 8080 en la interfaz de red local, tal como se ha definido en la configuración del servicio oculto. Con todo esto, después de que la instancia de TOR se levante y se creen los ficheros correspondientes al dominio “onion” y a las claves del servicio, cualquier cliente que intente ingresar por dicha la dirección onion del servicio oculto, podrá ver los contenidos del servidor web que se ha iniciado utilizando Twisted. La siguiente imagen enseña algo muy similar a lo que el usuario final verá en su navegador.

txtorcon2

Como se puede apreciar, al acceder a la dirección onion del servicio oculto, se pueden visualizar los contenidos del directorio “/opt/WebSite”, que es el directorio que se ha indicado como raíz del servidor web.

Aunque aquí se ha enseñado como crear un servicio web en la red de TOR, también es posible crear cualquier otro tipo de servicio siguiendo exactamente la misma dinámica que se ha explicado aquí, como por ejemplo por un servidor SSH/SFTP con Paramiko, un servidor FTP o incluso un servidor SMB. Tienes a tu disposición muchas alternativas a la hora de automatizar la creación de servicios ocultos en la web profunda de TOR.

Un Saludo y Happy Hack!

Cookies persistentes para tracear la navegación de un usuario con EverCookie

diciembre 2, 2014 2 comentarios

Las cookies son un elemento de lo más común en las aplicaciones web actuales y seguramente el lector sabe perfectamente cómo funcionan, sin embargo, para aquellos que no lo saben, basta con comentar que las cookies son ficheros temporales que se almacenan en el navegador del cliente y permiten simplificar el proceso de identificación y posterior comunicación con una aplicación web. Dado que HTTP es un protocolo sin estado, el uso de las cookies es realmente útil para conservar información que se ha intercambiado previamente entre cliente y servidor. Prácticamente todos los sitios web en Internet hacen uso de las cookies, sin embargo, la información que se almacena en ellas puede ser utilizada para identificar y perfilar a un usuario. Con las cookies se puede identificar la navegación de un usuario por un sitio web y de esta forma, tracear las páginas que visita, conociendo sus intereses y otras características. Esto no es necesariamente algo negativo, de hecho, puede ser muy beneficioso para el usuario ya que de esta forma el sitio web puede conocer sus preferencias y actuar en consecuencia para ofrecerle los contenidos que más le puedan interesar. Por ejemplo, en el caso de una tienda online de ropa, se pueden utilizar las cookies para saber si el usuario ha ingresado previamente en el sitio web y si ese es el caso, presentar ofertas o productos personalizados dependiendo de las páginas que ha visitado. No obstante, cuando dicha información es compartida con otros sitios web ajenos, es cuando muy posiblemente se está violando la privacidad del usuario, en el caso de que no haya dado su consentimiento expreso de compartir con otros sitios web las páginas que ha visitado, la información que ha podido ingresar, etc. Esto es común en sitios web dedicados a la publicidad y el marketing, los cuales utilizan la información compartida por otros sitios web para perfilar gustos, afinidades y tendencias de los usuarios, así como identificarles.
Ahora bien, las cookies son elementos que se pueden eliminar muy fácilmente del navegador y en la mayoría de casos no representarán ningún problema, sin embargo, las cookies persistentes, a diferencia de las cookies tradicionales, utilizan múltiples espacios de almacenamiento en el cliente y de esta forma, resulta muy complicado eliminar toda la información que almacena una cookie de estas características del navegador. Para que el lector se haga una idea, una cookie persistente puede almacenar información en el espacio estándar de cookies, en el espacio de “websql” del navegador, en el espacio de almacenamiento local, global y de sesión, en cookies flash (objetos locales compartidos), en la cache del navegador, entre otros. Cuando el usuario elimina dichas cookies desde uno o varios de estos espacios, pero no de todos, el sitio web que ha implementado la cookie persistente es capaz de detectar que se ha intentado eliminar la información de la cookie de uno o varios de dichos espacios de almacenamiento y se encarga de reestablecer los valores, revirtiendo la acción de borrado realizada por el usuario. Es decir, el usuario tiene que eliminar la información de la cookie de todos los sitios donde se ha guardado y si le falta al menos uno por limpiar, dichos valores volverán a ser replicados en todas las zonas de almacenamiento utilizadas por la cookie persistente.

Las cookies persistentes representan una forma muy agresiva de tracear la navegación de un usuario y una de las más conocidas es la que ha desarrollado el investigador Samy Kamkar (también conocido por el desarrollo del virus “Samy”) la cual recibe el nombre de “evercookie”.

Uso de Evercookie

Se trata de una API que cuenta con varios elementos que desde el punto de vista técnico resultan muy interesantes, pero que desde una perspectiva practica, se relacionan más con campañas de marketing agresivas y con el perfilado de los usuarios, actividades que suelen ser consideradas ilegales en algunos países. Esta herramienta cuenta con una API en Javascript que permite crear cookies persistentes que a la fecha de redactar este artículo, se incluyen en las siguientes zonas del navegador del cliente.

– Cookies HTTP estándar.

– Objetos compartidos locales (Cookies Flash).

– Almacenamiento en Silverlight

– Almacenamiento de cookies en formato RGB usando la etiqueta “canvas” de HMTL5

– Múltiples ubicaciones de almacenamiento definidas en la especificación de HTML5 (Almacenamiento local, global, sesion, WebSQL con SQLite y WebSQL con IndexedDB).

– Almacenamiento persistente en JNLP PersistenceService.

Para utilizar esta librería se debe descargar desde el repositorio de GitHub ubicado en la siguiente ruta: https://github.com/samyk/evercookie y posteriormente, se puede comenzar a utilizar la API de Javascript que permite crear páginas web que insertan una cookie de evercookie en los clientes que acceden a dichas páginas.

En esta entrada voy a explicar cómo utilizar esta librería para crear cookies persistentes y vamos a ver algunas de las zonas en las que se almacenan las cookies que se van creando.

Después de descargar o clonar el proyecto desde el repositorio de GitHub, se debe crear un fichero HTML que será incluido en un servidor web como Apache.
En este caso concreto, con el objetivo de probar el funcionamiento de Evercookie, se ha creado un directorio llamado “test” en el directorio “htdocs” de un servidor web Apache y en dicho directorio se han incluido los siguientes recursos, los cuales son los que se han obtenido del proyecto de Evercookie.

evercookie1

El contenido inicial de la página “index.html” es el que se indica a continuación y como se puede apreciar, no solamente incluye el script “js/evercookie.js”, sino que también se hace uso de la API para crear y almacenar cookies persistentes.


&lt;html&gt; 

&lt;head&gt; 

    &lt;script type=&quot;text/javascript&quot;
src=&quot;js/swfobject-2.2.min.js&quot;&gt;&lt;/script&gt; 

    &lt;script type=&quot;text/javascript&quot;
src=&quot;js/evercookie.js&quot;&gt;&lt;/script&gt; 

    &lt;script&gt; 
    var ec = new evercookie({ 
    	baseurl: '/test', 
    	asseturi: '/assets', 
    	phpuri: '/php' 
    }); 
  ec.set(&quot;user&quot;, &quot;adastra&quot;); 
  ec.get(&quot;user&quot;, function(value) { alert(&quot;Cookie value is &quot; + value) }); 
  function getCookie(best_candidate, all_candidates) 
  { 
    for (var item in all_candidates) 
      document.write(&quot;Storage mechanism &quot; + item + 
        &quot; returned &quot; + all_candidates[item] + &quot;
votes&lt;br&gt;&quot;); 
    } 
    ec.get(&quot;user&quot;, getCookie); 
    &lt;/script&gt; 
&lt;/head&gt; 
&lt;body&gt; 
&lt;h1&gt;evercookie!&lt;/h1&gt; 
&lt;/body&gt; 
&lt;/html&gt;

Lo primero que hace es crear un objeto del tipo “evercookie” indicando la URI del sitio web y la ubicación de los recursos necesarios para crear la cookie. Posteriormente, las funciones “set” y “get” permiten crear y recuperar un cookie respectivamente. Como se puede apreciar, la función “get” permite definir una función de callback que tratará el valor de una cookie que se ha guardado previamente con un identificador determinado.

Aunque el código puede parecer simple, en el momento de probar la librería he experimentado algunos problemas relacionados con la adición de capas en el árbol DOM de la página, ya que al parecer, cuando Evercookie se ejecuta sobre el navegador Chrome, Evercookie intenta añadir elementos al cuerpo de la página antes de que el árbol DOM se encuentre correctamente creado, lo cual da como resultado errores similares a los que se pueden ver en la siguiente imagen.

evercookie2

La solución a este problema pasa simplemente por realizar una verificación previa del árbol DOM antes de intentar insertar elementos en cualquier tag. Por ejemplo, en la linea 956 del fichero “js/evercookie.js” veremos el siguiente fragmento de código:

      if (append) { 
        document.body.appendChild(el); 
      }

Dado que en este punto el valor de “document.body” es “null”, la invocación a la función “appendChild” es invalida y produce un error. Es necesario realizar una validación previa antes de invocar a la función “appendChild”, algo tan simple como lo que se enseña a continuación será suficiente.

      if (append) { 
        if(document.body != null){
          document.body.appendChild(el); 
        }
      }

Después de corregir todos los errores que van saliendo y que están relacionados con el mismo problema que se ha explicado anteriormente, se puede apreciar como la cookie se crea en diferentes secciones del navegador.

evercookie3

Evercookie en el “Session Storage” del navegador

evercookie4

Evercookie en el “Local Storage” del navegador

evercookie5

Evercookie en la base de datos SQLite del navegador

Aunque se intente eliminar las cookies utilizando el procedimiento habitual de limpiar cache, formularios guardados, cookies, etc. Evercookie vuelve a crearse automáticamente en cada una de las zonas de almacenamiento indicadas anteriormente, convirtiéndola en un elemento difícil de remover del navegador web. Difícil, pero no imposible.
En un próximo articulo se hablará en detalle sobre las ubicaciones en las que se almacena evercookie y cómo eliminar una cookie persistente creada previamente. Por otro lado, también se hablará de implementaciones de evercookie en NodeJS y Django.

Un Saludo y Happy Hack!

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!

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 1.536 seguidores

A %d blogueros les gusta esto: