SIP Security | Protecting your network from attack

If you run your own on-premises IP PBX, such as Cisco Call Manager or Asterisk, then there are a number of different services which you need to ensure you have secured. We've broken the subject down into authentication, SIP signalling and the media sessions.

Authentication

Digest authentication

Digest authentication is where access to the VoIP service is given after the correct combination of username and password is provided. All of the standard advice on password security applies. If you are using this form of authentication then you must ensure all accounts are secured with strong and unique passwords.

IP authentication

An alternative to to digest authentication is IP authentication. With this approach to authentication a password is not normally required. Instead the SIP provider will check the IP address that the request is coming from and provide access if that IP is in a white list. The great advantage of this technique is there's no username and password to obtain that can then be used from any country in the world. However it will only be of use with fixed IP addresses of course, so it's most suited to on-site PBX servers, rather than devices such as Cloud PBX extensions that might get used over mobile or wireless networks.

Securing SIP signalling

By default SIP packets are exchanged as plain text between the the caller, the callee and any number of SIP proxy servers in the signalling path. This presents a range of opportunities for hackers if they can get access to either the network of one of the calling parties or a server or router involved in proxying the SIP packets. Since by default SIP packets are encoded in plain text and do not include any checks on the integrity of the message contents, the messages can be modified and replayed to perform various kinds of attacks.

Attack 1: Registration hijacking

In this attack scenario the hacker stops the calling party from connecting to the service by way of a denial of service attack and then rewrites the SIP packet to make the registration themselves. Once this has been achieved fraudulent calls can then be placed from the victim's SIP trunk.

Attack 2: Call redirection

Another attack that can be performed if an attacker has access to one or more devices on your network is call redirection. In this scenario the hacker intercepts packets and rewrites them to send the call to a different destination. This is potentially a very serious attack in a corporate environment. Imagine for example a trader that gets connected to a hacker from outside of the organisation who will then use their social hacking skills to try and extract the sensitive information they want for their fraud.

SIP over TLS

The underlying problem in both of the above attacks is the fact that packets are transmitted in plain text and are trusted without any kind of check by the parties involved. The most common solution is to use TLS to encrypt the SIP packets so that any packets intercepted cannot be read or tampered with. Much like when TLS is used to provide the encrypted HTTPS form of HTTP, when SIP is encrypted TLS is used to provide the encrypted SIPS service. With SIPS the encryption is made at each hop, so keys are exchanged and encryption established from the originating device to the first proxy and then between each pair of proxies onwards.

Securing media sessions

Eavesdropping

When thinking about the security of media sessions (most commonly RTP audio sessions) the primary attack scenario is simply eavesdropping on calls. Packets captured can be reassembled and played either in real time or later after capture. Any device between the caller and the callee that is compromised in some way can provide a means for calls to be listened to. The standard way to protect against these attacks is to deploy some form of encryption to the media transmitted.

SRTP + SDES

Outside of SIP or security circles you will commonly see people referring to SRTP encryption of media. There are in fact two stages involved in encrypting the media for a call. The first is the key exchange and this is where most SRTP set ups commonly deploy SDES. Once keys have been exchanged they can then be used to encrypt the media as SRTP and eavesdropping is no longer possible.

ZRTP (SRTP + Diffie–Hellman)

Many people get confused at this point and think that ZRTP is an alternative to SRTP. In fact ZRTP is used in combination with SRTP. ZRTP enables keys to be exchanged over an insecure channel without the need for public key infrastructure and then, as with standard SRTP+SDES, the media can be encrypted and the call can no longer be intercepted.