Major standards bodies including 3GPP, ITU-T, and ETSI have all adopted SIP as the core signalling proMajor standards bodies including 3GPP, ITU-T, and ETSI have all adopted SIP as the core signalling protocol for services such as LTE, VoIP, conferencing, Video on Demand (VoD), IPTV (Internet Television), presence, and Instant Messaging (IM) etc. With the continuous evolution of SIP as the defacto VoIP protocol, we need to understand the risk mitigation practices around it.
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.
exmaple implementation :
attacker de-registers all existing contacts for a URI
attacker can also register their own device as the appropriate contact address, thereby directing all requests for the affected user to him
solution – Autheticaion of user
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
Temparing 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
exmaple implementation :
attacker can point RTP media streams to a wiretapping device
can changes Subject header field to appear to users as spam
solution – end to end ecryption over TLS + Digest Authorization
Mid-session threats like tearing down session
Request forging– 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 wiretaping device
solution – authetication 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 geneerates 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.
Security mechanisms
Full encryption vs hop by hop encrption
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.
proxy servers need to also update the message with via headers
Thus SIP uses low level security along with hop by hop encrption 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 CertificateRequest message to request the client’s certificate. The client responds with
- Certificate message containing the client certificate with the client public key and
- CertificateVerify 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 