rtp bleed

Summary

Detects and exploits the RTP Bleed vulnerability

What it does

The purpose of this tool is to reproduce, detect and exploit the vulnerability described in the RTP Bleed attack details page. The tool goes beyond the very basics of the attack, allowing testers to probe the target concurrently, decode audio into wav files and display RTCP information when RTCP is received.

Tool functionality

The basic functionality of the rtp bleed bleed command is as follows:

1. Probe phase which consists of sending RTP and RTCP packets to the target host on the port ranges; This phase takes the following steps:
   1. Starting the specified number of socket pairs, each pair consisting of an RTP even port and an RTCP odd port socket.
   2. Sending probes for each RTP and RTCP port; each RTP port is, by default, sent 8 packets, while each corresponding RTCP port is sent 1 packet, both with an interval of 1ms.
   3. Asynchronously, listen for responses on the RTP and RTCP ports.
2. If any RTP response is received, the probing phase is paused and the probing socket pair is reused while RTP and RTCP packets are sent to the detected socket pairs only.
3. Each received RTP response packet is noted and potentially processed until the RTP stream is stopped.
4. The probing phase is then resumed from where it was paused.

The tool displays the following information:

• When RTCP responses are received, the RTCP response is decoded and logged at INFO level
• When the first RTP packet is received from a new source, the new source is logged at INFO level
• When the tool exits, the number of packets and type of packet (RTP or RTCP) received on each response is returned

Note that the probing phase only pauses when RTP packets are received and not for RTCP packets.

Video demonstration

Command format

sipvicious rtp bleed target-uri [flags]

Flags

      --bleed-config strings   Specify RTP/RTCP probe and attack interval and count. See documentation for specification details e.g. --bleed-config rtp-probe-interval:2ms,rtp-probe-count:16,rtcp-probe-interval:4ms
  -c, --conn-count int         Number of sockets to use during probing phase (default 10)
  -o, --output strings         Save received RTP and RTCP packets to pcap or wave file(s)
  -p, --port-ranges string     Range of ports to probe for RTP/RTCP (default "10000-20000,35000-65000")
  -A, --probe-all-ports        Probe all ports rather than sticking to the default behavior of only probing even RTP ports and/or odd RTCP ports
  -S, --probe-during-attack    Do not pause probing phase during attack phase
      --proto string           Choose which protocol to probe for (either RTP or RTCP; default being both)
      --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 probe the port ranges on the target(s)
      --rtcp-payload string    Set the RTCP payload file to be used for the probing and attacking phase
      --rtp-payload string     Set the RTP payload file to be used for the probing and attacking phase

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 bleed udp://target -p10000-11000
sipvicious rtp bleed udp://target --port-ranges 35000-40000 --proto rtp -T 10s

Advanced examples

# specify range of ports for the rtp attack using 100 sockets and keep probing 
sipvicious rtp bleed udp://demo.sipvicious.pro -p 35000-40000 -c 100

# rate limiting the attack, probe all ports and do not to pause probing while attack phase
sipvicious rtp bleed udp://demo.sipvicious.pro --rate 100/1s -S --probe-all-ports

# only probing for rtcp while using null rtcp payload with round count set to 5
sipvicious rtp bleed udp://demo.sipvicious.pro -p 35000-40000 --proto rtcp -r 5 --rtcp-payload ""

# specify an rtp payload, save audio received and save both rtp and rtcp received in a pcap file
sipvicious rtp bleed udp://demo.sipvicious.pro -p 35000-40000 --rtp-payload 2600hz.raw -o out.pcap -w

# rtp probe only with a 100ms attack interval, sending 20 rtp packets on each probe with 10ms interval
sipvicious rtp bleed udp://demo.sipvicious.pro --proto rtp --bleed-config rtp-attack-interval:100ms,rtp-probe-count:20,rtp-probe-interval:10ms -p 35000-40000

# probing all ports with specific rtcp requirements
sipvicious rtp bleed udp://demo.sipvicious.pro --bleed-config rtcp-probe-count:5,rtcp-probe-interval:10ms --bleed-config rtcp-attack-interval:10s --probe-all-ports --probe-during-attack

Exit codes

Full flag documentation

Flag: --bleed-config

Specify RTP bleed configuration. This flag accepts the following values:

• rtp-probe-count where the number of packets used for probing is set for RTP during probe mode
• rtp-probe-interval where the duration (e.g. 12ms) is set for the interval between one probe and another for RTP during probe mode
• rtp-attack-interval where the duration (e.g. 9ms) is set for the interval between one attack packet and another for RTP during attack mode
• rtcp-probe-count where the number of packets used for probing is set for RTCP during probe mode
• rtcp-probe-interval where the duration (e.g. 12ms) is set for the interval between one probe and another for RTCP during probe mode
• rtcp-attack-interval where the duration (e.g. 9ms) is set for the interval between one attack packet and another for RTCP during attack mode

Setting the probe count higher may increase the likelihood of winning a race condition, but it may also slow down the attack thus having the opposite effect.

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 during the probing phase. This may increase the chances of identifying an RTP session especially when the target is only vulnerable during a short period of time. The default value for this is set to 10 connections.

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: --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: -o, --output

Save received RTP and RTCP packets to pcap or wave file(s)

When the file extension is .pcap, a packet capture file is written to disk showing responses received during the test. This allows testers to make use of tools such as Wireshark to observe the behaviour of the target system.

When the file extension is .wav, wav files are created in each RTP stream that can be decoded. The file name is formatted as follows: [filename]-[srcIP_srcPort]-[dstIP_dstPort].wav.

Flag: -p, --port-ranges

The port-ranges argument is usually passed a comma delimited and hyphen separated list of ports to be used during the probing phase. 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

Flag: -A, --probe-all-ports

When the probe-all-ports flag is set, each target port is probed for all enabled protocols instead of probing even ports with RTP packets and odd ports with RTCP packets. In other words, each port is sent both RTP and RTCP packets when this flag is set, unless the proto flag specifies which protocol is to be probed, in which case, only that specific protocol is used for all specified ports.

Flag: -S, --probe-during-attack

The default behaviour is to pause while probing so that only one side of an RTP stream is hijacked at a time. When the probe-during-attack flag is used, the tool does not pause probing while the attack mode is on. This is useful when demonstrating Denial of Service attacks on a target RTP proxy. When this flag is turned on, RTP streams for both sides might be hijacked thus leaving the caller and callee without any audio.

Flag: --proto

Choose which protocol to use during the probing phase. Valid options are rtp and rtcp. By default, both protocols are used.

Flag: --rate

Rate allows one to limit the probing phase 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: --rtcp-payload

Pass a filename argument to the rtcp-payload flag to set the RTCP payload to be sent during the probe and attack phases.

Flag: --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

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 tool could test for the vulnerability multiple times, each time setting up a call and then testing for RTP bleed 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.

Codec changing and detection

In the future, the RTP header’s payload type may be specified and/or assumed automatically by copying the payload type in the incoming RTP packets.

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": {
            }
          },
          "issues": {
            "type": "object",
            "properties": {
              "stats": {
                "type": "array",
                "items": {
                  "type": "object",
                  "properties": {
                    "rtp_packet_num": {"type": "integer"},
                    "rtcp_packet_num": {"type": "integer"},
                    "unknown_packet_num": {"type": "integer"}
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}

Related information

• What is the difference between the rtp bleed and rtp inject commands?