Successfully reported this slideshow.

Rooted2020 Atacando comunicaciones-de_voz_cifradas_-_jose_luis_verdeguer

0

Share

Upcoming SlideShare
(in) seguridad en VoIP
(in) seguridad en VoIP
Loading in …3
×
1 of 54
1 of 54

Rooted2020 Atacando comunicaciones-de_voz_cifradas_-_jose_luis_verdeguer

0

Share

Download to read offline

Description

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

Transcript

  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

Editor's Notes

  • Presentación y agradecimientos.

    Este año hablaré de nuevo sobre VoIP. También vamos a hablar de phreaking y daremos un repaso a la evolución de la telefonía.
  • Description

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

    Transcript

    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

    Editor's Notes

  • Presentación y agradecimientos.

    Este año hablaré de nuevo sobre VoIP. También vamos a hablar de phreaking y daremos un repaso a la evolución de la telefonía.
  • More Related Content

    More from RootedCON

    Related Books

    Free with a 30 day trial from Scribd

    See all

    ×