El P2P como herramienta de recolección de inteligencia

Hace pocos días Bloomberg publicaba un artículo en el que se afirmaba que Wikileaks no se limitó a recibir filtraciones, sino que se ha dedicado a buscarlas activamente en Internet y más específicamente en redes P2P. Lo cierto es que estas noticias difícilmente se pueden catalogar de sorpresa para los que alguna vez hemos realizado auditorias de fugas de información en redes P2P o desarrollo de metodologías de ciberinteligencia. Con bastante más frecuencia de lo que se podría imaginar ficheros de carácter claramente confidencial acaban en este tipo de redes, incluso documentación policial, militar o de sectores privados críticos.




En ocasiones los usuarios de P2P , entre los que se encuentra personal con acceso a información sensible, de forma accidental comparten sus ficheros privados al hacer uso de este tipo de redes o bien los ponen a disposición de otros usuarios bajo la suposición que al no ser conocidos en sitios de descarga no van a ser localizados por terceros.

Nos encontraríamos ante la versión digital de las pérdidas de información accidental que han existido siempre . Aunque también se han dan casos en los que se filtran intencionalmente en redes P2P ficheros confidenciales, ya sea por parte de empleados descontentos o intrusos que extraen los datos de sistemas comprometidos. Un ejemplo seria la reciente publicación del código fuente del antivirus Kaspersky.

Según el artículo de Bloomberg la empresa Tiversa , una empresa de monitorización de redes P2P, habría identificado computadoras suecas asociadas a Wikileaks que habrían realizado búsquedas y descargas de documentos sensibles militares norteamericanos expuestos en la red , incluyendo información del U.S. Navy’s Space and Naval Warfare Systems Center. Ahora bien ¿hasta que punto este tipo de situaciones podría afectar a nuestro país? En esta entrada vamos a ver cuáles son las técnicas básicas de búsqueda, mostrando ejemplos reales sobre información sensible de origen español para ilustrar el nivel de riesgo y finalmente enumeraremos que tareas se deberían llevar a cabo para prevenir estas filtraciones.

Puesto que en redes P2P se comparten gran cantidad de archivos de todo tipo, necesitamos una metodología de localización de información así como el uso de herramientas apropiadas, de otra forma seria como buscar una aguja en un pajar. No obstante para nuestros ejemplos será suficiente esta sencilla pero efectiva técnica de búsqueda usando únicamente clientes habituales de P2P.

• Determinar una lista de palabras clave relacionadas con el objetivo de nuestra búsqueda y a ser posible que tengan un significado únicamente dentro del contexto de nuestra investigación, por ejemplo terminología especifica , nombres de programas o sistemas, etc. Esto evitara que tengamos que seleccionar, descargar y revisar entre ficheros compartidos que no tengan relación con nuestra investigación.

• Localizar de entre los ficheros devueltos por las búsquedas basadas en los términos anteriores cuales corresponden con el tipo de información que estamos buscando.

• Identificar si existe un patrón en los ficheros localizados, tales como formato de fichero, nombre de fichero siguiendo un patrón, nueva terminología identificada, etc.

• Realizar nuevas búsquedas para confirmar nuestra hipotesis.

Veamos un ejemplo práctico y real, realizaremos búsquedas en la red Emule con el fin de localizar ficheros con documentación de carácter policial, para ellos iniciamos búsquedas con términos específicos. Seleccionamos por ejemplo como termino SIRDEE, nombre de la red de radio digital estatal de emergencias usada por CNP y GC. Realizada una búsqueda descubrimos un fichero con el título “Informe SIRDEE.wpd” (formato Wordperfect). Realizando una nueva busqueda mediante “informe wpd” localizamos un buen numero de ficheros compartidos. Informes relativos a tareas de seguridad ciudadana con casi total seguridad originarios de la Guardia Civil (adviértase entre los nombres las referencias a las 5 y 6 Compañías de Madrid).

click sobre la imagen para ampliar

Contra lo que pudiera pensarse este caso no es aislado y a lo largo de los años han estado expuestos en diversas redes P2P decenas de Manuales del Ejército de Tierra Español y de Infantería de Marina, además de Informes y Circulares de Guardia Civil, Policía Nacional así como Policías Locales en este último caso incluso Atestados conteniendo datos personales de ciudadanos.

Con la profusión de las descargas directas las redes P2P han perdido protagonismo y por tanto han descendido el numero de usuarios. Con ello afortunadamente también ha disminuido el numero de ficheros sensibles compartidos, aun así a día de hoy es posible encontrar documentos como estos.


Nótese en el caso del manual militar que se trata de un documento clasificado, si bien pertenece a uno de los niveles más bajos “Difusión Limitada” desde luego no debería en ningún caso haber acabado en las redes P2P. Ademas en el caso de este documento particular desde P2P obtuvo gran difusión por su temática sensible y a día de hoy se puede encontrar incluso en algunas Web.

No solo los organismos gubernamentales se encuentran expuestos a este tipo de filtraciones, casos similares se han dado y se dan con información de todo tipo de empresas y sectores. Desde seguridad privada a generación de energía.

Por ello todas las organizaciones que manejen información sensible deberían implantar algunas medidas de protección para evitar este tipo de casos.

• Crear una política de seguridad que prohíba expresamente el uso de redes P2P por parte de los usuarios dentro de la organización.
• Tareas de concienciación de los riesgos de P2P en su uso a nivel personal.
• Implantar las medidas técnicas de filtrado que impidan el uso de estas redes.
• Utilizar herramientas técnicas para comprobar que efectivamente no se hace uso de este tipo de redes. Este tema lo hemos tratado anteriormente: Detección de agentes P2P: Emule/Edonkey
• Evaluar periódicamente la exposición de documentos realizando investigación de P2P en busca de fugas de información.
• En los casos en los que se identificaran fugas se podrian poner en marcha sistemas para prevenir la distribución, posiblemente hablemos de ello en futuras entradas.

Nota del Autor: En la preparación de este articulo hemos tenido en cuenta la necesidad de una actuación responsable y por ello el ejemplo de la red Emule pertenece a una única fuente actualmente desaparecida, mientras que los ejemplos de ficheros presentemente compartidos desde varias fuentes han sido censurados para evitar contribuir a su mayor difusión. Creíamos que era importante dar a conocer esta problemática pues el artículo sobre Wikileaks demuestra que actualmente existen adversarios explotando activamente las redes P2P como fuente de inteligencia y es necesaria una concienciación de los usuarios para prevenir posibles filtraciones de información sensible.

Limitaciones de los Antivirus en entornos gubernamentales

La lógica informática recomienda evitar el uso de sistemas operativos de seguridad no garantizada en entornos críticos. Pero la preeminencia de Microsoft con sus sistemas operativos, hace que sea habitual encontrar equipos basados en Windows en este tipo de entornos.

Para estos entornos existen otro tipo de sistemas operativos más robustos como: OpenBSD, Trusted-Solaris, HP/UX Virtual Vault, Hardened-Linux, etc.

Aunque la seguridad de Windows ha ido mejorando con las nuevas versiones, no llega al nivel de los anteriores y sigue siendo una plataforma especialmente vulnerable a algunos tipos de ataques. Por ejemplo a la infección por medio de malware.

La principal herramienta de protección frente a este tipo de ataques ha sido tradicionalmente el uso de software Antivirus. Pero este tipo de software ha sido diseñado principalmente para entornos domésticos o corporativos y se queda corto en entornos gubernamentales.

¿Por qué? Porque el malware enfocado a este tipo de entornos no se parecen al que encontraríamos en entornos civiles.

Los antivirus actuales basan la detección principalmente en 2 mecanismos:

Detección basada en firmas: El antivirus mantiene una base de datos de virus conocidos y de patrones binarios reconocibles que permiten identificar posible malware.

La detección basada en firmas puede ser evitada principalmente de 2 formas:

- Evitando que el malware sea catalogado por las casas de antivirus. Los virus o troyanos con objetivos militares o de inteligencia suelen ser desarrollados a medida, de forma que no han sido distribuidos anteriormente y no han podido ser analizados por los fabricantes de antivirus.

- Evitando que el malware tenga patrones identificables mediante una firma. Esto normalmente se consigue haciendo que el virus cambie de forma en cada infección. Para ello se utilizan técnicas de polimorfismo que codifican el binario de forma diferente cada vez que se copia.

Un virus polimórfico lo que hace normalmente es cifrar su propio código utilizando una llave de cifrado diferente cada vez. La parte del código que no puede ser cifrada (principalmente el código que realizara el proceso de descodificación) se genera mediante mutaciones. Estas mutaciones hacen que el código pueda seguir realizando las mismas funciones pero sustituyendo las instrucciones en ensamblador por otras equivalentes.

Para automatizar estas mutaciones los desarrolladores de malware suelen utilizar herramientas llamadas packers. Estas herramientas comprimen y codifican el cuerpo del binario de forma automática.

Los antivirus pueden intentar definir una firma específica para cada packer. Pero en entornos militares estos packers son desarrollados a medida, de forma que los antivirus no tienen forma de catalogarlos.

Detección basada en heurística: El antivirus realiza una simulación de lo que haría el binario a analizar si fuese ejecutado. Si detecta algún tipo de comportamiento sospechoso (o habitual del malware), podrá identificar un binario malicioso aunque no haya sido catalogado previamente.

Para realizar esta simulación la mayoría de antivirus lo que hacen es crear una especie de máquina virtual donde ejecutan el código del binario a modo de emulador. Dentro de esta emulación se analiza el comportamiento del binario durante unos breves segundos (no pueden hacerlo durante mucho tiempo ya que ralentizarían en exceso el equipo).

Para evitar este tipo de detección el malware moderno suele utilizar las siguientes técnicas:

- No realizar acciones sospechosas que puedan delatar su actividad: Simplificando las funcionalidades del malware podemos evitar que sea detectado por heurística. Pero este tipo de ocultación es limitada ya que impide al malware realizar ciertas acciones.

Además cada modelo de antivirus considera sospechosas una serie de acciones diferentes. De forma que aunque podamos evitar la detección por un antivirus en concreto, puede que otro si nos detecte.

- Técnicas anti-debugging: Estas técnicas consisten en hacer que el código no pueda ser analizado en un debugger o hacer que el código se comporte de forma diferente (para parecer inocuo) si detecta que está siendo debuggeado.

Para evitar que el código pueda ser analizado lo que se suele hacer es aprovechar defectos de diseño de las herramientas de debug para conseguir que fallen a la hora de analizar el binario.

Para detectar la presencia de un debugger se suelen utilizar funciones estándar de Windows como: IsDebuggerPresent(), CheckRemoteDebuggerPresent(), NtQueryInformationProcess(),leer NtGlobalFlag o acceder directamente al PEB.

- Técnicas anti-emulación: Estas técnicas consisten en actuar de forma no previsible para hacer que el antivirus no sea capaz de detectar la verdadera funcionalidad del binario.

Algunas de las técnicas más utilizadas son: Usar APIs no documentadas, usar funciones no soportadas por el emulador, retrasar la ejecución del código malicioso y realizar operaciones pesadas que consuman el tiempo del emulador.

Algunos packers avanzados ya incluyen “de serie” muchas de estas técnicas de forma que le ahorran trabajo al desarrollador del malware y dificultan su análisis. Cuanto más personalizado (y adaptado este el binario al sistema objetivo) más compleja será la detección.

¿Seguridad en GSM? NO!

El 28 de diciembre de 2010, marcó un antes y un después en la seguridad de las comunicaciones móviles. No porque se haya roto la misma, cosa que ya estaba hecha, sino porque un grupo de hackers lograron hacerlo en directo, con un presupuesto de apenas 60-70€ y demostraron que está al alcance de cualquiera con ciertos conocimientos de programación, electrónica y de los diferentes protocolos del sistema GSM.

Sin ánimo de ser técnicamente profundo.

1. El antes
2. El después
3. Consecuencias

El antes

Las primeras especificaciones de GSM-900 datan de 1990, en Noviembre de 1992 salió a la venta el Nokia 1011 el primer móvil GSM comercial. En España estuvimos que esperar hasta que en 1995 Movistar creó la primera red digital, seguida de Airtel y en 1999 Amena, a esta última con GSM-1800.

La seguridad de las redes GSM se basaban en:

• La dificultad de interceptar este tipo de comunicaciones digitales, las cuales usan salto de frecuencia FHMA (Frecuency Hops Multiple Access). Lo que hace un difícil reto el interceptar toda una conversación. Aparte del caro equipo necesario para el procesamiento digital de la señal.

• La tarjeta SIM, el Modulo de identidad del subscriptor es una tarjeta inteligente que contiene, de forma protegida, la información de suscripción del propietario de la misma, así como parámetros de la red a la que pertenece. Aparte puede tener más datos como un pequeño directorio telefónico.

• Los algoritmos de cifrado usados, mantenidos estos en secreto (security throught obscurity). El algoritmo A3 usado para la autenticación del usuario en la red, A8 para la generación de la clave de sesión usada para el cifrado y el A5 para el cifrado de la conversación y mensajes (SMS). Los  algoritmos A3 y A8 realmente eran de elección libre para las operadoras, el A5 es fijo.

1er ataque

Ya en 1998 se publicó la primera vulnerabilidad, fue descubierta por dos investigadores de la universidad de Berkeley.  En el standard de GSM se utiliza COMP128 (un algoritmo público) como referencia para facilitar ciertas operaciones, se descubrió que el A3  era en realidad el COMP128 en la especificación inicial y lo usaban la mayoría de los proveedores. Este, se podía romper en menos de un día.

La seguridad proporcionada por la SIM, se basa en que mantenía protegido una clave Ki teóricamente protegida y que sólo conoce el proveedor. Éste, a la hora de conectar, manda un reto al móvil que desea conectarse a su red, el móvil lo manda a la SIM la cual lo cifra con A3 y devuelve una respuesta SRES, el proveedor realiza la misma operación internamente, si lo calculado y SRES coinciden en usuario está autenticado. Debido a la debilidad del COMP128, mandando una serie de retos simples a la tarjeta y analizando las respuestas, la clave Ki puede ser calculada. Este proceso duraba menos de 6 horas.

Las consecuencias son que alguien con acceso físico a una tarjeta SIM durante ese tiempo, podía clonarla, permitiendo al atacante hacerse pasar (frente a la red GSM) por el usuario legítimo de la misma. 

Además, el algoritmo A8, basándose en SRES y el Ki genera una clave de sesión Kc que se usará para cifrar las conversaciones. Mediante la vulnerabilidad anterior, al obtener el Ki, se podría tener el Kc y simplemente aplicando el A5 descodificar una conversación interceptada. 

Esta vulnerabilidad fue debido a que las claves, al parecer, fueron debilitadas a propósito debido a presiones gubernamentales… Haciendo, que la clave original de 64 bits tenga 10 a 0, haciéndola  sólo de 54bits y vulnerable. 

La vulnerabilidad anterior tenía una importancia relativa, había que ser capaz de hacerse con el SIM durante más de 6 horas, conocer el PIN del mismo (recordamos que es una tarjeta inteligente y por lo tanto su información está protegida por el PIN). Hasta este punto, si que nos serviría para clonar la SIM y hacer llamadas a cargo de otro usuario. Para poder escuchar las conversaciones y leer los mensajes por el aire, debemos de ser capaces de interceptar a nivel digital la señal GSM, salto de  frecuencia incluido.

Esta opción no estaba al alcance de usuarios normales, solo empresas que quisieran gastarse una cantidad de dinero importante podrían hacerlo. Pero vamos, seguros a que muchas les merecerían la pena.

La respuesta fue cambiar las SIM progresivamente, añadiendo claves más largas y limitando en número de retos por tiempo.

2º Ataque

Ya en 1994, Ross Anderson, publicó el algoritmo (secreto) A5 y avisó de que era demasiado débil, alegando que esta era la razón por la cual no querían que fuera publicado y más conspiteorias.

From sci.crypt Fri Jun 17 17:11:49 1994 From: rja14@cl.cam.ac.uk (Ross Anderson) Date: 17 Jun 1994 13:43:28 GMT Newsgroups: sci.crypt,alt.security,uk.telecom Subject: A5 (Was: HACKING DIGITAL PHONES) The GSM encryption algorithm, A5, is not much good. Its effective key length is at most five bytes; and anyone with the time and energy to look for faster attacks can find source code for it at the bottom of this post. The politics of all this is bizarre. Readers may recall that there was a fuss last year about whether GSM phones could be exported to the Middle East; the official line then was that A5 was too good for the likes of Saddam Hussein. However, a couple of weeks ago, they switched from saying that A5 was too strong to disclose, to saying that it was too weak to disclose! The government line now pleads that discussing it might harm export sales. Maybe all the fuss was just a ploy to get Saddam to buy A5 chips on the black market; but Occam's razor suggests that we are really seeing the results of the usual blundering, infighting and incompetence of bloated government departments. Indeed, my spies inform me that there was a terrific row between the NATO signals agencies in the mid 1980's over whether GSM encryption should be strong or not. The Germans said it should be, as they shared a long border with the Evil Empire; but the other countries didn't feel this way, and the algorithm as now fielded is a French design. A5 is a stream cipher, and the keystream is the xor of three clock controlled registers. The clock control of each register is that register's own middle bit, xor'ed with a threshold function of the middle bits of all three registers (ie if two or more of the middle bits are 1, then invert each of these bits; otherwise just use them as they are). The register lengths are 19, 22 and 23, and all the feedback polynomials are sparse. Readers will note that there is a trivial 2^40 attack (guess the contents of registers 1 and 2, work out register 3 from the keystream, and then step on to check whether the guess was right). 2^40 trial encryptions could take weeks on a workstation, but the low gate count of the algorithm means that a Xilinx chip can easily be programmed to do keysearch, and an A5 cracker might have a few dozen of these running at maybe 2 keys per microsecond each. Of course, if all you want to do is break the Royal Family's keys for sale to News International, then software would do fine. It is thus clear that A5 should be free of all export controls, just like CDMF and the 40-bit versions of RC2 and RC4. Indeed, there seems to be an even faster attack. As the clock control is stop-go rather than 1-2, one would expect some kind of correlation attack to be possible, and on June 3rd, Dr Simon Shepherd of Bradford University was due to present an attack on A5 to an IEE colloquium in London. However, his talk was spiked at the last minute by GCHQ, and all we know about his attack is: that sparse matrix techniques are used to reconstruct the initial state (this was published as a `trailer' in the April 93 `Mobile Europe'); that he used some of the tricks from my paper `Solving a class of stream ciphers' (Cryptologia XIV no 3 [July 90] pp 285 - 288) and from the follow-up paper `Divide and conquer attacks on certain classes of stream ciphers' by Ed Dawson and Andy Clark (Cryptologia XVIII no 1 [Jan 94] pp 25 - 40) (he mentioned this to me on the phone). I believe that we have to stand up for academic freedom, and I hope that placing A5 in the public domain will lead to the embargo on Simon's paper being lifted. Ross Anderson APPENDIX - AN IMPLEMENTATION OF A5 The documentation we have, which arrived anonymously in two brown envelopes, is incomplete; we do not know the feedback taps of registers 2 and 3, but we do know from the chip's gate count that they have at most 6 feedback taps between them. The following implementation of A5 is due to Mike Roe , and all comments and queries should be sent to him. ….

El algoritmo A5/1 es el usado en USA y Europa, como ya vimos en 1994 ya avisaron, en 1997 Golic presentó un ataque de alta complejidad computacional al mismo, en el 2000, Alex Biryukov, Adi Shamir y David Wagner mejoraron el ataque de Golic (1997). Este ataque permite al atacante reconstruir la clave en 1 segundo a partir de 2 segundos de conversación, pero al principio se debe completar una cara etapa de preprocesado que requiere computar alrededor de 300Gb de datos. Fueron publicándose mejoras del ataque al A5/1.

En 2005 Elad Barkan y Eli Biham consiguieron un ataque que requería menos de un minuto de computación y pocos segundos de conversación conocida.

Concretamente en GSM, en 2003, Elad Barkan, publicó ataque por el cual obligaba a los teléfonos a usar A5/2, este algoritmo es más fácil de romper.

Fue ya en 2006, cuando publicaron un ataque sobre sólo texto encriptado en A5/1. Oficialmente ya estaba roto, pero aún se tardaba bastante tiempo en desencriptar texto encriptado. En diciembre del 2009, Chris Paget y Karsten Nohl iniciaron un proyecto para crear unas Rainbow Tables, una serie de datos precalculados que aceleraban el desencriptado, estas tablas fueron generadas de forma distribuida gracias a numerosos colaboradores, con las mismas, apenas en veinte segundos se obtiene texto claro (en lo que nos ocupa, la conversación desencriptada). Las Rainbow Tables están accesibles a todos los usuarios a través de Bittorrent así como el Kraken, el software necesario para desencriptar las comunicaciones.

3er Ataque

De las tres medidas de seguridad que he expuesto al principio del artículo, solo queda la dificultad de la interceptación de señales digitales.

Para afrontar este último punto, los investigadores pusieron grandes esperanzas en GNU Radio, la idea de hacer sistemas de radios basados en software, con grandes avances en el tema pero no se llegó a hacer de forma lo suficientemente económico, debido a las necesidades en Hardware. No obstante, se abarató bastante el precio de los sistemas de interceptación GSM.

En este contexto, existen proyectos de software libre que crean diferentes elementos de una red GSM, estos proyectos son OpenBSC y OpenBTS. Estas herramientas pueden ser utilizadas en la realización de más ataques.

Un ejemplo, en la conferencia Defcon en Las Vegas demostraron como crear una BTS, permitía a un móvil conectarse y enrutaba la llamada a través de Asterisk,  a una RTB o a través de otro móvil. Si configuramos esta BTS como si fuera de un proveedor existente, sin ninguna opción de encriptado activa, podríamos hacer creer al usuario que está realmente conectado e interceptar las llamadas que realice ya que no podría recibir llamadas (su número no constaría como activo en su proveedor). También sus llamadas saldrían con un número de teléfono diferente o anónimo. Si además tenemos en cuenta que ya existe un Live CD que lleva OpenBTS, Asterisk y todas las herramientas necesarias para crear un celda GSM funcional con llamadas que salen por una RTB, RDSI,VoIP... La OpenBootTS.

Todo esto, añadido a que muchos terminales anuncian con un icono cuando la BTS no acepta cifrado, hace que sea fácil darse cuenta cuando nos están haciendo un ataque de este tipo.

No obstante este ataque hay que tenerlo muy en cuenta, el precio del hardware necesario ronda los 1500$ lo que me parece bastante asequible, sobre todo cuando estamos hablando sobre seguridad en nuestras comunicaciones.

El después

El 28 de diciembre, Sylvain Munaut y Karsten Nohl, durante el 27 congreso del CCC en Berlin, demostraron como con 4 teléfonos de 15€ cada uno se pueden pinchar llamadas de teléfono GSM. Salvando así la última barrera, la interceptación de comunicaciones digitales. [Diapositivas] [Video]

Decir que el mérito es de ellos es reducir enormemente la lista de los investigadores implicados. Todo empezó con el proyecto osmocombb una pila GSM de software libre, liderada por un fenómeno llamado Harald Welte y con una larga lista de colaboradores, esta pila funciona sobre cierto tipo de teléfonos antiguos, los cuales son ideales para esta función debido a la cantidad de información interna sobre los mismos, estos teléfonos ya no se fabrican pero se pueden encontrar en gran número por eBay y son extremadamente baratos. Usado osmocombb, con ciertas funciones programadas para el objetivo de sniffar GSM, con una pequeña modificación del hardware del teléfono, hicieron la demostración en vivo, tardando apenas unos segundos en descifrar la conversación.

Afortunadamente, para las proveedoras, los autores han anunciado que no van a hacer público el código utilizado pero publicaron el camino a seguir:

Sylvain Munaut 246tnt at gmail.com Fri Dec 31 17:29:36 CET 2010 Previous message: 27c3 videos Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] Hi, Since a lot of people are asking the same questions and there seems to be a rush on the C123 on ebay I tought some clarification is needed. Short version: - The exact tools I used on stage are _not_ and will _not_ be released (or sold ... several people asked ...) - Any one willing to re-code them without any apriori knowledge of GSM would most likely need months to read/understand both the specifications and the way the code works. (That's thousands of page of GSM spec and thousands of line of code) - Osmocom-BB project is not designed to be a sniffer, it's a baseband implementation, I just used part of it as a base. So basically, unless you are really interested in GSM and are willing to dedicate time to understand it deeply and to contribute the various projects, there is not much point in you buying phones, or hanging out in the ml/irc or whatever ... For those who are still reading and interested here's a little more detail: * The HLR query step: -> Go watch the awesome 25C3 talk about it * The TMSI recovering step - Won't be published - If you know how paging works, you know what to do anyway and it's trivial. Method is in the talk, there is nothing to it. * The targeted sniffing application - Won't be published either - Some improvements to the layer23 app frame work will be done but these are generic framework stuff, not app-specific - Again, if you know how L2 works and have looked at several traces, it's obvious what to do. - The 'DSP' part of the sniffer is public for a while with a small demo app (single phone and doesn't exploit the full potential of the DSP patch) and it's perfectly sufficient to debug things on your o wn controlled network. (This is basically what I showed at Deepsec 2010). * The tool to generate the input to Kraken - Won't be published either - Making the guesses is easy for anyone that knows what he's doing. * The improved Kraken - No idea about it, see with Karsten / Sacha / Frank, I only got access to it 1 hour or so before the talk :) * Conversion from burst to audio - This was a hacked software mostly with airprobe code. - The exact app will not be released but I'd like to see the capability put in some clean library we can re-use from airprobe and other application without having to multiply the code each time. - ... But since I'd like it to support AMR and viterbi softoutput before that happens, it could take some time. - Anyone familiar with GSM, airprobe and C could re-hack the same thing in an hour ... …………………. Cheers, Sylvain Munaut

Como vemos, no publican el código, pero dicen los pasos a seguir, básicamente es necesario estudiarse el protocolo GSM, y entender el protocolo, ya que el código para sniffar desde el móvil si esta creado y publicado, hay que hacer el programa en C que, usando las rutinas propias del osmocom, lea las tramas las interprete de forma adecuada, y haga que el teléfono salte de canal cuando lo tiene que hacer, así con 4 teléfonos podemos abarcar todo el espectro de GSM-900, unos deben de detectar los cambios de frecuencia y otros se encargan de saltar de frecuencia y grabar las tramas para un posterior desencriptado.

Yo mismo, me he embarcado en este proyecto, con grandes avances, lo que me hace pensar que no tiene una dificultad alta reproducir su ataque, al menos para la parte de interceptar SMS ya que con codecs de audio y tal no me quiero meter, y no entra en un principio en mi campo de trabajo. Los pasos que me he marcado en esto:

• Entender como osmocom está creado y como programar para esta pila (hecho) 
• Capturar tramas GSM (hecho ya por osmocombb).
• Entender el protocolo GSM, envio/recepción de SMS en particular (Avanzando…).
• Implementar código (Avanzando…)

Consecuencias

Las consecuencias, son claras, de primeras, espionaje, a la novia, industrial, de estado… ¡Que voy a explicar yo ahora de esto! Solo que hoy en día la mayoría de la gente considera sus comunicaciones seguras a no ser que sea para temas ilegales (SITEL).  Pero también, debido a la nueva pila osmocombb, nos deja a los programadores un framework con el que trabajar para explotar otras vulnerabilidades conocidas de redes GSM, como por ejemplo reservar todos los canales de GSM mediante peticiones handover, es decir, mensajes para cambiar a celda que va a través del BS al BSC, las cuales no llegan a completarse haciendo que el BS ocupe N canales para N peticiones maliciosas, pudiendo dejar así un BS sin canales libres y el resto de móviles en la celda no podrían comunicarse, es decir una falsa congestión de red estilo las de Nochevieja. Este ataque fue publicado en la revista Saqueadores Edición Técnica.

Otras víctimas, son los sistemas de autenticación por SMS, actualmente utilizadas por páginas de pago de Internet, para Google Apps y banca. También es usada por proveedores de telefonía para poder acceder a la factura detallada de teléfono, incluidos los de empresas.

Mi proyecto en este tema es además implementar un fuzzer, para testar las diferentes implementaciones de GSM de las diferentes BTS, el mismo en unas malas manos puede llegar a crear el pánico en las operadoras de telefonía, ya que estos desarrollos no están muy investigados y pueden tener (seguro que tienen) muchos muchos fallos, con posibles consecuencias graves.

En resumen, nuestras comunicaciones móviles están en la cuerda floja, un grupo bien preparado de ciberterroristas tienen ahora un arma importante, y si no la tienen, en breve la tendrán, me tomaré la libertad de augurar un Live CD crackea GSM con las Rainbow tables aparte.

Hay que aclarar, que hasta ahora, sólo he estado hablando del GSM llamado 2G, de momento la transmisiones de datos (GPRS) y el GSM 3G están a salvo (de momento ya que la pila GPRS ya está creada y funcionando).  La mayoría de nuestros teléfonos, para conversaciones y SMS aún siguen usando la red 2G, ya que las operadores quieren dejar el 3G para los datos y no sobrecargarlas, va siendo el momento de ir dando el salto definitivo.

Existen muchos proyectos del estilo osmocombb. Por ejemplo esta Dedected para escuchar las conversaciones de los teléfonos inalámbricos DECT que no cifran las conversaciones (aunque el cifrado está roto),  este proyecto ya funciona y da miedito ver cuántos teléfonos no cifran (en standard deja a elección libre). La misma gente de osmocombb han empezado ahora a realizar una pila de TETRA, aunque, a día de hoy no conozco un ataque público al sistema TetraPol.

PSYOPS y la jihad en internet

La doctrina militar española define como operaciones de guerra psicológica, PSYOPS, a “aquellas actividades psicológicas planeadas y dirigidas, en paz, crisis o guerra, a un público hostil, amigo o neutral, para influir en sus actitudes y comportamientos que afectan a la consecución de objetivos políticos y militares”

Frecuentemente las PSYOPS han equivalido al uso de propaganda, destinada comúnmente a fortalecer la moral propia y especialmente a minar la moral del enemigo. A lo largo de la historia militar se han utilizado con este fin diversos medios, desde programas de radio en el idioma del enemigo a panfletos lanzados por aviones sobre las tropas del adversario.

Propaganda de la segunda guerra mundial. Fuente:psywar

Las operaciones psicológicas no solo pueden usarse para debilitar la voluntad del enemigo, también pueden usarse para reforzar y estimular los sentimientos de cooperación de los aliados y ganar el apoyo de los no definidos todavía.

Internet visto como un medio de comunicación de masas es por tanto territorio abonado para el despliegue de PSYOPS, conforme va ganando terreno sobre otros medios de comunicación tradicionales se convierte por sus propios meritos en un candidato ideal para la difusión de propaganda.

Una de las características de internet es que los generadores de contenidos son en gran parte los propios usuarios, al contrario de los antiguos medios unidireccionales, por ello está al alcance de cualquier grupo medianamente organizado el realizar operaciones de PSYOPS, incluidas por supuesto organizaciones terroristas.

Dos buenos ejemplos de PSYOPS terroristas en internet son las revistas electrónicas Inspire e InFight, se trata de dos publicaciones electrónicas jihadistas con un denominador común, se editan en ingles. Es esta característica las que las identifica claramente como material de propaganda, no están dirigidas a un público islámico que usaría mayoritariamente el árabe si no directamente a un público occidental.

InFight según se anuncia a sí misma como el medio de comunicación oficial del Emirato Islamico de Afganistan , el principal tema de esta publicación es dar publicidad a los ataques y operaciones realizadas por los talibanes y fuerzas afines contrarias a la presencia militar extranjera y al actual gobierno afgano. Sus artículos se ilustran principalmente con material de agencias de prensa y suelen seleccionarse por su impacto psicológico, imágenes de blindados destruidos por artefactos explosivos o entierros de soldados de la OTAN son recurrentes en sus páginas. Precisamente el uso de material de prensa occidental podría indicar que la publicación está originada en simples simpatizantes islámicos más que por militantes directamente vinculados en las organizaciones combatientes.

Inspire por su parte se trataría de una publicación en ingles de AQAP, Al-Qaeda en la Península Arabica. Si con InFight nos encontrábamos con un aspecto casi a nivel profesional, Inspire le supera al contar con una maquetación que podría ser la propia de cualquier revista occidental.

Los artículos de Inspire suelen tener una mayor variedad, y van desde reflexiones religiosas tales como si es ajustado a la moral islámica el robo de propiedades de los infieles a recetas caseras de explosivos y llamamientos a la jihad individual de ciudadanos en occidente. Al contrario que Inspire cuya única finalidad propagandística era minar la moral occidental de la intervención en Afganistán, aquí nos encontramos con otra de las posibilidades de la ciberpropaganda, la de servir de catalizador a simpatizantes indecisos y que estos cometan actos terroristas en sus países. Tal es así que uno de los números alababa la acción de Nidal Malik Hasan , el norteamericano musulmán de origen palestino y miembro del US Army que protagonizo un tiroteo en el interior de Fort Hood.

A los contenidos de Inspire se suelen añadir además entrevistas, fotos o relatos, supuestamente en exclusiva, lo que de ser cierto indicaría que los autores de esta publicación si se encuentran en comunicación directa con Al-Qaeda en Arabia. Como ejemplo en uno de los números ofrecieron fotografias en exclusiva de los artefactos explosivos escondidos en cartuchos de impresora y que de no haber sido detectados hubieran derribado en vuelo aviones de carga al servicio de compañías de mensajería. Así como detalles de cómo habrían vulnerado las medidas de seguridad que permitieron que los artefactos fueran embarcados en vuelos antes de llegar a ser encontrados.Segun la revista, y como ejemplo de la mas tipica propaganda, esta operación se considera un exito pues aunque las bombas no llegaran a explotar un gasto de unos pocos miles de dolares se iba a convertir en perdidas millonarias para la industria del transporte aereo.

Inspire además ofrece en su contraportada una clave publica del programa criptográfico “Mujahideen secrets 2” y unas direcciones de correo de contacto que llaman la atención por ser cuentas de servicios basados en EEUU como Yahoo o Hotmail. Por detalles como estos no han faltado teóricos de la conspiración que indican que la revista podría tratarse de una publicación honeypot realizada por algún servicio de inteligencia occidental. Aunque cabe preguntarse si fuera ese el caso por que dichos servicios son tan descuidados o pretenden parecerlo, más bien si aplicamos el razonamiento de la explicación más sencilla llegamos a la conclusión de que mas posiblemente nos encontramos ante simpatizantes del terrorismo islamico que ingenuamente o no son conscientes o no les preocupa que sus mensajes cifrados pueden ser interceptados.

Recursos:

Revista InFight 24 correspondiente al mes de Diciembre 2010. 187 paginas

http://www.zshare.net/download/845916138c1987c2/
http://www.zshare.net/download/84592781c4bac941/
http://www.megaupload.com/?d=QV6AJ13W
http://depositfiles.com/en/files/kmk4asx0s
http://hotfile.com/dl/93295595/d4561e9/3421465.rar.html
http://uploading.com/files/38cbf714/3421465.rar/
http://www.badongo.com/file/24887059

Revista Inspire 4 correspondiente al mes de Enero 2011. 67 paginas

http://www.scribd.com/doc/47119670/Inspire-January-2011

Publicar o no publicar: Esta NO es la cuestión

No han tardado... Uno de nuestros lectores, ya nos ha preguntado que sobre si que pensamos sobre el hecho de que desde este blog podamos dar ideas a los 'malos'.

He de decir, que este tema, ya lo tenía pensado, no es la primera vez que me ocurre, el año pasado por ejemplo, tras dar una conferencia sobre interceptación y aprovechamiento de conexiones satelitales, una persona de USA que trabajaba en 'análisis de amenazas en Virginia' (inteligencia vamos) me pregunto esto mismo. Antes de deciros mi respuesta, unos cuantos datos:

Hace unos 12/13 años, el mundo de la seguridad era bastante más reducido, prácticamente nos conocíamos todos, incluso en persona. Por aquel entonces ya existía cierto mercadeo con vulnerabilidades 0day (no publicadas), en congresos semi secretos, por chats y en ciertos foros especializados. Este trading se hacía cambiando exploits por otros exploits, muchos de ellos tardaban años en hacerse públicos lo que te daba una ventaja inmensa frente a competidores en el mundo de la seguridad o ventaja frente a los administradores de sistemas cuando aseguraban sus sistemas.

/** !!!! Private do not distribute !!!! * * <1080r2.c> defintive socks5 remote exploit / linux x86 * * Usage: * $ xhost + * $ ./1080r2 [offset] * => And wait a xterm to be sent back to you... * * Vulnerables: (offset) * socks5-v1.0r10 (compiled on a turbolinux 4.0.5) => 0 * socks5-v1.0r9 (compiled on a turbolinux 4.0.5) => 0 * socks5-v1.0r8 (compiled on a turbolinux 4.0.5) => 0 * socks5-v1.0r10 (compiled on a redhat 6.0) => 400 * socks5-s5watch-1.0r9-2 (redhat-contrib) => no? * socks5-0.17-1 (redhat 4.2) => no * socks5-1.0r10-5 (redhat-contrib) => no?? * socks5-server-1.0r6-8TL (TurboContrib) => no?? * * By: The Dark Raver of t0s (Spain - 9/5/2000) * - * "Pasaba arrolladora en su hermosura * y el paso le dejé, * ni aun mirarla me volví, y no obstante * algo en mi oído murmuró, esa es..." * */ ….

/* #### PRIVATE DO NOT DISTRIBUTE #### Expl para el Iplanet Web Proxy 1.0 Format bug en sistema de logs de errores. Modificamos el SEH con la direcci¢n 0x100015F8 que pertenece a ns-proxy35.dll y es un "call %ebx" ya que %ebx apunta al inicio del shellcode y %ebx no se modifica al cambiar al contexto del SEH. Esto es una BETA deberia de funcionar de manera local // Se buscan programadores de shellcodes para win32 <- Ya no! // ref 0xdeadcafe Por cierto, esto deberia de compilar en todos los compiladores de C y se usa: .\iwpx |nc Leonardo Nve aka Fuego Fatuo fatuo@t0s.org Agradecimientos: Dark Raver, Zhodiac, kekabron y Raise por su I+D para win32 al resto de 0xdeadcafe #### PRIVATE DO NOT DISTRIBUTE #### */ ….

Cabeceras de algunos exploits que eran 0days hace 10 años.  Sniff! Que tiempos.

Desde hace muy poco, esto ha cambiado, ahora este mercadeo se da a cambio de dinero. Todo empezó con proyectos como iDefense o el ZDI (Zero Day Initiative), empresas que compran vulnerabilidades a los investigadores. Inicialmente el dinero que te daban por una vulnerabilidad importante era de 1000$. Luego estas empresas les cobraban más a los fabricantes por el servicio de decirles sus vulnerabilidades antes de que sean publicadas y permitirles publicar un parche, así como vendían a profesionales para que pudieran advertir a sus clientes en el transcurso de una auditoría o  mantenimiento.

Junto con esto, surgieron otras familias que dedicándose al mundo de botnets/phising vieron que esta información era importante, ir por delante de los sistemas de seguridad les era rentable, así que empezaron a comprar vulnerabilidades también en el mercado negro. Es evidente que el precio de estas vulnerabilidades sube, oferta y demanda.... Ahora los precios oscilan de 1000$ a 100.000$, según diversos sitios, la media está en 50.000$, todo depende de que producto sea el vulnerable, lo difundido que esté, lo “zero” que sea esa vulnerabilidad, y más criterios. Según estos precios, ¿Por qué publicar y no vender?

  Fuente zdnet

¡¡¡Y aún hay más!!! Como vemos en el siguiente cuadro extraído de un informe  de ESET, vemos como tanto en el caso de Stuxnet y de la operación Aurora, se usaron 0days. Estos proyectos siempre han sonado a operación de Ciberinteligencia, puede que estas vulnerabilidades las hayan encontrado ellos o las hayan comprado, quien sabe... 

La cuestión es, ¿Estaríamos más seguros con esto publicado o sin publicar?

¡¡¡Y aún hay más!!! No solo se venden vulnerabilidades o técnicas, también sitios gubernamentales y militares ya hackeados, como veréis en este caso los precios son una ganga:

Fuente Imperva

Ahora haced un esfuerzo de imaginación, y pensad que pasaría si no se hubiera publicado las técnicas de descifrar WEP... Si, los vecinos no se robarían el wifi mutuamente, pero imaginad que podrían hacer aquellos que SI supieran hacerlo... 

Al final del artículo, publico una serie de links sobre el tema de compra/venta de vulnerabilidades, pero hay una presentación de Pedram Amini  “Mostrame la guita!” en la que explica muy bien este mundo. [Presentación] [Video]

Mi respuesta a la persona, que me preguntó sobre el uso de por parte de los malos de lo que publiqué fue, ¿Como sabemos que no lo estában haciendo ya?

Es necesario conocer nuestros puntos débiles, para esto se ha de promocionar la investigación (algo sobre lo cual no se hace lo suficiente a mi opinión) y la publicación, a no ser que nos interese que el  mundo se mantenga algo inseguro... No obstante, tengo los pies en la tierra, algunos de los fallos publicados y que se publicarán, no pueden ser solucionados de un día a otro debido a su complejidad, no solo técnica, sino también económica. ¿Qué hacer? Las empresas/administradores/agentes de seguridad implicados deben de crear una política de detección de ataques, y de reacción a los mismos haciendo un plan de contingencia adecuado. El objetivo: minimizar los posibles efectos a un nivel aceptable hasta que se ofrezca una solución viable (y por supuesto empezar a  buscarla).

Mañana, un ejemplo:  ¿¿¿Seguridad en GSM??? Nooooo



/* 


Pregunta para los comentarios: ¿Se podría comparar el tráfico de vulnerabilidades al tráfico de armas? 


*/

Links interesantes:

Charlie Miller’s paper on selling zero-day vulnerabilities: http://weis2007.econinfosec.org/papers/29.pdf

VeriSign’s bug-buying program: 
http://labs.idefense.com/vcp

TippingPoint’s bug-buying program: 
http://www.zerodayinitiative.com

Google’s bug-buying program: 

http://blog.chromium.org/2010/01/encouraging-more-chromium-security.html

Mozilla’s bug-buying program:
http://www.mozilla.org/security/bug-bounty.html