Sjur Usken

The RFC draft-ietf-speermint-voipthreats-01 was release in July and summarizes several of the threats towards VoIP.

SIP Request Spoofing

   Most SIP request spoofing require first a SIP message eavesdropping
   but some of the them could be also performed by guessing or
   exploiting broken implementations.  Threats in this category are:

      session teardown - the attacker uses CANCEL/BYE messages in order
      to tear down an existing call at SIP layer, it is needed that the
      attacker replicates the proper SIP header for the hijacking to be
      successful (To, From, Call-ID, CSeq);

      Billing fraud - the attacker alters an INVITE request to bill a
      call to a victim UE and avoid paying for the phone call.

      user ID spoofing - SSPs are responsible for asserting the
      legitimacy of user ID; if an SSP fails to achieve the level of
      identity assertion that the federation it belongs expects, it may
      create an entry point for attackers to conduct user ID spoofing
      attacks.

      Unwanted requests - the attacker sends requests to interfere with
      regular operation, i.e. sends a REGISTER request to hijack calls.
      The SPEERMINT architecture as defined in [refs.speermintarch] does
      not require registrations between the signaling functions (SF) of
      the connected SSPs.  Superfluous requests like REGISTERs should be
      rejected.

There is also a part of how to spoof messages:

SIP Reply Spoofing

   Threats in this category are:

      Forged 200 Response - the attacker sends a forged CANCEL request
      to terminate a call in progress tricking the terminating UE to
      believe that the originating UE actually sent it, and successfully
      hijacks a call sending a forged 200 OK message to the originating
      UE communicating the address of the rogue UE under the attacker's
      control;

      Forged 302 Response - the attacker sends a forged "302 Moved
      Temporarily" reply instead of a 200 OK, this enables the attack to
      hijack the call and to redirect it to any destination UE of his
      choosing;

      Forged 404 Response - the attacker sends a forged "404 Not Found"
      reply instead of a 200 OK, this enables the attack to disrupt the
      call establishment;

The RFC has a good overview how to protect yourself against these security issues in the end and elaborates on each of them what to do.

Here is a smaller part of it:

4.13.  Encyrption and Integrity Protection of Signalling Messages

   Encryption of signalling messages can be achieved with TLS or IPSec.
   Similar to strong identity assertion, a PKI infrastructure is assumed
   to be in place for TLS (or IPSec) deployment so that SSPs can obtain
   and trust the keys necessary to decrypt messages and verify
   signatures sent by other SSPs.

4.14.  Encyrption and Integrity Protection of Media Stream

   The Secure Real-time Transport Protocol (SRTP) [RFC3711] adds
   security features to plain RTP by mainly providing encryption using
   AES to prevent eavesdropping.  It also uses HMAC-SHA1 and index
   keeping to enable message authentication/integrity and replay
   protection required to prevent media hijack attacks.  Secure RTCP
   (SRTCP) provides the same security-related features to RTCP as SRTP
   does for RTP.  SRTCP is described in [RFC3711] as optional.  In order
   to prevent media session teardown, it is recommended to turn this
   feature on.

A MUST read and “are we covered” for all VoIP Service Providers! Good luck!

[ad]