Analizando el funcionamiento de PoisonTap. Continuación.

news and informations automotive,business,crime,health,life,politics,science,technology,travelautomotive,business,crime,health,life,politics,science,technology,travel

En el artículo anterior empezamos el análisis de cómo funciona PoisonTap y qué pasos sigue para comprometer un equipo. Nos habíamos quedado en el momento en que PoisonTap ya ha conseguido que el sistema le reenvíe todo el tráfico que va dirigido a Internet:

http://www.franciscosepulveda.eu/2016/11/20/analizando-el-funcionamiento-de-poisontap/

Además de implementar un servidor DHCP, también tiene instalado un pequeño servidor web basado en node.js:

https://nodejs.org/en/

Y aplica DNS Spoofing a las peticiones que llegan desde la víctima. Este DNS Spoofing provoca que cualquier petición desde la víctima termine en el servidor web interno de PoisonTap. Este servidor envía a la víctima respuestas en HTML y Javascript que generan iframes ocultos para dominios que están listados entre el primer millón de páginas más visitadas en Alexa. Si lo vemos de una forma muy simple, esto tiene como objetivo que el navegador de la víctima piense que va a visitar esas páginas, enviando las cookies que probablemente tenga almacenadas. De esta forma PoisonTap consigue las cookies de usuario pudiendo almacenar decenas de miles de ellas.

http-cookie-google

Como es PoisonTap el que hace las veces de servidor web, es él quien decide qué encabezados enviar a la víctima y puede saltarse la seguridad de las X-Frame-Options.

Al capturar estas cookies, el atacante podría suplantar a la víctima para continuar sesiones que tenga abiertas en diferentes páginas sin necesidad de volver a introducir las credenciales.

Al mismo tiempo, ya que obliga a la víctima a visitar páginas usando los iframes ocultos, sustituye archivos javascript de CDNs (Content Delivery Networks) como los de Google o de jQuery por otros modificados con backdoors que permiten al atacante acceder a cualquier dominio que cargue esos archivos infectados.

¿Cómo podemos protegernos contra PoisonTap?

La protección frente a este nuevo “juguete” es una tarea conjunta entre los servidores y los usuarios.

En primer lugar, los servidores Web deberían utilizar siempre HTTPS y garantizar que el flag “Secure” está habilitado en las cookies para evitar que puedan capturarse vía HTTP. Otra medida de seguridad es utilizar Subresource Integrity para estar seguros de que los archivos Jabascript que se cargan no han sido manipulados.

https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity

Otra medida de seguridad muy importante en los servidores es aplicar HSTS, aunque aún hará falta que pase más tiempo para que esto sea algo común.

http://www.wikiwand.com/en/HTTP_Strict_Transport_Security

¿Y los usuarios? ¿Qué podemos hacer para protegernos? Bloquear el ordenador mientras no lo estamos utilizando no sirve para nada, ya que el ataque sigue siendo perfectamente posible. Desactivar los puertos USB tampoco es algo práctico y, aunque contásemos con un mecanismo simple para activarlos y desactivarlos, probablemente se nos olvidaría con frecuencia. Otra medida que podemos tomar es cerrar siempre el navegador cuando nos vamos a alejar de nuestro equipo, pero esto tampoco solemos hacerlo. Estamos en otra de esas situaciones en las que la seguridad está reñida con la comodidad para los usuarios.

Sin duda, la mejor opción es confiar en que se empiecen a utilizar de forma general protocolos seguros para sustituir a los habituales que se diseñaron sin tener en mente todos estos posibles ataques.

Analizando el funcionamiento de PoisonTap

news and informations automotive,business,crime,health,life,politics,science,technology,travelautomotive,business,crime,health,life,politics,science,technology,travel

Esta pasada semana hemos visto cómo en muchas webs de tecnología y de seguridad se nos avisaba de un nuevo gadget que puede hackear nuestro ordenador simplemente con conectarlo a un puerto USB. Este nuevo juguete se llama PoisonTap.

Llama la atención el coste tan bajo que tiene el hardware necesario para construirlo, ya que basta con una Raspberry Pi Zero y podemos encontrarla por unos 5€. Sin embargo, si contamos con cualquier otra versión de Raspberry Pi, también sirve pero será necesario contar con el adaptador Ethernet a USB.

¿Qué puede hacer PoisonTap si se conecta a nuestro equipo?

  • Captura todo el tráfico que enviamos a Internet
  • Captura cookies y sesiones de los sitios web más conocidos (el primer millón de sitios que aparecen en Alexa).
  • Instala un troyano para los sitios web mencionados y es persistente, permaneciendo en el equipo incluso si desconectamos el dispositivo.
  • Fuerza a nuestro ordenador a enviar peticiones a los sitios web utilizando nuestras cookies

Todo esto lo consigue incluso si nuestro equipo está en la pantalla de bloqueo y tiene protección por contraseña.

¿Cómo funciona?

El funcionamiento de PoisonTap se divide en fases empezando por el secuestro de la red para luego capturar las cookies e instalar el troyano. Aquí vamos a hablar de la primera fase, la red, y en otros artículos explicaremos el resto del proceso.

Cuando se conecta PoisonTap a un puerto USB simula ser una tarjeta Ethernet que es reconocida por el sistema operativo, aunque la carga como un adaptador de baja prioridad (métrica alta). En la siguiente captura vemos 2 tarjetas, eth0 y wlan0, de mi portátil con diferentes métricas, 100 y 600.

route

Estos valores de métricas hacen que mi ordenador “prefiera” utilizar la tarjeta de cable en lugar de la inalámbrica. Dicho de otra forma, la tarjeta inalámbrica tiene una prioridad menor que la de cable. Lo mismo ocurre con PoisonTap, el sistema operativo le asigna una prioridad menor (una métrica mayor).

Con esta configuración, mi ordenador seguiría prefiriendo la tarjeta de cable, pero PoisonTap consigue que esto sea así sólo para el tráfico local, engañando al sistema operativo para que le envíe todo el tráfico que vaya dirigido a Internet. ¿Cómo lo hace?

El comportamiento por defecto de cualquier sistema operativo cuando detecta una nueva tarjeta de red es enviar una petición DHCP para solicitar una dirección IP. PoisonTap implementa un servidor DHCP que se va a encargar de responder a esta solicitud, pero en lugar de entregar direcciones IP de una subred (por ejemplo, 8.8.8.8), devuelve una respuesta que hace creer al sistema operativo que todas las direcciones IP (desde 0.0.0.0 a 255.255.255.255) pertenecen a la “red local” del dispositivo PoisonTap.

Como en cualquier sistema operativo una red local siempre tiene prioridad sobre la puerta de enlace, todo el tráfico que vayamos a enviar a cualquier red (por ejemplo a 8.8.8.8) se enviará al dispositivo PoisonTap en lugar de a nuestro router de salida a Internet. El tráfico que vaya a la red local se enviará por la tarjeta de red que esté conectada a esa red local y no se enviará directamente a PoisonTap.

¿Cómo consigue PoisonTap capturar nuestras cookies? Tenemos la costumbre de tener abiertas ventanas de navegador incluso si no las estamos leyendo en ese momento. Si esto es así, es bastante probable que el sitio web que estamos visitando provoque de forma periódica la recarga de la página, o bien que envíe peticiones HTTP request para carga un nuevo anuncio, para recopilar datos analíticos o registrar nuestros movimientos en la página. Basta con que en nuestro navegador abramos una página conocide y accedamos a las herramientas de desarrollador para ver que hay envío de tráfico incluso si nosotros no estamos haciendo nada en la página. Aquí vemos un ejemplo de mi navegador Chrome en una página de Amazon sin tocar nada:

web

Si esperamos unos segundos veremos que una página aparentemente inactiva sí que está generando tráfico, que en este caso iría a PoisonTap.

Con esto finalizaría la primera fase del proceso para comprometer el equipo. En otro articulo veremos cómo utiliza las cookies que está recibiendo y de qué forma instala el troyano.

Un antiguo ataque DoS afecta a dispositivos actuales

news and informations automotive,business,crime,health,life,politics,science,technology,travelautomotive,business,crime,health,life,politics,science,technology,travel

Sabemos que una conexión TCP está definida por dos pares IP:Puerto, uno para el origen y otro para el destino:

diagrama1

El puerto del cliente es aleatorio (aunque esto no es del todo cierto en algunas implementaciones). Si un atacante conociese este puerto podría enviar paquetes ICMP del tipo “destination un reachable” con el código “port unreachable” al servidor y cortar la conexión. Este tipo de paquetes están identificados por el tipo 3 y el código 3 en ICMP y se conocen desde hace más de 20 años.

destinationunreachable

Si el atacante no conoce el puerto origen del cliente, otra forma de implementar este ataque es enviar miles de paquetes con el mismo mensaje pero para todos los posibles puertos origen. No son muchos los paquetes que hay que enviar, ya que el número de puertos supera por poco los 65000, y hay un rango de ellos que no se utilizan como puertos de origen, lo que reduce algo los paquetes que necesita enviar el atacante. Con los anchos de banda que tenemos en la actualidad, es un ataque que se implementa en tiempos muy cortos.

A diferencia de los ataques DDoS que se han producido en las últimas semanas, “destination unreachable” no requiere grandes cantidades de paquetes para ser efectivos. Recordemos los DDoS que se han lanzado contra Dyn DNS o contra el blog de Brian Krebs, que alcanzaron unos 700 Gbps. En su lugar, un portátil con recursos muy limitados y una conexión normal para los estándares actuales podría llevarlos a cabo utilizando anchos de banda tan reducidos como 18 Mbps.

Podríamos pensar que algo tan antiguo ya no funcionará con los firewalls con los que contamos hoy en día, pero en el SOC del operador danés TDC han descubierto que no es así, y que sí que afecta a dispositivos supuestamente seguros. Han llamado a este ataque BlackNurse (más de 20 años después todavía no tenía un nombre) y ya está confirmado que afecta a los siguientes equipos:

  • Cisco ASA: 5515 y 5525
  • Algunas versiones de Palo Alto
  • SonicWall

En el siguiente enlace se puede acceder al informe técnico de TDC:

http://soc.tdc.dk/blacknurse/blacknurse.pdf

Por ahora, una posible solución es deshabilitar los mensajes ICMP de tipo 3 en las interfaces expuestas a Internet, aunque en determinados modelos como los ASS 5500 esto podría provocar problemas de conectividad en VPNs IPSec y PPTP.

¿Seguridad en la IoT?

news and informations automotive,business,crime,health,life,politics,science,technology,travelautomotive,business,crime,health,life,politics,science,technology,travel

Los ataques DDoS (Distributed Denial of Service) se vienen produciendo desde hace muchos años. Implementados por particulares, organizaciones más o menos clandestinas e incluso gobiernos de forma encubierta, se han utilizado para afectar el rendimiento de sistemas con diferentes fines. Sin embargo, parece que desde que hace unos días se liberó el código fuente de Mirai se ha abierto la veda para este tipo de ataques masivos y los cibercriminales han centrado su atención en ellos.
No se trata de ataques técnicamente muy complejos ni que hagan uso de complejos algoritmos basados en inteligencia artificial, simplemente se aprovecha de la dejadez de los implicados en la cadena de seguridad, principalmente los fabricantes de dispositivos. Basta con echarle un vistazo al código del módulo de escaneo de Mirai (que cualquiera puede descargar y compilar) para comprobar que busca dispositivos que tengan contraseñas por defecto como 123456 o admin.

seleccion_043

La botnet no necesita esforzarse más para infectar miles de dispositivos, no está tratando de acceder a un objetivo concreto que probablemente cuente con mejores medidas de seguridad. A los atacantes les basta con reunir un número suficiente de equipos que luego van a lanzar contra su víctima.
Al problema de que estos dispositivos son accesibles con contraseñas que están en el más básico de los diccionarios se une que, en muchos de los que se han visto comprometidos, el fabricante no permite que el usuario pueda cambiar estas contraseñas. No es raro que muchos de los dispositivos que se utilizaron para atacar a Dyn fuesen cámaras, grabadores de vídeo y otros dispositivos del mismo fabricante.
En otros casos, son las empresas que instalan estos dispositivos en los usuarios finales las que no modifican las credenciales, ya que les resulta más sencillo y puede acceder fácilmente de forma remota a ellos para dar asistencia a sus clientes.
Una simple búsqueda en Shodan nos devuelve cientos de miles de resultados que son potenciales miembros de una botnet:

seleccion_052

Los fabricantes no parecen tener muchos incentivos para modificar estas prácticas inseguras, pero los cibercriminales sí que parecen encontrarlos para elaborar herramientas cada vez más complejas, como es el caso del más reciente Linux/IRCTelnet, descubierto por Malware Must Die!:
http://blog.malwaremustdie.org/2016/10/mmd-0059-2016-linuxirctelnet-new-ddos.html
Por ahora, estos dispositivos vulnerables se están utilizando de forma rudimentaria para inundar de tráfico a determinados objetivos, pero no debemos olvidar que estos dispositivos están instalados en nuestras redes, por lo que se convierten en una puerta de acceso a ellas y pueden facilitan otros tipos de ataques.
Debe ser responsabilidad de los fabricantes poner todo su empeño en garantizar la seguridad de sus usuarios, igual que en la industria del automóvil se implementan medidas de seguridad activas y pasivas en los coches, no vale sólo con que el vehículo sea capaz de correr por una carretera.
Del mismo modo, tal y como se hace a la hora de conducir un coche, los usuarios debemos estar concienciados y formados para utilizar de una forma correcta y responsable esta IoT que ya podemos encontrar en todos los sitios.

Nuevo ataque de inyección de código en Windows

news and informations automotive,business,crime,health,life,politics,science,technology,travelautomotive,business,crime,health,life,politics,science,technology,travel

Las tablas atom son usadas en los sistemas operativos Windows para compartir strings entre diferentes aplicaciones. Cuando una aplicación escribe un string en una de estas tablas, recibe un identificador de 16 bits que se denomina atom y que se puede utilizar para acceder al string por parte de la misma aplicación o de otra con la que vaya a compartir la información. Incluso el propio sistema operativo utiliza tablas atom, aunque en este caso no son accesibles directamente para las aplicaciones:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms649053(v=vs.85).aspx

Hace dos días, investigadores de la empresa de ciberseguridad enSilo publicaron su descubrimiento de un nuevo tipo de ataque denominado AtomBombing que se basa en la inyección de código en estas tablas del sistema. Han sido capaces de escribir código malicioso en una tabla y de forzar a una aplicación a que lea ese código, dando lugar a posible escenarios de Man-in-the-browser, acceso a contraseñas en plano, tomar capturas de pantalla…

http://blog.ensilo.com/atombombing-a-code-injection-that-bypasses-current-security-solutions

En este caso no se está explotando una vulnerabilidad de Windows o aprovechando código incorrectamente escrito y que se pueda parchear con una actualización, sino abusando del modo en que está diseñada esta característica del sistema operativo, lo que hace más complicado encontrar una solución y expone al ataque cualquier versión de Windows que haga uso de ella.

code

¿Cómo podría utilizarse este descubrimiento? Es habitual que un atacante engañe a un usuario para que ejecute un archivo malicioso, la ingeniería social suele ser muy efectiva. Aunque el antivirus del usuario no detecte ese archivo como una amenaza, si dispone de un firewall correctamente configurado es probable que bloquee las comunicaciones con el exterior de ese archivo. Sin embargo, ahora el atacante podría encontrar la forma de inyectar código en una aplicación legítima, como por ejemplo un navegador web, utilizando una tabla atom. De esta forma, como el firewall confía en esa aplicación legítima, dejaría pasar su tráfico que habría sido convenientemente modificado por el atacante.

Por ahora no hay una solución sencilla para resolver este problema y la recomendación que nos dan desde enSilo es monitorizar las llamadas a las APIs para detectar cualquier comportamiento anómalo.