Mostrando entradas con la etiqueta covert-channel. Mostrar todas las entradas
Mostrando entradas con la etiqueta covert-channel. Mostrar todas las entradas

17 noviembre 2015

Hablando de canales encubiertos en La Sexta




A tenor de los brutales atentados terroristas cometidos en París el pasado viernes 13 de Noviembre, por grupos de radicales yihadistas, y como es habitual en estas situaciones, la confusión ha sido la reinante entre la información que ha ido saliendo a la luz.

Entre otras cosas, se publicó que el Ministro del Interior belga, Jan Jambon, anunció que los yihadistas utilizaron el chat de la PS4 para comunicarse y coordinarse. Esta noticia fue desmentida posteriormente, puesto que por lo menos en este caso, no se tiene la certeza.

Todo esto abre un interesante debate sobre los diferentes mecanismos para mantener comunicaciones entre diferentes interlocutores, que tras los escándalos de monitorización indiscriminada a los ciudadanos, las organizaciones que tienen interés en mantener la privacidad necesaria para el éxito de sus operaciones, han de utilizar.

A raíz de este tema, y a sabiendas que en el caso de París, ya no se tenga la certeza de la utilización del chat de la PS4, me invitaron a participar en directo al programa "Más Vale Tarde" de la cadena La Sexta.



Cuando me lo plantearon, la verdad es que pensé que el tema a hablar era algo que no añadía ninguna novedad para quienes nos dedicamos al mundo técnico, pero para los televidentes sí que podría ser algo distinto.

A lo largo del día preparamos diferentes escenarios, en los que se mostraban ejemplos de canales encubiertos. Casos como el ya famoso chat de la PS4, o incluso "mensajes escritos" por jugadores en partidas multijugador, dejados mediante disparos en una pared. Esta idea la leí en un post de Xataka, y me pareció un mecanismo muy creativo.



Otras formas de las que hablaría es la utilización de un webmail como mecanismo de almacenamiento compartido, de manera que entre los diferentes interlocutores, se intercambiarían los mensajes como si fuese un chat, dentro de un correo electrónico que se guardaría como borrador. Esto evitaría la inspección de correos electrónicos en transición entre diferentes servidores.

La última de las "demos" involucraba la utilización de esteganografía. Para ello preparé una foto en la que usando una herramienta como Steg, incluiría un fichero de texto dentro, utilizando una contraseña de uso compartido para poder extraer posteriormente la información.

Si a la esteganografía le añadimos mecanismos de cifrado a la información intercambiada, la complejidad hace que ser descubiertos mediante monitorización y descifrado, crezca a niveles muy elevados.

De hecho, ha sido noticia cómo la CIA se ha apresurado a culpar a Edward Snowden por decir qué mecanismos pueden ser descifrados por la NSA y cuáles no. Ni que decir tiene que este tipo de declaraciones me parecen altamente desafortunadas.

Obviamente, hay miles de canales encubiertos que se os pueden ocurrir. Desde contenedores cifrados en sistemas para compartir ficheros online, utilización de códigos compartidos previamente entre los interlocutores para referirse a según qué cosas, o incluso la utilización de código morse utilizando comunicaciones mediante un mecanismo de port knocking (con puerto puertos pares para el - e impares para el .),... entre un sinfín de posibilidades.

Debido a las noticias de última hora, sobre la suspensión del partido entre Alemania y Holanda, por el riesgo de un nuevo atentado terrorista, no hubo tiempo material para profundizar más en estos y otros temas. 

Os dejo un enlace al programa en cuestión. La parte en la que hablamos de esto es a partir del 1:36:54. 



Leer más...

06 noviembre 2014

Extracción de Datos en Sistemas Aislados a Través de Radio

Se ha publicado una PoC (Proof of Concept) de investigadores de la universidad Ben-Gurion donde explican cómo extraer información de un equipo aislado (no conectado a ninguna red) con un móvil debido a emisiones de radio mediante un malware desarrollado por ellos, llamado AirHopper.

El uso de tarjetas de vídeo, utilizando el cable que conecta el equipo con el monitor como antena, para la emisión de radio es un asunto poco novedoso. La novedad reside en el uso de dispositivos móviles con radio FM para perpetrar el ataque.
Comenzar diciendo que el ataque es complejo y llevarlo a cabo necesita de unas circunstancias particulares ya que requiere la instalación previa del malware en el equipo a extraer información así como en el dispositivo móvil. Además, la distancia entre el equipo y el móvil no debe ser superior a 7 m y consta de una tasa de transferencia de entre 13 bps y 60 bps lo cual va a dificultar la descarga de películas :).
El modelo de ataque consta de cuatro pasos:
  1.  Infección del equipo a "espiar" con AirHopper
  2.  Infección del móvil con AirHopper (aunque este paso podría no ser necesario si perteneciese al atacante).
  3.  Establecer el canal de control (Command and Control - C&C)
  4.  Detección de la señal y transmisión al atacante.
El primer escollo se encuentra en como infectar el equipo (fuera del objeto del artículo) con el malware ya que se supone que el atacante no tiene acceso al sistema. El informe remite a los famosos casos de Stuxnet o Agent.btz, y añadimos Flame y Duqu, para justificar la posibilidad real de ataque.
En la misma línea, se tiene que infectar el móvil (también fuera del objeto del artículo) aunque el rango de ataque es más amplio, ya que el móvil si tiene conexión con el exterior (3G, GPRS, Wireless, bluetooth o incluso la conexión física con otros dispositivos).
Una vez infectado los dispositivos, se debe establecer el canal de control a través de internet o por SMS con envío o recepción de mensajes sin aviso al usuario. El malware puede almacenar los datos si no fuese capaz de transmitir en un momento determinado para hacerlo posteriormente. Tras este paso, el malware monitorizará el canal de radio con el fin de detectar la señal deseada y su posterior decodificación.

La monitorización se puede realizar de forma continua, programada (por ejemplo dentro del rango horario del trabajador) o en función de la localización del dispositivo (vía GPS o Wireless).
Airhopper consta de dos componentes, uno dirigido a la capacidad de envío de datos del equipo aislado o el otro componente corresponde al receptor implementado en el móvil.
Debido a las limitaciones de los chip de los móviles a la hora de decodificar la señal FM, ésta sólo puede ser una señal audio, por lo que el equipo aislado tiene que codificar los datos (texto/binario) a audio y finalmente a una señal FM. De este modo el móvil tiene que hacer la decodificación contraria. Recibir una señal FM,  convertirla en audio y seguidamente en texto/binario.
Los datos que se van a transmitir vía radio hacia el móvil, deben ser enviados hacía la pantalla o monitor pero éstos deben ocultarse al usuario para mantener el anonimato de la operación y para ello puede utilizar tres técnicas:
  1. Transmitir cuando el monitor está apagado
  2. Apagar el monitor (como en el caso del salvapantallas)
  3. Conmutar con otro equipo. Puede detectar KVM y "jugar" con esta posibilidad para la ocultación de la transmisión/datos.
  4. También contempla la posibilidad de usar la característica de un segundo monitor, aunque esta opción sólo es válida cuando este monitor secundario está próximo al equipo. En el caso contrario, para presentaciones, conferencias, etc. no sería válido.
Para la transmisión de datos utiliza dos modos de transmisión, raw y structured.
  1.  Raw: Se recoge un array de bytes y se transmiten secuencialmente. No es "orientado a conexión". Ideal para texto y señales pequeñas (short signaling).
  2.  Structured: Perfecto para binarios con capacidad de detección de errores en la transmisión (pérdida o interrupción de transmisión).
Otra característica de Airhopper es que para reducir una posible detección accidental de la señal por un receptor FM se opta por extender la banda de recepción de 76 MHz a 108 MHz (frecuencia de transmisión 80 MHz). De 76 MHz hasta 87.5 MHz es utilizada en muy pocos países.

Para concluir las contramedidas propuestas están orientadas al aspecto TEMPEST. En nuestro país, según el grado de clasificación de la información a tratar se exige una protección anti-TEMPEST (amen de medidas de seguridad física y electrónicas) determinada que tiene que ir reforzada por procedimientos acordes. Ésta se puede dar a nivel de equipo o de local (más común). Una de esas medidas es no introducir elementos electrónicos sin la debida autorización.

Artículo cortesía de Ricardo Ramos
Leer más...

13 enero 2010

Tunelizando DNS, otra opción con iodine 0.5.x


Otra herramienta para llevar a cabo tuneles DNS, además de OzymanDNS, DNS2TCP (comentada en SbD el año pasado), NSTX o DNScat es iodine, que actualmente se encuentra en su versión 0.5.2 (0.5.1 para windows).

Este tipo de aplicaciones son útiles en las que deseamos ocultar el tráfico o se desea saltar las restricciones de un firewall, como en el caso de los hotspots wireless de hoteles, aeropuertos y otros malos lugares que se enriquecen con precios de a €uro el byte.

Para el primero de los casos hay túneles más eficaces que nos proveerán de mejor rendimiento y mayores prestaciones, pero para el segundo, esta es posiblemente la única opción.

Iodine funciona de forma portable y no requiere ningún módulo adicional. Además de es compatible con Linux, Mac OS X, FreeBSD, NetBSD, OpenBSD, Windows e incluso la plataforma móvil Android. Otra ventaja es que tiene un sistema de autenticación para que nadie pueda conectarse si no conoce la contraseña.

La aplicación se compone de un cliente y un servidor siendo ambos necesarios para poder crear el tunel. El cliente es la utilidad que se instala donde se desea saltar u ocultar la información y la parte servidor se ha de alojar en un sistema que se pueda configurar como servidor DNS.

Lo más "complicado" es configurar la parte servidor, ya que requiere que se disponga de un equipo conectado constantemente, un dominio y una dirección pública para que responda las peticiones DNS del cliente.

Por ejemplo, la siguiente configuración haría a que cualquier servidor DNS tuviera que solicitar a la dirección IP 74.82.14.199, donde escucha el servidor iodine, todas aquellas peticiones que se hagan sobre  los subdominios de tdns.securitybydefault.com:
tunnel          IN A 74.82.14.199
tdns            IN NS tunnel.securitybydefaul.com.

Una vez configurado el servidor, se arranca  con algo tan sencillo como:
iodined -f 10.0.0.1 tunnel.securitybydefault.com
y el cliente:
iodine tunnel.securitybydefault.com
Con lo que se crearía una red con dos direcciones IP (10.0.0.1 y 10.0.0.2) en las que el tráfico será enviado mediante peticiones DNS.

Leer más...