Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Rooted2020 Atacando comunicaciones-de_voz_cifradas_-_jose_luis_verdeguer

65 views

Published on

RootedCON https://www.rootedcon.com
Marzo/March 5-7 2020 Madrid (Spain)

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Rooted2020 Atacando comunicaciones-de_voz_cifradas_-_jose_luis_verdeguer

  1. 1. Atacando comunicaciones de voz cifradas Rootedcon 2020
  2. 2. ◆ Ingeniero Técnico de Sistemas Informáticos por la U.A. ◆ Máster en Desarrollo y Programación de Apps y Servicios Web por la U.A. ◆ CTO en Zoon Suite (Operador de VoIP) ◆ Más de 25 años en el mundo de la seguridad informática y del hacking ◆ Ponente en diferentes congresos nacionales ◆ Autor del libro Hacking y Seguridad VoIP (de 0xWord) Sobre mi Jose Luis Verdeguer (aka Pepelux) https://www.linkedin.com/in/pepelux/ @pepeluxx http://blog.pepelux.org verdeguer@zoonsuite.com
  3. 3. @pepeluxx
  4. 4. Protocolo SIP ◆ Signaling ◆ SIP (Session Initiation Protocol) - 5060/udp y 5060/tcp ◆ SDP (Session Description Protocol) ◆ Media Session ◆ RTP (Real-time Transport Protocol) @pepeluxx
  5. 5. Actores @pepeluxx
  6. 6. Protocolo SIP @pepeluxx
  7. 7. Protocolo SIP @pepeluxx
  8. 8. Protocolo SIP @pepeluxx
  9. 9. Protocolo SIP @pepeluxx
  10. 10. Comunicaciones cifradas Señalización ◆ Evitar el robo de credenciales ◆ Evitar secuestro de sesión (Session hijacking) ◆ Ocultar la información del SDP (*) Media ◆ (*) Evitar secuestro del media (Media session hijacking) ◆ Evitar que escuchen nuestras conversaciones (Eavesdropping) @pepeluxx ¿Por qué es importante cifrar nuestras comunicaciones?
  11. 11. ◆ Personalidades y gobiernos ◆ Gobiernos de otros países. De nuestro propio país ◆ Usuarios comunes ◆ Otros usuarios. Empresas comerciales ◆ Delincuentes, criminales, terroristas ◆ De todo el mundo Comunicaciones cifradas ¿De quién nos protegemos? Intereses (para proveedores y gobiernos) ◆ Cifrado robusto para que un tercero no pueda espiar ◆ Con posibilidad de interceptación de llamadas por parte del proveedor @pepeluxx
  12. 12. @pepeluxx
  13. 13. Comunicaciones cifradas @pepeluxx
  14. 14. Comunicación deseable @pepeluxx
  15. 15. Comunicación real @pepeluxx
  16. 16. ◆ ¿Se puede verificar la identidad del otro interlocutor? ◆ ¿La comunicación va cifrada de extremo a extremo? ◆ ¿El proveedor tiene acceso a las claves de cifrado? ◆ ¿Se almacenan las conversaciones, aunque sea cifradas? ◆ ¿El código del software es abierto y puede revisarlo cualquiera? ◆ ¿Está bien documentado el diseño criptográfico? ◆ ¿Ha habido alguna auditoría de seguridad independiente? ◆ ¿Es más complicado realizar una llamada segura que una insegura? ◆ ¿El sistema permite cosas como bifurcación, desvíos, transferencias? Comunicaciones cifradas Cuestiones importantes @pepeluxx
  17. 17. ◆ Cifrado en Signaling ◆ TLS (Transport Layer Security) - 5061/tcp ◆ Cifrado en Media Session ◆ SRTP (Secure Real-time Transport Protocol) ◆ Métodos para negociar una clave criptográfica para SRTP ◆ SDES (Session Description Protocol Security Descriptions) ◆ Mikey (Multimedia Internet KEYing) ◆ ZRTP (Z Real-Time Protocol) ◆ DTLS-SRTP (Datagram Transport Layer Security) Comunicaciones cifradas @pepeluxx
  18. 18. SIP + RTP SIP over TLS + RTP SIP + SRTP SIP over TLS + SRTP 4 modos de comunicación @pepeluxx
  19. 19. ◆ Señalización sin cifrar ◆ Media sin cifrar SIP - RTP @pepeluxx
  20. 20. ◆ Señalización cifrada ◆ TLS (Transport Security Layer) ◆ SHA-256 ◆ Media sin cifrar SIP over TLS - RTP @pepeluxx
  21. 21. ◆ Señalización sin cifrar ◆ Media cifrado ◆ SRTP (Secure Real-time Transport Protocol) ◆ SDES (Session Description Security Descriptions for Media Streams) ◆ Claves transportadas en el SDP SIP- SRTP @pepeluxx
  22. 22. ◆ Señalización cifrada ◆ TLS (Transport Security Layer) ◆ SHA-256 ◆ Media cifrado ◆ SRTP (Secure Real-time Transport Protocol) ◆ SDES (Session Description Security Descriptions for Media Streams) SIP over TLS - SRTP @pepeluxx
  23. 23. ◆ Ataque MitM para que el tráfico pase por nosotros ◆ Capturamos el tráfico en un PCAP ◆ En la captura veremos el SIP en claro ◆ Con las claves de cifrado SDES podremos convertir SRTP en RTP SIP over TLS - SRTP @pepeluxx
  24. 24. @pepeluxx
  25. 25. ◆ Envío de claves en el SDP ◆ Proporciona claves distintas para cada sesión, en cada dirección ◆ Las claves se transportan en claro durante la señalización ◆ Permite bifurcación pero de forma insegura ◆ MitM posible interceptando la señalización Protocolo SDES Características @pepeluxx
  26. 26. @pepeluxx
  27. 27. ◆ 3 modos iniciales de uso (RFC-3830): ◆ Mikey-PS o Mikey-PSK (pre-shared key) ◆ Mikey-PK o Mikey-RSA (public key) ◆ Mikey-DH o Mikey-DHSIGN (Diffie-Hellman) ◆ 2 nuevos modos: ◆ Mikey-DHHMAC (RFC-4650) ◆ Mikey-RSA-R (RFC-4738) ◆ 3 modos más: ◆ Mikey-Ticket (RFC-6043) ◆ Mikey-IBAKE (RFC-6272) ◆ Mikey-SAKKE (RFC-6509) Protocolo Mikey Envío de información de cifrado en el SDP @pepeluxx
  28. 28. Protocolo Mikey ◆ Cifrado simétrico ◆ Se cifra usando una clave previamente compartida ◆ No requiere el uso de una PKI (Public Key Infraestructure) ◆ Problemas ◆ Problema de escalabilidad para grupos grandes de usuarios ◆ No permite bifurcación ◆ Necesidad de un canal seguro para compartir la clave inicialmente ◆ Si la clave pre-compartida se ve comprometida se podrán escuchar todas las comunicaciones, presentes y pasadas Mikey-PSK @pepeluxx
  29. 29. Protocolo Mikey ◆ Cifrado de clave pública (RSA) ◆ Utiliza una PKI para la autenticación de extremo a extremo ◆ Problemas ◆ Una PKI es complejo y poco práctico ◆ No permite bifurcación ◆ Posible ataque DoS generando un consumo de recursos ◆ Requiere confianza con el proveedor del servicio ◆ El proveedor puede hacer un MitM Mikey-RSA @pepeluxx
  30. 30. Protocolo Mikey ◆ Intercambio de claves Diffie-Hellman ◆ Cifrado usando firmas digitales ◆ Funciona con o sin PKI ◆ Problemas ◆ No permite bifurcación ◆ Posible MitM sin uso de PKI ◆ En caso de usar PKI: ◆ Una PKI es complejo y poco práctico ◆ Posible ataque DoS generando un consumo de recursos ◆ Requiere confianza con el proveedor del servicio ◆ El proveedor puede hacer un MitM Mikey-DHSIGN @pepeluxx
  31. 31. Protocolo Mikey ◆ Intercambio de claves Diffie-Hellman ◆ Versión ligera de Mikey-DH pero usando HMAC en lugar de RSA ◆ No requiere una PKI ◆ Se cifra usando una clave previamente compartida ◆ Problemas ◆ Problema de escalabilidad para grupos grandes de usuarios ◆ No permite bifurcación ◆ Necesidad de un canal seguro para compartir la clave inicialmente Mikey-DHHMAC @pepeluxx
  32. 32. Protocolo Mikey ◆ RSA inverso ◆ El receptor genera el secreto usando la clave pública del emisor ◆ No requiere una PKI ◆ Problemas ◆ MitM posible: el atacante puede sustituir la clave pública del emisor por la suya. El receptor cifrará con la clave del atacante Mikey-RSA-R @pepeluxx
  33. 33. Protocolo Mikey ◆ Distribución de claves basado en tickets ◆ Uso de un KMS (Key Management Service) de alta disponibilidad ◆ Problemas ◆ Posible ataque DoS generando un consumo de recursos ◆ MitM posible en la conexión con el KMS Mikey-Ticket @pepeluxx
  34. 34. Protocolo Mikey ◆ Intercambio de claves basado en identidad (IBE) ◆ Uso de un KMS (Key Management Service) de baja disponibilidad ◆ Problemas ◆ El proveedor puede hacer un MitM Mikey-IBAKE @pepeluxx
  35. 35. Protocolo Mikey ◆ Intercambio de claves basado en identidad (IBE) ◆ Cifrado Sakai-Kasahara ◆ Uso de un KMS (Key Management Service) de baja disponibilidad ◆ Usa un depósito de claves ◆ El proveedor genera todas las claves privadas usando una master key ◆ Promovido por el gobierno de UK ◆ Problemas ◆ Permite vigilancia masiva ◆ El proveedor puede escuchar de forma pasiva Mikey-SAKKE @pepeluxx
  36. 36. Protocolo ZRTP @pepeluxx
  37. 37. Protocolo ZRTP ◆ Creado por Phil Zimmermann ◆ Usado inicialmente en el softphone Zfone ◆ Diseñado para realizar conexiones seguras en un entorno inseguro ◆ No requiere uso de PKI ◆ Modos de uso ◆ Diffie-Hellman: Intercambio de claves entre los interlocutores ◆ SAS (Short Authentication String) ◆ Preshared: Se usan secretos compartidos ◆ Problemas ◆ Alta carga de computación ◆ Posible ataque DoS (mensajes HELLO) Características @pepeluxx
  38. 38. Protocolo ZRTP Simple reenvío de tráfico RTP ◆ Ventajas ◆ Poco retardo ◆ Calidad normal de audio ◆ No es necesaria la intervención humana ◆ Ambos interlocutores escuchan sus propias voces ◆ Inconvenientes ◆ Si se compara el SAS se descubre el ataque Ataques: Relay directo @pepeluxx
  39. 39. Protocolo ZRTP El atacante reemplaza el SAS imitando la voz del interlocutor ◆ Ventajas ◆ Poco retardo ◆ Calidad normal de audio ◆ Ambos interlocutores escuchan sus propias voces ◆ Inconvenientes ◆ Requiere intervención humana ◆ Retardo en la inserción del fake SAS Ataques: Relay directo con imitación del SAS @pepeluxx
  40. 40. Protocolo ZRTP El atacante reemplaza el SAS mediante un audio, pidiendo el SAS del otro interlocutor y luego diciendo que es correcto ◆ Ventajas ◆ Poco retardo ◆ Calidad normal de audio ◆ No es necesario decir el SAS ◆ Ambos interlocutores escuchan sus propias voces ◆ Inconvenientes ◆ Requiere intervención humana (y mucha precisión) Ataques: Relay directo eludiendo el SAS @pepeluxx
  41. 41. Protocolo ZRTP El atacante escucha a ambos participantes y repite cada palabra, modificando el SAS para que coincida ◆ Ventajas ◆ Comparación del SAS efectiva ◆ Se usa la misma voz para el SAS y para el resto de la comunicación ◆ Inconvenientes ◆ Alto retardo en la comunicación ◆ No es viable si los interlocutores conocen sus voces ◆ El atacante tiene que escuchar y hablar al mismo tiempo con ambas personas Ataques: Repetición @pepeluxx
  42. 42. Protocolo ZRTP Se trata de mantener una comunicación con el objetivo, de forma que se realice una validación del SAS y se generen unos secretos compartidos ◆ Casos ◆ Una personalidad pública no recuerda la voz de toda la gente con la que habla ◆ Alguien con la que el objetivo lleva tiempo sin hablar ◆ Cuando los interlocutores no se conocen Ataques: Creación de secretos compartidos @pepeluxx
  43. 43. Otro tipo de ataques ◆ Fallos de seguridad en la aplicación (softphone) ◆ Ej: CVE-2016-6271 - afecta a la librería libbzrtp usada por algunos softphones, como Linphone ◆ En este caso se podía forzar el SAS que va a ver cada interlocutor ◆ Instalación de un malware en el teléfono del objetivo @pepeluxx
  44. 44. DTLS-SRTP @pepeluxx
  45. 45. DTLS-SRTP No hay un protocolo específico para la señalización ◆ SIP over Websockets: uso de websockets para enviar tráfico SIP ◆ XMPP/Jingle: extensión del protocolo XMPP para multimedia ◆ Websockets ◆ XHR/Comet ◆ Data Channel Características Signaling: cifrado de websockets con WSS (WS-Security) Media: DTLS (Datagram Transport Layer Security) Cifrados @pepeluxx
  46. 46. DTLS-SRTP Ataque: active MitM @pepeluxx
  47. 47. @pepeluxx
  48. 48. @pepeluxx
  49. 49. Protocolo Signal ◆ Creado por Moxie Marlinspike ◆ Protocolo abierto ◆ Considerado como uno de los protocolos más seguros ◆ Usado por aplicaciones como: ◆ WhatsApp, Skype, Facebook Messenger, Google Duo, Allo Características ◆ Usa el número de teléfono móvil como identificador Inconvenientes @pepeluxx
  50. 50. Protocolo Signal @pepeluxx
  51. 51. Aplicación Signal ◆ Signal = TextSecure + RedPhone ◆ Sólo almacena el número de teléfono asociado a tu cuenta y la última vez que conectaste ◆ No almacena mensajes ni conversaciones ◆ No almacena registro de llamadas ◆ No almacena registro de conexiones ◆ Aplicación de código abierto Lo que nos ofrece la aplicación Signal @pepeluxx
  52. 52. Aplicación Signal @pepeluxx
  53. 53. ◆ Protocolos de seguridad robustos ◆ ¿Confianza en el proveedor de servicios? ◆ Ataques al eslabón más débil Conclusiones @pepeluxx
  54. 54. ¡ Gracias ! ¿ Preguntas ? @pepeluxx

×