rtp inject

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.

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

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 12345
• 12000-13000, to probe between port 12000 and 13000
• 12345,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 certificate cert.crt, then the private key cert.key and finally, the optional certificate authority file ca.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": {
            }
          }
        }
      }
    }
  }
}