Del traductor y TL;DR
TL;DR:
Parece que VoLTE está aún peor protegido que los primeros clientes de Wi-Fi con WEP. Un error arquitectónico que permite algo de XOR en el tráfico y recuperar la clave. El ataque es posible si estás cerca del que llama y realiza llamadas con frecuencia.
Gracias por la referencia y TL;DR
Los investigadores han creado una aplicación para determinar si tu operador es vulnerable, más detalles . Comparte en los comentarios los resultados, en mi región VoLTE está desactivado en MegaFon.
Sobre el autor
Matthew Green.
Soy criptógrafo y profesor en la Universidad Johns Hopkins. He desarrollado y analizado sistemas criptográficos utilizados en redes inalámbricas, sistemas de pago y plataformas de protección de contenido digital. En mis investigaciones, examino diversas formas de utilizar la criptografía para mejorar la privacidad de los usuarios.
No he escrito un post del formato , y eso me ha molestado. No porque no haya ataques, sino principalmente porque no había un ataque a algo lo suficientemente ampliamente utilizado como para sacar de mi crisis creativa.
Pero hoy me encontré con llamado ReVoLTE a los protocolos, cuya vulneración me alegra especialmente, es decir, los protocolos de redes celulares (voz sobre) LTE. Estoy entusiasmado con estos protocolos y este nuevo ataque porque es muy raro ver la violación de protocolos y realizaciones reales de redes celulares. Principalmente porque estos estándares están desarrollados en habitaciones fumadas y documentados en documentos de 12000 páginas que no podría soportar cualquier investigador. Además, la implementación de estos ataques obliga a los investigadores a utilizar protocolos de radio complejos.
Por lo tanto, graves vulnerabilidades criptográficas pueden extenderse por todo el mundo y podrían ser utilizadas solo por gobiernos, antes de que algún investigador se fije en ellas. Pero de vez en cuando hay excepciones, y el ataque de hoy es una de ellas.
Autores : David Rupprecht, Katharina Kohls, Thorsten Holz y Christina Pöpper de la Universidad Ruhr de Bochum y la Universidad de Nueva York en Abu Dabi. Este es un excelente ataque a la reinstalación de la clave en el protocolo de voz que probablemente ya esté utilizando (asumiendo que pertenece a una generación mayor que aún realiza llamadas telefónicas desde un teléfono móvil).
Para empezar, un breve recorrido histórico.
¿Qué son LTE y VoLTE?
La base de nuestros estándares modernos de telefonía móvil se estableció en Europa ya en los años 80 con el estándar (Sistema Global para Comunicaciones Móviles). GSM fue el primer estándar principal de telefonía móvil digital que introdujo una serie de funciones revolucionarias, como el uso de para proteger las llamadas telefónicas. El GSM temprano fue desarrollado principalmente para la comunicación de voz, aunque se podía agregar de forma paga .
A medida que ganaba importancia la transmisión de datos en la telefonía móvil, se desarrollaron los estándares Long Term Evolution (LTE) para racionalizar este tipo de comunicación. LTE se basa en un conjunto de estándares más antiguos, como GSM, y y está diseñado para aumentar la velocidad de intercambio de datos. En este ámbito, hay mucha comercialización y , pero en resumen, LTE es un sistema de transmisión de datos que sirve como puente entre los antiguos protocolos de transmisión de datos por paquetes y las futuras tecnologías de transmisión de datos móviles .
Por supuesto, la historia nos dice que tan pronto como haya suficiente ancho de banda (IP), conceptos como 'voz' y 'datos' comenzarán a difuminarse. Lo mismo se aplica a los protocolos móviles modernos. Para hacer esta transición más fluida, los estándares LTE definen (VoLTE), que es un estándar IP para la transmisión de llamadas de voz directamente a través del plano de datos del sistema LTE, eludiendo por completo la parte conmutada de la red celular. Al igual que con las , las llamadas VoLTE pueden ser terminadas por el operador de la red celular y conectadas a la red telefónica convencional. O (lo que se está volviendo cada vez más común) pueden ser directamente de un cliente móvil a otro, e incluso entre diferentes proveedores.
Al igual que la VoIP estándar, VoLTE se basa en dos protocolos populares basados en IP: el protocolo de iniciación de sesión ( – SIP) para establecer la llamada, y el protocolo de transporte en tiempo real (, que debería llamarse RTTP, pero en realidad se llama RTP) para manejar los datos de voz. VoLTE también añade algunas optimizaciones adicionales de ancho de banda, como la compresión de encabezados.
Bien, ¿qué relación tiene esto con el cifrado?
LTE, al igual que , tiene un conjunto estándar de protocolos criptográficos para cifrar los paquetes mientras se transmiten por aire. Están diseñados principalmente para proteger sus datos mientras se trasladan entre el teléfono (denominado 'equipo del usuario' o UE) y la torre de telefonía móvil (o donde quiera que su proveedor decida finalizar la conexión). Esto se debe a que los proveedores de telefonía móvil consideran a los dispositivos de escucha externos como enemigos. Por supuesto.
(Sin embargo, el hecho de que las conexiones VoLTE pueden ocurrir directamente entre clientes en diferentes redes de proveedores significa que el propio protocolo VoLTE tiene algunos protocolos de cifrado adicionales y opcionales que pueden ocurrir en niveles de red más altos. Esto no se refiere al artículo actual, excepto por el hecho de que pueden arruinarlo todo. Hablaremos brevemente de ellos más adelante).
Históricamente, el cifrado en GSM tenía : malos , protocolos en los que solo el teléfono se autenticaba en la torre (lo que significa que un atacante podría hacerse pasar por la torre, generando ) y así sucesivamente. LTE corrigió muchos de los errores evidentes, aunque mantuvo gran parte de la estructura anterior.
Comencemos con el cifrado en sí. Suponiendo que ya se ha creado una clave —y hablaremos de esto en un minuto— cada paquete de datos se cifra utilizando un modo de cifrado de flujo con un cifrado denominado 'EEA' (que en la práctica puede implementarse mediante cosas como AES). En esencia, aquí el mecanismo de cifrado es , como se muestra a continuación:
El algoritmo principal de cifrado de paquetes VoLTE (fuente: ). EEA – cifrado, «COUNT» – contador de 32 bits, «BEARER» — identificador único de sesión que separa conexiones VoLTE y tráfico de internet normal. «DIRECTION» indica en qué dirección se mueve el tráfico – desde el UE hacia la torre o viceversa.
Dado que el propio algoritmo de cifrado (EEA) puede implementarse utilizando un cifrado fuerte como AES, es poco probable que haya algún ataque directo al cifrado como ocurrió Sin embargo, es evidente que incluso con un cifrado fuerte, este esquema de cifrado representa un excelente medio para dispararse en el pie.
En particular: en el estándar LTE se utiliza un cifrado de flujo (no autenticado) con un modo que sería extremadamente vulnerable si el contador – y otras entradas, como «bearer» y «direction» – fueran utilizados nuevamente. En lenguaje moderno, el término para este concepto es «ataque de reutilización de nonce», pero los riesgos potenciales aquí no son algo novedoso. Son conocidos y antiguos, que se remontan a los días del glam metal e incluso del disco.
Los ataques de reutilización de nonce en el modo CTR existían ya cuando Poison se hicieron conocidos.
A decir verdad, en los estándares LTE se indica: «No reutilicen estos contadores, por favor». Pero los estándares LTE ocupan alrededor de 7000 páginas, y en cualquier caso, es como suplicar a los niños que no jueguen con una pistola. Inevitablemente lo harán, y ocurrirán cosas horribles. En este caso, la pistola que dispara es un ataque de reutilización de flujo de claves, donde dos mensajes confidenciales diferentes se XORan con los mismos bytes del flujo de claves. Se sabe que esto .
¿Qué es ReVoLTE?
El ataque ReVoLTE demuestra que, en la práctica, esta construcción de cifrado muy vulnerable se utiliza incorrectamente en el equipo real. En particular, los autores analizan llamadas reales de VoLTE realizadas con equipo comercial y muestran que pueden usar algo llamado «ataque de reinstalación de clave». (Un gran mérito por descubrir este problema pertenece a (Raza & Lu), que fueron los primeros en señalar una posible vulnerabilidad. Pero las investigaciones de ReVoLTE la convierten en un ataque práctico).
Déjame mostrarte brevemente la esencia del ataque, aunque deberías mirar también el .
Se puede suponer que una vez que LTE establece una conexión de transferencia de datos, la tarea de transmitir voz sobre LTE se convierte simplemente en un asunto de enrutar paquetes de voz a través de esta conexión junto con todo tu otro tráfico. En otras palabras, VoLTE será un concepto que existe solo sobre [modelos OSI – ejemplo de referencia.] No es exactamente así.
De hecho, el nivel de enlace de LTE introduce el concepto de "bearer". Bearer son identificadores de sesiones individuales que separan diferentes tipos de tráfico de paquetes. El tráfico habitual de Internet (tu Twitter y Snapchat) pasa a través de un bearer. La señalización SIP para VoIP va a través de otro, y los paquetes de tráfico de voz se procesan en un tercero. No tengo mucho conocimiento sobre los mecanismos de canales de radio y el enrutamiento de red LTE, pero supongo que se hace así porque las redes LTE quieren garantizar el funcionamiento de los mecanismos de QoS (calidad de servicio), de modo que diferentes flujos de paquetes sean procesados con diferentes niveles de prioridad: es decir, tus conexiones TCP de segunda categoría con Facebook pueden tener una menor prioridad que tus llamadas de voz en tiempo real.
Esto en general no es un problema, pero las consecuencias son las siguientes. Las claves para el cifrado de LTE se crean por separado cada vez que se establece un nuevo "bearer". En principio, esto debería ocurrir de nuevo cada vez que realizas una nueva llamada telefónica. Esto hará que cada llamada use una clave de cifrado diferente, lo que excluye la posibilidad de reutilizar la misma clave para cifrar dos conjuntos diferentes de paquetes de llamadas de voz. De hecho, el estándar LTE dice algo así como "debes usar claves diferentes cada vez que estableces un nuevo bearer para procesar una nueva llamada telefónica". Pero eso no significa que esto realmente ocurra.
En realidad, en las implementaciones reales, dos llamadas distintas que ocurren en proximidad temporal usarán la misma clave, a pesar de que se están configurando nuevos bearers (con el mismo nombre) entre ellas. El único cambio práctico que ocurre entre estas llamadas es que el contador de cifrado se reinicia a cero. A veces, en la literatura, esto se denomina . Se podría argumentar que, en esencia, es un error de implementación, aunque en este caso los riesgos, parece, derivan en gran medida del propio estándar.
En la práctica, este ataque conduce a la reutilización del flujo de clave, donde un atacante puede obtener paquetes cifrados $inline$C_1 = M_1 ⊕ KS$inline$ y $inline$C_2 = M_2 ⊕ KS$inline$, lo que permite calcular $inline$C_1 ⊕ C_2 = M_1 ⊕ M_2$inline$. Aún mejor, si el atacante conoce uno de $inline$M_1$inline$ o $inline$M_2$inline$, puede recuperar inmediatamente el otro. Esto le da un fuerte incentivo para conocer uno de los dos componentes no cifrados.
Esto nos lleva al escenario de ataque más completo y eficaz. Consideremos a un atacante que puede interceptar el tráfico de radio entre el teléfono objetivo y la torre de celular, y que, de alguna manera astuta, tuvo 'suerte' al grabar dos llamadas distintas, donde la segunda ocurre inmediatamente después de la primera. Ahora imagina que de alguna manera puede adivinar el contenido no cifrado de una de las llamadas. Con tal suerte fortuita nuestro atacante puede descifrar completamente la primera llamada utilizando un simple XOR entre dos conjuntos de paquetes.
Por supuesto, aquí la suerte no tiene nada que ver. Dado que los teléfonos están diseñados para recibir llamadas, un atacante que puede escuchar la primera llamada podrá iniciar la segunda llamada justo en el momento en que finalice la primera. Esta segunda llamada, en caso de reutilizar la misma clave de cifrado con el contador reiniciado a cero, permitirá recuperar los datos no cifrados. Además, dado que nuestro atacante controla efectivamente los datos durante la segunda llamada, puede recuperar el contenido de la primera llamada, gracias a una serie de pequeños detalles específicos de la implementación , que juegan a su favor.Aquí está una representación general del plan de ataque, tomada de
Aquí está la imagen del plan de ataque general, tomada de :
Revisión del ataque desde . Este esquema supone que se producen dos llamadas diferentes utilizando la misma clave. El atacante controla un sniffer pasivo (en la parte superior izquierda), así como un segundo teléfono, con el cual puede realizar una segunda llamada al teléfono de la víctima.
¿Así que el ataque realmente funciona?
Por un lado, esta es realmente la pregunta principal para un artículo sobre ReVoLTE. Teóricamente, todas las ideas mencionadas anteriormente son magníficas, pero dejan muchas preguntas. Tales como:
- ¿Es posible (para los investigadores académicos) interceptar realmente una conexión VoLTE?
- ¿Realmente los sistemas LTE reales reestablecen las claves?
- ¿Puedes realmente iniciar una segunda llamada lo suficientemente rápido y de manera confiable para que el teléfono y la torre vuelvan a usar la misma clave?
- Incluso si los sistemas reestablecen las claves, ¿puedes realmente conocer el contenido no cifrado de la segunda llamada, considerando que cosas como los códecs y la recodificación pueden cambiar completamente (bit a bit) el contenido de esa segunda llamada, incluso si tienes acceso a los "bits" que provienen de tu teléfono atacante?
Sobre algunas de estas preguntas, el trabajo de ReVoLTE responde afirmativamente. Los autores utilizan un sniffer de radio software-programable comercial llamado para interceptar la llamada VoLTE desde el lado descendente. (Creo que simplemente dominar el software y entender aproximadamente cómo funciona tomó meses de vida a los pobres graduados, lo cual es típico en tales investigaciones académicas).
Los investigadores descubrieron que para activar la reutilización de la clave, la segunda llamada debe ocurrir lo suficientemente rápido después de que la primera haya finalizado, pero no demasiado – aproximadamente diez segundos para los operadores con los que experimentaron. Afortunadamente, no importa si el usuario responde la llamada durante este tiempo – la "llamada", es decir, la propia conexión SIP, obliga al operador a reutilizar la misma clave.
Por lo tanto, muchos de los problemas más graves giran en torno al problema (4): la obtención de bits de contenido en claro de una llamada iniciada por un atacante. Esto sucede porque durante la transmisión de tu contenido desde el teléfono del agresor al teléfono de la víctima a través de la red celular pueden ocurrir muchas cosas. Por ejemplo, pueden producirse alteraciones en la codificación del flujo de audio, que mantienen el sonido original pero cambian completamente su representación binaria. Las redes LTE también utilizan compresión de encabezados RTP, lo que puede modificar significativamente gran parte del paquete RTP.
Finalmente, los paquetes enviados por el atacante deben alinearse más o menos con los paquetes que se enviaron durante la primera llamada telefónica. Esto puede ser problemático, ya que la modificación del silencio durante la llamada telefónica resulta en mensajes más cortos (el llamado ruido de confort), que pueden sincronizarse mal con la llamada original.
vale la pena leer en detalle. En ella se examinan muchos de los problemas mencionados anteriormente; en particular, los autores descubrieron que algunos códecs no son recodificados, y que aproximadamente el 89% de la representación binaria de la llamada objetivo puede ser recuperada. Esto es relevante al menos para dos operadores europeos que fueron probados.
Es un nivel de éxito sorprendentemente alto, y, francamente, mucho más alto de lo que esperaba cuando empecé a trabajar en este documento.
¿Qué podemos hacer para solucionarlo?
La respuesta inmediata a esta pregunta es extremadamente simple: dado que la esencia de la vulnerabilidad reside en el ataque de reutilización (reinicialización) de la clave, simplemente soluciona este problema. Asegúrate de que se obtenga una nueva clave para cada llamada telefónica, y nunca permitas que el contador de paquetes se restablezca a cero utilizando la misma clave. ¡El problema está resuelto!
Tal vez no. Esto requeriría una actualización significativa del equipo, y, francamente, tal fijación por sí sola no es muy confiable. Sería ideal si los estándares pudieran encontrar una manera más segura de implementar sus modos de cifrado, que no sean inherentemente catastróficamente vulnerables a problemas de reutilización de claves como este.
Una de las posibles opciones es utilizar . Esto puede ser demasiado costoso para algunos equipos modernos, pero sin duda es una dirección en la que los diseñadores deben pensar en el futuro, especialmente considerando que los estándares 5G van a conquistar el mundo.
Este nuevo estudio también plantea la pregunta general de por qué , muchos de los cuales utilizan construcciones y protocolos muy similares. Cuando te enfrentas al problema de reinstalar la misma clave en varios protocolos ampliamente utilizados, como WPA2, ¿no te parece que ha llegado el momento de hacer tus especificaciones y procedimientos de prueba más confiables? Ya basta de tratar a los implementadores de estándares como socios considerados que prestan atención a tus advertencias. Trátalos como (involuntarios) adversarios que inevitablemente van a implementar todo incorrectamente.
O como opción, podemos hacer lo que cada vez más hacen las empresas como Facebook y Apple: hacer que el cifrado de las llamadas de voz ocurra en un nivel más alto del stack de red OSI, sin depender de los fabricantes de equipos de telecomunicaciones. Incluso podríamos promover el cifrado de extremo a extremo de llamadas de voz, como lo hacen WhatsApp con Signal y FaceTime, suponiendo que el gobierno de los EE. UU. simplemente deje de . Entonces (excepto por algunos metadatos) muchos de estos problemas simplemente desaparecerían. Esta solución es especialmente relevante en un mundo donde .
O simplemente podemos hacer lo que ya hicieron nuestros hijos: dejar de responder estas molestas llamadas de voz.
Fuente: habr.com
