Una vez descrito el funcionamiento básico del protocolo, y centrándonos en su seguridad, vamos a describir brevemente el funcionamiento de la autenticación SIP y un ataque de cracking de contraseñas.
Entrando ya de lleno en el campo de la seguridad, el protocolo SIP proporciona un mecanismo desafío-respuesta para realizar la autenticación, el cual esta basado en la autenticación HTTP. El esquema, conocido como Digest Authentication, evita el envío de la contraseña de los usuarios en texto plano puesto que hace uso de una función hash MD5 y de un secreto compartido por ambas partes: la contraseña.
Su funcionamiento es el siguiente: cuando un cliente intenta establecer una llamada con el servidor, éste responde con un mensaje que incluye un valor aleatorio (nonce) junto al dominio contra el que se va a autenticar (realm). Entonces, el cliente debe enviar una respuesta cifrada al servidor en un mensaje de tipo response, indicando el nonce, el realm junto con el nombre de usuario, el uri y la contraseña. Una vez recibidos estos datos, el servidor compara el valor de la respuesta del cliente con el resultado de cifrar él por su cuenta los mismos datos, con la contraseña que tiene del cliente.
El funcionamiento se puede ver de forma más clara en la imagen a continuación:
Analizando parte de las cabeceras de autenticación SIP, podemos ver la estructura de la autenticación durante el registro del cliente:
El cliente solicita el registro
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
El servidor envía al cliente el desafío
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
El cliente envía la respuesta al desafío generado por el servidor
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
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
Debemos tener en cuenta que si un atacante captura los mensajes descritos anteriormente durante la fase de registro del cliente, podría ser capaz de obtener el hash MD5 de la contraseña y quedar expuesto a ataques de fuerza bruta y diccionario, como veremos a continuación.
Cracking de contraseñas SIP
Teniendo presente el modelo de autenticación usado por SIP, y mediante ARP Poisoning (o ARP Spoofing, basado en suplantación de identidad por falsificación de tabla ARP) podemos lanzar un ataque Man-in-the-Middle y capturar tráfico mediante la aplicación wireshark en busca de peticiones de registro SIP, y por lo tanto, hashes de usuarios.
Una vez lanzado el ataque y con los datos capturados, podríamos usar la aplicación sipdump para extraer las peticiones de registro de clientes en nuestro servidor (también lo podemos usar directamente para llevar a cabo la captura de datos), de la siguiente forma:
SIPdump 0.1 ( MaJoMu | www.remote-exploit.org )
————————————————
* Using tcpdump data file ‘captura2.pcap’ for sniffing
* Starting to sniff with filter ‘tcp or udp’
* Adding 192.168.3.1:50195 < -> 192.168.3.21:776 to monitor list…id 0
* New traffic on monitored connection 0 (192.168.3.1 -> 192.168.3.21)
* New traffic on monitored connection 0 (192.168.3.1 -> 192.168.3.21)
* New traffic on monitored connection 0 (192.168.3.1 -> 192.168.3.21)
* New traffic on monitored connection 0 (192.168.3.1 -> 192.168.3.21)
* Found challenge response (192.168.3.1:50195 < -> 192.168.3.21:776)
* Wrote sniffed login 192.168.3.1 -> 192.168.3.21 (User: ’21’) to dump file
* Found challenge response (192.168.3.1:50195 < -> 192.168.3.21:776)
* Wrote sniffed login 192.168.3.1 -> 192.168.3.21 (User: ’21’) to dump file
Exiting, sniffed 2 logins
Como se puede ver, tenemos dos logins de usuarios (ambos de la extensión 21) capturados que almacenaremos en el fichero logins.sip.
En este punto, podemos usar sipcrack para lanzar un ataque de diccionario contra los hashes obtenidos, o usar un ataque de fuerza bruta como John the Ripper:
SIPcrack 0.1 ( MaJoMu | www.remote-exploit.org )
————————————————–
* Reading and parsing dump file…
* Found Accounts:
Num Server Client User Algorithm Hash / Password
1 192.168.3.21 192.168.3.1 21 MD5 0d0cdfcd73a9bf6a936e248dc368fcfd
2 192.168.3.21 192.168.3.1 21 MD5 0d0cdfcd73a9bf6a936e248dc368fcfd
Select which entry to crack (1 – 2):
* Generating static MD5 hash…88ab21094e1dfb6b29d2a5a80bec2aa2
* Starting bruteforce against user ’21’ (MD5 Hash: ‘0d0cdfcd73a9bf6a936e248dc368fcfd‘)
* Loaded wordlist: ‘/usr/share/dict/spanish’
* Tried 51837 passwords in 0 seconds
* Found password: ‘joseluis’
Updating ‘fichero’…done
Tras lo que, como podemos ver en este caso, obtendríamos la contraseña del cliente. En la siguiente entrada, aplicaremos parte de lo visto para realizar una captura completa de una conversación VoIP, mediante Ettercap y Wireshark.
Hasta entonces, de momento, por mi parte, nada más. Pasen un buen fin de semana y sean buenos.
Hola, Muy interesante!!!
Me gustaría saber como protegerse contra estos ataques, o que forma seria bien segura para la autenticacion SIP.
Si puede publicarlo o reponderme.
Muchas Gracias.
Buenas,
Te comento lo que he contestado a uno de los comentarios a otro post. El ejemplo se basa en la premisa de usar la infraestructura existente para implantar la red de VoIP, ya sea por coste o comodidad, y por lo tanto, el ataque reproducido era posible.
Si quisiéramos proteger nuestra red de voz, a parte de separar lógica o físicamente ambas redes, deberemos añadir algunas medidas de seguridad adicionales, como puede ser la autenticación y el cifrado, tanto a nivel de señalización, por ejemplo mediante SIP sobre TCP/SSL, como a nivel de transporte, usando SRTP o ZRTP, éste último desarrollado por el conocido Phil Zimmermann, y el cual también es usado Zfone, y como comentas, ofrece muchas posibilidades aunque personalmente no lo he probado. No obstante, también habrá que tener en cuenta la carga extra generada por el cifrado, así cómo el tipo de cifrado que son capaces de soportar los terminales o incluso la PBX, puesto que habitualmente, se requieren terminales con grandes funcionalidades mientras que se descuidan otros aspectos importantes como la seguridad.
También podremos, dependiendo de las capacidades del switch que usemos para la red de voz, forzar una MAC concreta a un puerto del switch, establecer vlans, … e incluso, al igual que en una red de datos, implantar sistemas de detección de intrusos y el resto de medidas habituales.
Un saludo.