22 diciembre 2010

SYND(E), burlar la censura de tu gobierno usando los canales permitidos

Internet, tal y como lo conocemos, está pasando por un momento que, según opinan muchos, marcará un antes y un después en la red. Por ello, debemos prepararnos generando y desarrollando nuevas ideas.

La idea que vamos a ver llegó a mi en una conversación con Román, algún comentario suyo, o incluso puede que una mezcla de ambas. Me pareció tan potente que quería, al menos, demostrar que era posible llevarla a cabo.

Pensemos en Internet como en un flujo continuo y gigantesco de todo tipo de datos. Estos datos pueden estar clasificados según contenido, protocolo, etc. Para un censor que implante un mecanismo de censura habrá datos permitidos y datos que están prohibidos. Pero, ¿que pasa si metemos datos prohibidos de forma oculta en datos permitidos para que pasen por el filtro sin problema? Hace poco veíamos algunas herramientas de esteganografía que hacían algo parecido, incrustaban datos dentro de otros sin modificar a simple vista el contenedor.

Si combinamos ésto con la creciente cantidad de servicios de compartición de contenidos multimedia, tenemos la ecuación completa.

La herramienta SYND(E) [Share your nasty docs (eyeless)], made in SbD, nos permite hacer ésto de forma automática. Está pensada para enviar un fichero de un punto a otro (u otros) incrustándolo en fotografías y subiéndolo a un depósito público como es Imageshack. El receptor solo tendrá que descargar las fotos y extraer el contenido. El funcionamiento es el siguiente:

  1. El usuario A selecciona una lista de fotografías (en formato JPEG), una clave de cifrado y el fichero a enviar.
  2. El programa hace las verificaciones pertinentes, fragmenta el fichero en pedazos ajustados a lo almacenable en cada foto, los cifra con la clave de cifrado y el algoritmo AES de 128 bits, los incrusta en las fotografías y las sube a Imageshack.
  3. Después de ésto genera un fichero de configuración con la contraseña cifrada (con doble SHA512) y la lista de fotos. Este fichero deberá ser enviado al receptor (preferiblemente por un canal seguro).
  4. El usuario (usuarios) B usa el programa con el fichero de configuración generado, inserta la clave de cifrado (debe de ser comunicada por un canal seguro) y si coincide procede a descargar las fotos, extraer los datos, descifrarlos y recomponerlos en el fichero a recibir.

Ya que dicho así puede sonar un tanto abrumador, vamos a ver una demo de cómo funciona.

El programa tiene el objetivo de demostrar que la idea es posible, por lo que algunos errores no están controlados y depende de programa externos. Está pensado para entornos tipo Unix, es software libre, programado en Ruby, utiliza curl para la interacción con la API de Imageshack, wget para descargar y steghide para trabajar con las fotos.

Necesitamos estas dependencias, en Debian o sus derivados (como Ubuntu) se instalarían con el siguiente comando (con permisos de root):

apt-get install ruby curl wget steghide

En las primeras líneas de código del programa (editable con un editor de texto sin formato) encontrareis algunas opciones de configuración. La más interesante es poder configurarle un proxy HTTP para la subida, con lo que podemos mejorar la privacidad.

Teniendo todo preparado, vemos las opciones del programa.


El programa se maneja mediante ficheros de configuración. El de descarga lo genera él, por lo que solo tendremos que preocuparnos por el de subida. El formato es el siguiente:

clave_de_cifrado
/ruta/del/fichero/secreto.zip

/home/yo/foto01.jpg
/home/yo/foto02.jpg
...

Para el ejemplo he elegido como fichero secreto La Declaración Universal de los Derechos Humanos en formato PDF. El fichero de configuración queda así:

clave_cifrado_sbd
derechos.pdf

demo/watchmen.jpg
demo/world.jpg
demo/sc1.jpg
demo/sc2.jpg

Para verificar que todo está bien y que las fotos tienen la capacidad suficiente para albergar el PDF vamos a utilizar la opción -s.



Perfecto, ahora con la opción -u pondremos a funcionar el programa, los datos quedarán almacenados  en Internet (el contenido y las fotos subidas a Imageshack) y generaremos el fichero de configuración de salida.



La estructura del fichero de configuración de salida es la siguiente (clave de cifrado cifrada en un doble SHA512 y lista de links a las fotos).

77d708398595708f184a7f99009938aef4915a218862e05d025dc84264b61d9e91638958241ca570c540d3e9e660f3df61dff848e889c75a86ca84edaef19198
http://img832.imageshack.us/img832/7497/watchmenk.jpg
http://img37.imageshack.us/img37/7074/worldrw.jpg
http://img832.imageshack.us/img832/6682/sc1o.jpg
http://img716.imageshack.us/img716/9112/sc2rg.jpg

Como curiosidad podéis visitar la dirección de cualquiera de las fotos y veréis que es visible, como una foto cualquiera. Para recuperar el fichero, con la opción -d solo tendremos que pasarle el fichero de configuración, la clave de cifrado y el fichero donde guardar la descarga (si queréis probar a descargarlo vosotros aquí tenéis la configuración de salida, la clave de cifrado ya sabéis que es "clave_cifrado_sbd").



Como podemos ver el fichero ha llegado intacto y el SHA1 es el mismo, por lo que no ha cambiado nada.



Preguntas que pueden surgir:

- ¿Que ventajas tiene esto?

Nuestro fichero secreto va a ser troceado, cifrado (AES de 128 bits), incrustado de forma oculta en fotografías y éstas van a ser subidas a un almacén público gigantesco. Las posibilidades de recuperar el fichero íntegro son muy remotas ya que está fragmentado (y un atacante no debería saber el orden ni la localización de los fragmentos), cifrado y entre muchísimas mas fotos.

Además, el canal está permitido por un posible censor, por lo que podríamos compartir cualquier tipo de datos por esa vía, por muy fuerte que fuera la censura.

- Alguna desventaja tendrá, ¿no?

Si, por ejemplo que aumenta mucho el tráfico generado. Tenemos que enviar los datos y las fotos. Además, dependemos de un tercero, y al haber muchos fragmentos la disponibilidad puede caer en cuanto uno de ellos deje de estar disponible. Esto último se solucionaría copiando los datos en varios servicios diferentes para crear redundancia.

- Pero, ¿y si bloquean Imageshack?

No hay problema, ésta misma implementación de puede portar a cualquier servicio que no modifique los datos cuando se suben. Para imágenes tenemos muchos más servicios del estilo de Imageshack, Flickr, etc. Y no solo eso, también podemos usar como contenedor vídeo, texto (comentarios en foros, blogs, pastebin, etc), audio, etc ...

- No me gusta, la herramienta me resulta muy arcaica.

La herramienta pretende demostrar que la técnica es posible, usable y enseñar como funciona. Cualquiera es libre de hacer una herramienta de botón gordo, integrarlo con algún programa de compartición de ficheros, etc ...

Descargar SYND(E) desde nuestro repositorio de software: Descargar

23 comments :

fossie dijo...

Muy interesante la herramienta y muy currada (aunque yo sea de windows y no pueda usarla ;D). Como prueba de concepto esta bien pero pienso que realmente el problema son los foros donde luego se publican los enlaces a esas fotos diciendo que en dichas fotos existe el fichero .pdf oculto (lease la película de estreno de turno)

Lo que perseguirá el censor serán todos los sitios donde se publique la información de como extraer ese archivo oculto para que no se pueda descargar masivamente.

Actualmente hay muchos foros privados que comparten archivos encriptados (zip o rar con contraseña) que, en principio, un censor no debería poder saber que contienen por lo que no debería bloquearlos (aunque es sospechoso si ve un archivo que diga "fotos familiares" y que ocupe 1.7GB ;D)

Supongamos que alguien ripea una película en 700megas y la parte en 200archivos de poco más de 3.5megas renombrandolos como "fotos del cumpleañosNNN.jpg". Mete todas esas fotos en un .rar con contraseña y lo comparte en megaupload poniendo en un foro los enlaces para descargar sus "fotos del cumpleaños".
En principio un censor no tendría forma de saber si son o no las fotos de un cumpleaños (tendría que descargar y descomprimir el rar (romper la contraseña))
Pero esta claro que si en el foro se dice "Aquí os dejo la pelí de estreno fulanito y la contraseña de descarga es fulanitoskey" pues el censor cerrará el foro o ira contra el que ha puesto los enlaces.

Victor dijo...

Hola,

Sin ser un experto en el tema, esto sólo serviría en comuniciaciones directas ¿no?

Es decir, si las partes son publicadas en una web para descarga pública, nada impide al censor solicitar la eliminación de las imagenes o cerrar la web (gracias a la futura Ley Sindios).

Saludos

Mario dijo...

Hace años había un programa llamado Kamaleon que hacía esto, con interfaz, de forma sencilla e incluso traía imagenes predeterminadas para meter cosas en ellas. Nada nuevo en el horizonte.

Román Ramírez dijo...

Excelente trabajo @Alberto :)

@Mario Esta misma idea la estamos perfilando para que se una con filosofía p2p y el contenido esté distribuido.

El éxito dependerá de que haya una masa crítica de usuarios insertando información con canales encubiertos.

¿Cuánto es el coste de operación para poder detectar, confirmar y eliminar la stegoinformación? ¿y cuánto es el beneficio para realizar invertir en esa detección?

Stego + p2p + fuentes públicas = guerra ganada contra los lobbies de la propiedad intelectual.

De nuevo un diez por la línea editorial.

Anónimo dijo...

Estimado Alberto,
Aunque existe numerosas cuestiones por las que yo no recomendaría el procedimiento que comentas, es cierto, que quizás para evitar la censura de un par de funcionarios iletrados (o similares) podría valer. Inconvenientes:

1. La idea es muy antigua. Trocear una información cifrarla y luego ocultarla. Creo recordar que ya en 2008 hablaba de este hecho en un congreso EATIS, ventajas y limitaciones. El problema principal de esta propuesta es la escalabilidad y como compartes la información necesaria para que emisor y receptor sepan donde está la información. Considerar intercambiar algo (aunque sea un fichero de configuración) por un canal seguro es cuanto menos gracioso. ¿Qué es para tí un canal seguro? ¿porqué no intercambio la información interesante directamente por ese "canal seguro"? ¿el uso de un "canal seguro" establece que el procedimiento sea manual y poco escalable?. De hecho, mira la herramienta StegPage publicada en ¿2004?

2. La herramienta stegHide es detectada con los estudios de estegoanálisis actuales.

Un abrazo
Alfonso Muñoz

Newlog dijo...

Un aplauso por el esfuerzo hecho, pero creo que lo que se comenta tiene poco sentido.

No hay ningún problema cuando quieres compartir una película, música o foto con pocas personas. Ya que subes la película, música o foto donde te apetezca y envías el link a las pocas personas que quieras. El problema está en tener un servidor centralizado con todos estos links, que es lo que realmente se necesita y que es lo que se intenta impedir con la ley Sinde.

Para que no se puedan capar las descargas es tan simple como volver a programas como Pando, que dependía de cuentas de correo -que, en un principio, no se pueden cerrar-.

Newlog dijo...

Por otro lado, ahora que veo el comentario de Román, decir que creo que actualmente las redes p2p van camino a morir.
Yo ya no las uso ni para archivos antiguos. Puede que haya cosas que no encuentre de otro modo, pero realmente estos casos son bastante aislados.

Almenos yo ya no veo necesario esperarme dos dias para descargarme 1GB.

Aunque el tema del p2p 'soluciona' el tema de los links centralizados. Aunque creo que es dar un paso atrás.

Alberto Ortega dijo...

Bueno, antes de nada gracias por los comentarios y señalar que el artículo no está enfocado directamente al asunto de las descargas de contenidos multimedia. Que cada uno haga su interpretación :)

@fossie @Victor @Newlog
Como bien comentais, si se montara una comunidad (o lo que sea) de descargas mediante el sistema tal y cómo está detallado, el punto débil sería la centralización de todo. Aún así, pensad que la arquitectura permite modificaciones, lo dicho es solamente un canal de comunicación, como puede ser un protocolo de cualquier programa de compartición. Por cierto, me viene a la cabeza el disparate de denunciar a una web por compartir imágenes entre los usuarios :D

@Mario
Kamaleon no sube las fotos a internet, solo te permite generar una lista de links a ficheros ya subidos. Por cierto, no he encontrado el código fuente por ningún lado (puede que esté y no he dado con él), aquí lo tienes disponible en la descarga. En mi opinión, mal ejemplo :)

@Román
Bien pensado! Ésta ha sido mi pequeña adaptación de la idea, pero da para mucho más.

@Anónimo (Alfonso)
Efectivamente, has relatado las debilidades de éste programa en concreto. Para que fuera usable de forma masiva el diseño tendría que ser diferente.

Un saludo!

Jugocas dijo...

Buenas:

Corregirme si me equivoco esto no serviria tambien para distribuir malware de forma totalmente oculta¿? Esta claro que es un metodo algo complicado para distribuirlo pero:

si algo se encargara de desencriptar, extraer y ejecutar dicho archivo oculto¿?.

Me explico:

Supongamos PC1 y PC2

PC1 oculta el malware en multiples fotos.
PC2 y mediante ingenieria social acaba como con un downloader en el cual baja dichas fotos, las desencripta y guarda el contenido oculto (en este caso malware). Es un metodo poco practico (lo se, im sorry no tengo tildes...) pero a veces no se necesita lo mas practico sino lo menos pensado.

¿Seria factible? o por el contrario es una tonteria¿?

J.V. Lobo dijo...

uuuooo, muy interesante la herramienta!!! me gusta su funcionamiento, una muy buena idea, enhorabuena y gracias por enseñar estas cosas.

Por cierto, muy gracioso el nombre!! jaja

Román Ramírez dijo...

Lo importante de trabajar en seguridad (y recalco el "trabajar") es descubrir potenciales vectores o mecanismos de impacto.

Con esa premisa, el artículo es un 11 sobre 10.

@Alfonso Lo relevane no es que la técnica concreta de stego haya sido "observada". Lo relevante es la premisa abstracta tras ella.

De nuevo, +10.

Anónimo dijo...

@Román: La cuestión es que en la práctica este tipo de ideas son muy similares a propuestas que ya llevan funcionando varios años, por ejemplo, mediante el uso de peer2mail, sobre todo cuando el uso de servidores de descarga directa no era tan masiva. Entonces la información se troceaba y se distribuida en varios correos, para mayor precaución la gente utilizaba procedimientos esteganográficos más o menos sencillos (por ejemplo, ocultar la info al final de un fichero JPEG). Se extrablecían muchas medidas, algunas sofisticadas, pero al final el proveedor de turno (por ejemplo, google-gmail) detectaba un trafico no adecuado y la conexión simultánea de un número excesivo de IPs y bloqueaba la cuenta (fin de la distribución). El mayor problema que tenía esta idea era la distribución de esos enlaces, lo que hacía que en la práctica o se publicaba de forma centralizada en una web o se compartían persona a persona, lo que lo convertía en un procedimiento poco útil.

Sería interesante que mejoráramos este tipo de propuestas por su utilidad...

Un abrazo
Alfonso

Alberto Ortega dijo...

@Jugocas
Es interesante lo que comentas. Un escenario que me viene a la cabeza es el de un master de una botnet que quiera actualizar el cliente en cada bot. Para ello podría almacenarlo en Internet de esta forma (en vez de en un servidor concreto) y mandar a los bots que actualicen desde ahí.
Personalmente lo veo muy difuso, ya que no se en que situación le sería realmente necesario, pero por poderse se puede (hay que tener en cuenta que al final es una forma de almacenamiento).

Anónimo dijo...

@Jugocas: la distribución y la esteganografía se han utilizado en la presente década para distribuir o "accionar" malware. Por ejemplo, en un entorno más "local" es muy conocido el uso de ADS-NTFS (Alternate Data Stream) para trocear código y luego unirlo y ejecutarlo mediante un cargador.

Un saludo
Alfonso

Román Ramírez dijo...

@Alfonso No, si no digo que se esté planteando una técnica innovadora.

Lo que subrayo es, como tú indicas, la importancia de que estas técnicas sean de "botón gordo". El éxito de utilizar este tipo de aproximación depende de que los usuarios hagan uso extensivo.

La idea que tengo y que he comentado con Alberto varias veces es una Class/dll/... para integrar con jdownloader, utorrent etc. y que pueda ser una extensión de forma que se repartan los trozos por todas partes.

El objetivo (el mío concreto) no es conseguir una técnica muy segura, es conseguir una técnica (casi)imposible de bloquear de forma razonable, por lo que la parte de steg no es más que una capa para complicar el proceso de filtrado y bloqueo.

Si el coste de bloqueo es mucho más alto que la rentabilidad que consigas aplicándolo... no bloquearás, es bien simple.

Jandro dijo...

En parte estoy en linea con lo que dice alfonso, hace tiempo ya se usaba peer2mail con servidores de correo como google o yahoo. El problema es que ya sea imageshack o cualquier otra web, si ve que hay un tráfico "inusual" (es decir, un tio no puede ver 200 imagenes sin esperarse 5 segundos en cada una) lo va a bloquear ya sea poniendo un captcha o algun que otro metodo.

Anónimo dijo...

Creo, desde mi humilde punto de vista, que estamos enfocando el problema de forma errónea.
No hay que ocultar qué se comparte, sino quién lo hace.

Creo que lo más eficaz, aunque no lo más eficiente sería que todos usásemos la red TOR + un programa P2P descentralizado + cifrado entre clientes.

Si la cosa se pone fea nos veremos obligados a ello, y mi pregunta es... ¿Tan ineficiente sería este sistema si todos usásemos TOR? ¿Cuanto tráfico útil podríamos descargar?
Me gustaría generar debate en torno a esta cuestión.

Anónimo dijo...

Siguiendo con el comentario de Anónimo que propone usar TOR, me gustaría hacer la objeción de que uno de los principales puntos débiles de ese sistema sería el ruido inducido por el censor en el propio sistema montado por el usuario.
¿Que formas se os ocurrirían de burlar este ruido o hacer más eficiente al sistema?

Anónimo dijo...

El sistema propuesto es interesante porque utiliza recursos externos y proporciona una capa de anonimato con el proxy.
En mi opinión lo que le falta a este sistema es la falta de creación activa de redundancia.
Creo que el principal lastre de la filosofía propuesta y de programas como JDownloader es que el que comparte es el "encargado" de crear redundancia, y crearla es un trabajo costoso.

JDownloader debería crear redundancia actívamente subiendo una o varias partes del fichero nuevamente a megaupload con otro nombre y compartir mediante p2p descentralizado el link para ese hash de fichero, haciendo upload de las partes con menos redundancia al igual que los p2p actuales.

De esta forma se desbordaría al censor, ya que el nivel de redundancia sería altísimo... habría que ver si también desborda megaupload y les hace tomar medidas en vez de mantenerse al margen.

Alberto Ortega dijo...

Personalmente, veo varios problemas en pasar todo ese tráfico por Tor.
En primer lugar, a no ser que hubiera más cantidad de nodos y con mayor ancho de banda, el rendimiento actual de Tor para estos menesteres sería insuficiente. Tanto por cantidad de conexiones simultáneas como por ancho de banda.
El otro problema principal que veo es que cualquiera puede montar un nodo de Tor, por lo que no podemos asegurarnos de que no haya nodos malignos en la red que capen tráfico, den prioridad a un tráfico sobre otro, guarden información de los usuarios, etc ...
Además, en cierto modo se mataría parte de la filosofía P2P, que es tener la mayor parte de la red descentralizada. Si metemos Tor, en cierto modo estamos segmentando la red.

Por otro lado, configurar nuestro cliente P2P para cifrar todo el tráfico, y cambiar el puerto por defecto lo veo desde hace tiempo como una medida imprescindible, aunque si es cierto que dentro de la red nuestra IP seguirá siendo identificada como "peer".

Antonio dijo...

Hay también herramientas windows que lo permiten, y desde hace mucho tiempo. Recuerdo hace 6 o 7 años como era "habitual" en ciertas webs de descargas de música la utilizacion del programa camouflage. Se subían fotos a una web, y al bajartelas las pasabas por el programa y te sacaba el mp3.

f0n dijo...

A mí sí que se me ocurre, no es lo mismo hacer una petición get a 

http://free-webs.ru/monica999/texts/payload.txt

que a imageshack, es interesante eso que ha comentado Jugocas :D

sistemasnegros dijo...

exelente post!