Major standards bodies including 3GPP, ITU-T, and ETSI have all adopted SIP as the core signalling protocol for LTE, VoIP, conferencing, Video on Demand (VoD), IPTV (Internet Television), presence, and Instant Messaging (IM) among others. With the continuous evolution of SIP as the defacto VoIP protocol, we need to understand the risk mitigation practices around it.
- Problems that can arise in SIP Servers
- Types of attacks on SIP based systems
- Unauthorized Access to SIP Networks
Problems that can arise in SIP Servers
Avalanche Restart
Avalanche restart (e.g., “Manhattan reboot”) causes simultaneous floods of certain messages (e.g.,
REGISTRAR, SUBSCRIBE, PUBLISH) which overloads the SIP server. It is also difficult for the UAs to choose an appropriate backoff time by themselves during avalanche restart.
NAT and Firewalls Issues
Session Initiation Protocol (SIP) often faces connectivity problems when operating behind NAT (Network Address Translation) and firewalls. These issues disrupt call setup, cause one-way audio, or prevent calls entirely. Below is a breakdown of common problems and their solutions.
Impact on SIP Signaling – Firewalls may block SIP ports (5060 TCP/UDP) or NAT Breaks SIP Headers – where private IPs in SIP packets (Contact, Via) are not routable.
Impact on media flow – Firewall blocks RTP ports (16384-32768 UDP) or NAT could lead to one one way audio or complete misrouting of streams , especially in case of symmetric NAT. In some cases it can also lead to early media cutoff which is when firewall drops packets after initial SIP handsahke.
SIP ALG ( Application Layer Gateway) misconfiguration
Many routers (Cisco, Netgear, MikroTik) have buggy SIP ALG implementations where they may “rewrites” SIP packets incorrectly. For example many tend to Rewrite Contact and Via Header
if (nat_uac_test()) {
force_rport();
fix_nated_contact();
}
Above is an example from Kamilio
VPN or Direct Peering impact on SIP flows
Site to site VPN ( IPSec, OpenVPN) bypass the NAT entirely, which avoids risky public internet but they come with tradeoffs of increases latency and complexity. Furthermore this leads to bandwidth overhead as tunneling adds upto 15% in packet size during encapsulation
In special cases this can enable direct SIP trunking between communications providers and enterprise PBXs
Direct Peering aka Private SIP trunking is usually a dedicated direct physical line ( MPLS , leased line , fibre) between an enterprise PBX and the communication provider. This also bypasses the public internet. However this setup leads to limited flexibility as the setup cannot scale up dynamically and is geographically constraint to where the peering exists . This is often used for reliable, high call quality and high priority voice traffic such as trading desks.
Explosion of incompatible types
SIP is defined by RFC 3261, but vendors add proprietary extensions. Different devices (phones, PBXs, gateways) may support different SIP “flavors” (e.g., Cisco SIP, Avaya SIP, Microsoft Teams SIP).
Custom SIP headers (e.g., X- headers) are often used for non standard parameters that other systems don’t recognize.
Some devices use non-standard SDP attributes, causing call failures. This leads to call failure with
- 488 Not Acceptable Here (codec mismatch).
- “603 Decline” (call rejected due to unsupported headers)
- SDP negotiation failure or call drop after a few seconds
Inconsistent Auth : Some use Digest Auth, others IP-based auth, or even OAuth for SIP over WebRTC, inconsistencies lead to Registration failures (“401 Unauthorized” or “403 Forbidden”).
SDP negotiation failures due to fragmented SIP dialects for instance differences in handling “100 Trying” responses or “183 Session Progress”
Solution : Since communication providers cannot Disable Proprietary Features in endpoint settings, a common solution for such issues is to ase a Session Border Controller (SBC) – Strips non-standard attributes.
Types of attacks on SIP based systems
Registration Hijacking
malicious registrations on registrar by a third party who modifies From header field of a SIP request.
For example an implementation of this attack can be
- An attacker de-registers all existing contacts for a URI
- An attacker can also register their own device as the appropriate contact address, thereby directing all requests for the affected user to him
Simple solution would be Authentication of user on every new SIP request
Impersonating a Server
attacker impersonates the remote server
user’s request can now be intercepted by some other party
user’s request may be forwarded to insecure locations
Solution : confidentiality, integrity, and authentication of proxy servers
Proxy/redirect sever, and registrars SHOULD possess a site certificate issued by CA which could be validated by UA
Tempering Message bodies
If users are relying on SIP message bodies to communicate either of
- session encryption keys for a media session
- MIME bodies
- SDP
- encapsulated telephony signals
Then the atackers on proxy server can modify the session key or can act as a man-in-the-middle and do eaves droppng
An example implementation :
- The attacker can point RTP media streams to a wiretapping device
- or Attacker can changes Subject header field to appear to users as spam
solution – end to end encryption over TLS + Digest Authorization
Mid-session threats like tearing down session
Request forging
In this case of targeted attack , a attacker learns the params of the session like To , From tags etc then he can alter ongoing session parameters and even bring it down
example implementation :
attacker inserts a BYE in a ongoing session thereby tearing it down
can insert re INVITE and redierct the stream to wiretapping device
solution – authentication on every request
signing and encrypting of MIME bodies, and transference of credentials with S/MIME
DOS (Denial of Service) Amplification
DOS – rendering a particular network element unavailable, usually by directing an excessive amount of network traffic at its interfaces.
dDOS – multiple network hosts to flood a target host with a large amount of network traffic.
Can be created by sending falsified sip requests to other parties such that numerous transactions originating in the backwards direction comes to the target server created congestion. Some examples of implementation of DOS attacks :
- Attackers creates a falsified source IP address and a corresponding Via header field that identify a targeted host as the originator of the request. Then send this to large number of SIP network element. This generates DOS aimed at target.
- Attackers uses falsified Route header field values in a request that identify the target host and then send such messages to forking proxies that will amplify messaging sent to the target.
- Flooding with register attacks can deplete available memory and disk resources of a registrar by registering huge numbers of bindings.
- Flooding a stateful proxy server causes it to consume computational expense associated with processing a SIP transaction
Solution – detect flooding and pike in traffic and use ipban to block
challenge questionable requests with only a single 401 (Unauthorized) or 407 (Proxy Authentication Required), forgoing the normal response retransmission algorithm, and thus behaving statelessly towards unauthenticated requests.
Unauthorized Access to SIP Networks
Security mechanisms to overcome unauthorized access to SIP networks
Full encryption vs hop by hop encryption
SIP mssages cannot be encrypted end-to-end in their entirety since message fields such as the Request-URI, Route, and Via need to be visible to proxies in most network architectures so that SIP requests are routed correctly.
Additionally proxy servers need to also update the message with via headers. Thus SIP uses low level security along with hop by hop encryption and auth headers to verify the identity of proxy servers
Transport and Network Layer Security
IPsec – used where set of hosts or administrative domains have an existing trust relationship with one another.
TLS – used where hop-by-hop security is required between hosts with no pre-existing trust association.
SIPS URI Scheme
Used as an address-of-record for a particular user, signifies that each hop over which the request is forwarded, must be secured with TLS
HTTP Authentication
Reuse of the HTTP Digest authentication via 401 and 407 response codes that implement challenge for autehtication
provides replay protection and one-way authentication.
S/MIME
allows SIP UAs to encrypt MIME bodies within SIP, securing these bodies end-to-end without affecting message headers.
provides end-to-end confidentiality and integrity for message bodies
nonce-count
provides replay protection
SIP over TLS
SIP messages can be secured using TLS. There is also TLS for Datagrams called DTLS. Security of SIP signalling is different from security of protocols used in concert with SIP like RTP , RTCP. and that will be covered in later topics of this article.
TLS operation consists of two phases: handshake phase and bulk data encryption phase
Handshake phase : Prepare algorithm to be used during TLS session
Server Authentication : server sends its certificate to the client, which then verifies the certificate using a certificate authority’s (CA’s) public key.
Client Authentication : Server sends an additional Certificate Request message to request the client’s certificate. The client responds with
- Certificate message containing the client certificate with the client public key and
- Certificate Verify message containing a digest signature of the handshake messages signed by clients private key
Server authenticates client by client’s public key , since only client holding correct private key can sign the message.
Prepare the shared secret for bulk data encryption
client generate a pre_master_secret, and encrypt it using the server’s public key obtained from the server’s certificate. The server decrypts the pre_master_secret using its own private key.
Both the server and client then compute a master_secret they share based on the same pre_master_secret. The master_secret is further used to generate the shared symmetric keys for bulk data encryption and message authentication
Public key cryptographic operations such as RSA are much more expensive than shared key cryptography. This is why TLS uses public key cryptography to establish the shared secret key in the handshake phase, and then uses symmetric key cryptography with the negotiated shared secret as the data encryption key.
Stateless proxy servers do not maintain state information about the SIP session and therefore tend to be more scalable. However, many standard application functionalities, such as authentication, authorization, accounting, and call forking require the proxy server to operate in a stateful
mode by keeping different levels of session state information.
Steps :
- The SIP proxy server enforces proxy authentication with
407 Proxy Authentication Required challenge. - UAC provides credentials that verify its claimed identity (e.g., based on MD5 [34] digest algorithm) and retransmits in authorization header
Security of RTP
confidentiality protection of the RTP session and integrity protection of the RTP/RTCP packets requires source authentication of all the packets to ensure no man-in-the-middle (MITM) attack is taking place.
end to end media encryption – SRTP ( Secure RTP )
encodes the voice into encrypted IP packages and transport those via the internet from the transmitter to receive
References
- The Impact of TLS on SIP Server Performance – Charles Shen† Erich Nahum‡ Henning Schulzrinne† Charles Wright , Department of Computer Science, Columbia University,IBM T.J. Watson Research Center
I have written about VoIP and security in these blogs before
- Certificates , compliances and Security in VoIP which describes HIPPA , SOX, COPPA , CPNI , CDPR , CCPA , PDP, SPIT and FCC E911
For security around web browser-based calling via webrtc, the articles below discuss security practices in general
- Webrtc Security , which describes browser threat modal , access to local resource , Same Orogin Policy (SOP) and Cross Resource Sharing ( CORS) as well as Location sharing , ICE , TUEN and threats to privacy with screen sharing , microgone camera long term access and probable mid call attacks .
- Genric secrutity of web Application build around hosting platform of webrtc. Includs concepts like Identity management , browser security – cross site security amd clickjacking , Authetication of devices and applications , Media Encryption and regex checking.
- Kamailio security – https://telecom.altanai.com/2018/02/17/kamailio-security/ .
- Secure Communication – https://telecom.altanai.com/2018/03/16/secure-communication-with-rtp-srtp-zrtp-and-dtls/ which discusses the Key management protocols used for establishing end to end encryption in VoIP media streams. It describes Sanity checks , ACL lists with permissions , hiding topology details , countering Flood using pike and Fail2Ban as well as Traffic monitoring and detection .
Telecom R & D 