Del traductor y TL;DR
-
TL; DR:
Parece que VoLTE resultó estar incluso peor protegido que los primeros clientes Wi-Fi con WEP. Un error de cálculo exclusivamente arquitectónico que le permite XOR un poco el tráfico y restaurar la clave. Es posible un ataque si está cerca de la persona que llama y él hace llamadas con frecuencia.
-
Gracias por el consejo y TL;DR
-
Los investigadores han creado una aplicación para determinar si su operador es vulnerable, leer más . Comparta los resultados en los comentarios, VoLTE está deshabilitado en mi región en Megafon.
Acerca del Autor
Mateo Verde.
Soy criptógrafo y profesor en la Universidad Johns Hopkins. He diseñado y analizado sistemas criptográficos utilizados en redes inalámbricas, sistemas de pago y plataformas de seguridad de contenidos digitales. En mi investigación, analizo diferentes formas de utilizar la criptografía para mejorar la privacidad del usuario.
Ha pasado un tiempo desde que escribí un formato de publicación. , y me molestó. No porque no hubo ataques, sino sobre todo porque no hubo un ataque a algo lo suficientemente utilizado como para sacarme del bloqueo del escritor.
Pero hoy me encontré Se llama ReVoLTE por los protocolos que me entusiasman especialmente para piratear, es decir, los protocolos LTE de red celular (voz en off). Estoy entusiasmado con estos protocolos en particular (y este nuevo ataque) porque es muy raro ver protocolos e implementaciones de redes celulares reales siendo pirateados. Principalmente porque estos estándares se desarrollaron en salas llenas de humo y se documentaron en documentos de 12000 páginas que no todos los investigadores pueden manejar. 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 podrían extenderse por todo el mundo, tal vez sólo para ser explotadas por los gobiernos, antes de que cualquier investigador se dé cuenta. Pero de vez en cuando hay excepciones, y el ataque de hoy es una de ellas.
Autores Colaboradores: David Rupprecht, Katharina Kohls, Thorsten Holz y Christina Pöpper de la Ruhr-University Bochum y la New York University Abu Dhabi. Este es un gran ataque para reinstalar la clave en el protocolo de voz que probablemente ya estés usando (suponiendo que seas de una generación anterior que todavía hace llamadas telefónicas usando un teléfono celular).
Para empezar, una breve excursión histórica.
¿Qué son LTE y VoLTE?
La base de nuestros estándares modernos de telefonía celular se sentó en Europa en los años 80 con el estándar (Sistema global para comunicaciones móviles). GSM fue el primer estándar importante de telefonía celular digital, que introdujo una serie de características revolucionarias, como el uso para proteger las llamadas telefónicas. Los primeros GSM se diseñaron principalmente para comunicaciones de voz, aunque se podía gastar dinero .
A medida que la transmisión de datos se volvió más importante en las comunicaciones celulares, se desarrollaron estándares Long Term Evolution (LTE) para agilizar este tipo de comunicación. LTE se basa en un grupo de estándares más antiguos como GSM, и y está diseñado para aumentar la velocidad de intercambio de datos. Hay mucha marca y pero el TL;DR es que LTE es un sistema de transmisión de datos que sirve como puente entre los protocolos de datos por paquetes más antiguos y las futuras tecnologías de datos móviles. .
Por supuesto, la historia nos dice que una vez que haya suficiente ancho de banda (IP) disponible, conceptos como “voz” y “datos” comenzarán a desdibujarse. Lo mismo se aplica a los protocolos celulares modernos. Para hacer esta transición más fluida, los estándares LTE definen (VoLTE), que es un estándar IP para realizar llamadas de voz directamente a través del plano de datos de un sistema LTE, evitando por completo la parte de acceso telefónico de la red celular. Como con el estándar ,El operador de telefonía móvil puede finalizar las llamadas VoLTE y conectarlas a la red telefónica habitual. O (como es cada vez más común) directamente de un cliente celular a otro, e incluso entre diferentes proveedores.
Al igual que VoIP estándar, VoLTE se basa en dos protocolos populares basados en IP: Protocolo de inicio de sesión ( – SIP) para configuración de llamadas y protocolo de transporte en tiempo real (, que debería llamarse RTTP pero en realidad se llama RTP) para procesar datos de voz. VoLTE también agrega algunas optimizaciones de ancho de banda adicionales, como la compresión de encabezados.
Bien, ¿qué tiene esto que ver con el cifrado?
LTE, como , tiene un conjunto estándar de protocolos criptográficos para cifrar paquetes a medida que se transmiten por aire. Están diseñados principalmente para proteger sus datos mientras viajan entre el teléfono (llamado equipo de usuario o UE) y la torre de telefonía celular (o donde su proveedor decida terminar la conexión). Esto se debe a que los proveedores de telefonía móvil ven los dispositivos de escucha externos como enemigos. Bueno, por supuesto.
(Sin embargo, el hecho de que las conexiones VoLTE puedan ocurrir directamente entre clientes en redes de diferentes proveedores significa que el protocolo VoLTE en sí tiene algunos protocolos de cifrado adicionales y opcionales que pueden ocurrir en capas de red superiores. Esto no es relevante para el artículo actual, excepto el hecho de que pueden arruinarlo todo (hablaremos brevemente de ellos a continuación).
Históricamente, el cifrado en GSM ha sido : malo , protocolos en los que solo el teléfono estaba autenticado en la torre (lo que significa que un atacante podría hacerse pasar por la torre, generando ) etcétera. LTE corrigió muchos de los errores obvios manteniendo gran parte de la misma estructura.
Comencemos con el cifrado en sí. Suponiendo que la creación de la clave ya ocurrió, y hablaremos de eso en un minuto, entonces cada paquete de datos se cifra usando cifrado de flujo usando algo llamado "EEA" (que en la práctica se puede implementar usando cosas como AES). Esencialmente, el mecanismo de cifrado aquí es Como se muestra abajo:
El principal algoritmo de cifrado para paquetes VoLTE (fuente: ). EEA es un cifrado, "COUNT" es un contador de 32 bits, "BEARER" es un identificador de sesión único que separa las conexiones VoLTE del tráfico normal de Internet. "DIRECCIÓN" indica en qué dirección fluye el tráfico: del UE a la torre o viceversa.
Dado que el algoritmo de cifrado en sí (EEA) se puede implementar utilizando un cifrado fuerte como AES, es poco probable que haya algún ataque directo al cifrado como este. . Sin embargo, está claro que incluso con un cifrado sólido, este esquema de cifrado es una excelente manera de dispararse en el pie.
En particular: el estándar LTE utiliza un cifrado de flujo (no autenticado) con un modo que será extremadamente vulnerable si el contador (y otras entradas como "portador" y "dirección") alguna vez se reutilizan. En el lenguaje moderno, el término para este concepto es “ataque sin reutilización”, pero los riesgos potenciales aquí no son algo moderno. Son famosos y antiguos, y se remontan a la época del glam metal e incluso de la música disco.
Los ataques a la reutilización de nonce en el modo CTR existían incluso cuando se conoció Poison
Para ser justos, los estándares LTE dicen: "No reutilice estos medidores". Pero los estándares LTE tienen alrededor de 7000 páginas y, en cualquier caso, es como rogar a los niños que no jueguen con un arma. Inevitablemente lo harán, y sucederán cosas terribles. El arma disparadora en este caso es un ataque de reutilización de flujo de claves, en el que dos mensajes confidenciales diferentes XOR los mismos bytes de flujo de claves. Se sabe que este .
¿Qué es ReVoLTE?
El ataque ReVoLTE demuestra que, en la práctica, el hardware del mundo real hace un mal uso de este diseño de cifrado tan vulnerable. Específicamente, los autores analizan llamadas VoLTE reales realizadas con equipos comerciales y muestran que pueden utilizar algo llamado "ataque de reinstalación de claves". (Gran parte del crédito por encontrar este problema es para (Raza y Lu), quienes fueron los primeros en señalar la posible vulnerabilidad. Pero la investigación ReVoLTE lo convierte en un ataque práctico).
Déjame mostrarte brevemente la esencia del ataque, aunque debes mirar y .
Se podría suponer que una vez que LTE establece una conexión de paquetes de datos, la tarea de voz sobre LTE se convierte simplemente en una cuestión de enrutar paquetes de voz a través de esa conexión junto con el resto del tráfico. En otras palabras, VoLTE será un concepto que sólo existirá a lo largo de [Modelos OSI – aprox.]. Esto no es enteramente verdad.
De hecho, la capa de enlace LTE introduce el concepto de "portador". Los portadores son identificadores de sesión separados que separan diferentes tipos de tráfico de paquetes. El tráfico regular de Internet (tu Twitter y Snapchat) pasa por un portador. La señalización SIP para VoIP pasa por otro y los paquetes de tráfico de voz se procesan por un tercero. No tengo mucho conocimiento sobre los mecanismos de enrutamiento de redes y radio LTE, pero creo que se hace de esta manera porque las redes LTE quieren imponer mecanismos de QoS (calidad de servicio) para que se procesen diferentes flujos de paquetes en diferentes niveles de prioridad: es decir, tuyo segunda categoría Las conexiones TCP a Facebook pueden tener una prioridad menor que sus llamadas de voz en tiempo real.
Generalmente esto no es un problema, pero las consecuencias son las siguientes. Las claves para el cifrado LTE se crean por separado cada vez que se instala un nuevo "portador". Básicamente, esto debería volver a suceder cada vez que realice una nueva llamada telefónica. Esto dará como resultado que se utilice una clave de cifrado diferente para cada llamada, eliminando 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 una clave diferente cada vez que instales un nuevo portador para manejar una nueva llamada telefónica". Pero esto no significa que esto realmente suceda.
De hecho, en implementaciones de la vida real, dos llamadas diferentes que ocurren en estrecha proximidad temporal utilizarán la misma clave, a pesar de que se configuren nuevos portadores con el mismo nombre entre ellas. El único cambio práctico que se produce entre estas llamadas es que el contador de cifrado se pone a cero. En la literatura esto a veces se llama . Se podría argumentar que esto es esencialmente un error de implementación, aunque en este caso los riesgos parecen provenir en gran medida del estándar mismo.
En la práctica, este ataque da como resultado la reutilización del flujo de claves, donde el atacante puede obtener los paquetes cifrados $inline$C_1 = M_1 más KS$inline$ y $inline$C_2 = M_2 más KS$inline$, lo que permite el cálculo de $inline$ C_1 más C_2 = M_1 más M_2$en línea$. Aún mejor, si el atacante conoce uno de $inline$M_1$inline$ o $inline$M_2$inline$, entonces puede recuperar inmediatamente el otro. Esto le da un fuerte incentivo. Descubra uno de los dos componentes no cifrados..
Esto nos lleva al escenario de ataque completo y más efectivo. Consideremos un atacante que puede interceptar el tráfico de radio entre un teléfono objetivo y una torre de telefonía móvil, y que de alguna manera tiene la suerte de grabar dos llamadas diferentes, y la segunda ocurre inmediatamente después de la primera. Ahora imagine que de alguna manera pudiera adivinar el contenido no cifrado de una de las llamadas. Con tal casualidad nuestro atacante puede descifrar completamente la primera llamada usando un XOR simple entre los dos conjuntos de paquetes.
Por supuesto, la suerte no tiene nada que ver. Dado que los teléfonos están diseñados para recibir llamadas, un atacante que pueda escuchar la primera llamada podrá iniciar una segunda llamada en el momento exacto en que finalice la primera. Esta segunda llamada, si se vuelve a utilizar la misma clave de cifrado con el contador puesto a cero, permitirá recuperar los datos no cifrados. Además, dado que nuestro atacante realmente controla los datos durante la segunda llamada, puede recuperar el contenido de la primera llamada, gracias a muchas funciones específicamente implementadas. Pequeñas cosas, jugando de su lado.
Aquí hay una imagen del plan de ataque general tomada de :
Descripción general del ataque de . Este esquema supone que se realizan dos llamadas diferentes utilizando la misma clave. El atacante controla el rastreador pasivo (arriba a la izquierda), así como un segundo teléfono con el que puede realizar una segunda llamada al teléfono de la víctima.
Entonces, ¿el ataque realmente funciona?
Por un lado, esta es realmente la pregunta principal del artículo sobre ReVoLTE. Todas las ideas anteriores son geniales en teoría, pero dejan muchas preguntas. Como:
- ¿Es posible (para los investigadores académicos) interceptar una conexión VoLTE?
- ¿Los sistemas LTE reales realmente cambian de clave?
- ¿Puede realmente iniciar una segunda llamada de manera suficientemente rápida y confiable para que el teléfono y la torre reutilicen la clave?
- Incluso si los sistemas vuelven a codificar, ¿puede realmente conocer el contenido no cifrado de la segunda llamada, dado que cosas como los códecs y la transcodificación pueden cambiar completamente el contenido (bit a bit) de esa segunda llamada, incluso si tiene acceso a los "bits"? " ¿viene de tu teléfono de ataque?
El trabajo de ReVoLTE responde afirmativamente a algunas de estas preguntas. Los autores utilizan un rastreador de transmisiones de radio reconfigurable por software comercial llamado para interceptar una llamada VoLTE desde el lado del enlace descendente. (Creo que simplemente familiarizarse con el software y tener una idea aproximada de cómo funciona les quitó meses a los estudiantes de posgrado pobres, lo cual es típico de este tipo de investigación académica).
Los investigadores descubrieron que para que la reutilización de claves funcionara, la segunda llamada tenía que realizarse lo suficientemente rápido después de que terminara la primera, pero no demasiado rápido: unos diez segundos para los operadores con los que experimentaron. Afortunadamente, no importa si el usuario contesta la llamada dentro de este tiempo: el "timbre", 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): recibir bits del contenido no cifrado de una llamada iniciada por un atacante. Esto se debe a que pueden pasar muchas cosas con su contenido mientras viaja desde el teléfono del atacante al teléfono de la víctima a través de la red celular. Por ejemplo, trucos sucios como volver a codificar un flujo de audio codificado, lo que deja el sonido igual, pero cambia completamente su representación binaria. Las redes LTE también utilizan compresión de encabezados RTP, lo que puede cambiar significativamente gran parte del paquete RTP.
Finalmente, los paquetes enviados por el atacante deben coincidir aproximadamente con los paquetes enviados durante la primera llamada telefónica. Esto puede resultar problemático porque modificar el silencio durante una llamada telefónica genera mensajes más cortos (también conocidos como ruido de confort) que pueden no encajar bien con la llamada original.
Vale la pena leerlo en detalle. Aborda muchos de los problemas anteriores; en particular, los autores encontraron que algunos códecs no se vuelven a codificar y que aproximadamente el 89% de la representación binaria de la llamada de destino se puede recuperar. Esto es válido para al menos dos operadores europeos que fueron evaluados.
Esta es una tasa de éxito sorprendentemente alta y, francamente, mucho más alta de lo que esperaba cuando comencé a trabajar en este documento.
Entonces, ¿qué podemos hacer para solucionarlo?
La respuesta inmediata a esta pregunta es muy simple: dado que la esencia de la vulnerabilidad es un ataque de reutilización (reinstalación) de claves, simplemente solucione el problema. Asegúrese de obtener una nueva clave para cada llamada telefónica y nunca permita que el contador de paquetes lo restablezca a cero usando la misma clave. ¡Problema resuelto!
O tal vez no. Esto requerirá actualizar una gran cantidad de equipos y, francamente, esa solución en sí misma no es muy confiable. Sería bueno si los estándares pudieran encontrar una forma más segura de implementar sus modos de cifrado que no sea catastróficamente vulnerable por defecto a tales problemas de reutilización de claves.
Una posible opción es utilizar . Esto puede ser demasiado costoso para algunos equipos actuales, pero ciertamente es un área en la que los diseñadores deberían pensar en el futuro, especialmente ahora que los estándares 5G están a punto de conquistar el mundo.
Este nuevo estudio también plantea la pregunta general de por qué , muchos de los cuales utilizan diseños y protocolos muy similares. Cuando se enfrenta al problema de reinstalar la misma clave en múltiples protocolos ampliamente utilizados como WPA2, ¿no cree que podría ser el momento de hacer que sus especificaciones y procedimientos de prueba sean más sólidos? Deje de tratar a quienes implementan las normas como socios reflexivos y atentos a sus advertencias. Trátelos como adversarios (involuntarios) que inevitablemente van a hacer las cosas mal.
O, alternativamente, podemos hacer lo que empresas como Facebook y Apple están haciendo cada vez más: hacer que el cifrado de llamadas de voz se realice en un nivel superior de la red OSI, sin depender de los fabricantes de equipos celulares. Incluso podríamos impulsar el cifrado de extremo a extremo de las llamadas de voz, como lo está haciendo WhatsApp con Signal y FaceTime, suponiendo que el gobierno de EE. UU. simplemente deje de hacerlo. . Entonces (con la excepción de 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 nuestros hijos ya han hecho: dejar de contestar esas molestas llamadas de voz.
Fuente: habr.com