Common VoIP Security Problem - Spoof Attacks

Today, let's talk about spoofing in VoIP.  It's a real security threat in a lot of VoIP implementations, unlike the hysteria surrounding the SIPtap tool that supposedly allows easy eavesdropping on VoIP calls. 

One of the more common spoof attacks in VoIP results from unauthenticated messages.   What can happen in a lot of VoIP implementations is that any computer on the Internet can send a message to your VoIP client and your VoIP client doesn't know that it is a message from a scammer or spammer. 

Here's an example:  Your Vonage VT 2142-VD phone adapter (from Motorola) receives a SIP INVITE message (trying to start a phone call with you) from a spam source.  This particular phone adapter doesn't authenticate incoming messages, so it responds to the SIP INVITE and sets up a call with the spam source.  Your Vonage phone rings and in a few seconds you are listening to a recording of someone trying to sell you Viagra.  Kind of circumvents the "do not call list", doesn't it?

How do you fix this kind of problem?  We have a three-layer toolbox for fighting spoof attacks:

1. Application layer: message authentication using SIP Digest.
2. Transport layer: authenticating a session so you only accept messages from know senders, using Transport Layer Security (TLS).
3. Network layer: encrypting messages using an IPSec mechanism.

Let's start with application layer message authentication.  SIP provides an HTTP digest authentication mechanism that allows any message to be challenged.  This means that the client could ask the sender to authenticate the message it just received, and the sender is required to re-send the message with credentials that the receiver can check to see if the message is legit.  In our example, the Vonage client could challenge every SIP INVITE and could avoid spam calls, assuming the credential mechanism used is hard to hack. 

Next: transport layer mechanisms.  Transport Layer Security allows the Vonage client to authenticate the session it sets up with its SIP proxy server at the time the session is set up.  This should be a bi-directional authentication, so that both the proxy server and the client are authenticated.  In our example, the Vonage client could then trust any message it receives on the authenticated TCP/IP session with the Proxy Server. (Note, SIP can use either UDP/IP or TCP/IP).

Network Layer Security using IPSec extends the IP packet header to allow encryption of any higher layer protocol.  You can secure all communication with a VoIP client by requiring that all traffic with that VoIP client be encrypted using an IPSec mechanism.  In our example, if the Vonage client received an unencrypted SIP INVITE, it would discard it. 

While you can use any of these three mechanisms in combination, that is kind of like having a belt and two sets of suspenders.  Of the three, the TLS-based mechanism is my preference.  It is more efficient than SIP Digest (not requiring the message overhead of challenges and responses on every message), and simpler than IPSec (not so many crypto keys and security associations to manage), and it gets the job done.

The problem is that so many VoIP services and VoIP clients use NONE of the above mechanisms, and that is a real vulnerability.