Seguridad en VoIP Seguridad 1

Seguridad en VoIP Entender como instalar Asterisk es importante pero: “Tanto como para un “CRACKER” como para un “Ethical Hacker” es vital entender como funciona el “nucleo” de la telefonia IP” Estos no solo tratan con Asterisk sino con la telefonia IP en general – protocolos Julián Dunayevich, Lázaro Baca, Andrés Brassara, Santiago Alberch, Antonio Lobo 2 2 2

“CERTIFIED ETHICAL HACKER” Etical hacker El Ethical Hacker es un individuo con elevados conocimientos informáticos en quien puede confiarse para realizar una Auditoria Informática; Dicho de otra forma es una persona con experticia técnica para hacer intentos de penetración en la red y/o sistemas computacionales, usando los mismos métodos que un Hacker para verificar así la efectividad de la seguridad informática de la empresa. “CERTIFIED ETHICAL HACKER” Julián Dunayevich, Lázaro Baca, Andrés Brassara, Santiago Alberch, Antonio Lobo 3 3 3

Vulnerabilidades en VoIP -Vulnerabilidades de los protocolos usados en VoIP (se~alizacion y flujo multimedia), por ejemplo: SIP, AIX, RTP. -Captura de trafico de VoIP -Secuestro de sesiones. -Ataques de denegacion de servicios (DoS) -Ataques a clientes terminales :La víctima se ve saturada de paquetes inservibles y es incapaz de procesar peticiones válidas. -Ataques a redes Vowifi Julián Dunayevich, Lázaro Baca, Andrés Brassara, Santiago Alberch, Antonio Lobo 4 4 4

Protocolo SIP S e s s i o n I n i t i a t i o n P r o t o c o l : E s u n p r o t o c o l o d e c o n t r o l d e s a r r o l l a d o p o r e l I E T F , b a s a d o e n a r q u i t e c t u r a c l i e n t e / s e r v i d o r s i m i l a r a l H T T P . E s t r u c t u r a d e p e t i c i ó n - r e s p u e s t a : E s t a s p e t i c i o n e s s o n g e n e r a d a s p o r u n c l i e n t e y e n v i a d a s a u n s e r v i d o r , q u e l a s p r o c e s a y d e v u e l v e l a r e s p u e s t a a l c l i e n t e . A l i g u a l q u e e l p r o t o c o l o H T T P , S I P p r o p o r c i o n a u n c o n j u n t o d e s o l i c i t u d e s y r e s p u e s t a s b a s a d a s e n c ó d i g o s . El par petición-respuesta recibe el nombre de transacción SIP utiliza HTTP Digest (RFC2617) como mecanismo de autenticación Sencillo Eficiente Inseguro Funcionamiento Se genera el texto del desafío (digest) y se le envía al usuario que se quiere autenticar (junto al error 407) El usuario lo cifra con su información (realm, usuario, contraseña) y lo envía El autenticador podrá validar las credenciales gracias al digest Julián Dunayevich, Lázaro Baca, Andrés Brassara, Santiago Alberch, Antonio Lobo 5 5 5

Protocolo SIP Tipos de solicitudes: »INVITE: establece una sesión. »ACK: confirma una solicitud INVITE. »BYE: finaliza una sesión. »CANCEL: cancela el establecimiento de una sesión. »REGISTER: comunica la localización de usuario (nombre de equipo, IP). »OPTIONS: comunica la información acerca de las capacidades de envío y recepción de teléfonos SIP. Julián Dunayevich, Lázaro Baca, Andrés Brassara, Santiago Alberch, Antonio Lobo 6 6 6

Protocolo SIP Clases de respuestas: » 1xx: respuestas informativas, tal como 180, la cual significa teléfono sonando. » 2xx: respuestas de éxito. » 3xx: respuestas de redirección. » 4xx: errores de solicitud. » 5xx: errores de servidor. » 6xx: errores globales. Julián Dunayevich, Lázaro Baca, Andrés Brassara, Santiago Alberch, Antonio Lobo 7 7 7

Protocolo SIP Llamada SIP: Usuario A Proxy Server Usuario B Las dos primeras transacciones corresponden al registro de los usuarios. Los usuarios deben registrarse para poder ser encontrados por otros usuarios. En este caso, los terminales envían una petición REGISTER, donde los campos from y to corresponden al usuario registrado. El servidor Proxy, que actúa como Register, consulta si el usuario puede ser autenticado y envía un mensaje de OK en caso positivo. • La siguiente transacción corresponde a un establecimiento de sesión. Esta sesión consiste en una petición INVITE del usuario al proxy. Inmediatamente, el proxy envía un TRYING 100 para parar las retransmisiones y reenvía la petición al usuario B. El usuario B envía un Ringing 180 cuando el teléfono empieza a sonar y también es reenviado por el proxy hacia el usuario A. Por ultimo, el OK 200 corresponde a aceptar la llamada (el usuario B descuelga). • En este momento la llamada está establecida, pasa a funcionar el protocolo de transporte RTP con los parámetros (puertos, direcciones, codecs, etc.) establecidos en la negociación mediante el protocolo SDP. • La última transacción corresponde a una finalización de sesión. Esta finalización se lleva a cabo con una única petición BYE enviada al Proxy, y posteriormente reenviada al usuario B. Este usuario contesta con un OK 200 para confirmar que se ha recibido el mensaje final correctamente. Julián Dunayevich, Lázaro Baca, Andrés Brassara, Santiago Alberch, Antonio Lobo 8 8 8

Protocolo SIP Llamada SIP: 1 er laboratorio : Capturar una traza de telefonia IP-SIP usando el comando tcpdump y wireshark Comandos del tcpdump para capturar #tcpdump -i eth0 -s 1500 not port 22 -w callsip.cap Objetivos: Identificar las Ips involucradas en el trafico capturado.- Identificar los puertos involucrados en el trafiico capturado.- Identificar solicitudes y respuestas en el trafico capturado.- Julián Dunayevich, Lázaro Baca, Andrés Brassara, Santiago Alberch, Antonio Lobo 9 9 9

1er Laboratorio Seguridad VoIP Capturar trafico SIP Usando tcpdump y wireshark Objetivos: Identificar las Ips involucradas en el trafico capturado.- Identificar los puertos involucrados en el trafico capturado.- Identificar solicitudes y respuestas en el trafico capturado.- 1 er laboratorio : Capturar una traza de telefonia IP-SIP usando el comando tcpdump y wireshark Comandos del tcpdump para capturar #tcpdump -i eth0 -s 1500 not port 22 -w callsip.cap Objetivos: Identificar las Ips involucradas en el trafico capturado.- Identificar los puertos involucrados en el trafiico capturado.- Identificar solicitudes y respuestas en el trafico capturado.- Julián Dunayevich, Lázaro Baca, Andrés Brassara, Santiago Alberch, Antonio Lobo 10 10 10

Autenticacion SIP SIP utiliza HTTP Digest (RFC2617) como mecanismo de autenticación Sencillo Eficiente Inseguro Funcionamiento Se genera el texto del desafío (digest) y se le envía al usuario que se quiere autenticar (junto al error 407) El usuario lo cifra con su información (realm, usuario, contraseña) y lo envía El autenticador podrá validar las credenciales gracias al digest Julián Dunayevich, Lázaro Baca, Andrés Brassara, Santiago Alberch, Antonio Lobo 11 11 11

Autenticacion SIP Dentro de un digest: Realm: Identifica el dominio del cual el servidor es responsable Nonce: String generado de forma única para cada desafío (string arbitrario + marca de tiempo) Algorithm: De momento solo esta soportado MD5 -> se puede romper! Julián Dunayevich, Lázaro Baca, Andrés Brassara, Santiago Alberch, Antonio Lobo 12 12 12

c u a n d o u n c l i e n t e i n t e n t a e s t a b l e c e r u n a l l a m a d a c o n e l s e r v i d o r , é s t e r e s p o n d e c o n u n m e n s a j e q u e i n c l u y e u n v a l o r a l e a t o r i o ( n o n c e ) j u n t o a l d o m i n i o c o n t r a e l q u e s e v a a a u t e n t i c a r ( r e a l m ) . E n t o n c e s , e l c l i e n t e d e b e e n v i a r u n a r e s p u e s t a c i f r a d a a l s e r v i d o r e n u n m e n s a j e d e t i p o r e s p o n s e , i n d i c a n d o e l n o n c e , e l r e a l m j u n t o c o n e l n o m b r e d e u s u a r i o , e l u r i y l a c o n t r a s e ñ a . U n a v e z r e c i b i d o s e s t o s d a t o s , e l s e r v i d o r c o m p a r a e l v a l o r d e l a r e s p u e s t a d e l c l i e n t e c o n e l r e s u l t a d o d e c i f r a r é l p o r s u c u e n t a l o s m i s m o s d a t o s , c o n l a c o n t r a s e ñ a q u e t i e n e d e l c l i e n t e . Autenticacion SIP Julián Dunayevich, Lázaro Baca, Andrés Brassara, Santiago Alberch, Antonio Lobo 13 13 13

Autenticación SIP El cliente solicita el registro SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.3.21:2051;branch=z9hG4bK- t88fqbra1bie;received=192.168.3.21;rport=2051 From:<sip:21@192.168.3.1>;tag=3w6dbu6uyc To: <sip:21@192.168.3.1> Call-ID: 3c26700d8165-v62iicjqkocw@snom300-00041325BC30 CSeq: 1 REGISTER User-Agent: Asterisk PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces Contact: <sip:21@172.18.0.1> Content-Length: 0 Julián Dunayevich, Lázaro Baca, Andrés Brassara, Santiago Alberch, Antonio Lobo 14 14 14

Autenticación SIP El servidor envía al cliente el desafío SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 192.168.3.21:2051;branch=z9hG4bK- e4uj8qvx5f95;received=192.168.3.21;rport=2051 From: <sip:21@192.168.3.1>;tag=fegspc9i4c To: <sip:21@192.168.3.1>;tag=as4d3ce180 Call-ID: 3c26700d7ef4-x4kkws5ejsgn@snom300-00041325BC30 CSeq: 1 REGISTER User-Agent: PBX Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces WWW-Authenticate: Digest algorithm=MD5, realm=bernia.s2grupo.es, nonce=5812ed07 Content-Length: 0 Julián Dunayevich, Lázaro Baca, Andrés Brassara, Santiago Alberch, Antonio Lobo 15 15 15

Autenticación SIP El cliente envía la respuesta al desafío generado por el servidor REGISTER sip:192.168.3.1 SIP/2.0 Via: SIP/2.0/UDP 192.168.3.21:2051;branch=z9hG4bK- f1jw8puwjx5t;rport From: <sip:21@192.168.3.1>;tag=fegspc9i4c To: <sip:21@192.168.3.1> Call-ID: 3c26700d7ef4-x4kkws5ejsgn@snom300-00041325BC30 CSeq: 2 REGISTER Max-Forwards: 70 User-Agent: snom300/6.2.3 Supported: gruu Allow-Events: dialog CONTINUA  Julián Dunayevich, Lázaro Baca, Andrés Brassara, Santiago Alberch, Antonio Lobo 16 16 16

Autenticación SIP El cliente envía la respuesta al desafío generado por el servidor Authorization: Digest username=21, realm=xxxxx.s2grupo.es, nonce=5812ed07, uri=sip:192.168.3.1, response=0d0cdfcd73a9bf6a936e248dc368fcfd, algorithm=md5 Expires: 3600 Content-Length: 0 Julián Dunayevich, Lázaro Baca, Andrés Brassara, Santiago Alberch, Antonio Lobo 17 17 17

Medidas de Seguridad en SIP -Mecanismos de gestion de claves * Metodos: Pre-Shared Key, Public Key, Diffie-Hellman -Cifrado de flujo de Datos * TLS Julián Dunayevich, Lázaro Baca, Andrés Brassara, Santiago Alberch, Antonio Lobo 18 18 18

2do Laboratorio Seguridad VoIP Cracking de contrase~as SIP Objetivos: - Comprobar la vulnerabilidad del protocolo SIP en la autenticacion de cuentas.- 2 do laboratorio : Cracking de contrase~as SIP usando sipdump sipcrack Objetivos: Comprobar la vulnerabilidad del protocolo SIP Julián Dunayevich, Lázaro Baca, Andrés Brassara, Santiago Alberch, Antonio Lobo 19 19 19

Protocolo RTP El Protocolo RTP (Real-time Transport Protocol), que en español es Protocolo de Transporte de Tiempo Real RTP provee funciones de transporte de red de extremo a extremo adecuado para aplicaciones de transmisión de datos en tiempo real, tales como audio y video, sobre servicios de redes unicast y multicast. RTP no garantiza la calidad del servicio para los servicios en tiempo real. RTP está formado conjuntamente con el protocolo RTCP (Real-time Contro Protocol) RTCP: su función principal es proporcionar mecanismos de realimentación para informar sobre la calidad en la distribución de los datos. Julián Dunayevich, Lázaro Baca, Andrés Brassara, Santiago Alberch, Antonio Lobo 20 20 20

Protocolo RTP Julián Dunayevich, Lázaro Baca, Andrés Brassara, Santiago Alberch, Antonio Lobo 21 21 21

Protocolo RTP Versión (V): identifica la versión del RTP. La versión actual es la 2 (2 bits) Relleno (R): este campo indica que el paquete contiene uno o más bytes de relleno que no son parte de la carga útil (1 bit) Extensión (X): cuando este bit está a 1 se indica que la cabecera está seguida de una extensión de cabecera. Cuenta CSRC (CC): especifica el número de CSRC que siguen a la cabecera (4 bits). Marcador (M): este campo se define en el perfil. Se utiliza para marcar eventos significativos (1 bit) Julián Dunayevich, Lázaro Baca, Andrés Brassara, Santiago Alberch, Antonio Lobo 22 22 22

Protocolo RTP Tipo de carga útil (TC): identifica el formato de la carga útil y determina como las aplicaciones tienen que interpretarla (7 bits). Número de Secuencia: se incrementa cada vez que se envía un nuevo paquete. Este número se utiliza en el destino para detectar pérdidas y ordenar los paquetes en la secuencia original. El valor inicial se elige de forma aleatoria. Julián Dunayevich, Lázaro Baca, Andrés Brassara, Santiago Alberch, Antonio Lobo 23 23 23

Protocolo RTP Marca de tiempo: refleja el instante demuestro del primer byte del paquete RTP (carga útil). *Basado en un reloj que se incrementa monótonamente *Se utiliza para sincronización y cálculo del jitter *La marca inicial es aleatoria. SSRC: es un número aleatorio. Se utiliza para identificar a la fuentes de sincronización dentro de la misma sesión RTP. Indica donde se combinaron los datos o la fuente de los mismos (si solo hay una fuente) * Ej.: si un paquete contiene segmentos de audio que cubren 310 muestras la MT se incrementará en 310 Julián Dunayevich, Lázaro Baca, Andrés Brassara, Santiago Alberch, Antonio Lobo 24 24 24

Protocolo RTP Lista CSRC: contiene de 0 a 15 ítems de 32 bits cada uno de los cuales especifica la fuente que a contribuido a la carga útil del paquete. El número de identificadores se especifica en CC . Julián Dunayevich, Lázaro Baca, Andrés Brassara, Santiago Alberch, Antonio Lobo 25 25 25

3er Laboratorio Seguridad VoIP Capturar trafico RTP Usando tcpdump y wireshark Objetivos: Analizar la trama del protocolo RTP Graficar el trafico RTP Julián Dunayevich, Lázaro Baca, Andrés Brassara, Santiago Alberch, Antonio Lobo 26 26 26

4er Laboratorio Seguridad VoIP Particas de Denegacion de Servicios DoS al servidor PBX asterisk DoS al protocolo RTP DoS al protocolo SIP (softphones) A LO MEJOR FALTAN UNAS LAMINAS PARA EXPLICAR EN QUE CONSISTE LA DENEGACION DE SERVICIOS Y POR QUE PUEDE OCURRIR EN LA VoIP. Julián Dunayevich, Lázaro Baca, Andrés Brassara, Santiago Alberch, Antonio Lobo 27 27 27

Detalles de la licencia: Curso elaborado por Júlian Dunayevich julian@dunayevich.com Lázaro Baca lazaro.baca@gmail.com Andrés Brassara abrassara@gmail.com Santiago Alberch salbech@gmail.com Antonio Lobo antoniwolf@gmail.com Detalles de la licencia: http://creativecommons.org/licenses/by-nc-sa/2.5/deed.es_AR Autores: Julián Dunayevich, Lázaro Baca, Andrés Brassara, Santiago Alberch, Antonio Lobo (cc) Creative Commons - Attribute Non-Commercial Share-Alike 2.5 Trabajo originalmente basado en bibliografía de: Irontec: contacto@irontec.com (CC) Asterisk, The Future of Telephony, Jim Meggelen, Jared Smith, and Leif Madsen, O´REILLY, 2005 Julián Dunayevich, Lázaro Baca, Andrés Brassara, Santiago Alberch, Antonio Lobo 28