rtp inject
Note
This documentation applies to SIPVicious version v6.0.0-beta.6. Please note that only the latest version of SIPVicious PRO is supported.Summary
Detects and exploits the RTP injection vulnerability
What it does
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.
Tool functionality
The basic and default functionality of the rtp inject
bleed command is as follows:
- Open a pair of ports, one dedicated to RTP and the other to RTCP
- Start sending the RTP media stream playing a hardcoded 2600Hz for a few seconds to the target port
- At the same time, listen for RTP and RTCP responses
- If RTP responses are received, log at INFO level that RTP Bleed was detected so that the tester could prefer to use the
rtp bleed
tool - If RTCP responses are received, optionally send an RTCP report saying that the quality is amazing
- If an error (e.g. ICMP unreachable) is received on the socket, move on to the next port
The above steps are done concurrently on each connection.
Note
The target URI for this tool does not take a port. Therefore the format for the target URI isudp://hostname-or-ip
.Video demonstration
Command format
sipvicious rtp inject target-uri [flags]
Flags
-c, --conn-count int Number of sockets to use (default 1)
--inject-config strings Specify RTP probe and attack interval and count. See documentation for specification details e.g. --inject-config rtp-attack-interval:2ms,rtp-attack-count:16
-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
--rate string Specify how many packets to send for each period of time; format: packets/duration; e.g. 100/30ms
-r, --rounds int Number of times to spray the port ranges on the target(s)
-P, --rtp-payload string Specify the RTP payload for the audio (e.g. music.wav or 2600hz.raw) or DTMF tones when value starts with dtmf: see the rtp-payload documentation for further details on specifying DTMF tones.
Flags inherited from parent commands
-C, --config string configuration file to use (may be JSON, TOML or YAML)
--debug set log level to debug
-T, --duration duration Stop the tool after a certain amount of time; e.g. 30s
--logfile string specify a log filename
--results string specify the filename for the result output, defaults to standard output. See documentation for information on file extension meanings
--srtp string Specify either none, dtls or sdes to enforce SRTP for calls; format: method or method:parameters; see full documentation for details (default "none")
Examples
sipvicious rtp inject udp://target -c 10 -p21001,21003
sipvicious rtp inject udp://target -p 35000-40000 -r1
Advanced examples
# 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 --probe-all-ports
# null audio injection with 100 sockets and specified port number
sipvicious rtp inject udp://demo.sipvicious.pro -P "" -p 35000-40000 -c 100 -T 1m
# send dtmf sequences while injecting with max time duration of 1000 secs
sipvicious rtp inject udp://demo.sipvicious.pro --rtp-payload dtmf:5 -T 1000s
Exit codes
Code | Description |
---|---|
40 | Security issues cannot be detected with this tool since typically no feedback is given whether or not the attack actually worked |
30 | Network connectivity issues cannot be detected with this tool since no network feedback is expected from the target during attack |
Full flag documentation
Flag: -C
, --config
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
run the 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.
Flag: -c
, --conn-count
The 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.
Flag: --debug
Tells the logger to print out debug messages.
Flag: -T
, --duration
Specify the maximum duration of the attack so that it stops after a certain time. Examples include:
30s
10m
24h
Flag: --inject-config
Specify RTP injection configuration. This flag accepts the following values:
rtp-attack-count:count
where count is an integer specifying the number of RTP packets to be sent to each port before moving on to the next port.rtcp-attack-count:count
where count is an integer specifying the number of RTCP packets to be sent to each port before moving on to the next port.rtp-attack-interval:duration
where duration (e.g.9ms
) is the time interval between each RTP packet.rtcp-attack-interval:duration
where duration (e.g.1s
) is the time interval between each RTCP packet.rtp-ssrc:integer
where the SSRC can be specified as an integer.rtp-payload-type:integer
where the payload type of the RTP packet can be specified as an integer.
In the following example, the configuration is set to send 20 RTP packets per port, with an interval of 5ms per packet:
--inject-config rtp-attack-count:20,rtp-attack-interval:5ms
Flag: --logfile
When the 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.
Flag: -p
, --port-ranges
The 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 1234512000-13000
, to probe between port 12000 and 1300012345,23456,34567,35000-65000
to 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.
Flag: -A
, --probe-all-ports
When 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.
Flag: --rate
Rate allows one to limit the attack below a certain rate. If the value is 100/30ms, that means that 100 packets should be spread out evenly across 30 milliseconds across all the connections per target.
Flag: --results
When the results
flag is specified, upon completing the test, it outputs the results to the specified filename. The format for this output file is text unless the filename ends with a .json
file extension. In that case, the result output is that of JSON.
The schema for the JSON output for this submodule can be found here.
Flag: -r
, --rounds
The number of rounds for how many times the port ranges are tested is specified by the rounds
argument.
Flag: -P
, --rtp-payload
The rtp-payload
parameter allows the setting of a file that is used for the RTP stream. The following file types are supported:
.raw
, for raw audio to be passed to the RTP stream without any transcoding.wav
, for wave files to be transcoded for the RTP stream.rtp
, for payload files containing the whole RTP packet to be sent as is
If the value of rtp-payload
starts with dtmf:
, then the RTP stream will consist of a sequence of DTMF tones instead of audio stream.
The supported alphabet in the DTMF string is 0-9
, A-D
, *
, #
, F
(flash), and ,
(comma) for a pause equivalent to one digit in length. The other side may not support all of these.
Example: When Asterisk is configured to allow call forwarding with feature code #1
, the following value to rtp-payload
will forward the call to 123456: dtmf:#1,,,123456
.
Flag: --srtp
The 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 INVITE
. The srtp
mode can also be either dtls
or sdes
. In both dtls
and sdes
modes, the parameters are not required and will be generated randomly as need be.
Options for both dtls
and 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 certificatecert.crt
, then the private keycert.key
and finally, the optional certificate authority fileca.crt
--srtp sdes:d0RmdmcmVCspeEc3QGZiNWpVLFJhQX1cfHAwJSoj
where 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 AES_CM_128_HMAC_SHA1_80
.
Future enhancements
Call setup functionality
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.
Packet-level attacks
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.
JSON schema
The following is the JSON schema for the JSON output of this tool:
{
"type": "object",
"properties": {
"status": {
"type": "object",
"properties": {
"returncode": { "type": "integer" },
"description": { "type": "string" }
}
},
"targets": {
"type": "array",
"items": {
"type": "object",
"properties": {
"target": { "type": "string" },
"status": {
"type": "object",
"properties": {
"returncode": { "type": "integer" },
"description": { "type": "string" }
}
},
"results": {
"type": "object",
"properties": {
"stats": {
"type": "array",
"items": {
"type": "object",
"properties": {
"rtp_payloads_sent": {"type": "integer"},
"rtcp_payloads_sent": {"type": "integer"}
}
}
}
}
},
"issues": {
"type": "object",
"properties": {
}
}
}
}
}
}
}