Let’s dive into VoIP protocols — Episode 2 : SIP Part 2

Let’s dive in !

The article is also available in French.

Hi ! This article is the continuation of Episode 1 : SIP Part 1.

Registering with Kamailio

Authentication

We are going to assume that we want to authenticate the users in order to have at least basic security. Kamailio is a SIP proxy that can act also as a registration server. We are going to try to register Alice with a password and analyze the PCAPs.

We add the user Alice with the password “secretAlice” to the user database in the registering server. Next we try to register on the server from the softphone (Ekiga) on PC-Alice with “secretAlice”, we keep the connection up for an hour then we disconnect.

You can download the PCAP here : https://we.tl/HOLft8MAnF

In order to explore the PCAP you can use the software I’m working on : PCAP-Inspector, you can download for free at https://pcap-inspector.com and get a free licence for 30 days. It is currently in Beta but already has a lot of interesting functionalities. If you are not interested in this software you can use Wireshark.

PCAP Analysis with PCAP-Inspector

First let’s analyze the authentication scheme, SIP uses a variant of HTTP digest, if you are not familiar with the process, it goes like this :

• First the client tries to register with no authentication , the server answers with a 401/Unauthorized and the challenge’s information for the authentication : the realm and the nonce. The realm is usually a domain name or an IP, the nonce is a string generated by hashing useful values for the authentication (timestamp, client_ip for example, it can change between implementations and configurations). See frame 3 and 4 in the PCAP.
• The client then sends another request (Frame 5) with the answer to the challenge :

A1 = username “:” realm “:” password
A2 = Method “:” Request-URI
response = MD5(MD5(A1) “:” nonce “:” MD5(A2))

• The server checks the answer and authenticate the client : Frame 6.

In red the first attempt, then in green the second with the authentication

For more information see : https://tools.ietf.org/html/rfc2617.

We see that, by default, all the information from this exchange is accessible by someone sniffing the network since we don’t use TLS on the transport layer, all the information is available in plain text.

Security considerations :

Firstly, MD5 is not very robust, if the user uses a password under 8 characters, an attacker could crack it with less than 10 euros worth of computing power on the cloud. It is possible to configure Kamailio to use SHA256 rather than MD5 by changing the “Algorithm” parameter in the AUTH module.

Secondly, Kamailio has a 300s expiration time on the nonce by default [doc]. But the nonce is computed with the Request-URI, Call-ID, and source IP of the request [doc]. Therefore, an attacker could only do a replay attack by spoofing the client IP and sending the exact same registering message. He would therefore only be able to register the same IP/SIP address translation, which as you can imagine has very limited implication since it doesn’t add anything to the original IP spoofing in the general case. The only case I see of potential malicious usage would be to take the IP of someone who registered and then disconnected under 300s then replay the original message to register on the server. That would allow the attacker to restore the potentially severed connection between the IP and the SIP address and make the user appear as connected. The attacker would then receive the SIP messages but wouldn’t be able to respond to them since he wouldn't be able to answer the next authentication challenges. We could configure the authentication module to change the nonce at every request in order to avoid that.

Keep-Alive the registration

Now that we studied the registration process, we can explore how the server and client know how to keep the registration active. In the first registration message, the client sends a contact parameter : “expires=3600” which means that unless the client explicitly unregister itself from the server or re-registers, the connection should be kept for that time-frame of 1 hour, then cut. We can see in the PCAP that the client re-registers after 50 minutes (Frame 39–42).

Keep-Alive : highlighted in blue.

Security considerations :

An attacker could hijack the registration of the user for a duration of 1 hour by spoofing the IP address of the user. He wouldn't be able to answer the consecutive SIP request or send new ones because he would not be able to authenticate them but he could still get some information for other purposes (SE, phishing, …). We can see in the Kamailio documentation that you can influence the range of values for that with 3 parameters : default_expires (3600), min_expires(60), max_expires(0). By default there is no maximum value, setting it to 3600 for example would be a good start to limit abnormally large values from the client.

Disconnection

The disconnection is a similar process to the registration to break the bindings between the address and the IP. Not so much to add to what has been said before.

Disconnection : highlighted in purple.

Conclusion

The SIP registration process offers a rather good level of security by default in this implementation, and can be easily taken up a notch if deemed necessary. Without TLS on the Transport layer, an attacker able to sniff the packets can spy on the registration process to get information on the users, we could imagine easily that an attacker could leverage the times of connection and disconnection of the employees. As we will see in the next article, also information about who called who at what time, to do some social engineering for example. In the next article of the series we’ll explore call setups and the difference between B2BUA and proxies.

If you liked this article you can follow me on medium : Constantin VURLI, or Twitter : @flashybowtie