23 octubre 2014

Controla las conexiones de tu Mac con Little Snitch.


Little Snitch es una herramienta que permite controlar las conexiones que realiza tu Mac con otras redes. Esta aplicación, desarrollada por la compañía Objective Development, es un corta fuegos tradicional que crea sus reglas basadas en acciones que solicita al usuario cada vez que detecta un intento de acceso nuevo o no configurado. De esta forma, en un par de días tras su instalación, se obtiene una línea base que será afinada según las nuevas necesidades del día a día.

También es un monitor de conexiones que identifica el uso que hace de la red cada una de las aplicaciones, ancho de banda consumido y la velocidad de transferencia.

Monitor de red y conexiones por aplicación.
El monitor de red es histórico y sirve como herramienta para visualizar rápidamente horas con picos de tráfico y anchos de banda consumidos.

De esta herramienta destaca la facilidad de uso para que cualquier persona pueda usarla y aquellos más avanzados obtengan toda la información de conexión, aunque los primeros días puede ser un poco estresante con tanta pregunta.

Detalle del proceso TweetDeck y conexiones establecidas
El panel de preferencias es sencillo y configura opciones genéricas, como propiedades de visualización, arranque,  actualizaciones o la seguridad de acceso a la  propia aplicación.

Preferencias de configuración

El interfaz para editar reglas es muy completo. Demasiado para un usuario no experimentado, pero permite a los más avanzados crear reglas, proteger otras o eliminar aquellas que sean redundantes. Seguro que ideal para cualquier lector de este blog.

Otra opción curiosa, conocida como reglas de login, es la que permite que se acepte determinado tráfico cuando el sistema se enciende y antes de que el usuario se autentique.

Vista general del editor de reglas

A la hora de solicitar la aceptación o denegación de una nueva conexión y por lo tanto, la creación de una regla, nos obliga a que se haga basada en el puerto de destino, el dominio o la combinación de ambos: dominio y puerto, además la duración de esa regla, como por ejemplo "para siempre", "hasta que se cierre", "durante 1 hora", "durante 15 minutos", etc.

En caso de que no sepamos cual es la aplicación que intenta generar la conexión, si se pulsa en la interrogación de la parte inferior, el propio Little Snitch comprueba la firma y origen del binario. Esta característica tiene como propósito identificar procesos sospechosos o malware.

Ventana solicitando acción para Permitir o Denegar una conexión (netcat) y comprobación del binario
Aunque es curioso el ejemplo de la captura anterior, ya que la aplicación iTerm es solo el terminal que invoca el ejecutable "nc" y pese a que en el título de la ventana de dialogo se identifica como "nc" la firma se realiza sobre el propio iTerm.

Dejo para el final una buena sorpresa que me he llevado haciendo uso de ella, con un par de clicks es posible capturar el tráfico generado por una aplicación cualquiera en un fichero PCAP. Personalmente, me ha solventado problemas con otras herramientas rapidísimamente.

Capacidades de registro en fichero PCAP de las conexiones de un proceso.

El único punto negativo de Little Snitch es que es un producto comercial y en su versión para un único usuario tiene un precio de 30€. Para adquirirlo hay que ir a la propia tienda del fabricante. 


Leer más...

22 octubre 2014

VI Jornadas sobre Ciberamenazas y Ciberdefensa


Mañana 23 de octubre se celebra en la Universidad Europea de Madrid las VI Jornadas sobre ciberamenazas y ciberfensa de forma gratuita para todo aquel que quiera asistir.

El programa tiene una estructura similar a la de otros años, en el que después de unas interesantes ponencias de distintos miembros relevantes en la Estrategia Española de Seguridad se hará una demostración práctica de técnicas de ciberamenzas. En este caso, de la mano de Raúl Siles.

Copio el programa que se ha publicado en la página de la UEM.
  

16:00 Apertura y Bienvenida 


Dr. D. Miguel Gómez Navarro, Director de la Escuela Politécnica de la Universidad Europea de Madrid 
Dr. D. Luis de Salvador Carrasco, Director de la Jornada 


16:30 Estrategia Española de Seguridad (EES)


Introducción a la Estrategia Española de Ciberdefensa - D. David Ramírez Morán – Analista del Instituto Español de Estudios Estratégicos


La Guardia Civil Frente a las Ciberamenazas - T.Col. D. Juan Salom Clotet – Responsable de Seguridad de la Información de la Guardia Civil Desarrollo de software para Defensa: un deporte de riesgo - D. Pedro Bernad Silva – Jefe del Centro de Obtención y Mantenimiento de Sistemas de Información (CCOMSI) del Ministerio de Defensa


18:30 Demostraciónes


Demostración de ataques sobre dispositivos móviles mediante redes Wi-Fi empresariales - Raúl Siles - Fundador y analista de seguridad de DinoSec



20:00 Clausura de la jornada 

Dr. Dña. Maite Villalba de Benito, Directora Académica del Master en Seguridad TIC - Universidad Europea de Madrid


Dr. D. Luis de Salvador Carrasco, Director de la Jornada



Lugar de Celebración: Universidad Europea de Madrid, Auditorio. Edificio B. Campus de Villaviciosa de Odón, c/ Tajo, s/n.

Más información: Coordinación Académica (victoria.pascual@uem.es) Esta actividad ha recibido una subvención de la Secretaría General de Política de Defensa del Ministerio de Defensa


Esta actividad ha recibido una subvención de la Secretaría General de Política de Defensa del Ministerio de Defensa
Leer más...

21 octubre 2014

Evadiendo implementaciones de certificate pinning en Android

Pongamos la siguiente situación: estamos realizando el análisis de una aplicación en la que nos interesa ver las comunicaciones HTTP/S que realiza, para ello disponemos de un dispositivo Android rooteado en el que redirigimos el tráfico de estos protocolos a un web proxy del que tenemos instalado su certificado en el dispositivo.

Todo está configurado correctamente pero algo falla, la aplicación nos indica que no puede establecer comunicación con el servidor de destino y confirmamos que sin redirigir al web proxy la aplicación funciona perfectamente. Puede que nos hayamos encontrado con una implementación de certificate pinning, pero esto no nos va a detener.

Llevemos a la práctica un método de evasión sobre un ejemplo real cogido de Google Play.

La aplicación de ejemplo, eTools


Figura 1

eTools se presenta como una herramienta orientada a realizar búsquedas en la web utilizando los motores más conocidos de manera segura y totalmente privada, implementando entre otros mecanismos de seguridad un certificate pinning.

Preparamos el escenario que hemos descrito anteriormente (dispositivo rooteado + Proxydroid +  Burp + certificado Burp instalado en dispositivo), probamos a realizar una búsqueda utilizando la aplicación y confirmamos como el certificate pinning entra en juego y no nos permite realizar la búsqueda bajo estas condiciones:

Figura 2

Evasión por parcheo de código

Para saltarnos esta restricción el proceso que vamos a seguir se resume en descargar el APK y analizar su código, anular las llamadas que comprobarán el certificate pinning, re-empaquetar la aplicación y reinstalar.

Vamos con ello:

1. Descargamos el APK del dispositivo

Figura 3

2. Buscamos cadenas que apunten al uso de la clase TrustManager

Utilizando dex2jar podemos extraer el JAR del APK y utilizando JD-GUI podremos ver el código Java. Ya desde JD-GUI podemos comenzar nuestras búsqueda por el código:

Figura 4

Como vamos viendo, el código se encuentra ofuscado y puede llegar a complicarnos el análisis, aunque veremos que en este caso tenemos suerte ya que si abrimos la clase "a" encontraremos claramente que es la implementación de la interfaz X509TrustManager:

Figura 5

El código anterior nos deja ver la clave pública contra la que se validará cuando se realice la petición HTTPS. Tenéis información más detallada sobre esta implementación en la web de OWASP.

Por otro lado si miramos el otro resultado de la búsqueda en JD-GUI, la clase "c", encontraremos en ella el método que se encarga de realizar la petición por HTTPS:

Figura 6
He remarcado las partes más relevantes:
  • El primer bloque declara y asigna un array compuesto por la implementación de X509TrustManager. Este array se pasa como parámetro al objeto SSLContext que se utilizará para crear la conexión HTTPS.
  • En el segundo bloque se define que se utilizará la implementación X509TrustManager para la verificación.

En este punto la situación es clara, hay que anular en el método de la Figura 6 todo rastro de uso de la clase "a" si queremos evadir el certificate pinning implementado.

3. Modificamos el código

Tendremos que desensamblar el código Jasmin del APK para modificarlo, así que podéis seguir el paso a paso desde la documentación de dex2jar ModifyApkWithDexTool o utilizar el script modify.py que os comentaba en el artículo sobre inyección de Meterpreter en aplicaciones.

Si optáis por el script, saltaremos el primer paso ya que no necesitamos tocar nada en el AndroidManifest.xml y nos pararemos a modificar el código en el segundo paso:

Figura 7

Respecto a la modificación de código vamos atacar al punto más débil, la clase "c" en su método "a" encargado de gestionar la conexión por HTTPS.

Figura 8


Si recordamos la figura 6, en la línea de código "localSSLContext.init(...)" se pasaban dos valores nulos y el array de TrustManager. En nuestro caso para anularlo vamos a pasar en lugar del array otro valor null, de modo que sustituiremos el valor de la línea 469 por aconst_null .

También en la figura 6 veíamos como se definía el uso de la clase "a" para verificar el hostname, en este caso lo que haremos será eliminar las líneas 484, 485 y 486 para anular esa parte del código.

Finalmente nos debería quedar algo así:

Figura 9

Ya tenemos preparado el código modificado, sólo queda re-empaquetar y firmar el APK. Si estabais usando el script modify.py sólo tendréis que guardar el código modificar y dar a enter.

4. Probamos nuestra obra

Reinstalamos la aplicación:

Figura 10
Activamos Proxydroid, abrimos la aplicación y realizamos una búsqueda:

Figura 11

Perfecto, ya estamos capturando las comunicaciones:

Figura 12


Conclusiones

Realizar certificate pinning en nuestras aplicaciones puede aportarnos una capa más de seguridad, pero debemos entenderlo como una capa más y no delegar en esta técnica la seguridad de nuestras comunicaciones ya que como hemos visto no la hace inmune a su análisis.

Desde el punto de vista del ataque realizado, podría haberse complicado el escenario si hubiéramos encontrado una ofuscación más fuerte o si se hubiera incluido algún método de validación de código en tiempo de ejecución que debidamente ofuscado nos llevara a dedicar más tiempo de reversing (aunque incluso ante estas contra-medidas quedaría la posibilidad de aplicar otras técnicas de hooking y debugging).

Artículo cortesía de Miguel Ángel García
Leer más...

20 octubre 2014

Deshabilita el envío de tus búsquedas en Spotlight a Apple

Ya ha llegado Yosemite, el último sistema operativo de Apple que incluye increíbles y asombrosos cambios(tm). Entre ellos, las nuevas funcionalidades de su panel de búsqueda "Spotlight" que también permite lanzar aplicaciones y decenas de cosas más

El problema de esta asombrosa herramienta es que entre sus nuevas "características" han añadido el envío de las búsquedas que se hagan en ella a la compañía de la manzana. Y esto lo hace de forma automática si expresamente no se modifica esta configuración.

En las preferencias de la aplicación, si se pulsa sobre "About Spotlight Suggestions & Privacy", se puede observar el siguiente texto.
Ventana de información de "Privacy" de las preferencias de Spotlight. Fuente: Fix-MacOSX.com

Para deshabilitar el envío de esta información hay que abrir las preferencias de Spotlight y desmarcar los cuadros de selección de "Spotlight suggestions" y "Bing Web Searches".

Preferencias de configuración de Spotlight

Si somos de consola, gracias a la página web Fix-MacOSX.com, es posible hacerlo con un par de comandos dentro de una terminal:

$ curl -O https://fix-macosx.com/fix-macosx.py
$  /usr/bin/python fix-macosx.py

Leer más...

19 octubre 2014

Enlaces de la SECmana - 246

Leer más...

17 octubre 2014

Diversos usos de las cámaras térmicas


Leo en la lista de SecurityByDefault un artículo relativo al uso de las imágenes térmicas en vigilancia digital.

Como introducción decir que Wikipedia define la radiación infrarroja como “un tipo de radiación electromagnética y térmica, de mayor longitud de onda que la luz visible”, lo que significa que no puede ser vista por el ojo humano. Esto puede ser aprovechado, con la debida tecnología, para detectar algo a través de la refracción de ésta sobre los diferentes objetos que nos rodean.

Un ejemplo muy extendido de ésta característica electromagnética es aplicado en seguridad para la detección de personas mediante sensores volumétricos. La variación de temperatura en un punto o zona determinada puede ser interpretada como que una persona está accediendo por un lugar no permitido, activándose la alarma.

Pero el artículo de hoy se refiere al uso de las cámaras térmicas.

Se pueden encontrar diferentes tipos de cámaras:
  1. En función del tipo de detector
    1. Detectores criogenizados: El detector está al vacío y a muy baja temperatura. Más sensible y preciso.
    2. Detectores ambiente: Más barato y menor sensibilidad.
  2. En función del origen de la radiación
    1. Activas: Emiten un haz infrarrojo y analizan su exposición.
    2. Pasivas: Analizan la exposición de la emisión natural del cuerpo en cuestión.
  3. En función de su representación
    1. Monocromáticas: Muestran la diferencia de calor entre un cuerpo y su entorno
    2. Policromáticas: Representa mediante colores escogidos arbitrariamente un rango mayor de diferentes temperaturas.

Siguiendo con sus usos, todos conocéis su utilización en entornos de militares y policiales. Además de proyectar imágenes en entornos poco luminosos pueden ayudar a unidades de emergencia a detectar personas en extensiones amplias, como náufragos en el mar o también se utilizan en la lucha contra la inmigración ilegal o el contrabando.

En entornos industriales pueden detectar piezas deformadas o susceptibles de fallo o rotura, ya que la pieza o parte de ella puede mostrar un contraste de calor (y color) producido, por ejemplo, por un desgaste de la misma. Ayudan a descubrir fuga de gases en gaseoductos, oleoductos, plantas, etc.. También pueden controlar la eficiencia energética de un edificio, descubriendo zonas de escape de calor.

En medicina pueden detectar patologías, disfunciones o trastornos, cánceres, etc. Sin entrar en detalle, algunos cánceres manifiestan una zona de mayor calor por diversas razones. Ahora que está muy en boga, sirven para comprobar la temperatura de personas en aduanas y fronteras y así detectar posibles casos de enfermedades contagiosas, como en el caso de Ébola (eso sí una vez manifestadas la enfermedad, gracias al mecanismo de la fiebre).

Son muchos usos los que se les puede dar a este tipo de herramientas.

El artículo, base de este otro, para quienes no lo hayan leído es muy sencillo muestra imágenes de objetos inanimados cuyo espectro de calor cambia en función de su uso.

Por ejemplo, gafas con cámara incorporada. La imagen muestra como la temperatura es claramente diferente ahí donde se localiza el dispositivo. Para los grupos mafioso es una buena herramienta. 

Escaneando al poli encubierto, se pueden descubrir micro cámaras y micrófonos escondidos. Adiós a desabrochar camisas en busca de micros… es de muy mal gusto.

Me atrae especialmente cuando muestra el típico teclado de control de acceso, donde se observa el uso de las teclas que han sido recientemente presionadas. No se sabe la combinación pero se acota a un número determinado de dígitos.

Otro ejemplo más ilustrativo son las cámaras de circuito cerrado de televisión (CCTV). El artículo muestra cómo se podría llegar a deducir si están en uso o no mediante la irradiación del calor que desprenden.


Hay muchas cámaras en el mundo, cuyo objetivo es más disuadir que monitorizar. Por ejemplo, metro de Madrid cuenta con 4500 cámaras, se podría deducir que no todas están operativas. Así que si alguien tiene los recursos necesarios (cámaras térmicas, tiempo, ganas, etc.) puede pasearse por sus 292 estaciones haciendo una estadística de cuales están en uso así como el posible algoritmo de utilización }:D.


Para las empresas de seguridad que realizan seguimientos también les resultará útil el artículo. Ya no será necesario posar la mano sobre el capó para saber si el coche ha sido recientemente utilizado. La tecnología les puede echar una "mano" en este caso y hacerlo de forma remota.

Como bien dice el artículo, este tipo de análisis está sujeto a las condiciones climatológicas y no todos los dispositivos disipan el calor del mismo modo. Para evitar esto existen tejidos y materiales que mitigan o no reflejan los infrarrojos con lo que se podría llegar a camuflar (contramedida).

Llegados a este punto el lector puede pensar que todo esto está muy bien pero es difícil hacerse con una… pues no!. Si tienes un iPhone también puedes tener tu cámara térmica de bolsillo ;).

Contribución por Ricardo Ramos
Leer más...

15 octubre 2014

Vulnerabilidad CRÍTICA en SSL (POODLE)

Desde el punto de vista de la seguridad informática, esta semana está siendo muy pero que muy movidita en cuanto a fallos y vulnerabilidades publicadas.

Hoy, desde Google, tres investigadores: Bodo Möller, Thai Duong and Krzysztof Kotowicz han publicado los detalles de un nuevo fallo que, definitivamente, va a llevar a la tumba al protocolo SSL v3 (con 15 años de antigüedad ...) y parece que va a ser el espaldarazo definitivo para que *todo* sea TLS.

Los detalles de la vulnerabilidad se pueden leer en este PDF y que (en una lectura muy preliminar aun) deduzco que combina dos ataques, por un lado llevar al cliente a un 'downgrade', es decir a un terreno menos seguro (SSL 3.0) y una vez ahí, es donde se produce el ataque que permite acceder a datos cifrados bajo una sesión SSL.

Como recomendación obvia para mitigar este ataque se propone deshabilitar SSL v3 y también activar TLS_FALLBACK_SCSV lo que mitigaría la parte del downgrade.

La primera reacción a POODLE llega desde Mozilla que ya anuncia el abandono de SSL v3 en futuras versiones del navegador.

Cabe señalar que esto no supone, per se, que alguien pueda acceder directamente al tráfico SSL de un PC contra una web, es necesario un escenario de tipo MitM para poder acceder a los datos.
Leer más...