Detects and exploits the RTP injection vulnerability.
The purpose of this tool is to reproduce, detect and exploit the RTP inject vulnerability. The tool goes beyond the very basics of the attack, allowing testers to replay custom audio wave files and send DTMF tones.
The basic and default functionality of the
rtp inject bleed command is as follows:
The above steps are done concurrently on each connection.
This tool does not produce any output.
sipvicious rtp inject target-uri [flags]
-c, --conn-count int Number of sockets to use (default 10) -T, --max-time duration Stop injecting after this long; zero to never stop (default 10s) -p, --port-ranges string Range of ports to probe for RTP/RTCP (default "10000-20000,35000-65000") -A, --probe-all-ports Also attempt RTP injection on odd port numbers -d, --send-dtmf string Send DTMF sequence while injecting -W, --send-wav string Send WAV audio while injecting
-C, --config string configuration file to use (may be JSON, TOML or YAML) --debug set log level to debug --logfile string specify a log filename --srtp string specify if either none, dtls or sdes to enforce SRTP for calls; format: method or method:parameters; see full documentation for details (default "none")
sipvicious rtp inject udp://target -c 10 -p21001,21003
# basic inject utility with 20 sockets and specified port range sipvicious rtp inject udp://demo.sipvicious.pro --conn-count 20 -p 35000-40000 # never stop the injecting while attempting RTP injection on both even and odd ports on the default port range sipvicious rtp inject udp://demo.sipvicious.pro --max-time 0s --probe-all-ports # null audio injection with 100 sockets and specified port number sipvicious rtp inject udp://demo.sipvicious.pro -W "" -p 35000-40000 -c 100 # send dtmf sequences while injecting with max time duration of 1000 secs sipvicious rtp inject udp://demo.sipvicious.pro --send-dtmf 5 -T 1000s
This tool does not return exit code 3, i.e. security issues are not currently automatically detected. The tool also does not return exit code 4, i.e. network connectivity problems since no feedback is typically received from the target during attack.
Specify a configuration file which may be a JSON, TOML and YAML config
format. To get the default settings and figure out which settings are available, one may
sipvicious utils dump config command. This is typically used to create a template
configuration that can then be edited as need be.
These settings may be overwritten when the corresponding flag is explicitly set, if one is present.
conn-count allows setting of how many sockets should be used concurrently. Increasing this value may increase the chances of injecting our RTP media in a real RTP stream.
Tells the logger to print out debug messages.
logfile flag is specified, a log file is created in the location specified and logs are generated in this file instead of being sent to standard output. If the filename ends with a
.json file extension, then the output format is in JSON, otherwise it defaults to text format.
By default the injection attempt ends after 10 seconds. To change this time use the
max-time flag. When set to
0 the target ports are sent RTP packets infinitely so that the tool does not need to be restarted. This is useful when demonstrating various features such as flooding all current and future media streams with a spam audio or making use of the attack to cause Denial of Service.
port-ranges argument is usually passed a comma delimited and hyphen separated list of ports to be used to send RTP media. The default list of ports is
10000-20000,35000-65000 which is known to cover a number of common media gateway configurations. The following are examples of valid values that can be passed to this argument:
12345, to target only port 12345
12000-13000, to probe between port 12000 and 13000
12345,23456,34567,35000-65000to probe ports 12345, 23456, 34567, and between 35000 and 65000
By default RTP injection is only attempted on even ports in the given range. See also the
probe-all-ports flag is set, each target port is probed instead of simply probing even ports with RTP packets and odd ports with RTCP packets.
A string value can be passed to the
send-dtmf argument which tells the tool to send a specific DTMF sequence when RTP packets are received. This feature exists to demonstrate exploitation of PBX systems that allow special codes to perform actions during a call. For example, many Asterisk PBX systems can be configured to forward calls when the sequence
#1 is detected, followed by the extension number. By injecting the correct sequence, an attacker could force calls to be forwarded to a specific number. When abused, this functionality may lead to toll fraud.
The supported alphabet in the DTMF string is
F (flash), and
, (comma) for a pause equivalent to one digit in length. The other side may not support all of these. The payload type is probed in the range 97-127 (user defined space), starting at 100 and then looping back once 127 is reached. Payloads 100 and 101 appear to be the most common.
Example: When Asterisk is configured to allow forwarding with feature code
#1 the following string will forward the call to 123456:
Testers can replay custom audio from a wave file by setting the value to the
send-wav argument. This is great for demos.
srtp flag when specified, allows users to set the SRTP mode. By default, outgoing calls do not make use of SRTP, while incoming calls automatically handle SRTP depending on the SDP body of the incoming
INVITE message. When the
srtp flag is set to
none, incoming calls do not make use of SRTP, regardless of the SDP body in an incoming
srtp mode can also be either
sdes. In both
sdes modes, the parameters are not required and will be generated randomly as need be.
Options for both
sdes mode may be passed after a colon. For example:
--srtp dtls:cert.crt:cert.key[:ca.crt]where the first argument after the mode (
dtls) is the public certificate
cert.crt, then the private key
cert.keyand finally, the optional certificate authority file
--srtp sdes:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSojwhere the argument is the base64 encoded cryptographic master key appended with the master salt.
Note that in the case of
sdes key, the master key needs to be a valid length, which is 30 octets, for the default crypto-suite
We would like to have a SIP client built into the tool which allows setting up of a (legit) SIP call. This will allow testers in lab environment or with SIP credentials to easily test for the vulnerability. The legitimate test call would be checked for the injected RTP packets from the attack, thus allowing programmatic detection of successful attacks.
The tool could test for the vulnerability multiple times, each time setting up a call and then testing for RTP Inject after an amount of time that increases with each round. This would allow the tester to automatically be able to tell if the target system is vulnerable, and if the vulnerable system can only be attacked during the first few seconds or first few packets.
A more advanced test would be to be able to spoof the source IP and port for the RTP packets. This would allow the tester to see if RTP injection takes place only when the right IP and/or port is found in the TCP and IP headers. Additionally, when coupled with the call setup functionality, this would allow the tester a more complete test by specifying a different IP for the RTP injection packets than for the legitimate RTP stream. Thus would allow the tester to simulate a realistic attack in a contained (i.e. just one tool) manner.