Sin ánimo de ser técnicamente profundo.
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
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.
Buen artículo Leo, sigue investigando que esto traerá tela :)
ResponderEliminarS. Crespo.