sipvicious 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 in 19ms intervals, while each corresponding RTCP port is sent 1 RTCP packet
    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.

The following is an example logging of this tool:

INFO[0002] received RTP packet from from 1.2.3.4:17744 on [::]:38757
INFO[0002] received RTCP packet from from 1.2.3.4:17745 on [::]:38758
INFO[0002] starting attack against 1.2.3.4:17744 from [::]:38757
INFO[0016] attack on 1.2.3.4:17744 seems to have stopped, resuming

The following is an example output given when the test is finished:

{
     "1.2.3.4:17744": {
          "rtp_packet_num": 200,
     },
     "1.2.3.4:17745": {
          "rtcp_packet_num": 3,
          "rtcp_packets": {
               // decoded rtcp packets
          },

     }
}

Command format

sipvicious rtp bleed target-uri [flags]

Flags

  -c, --conn-count int                  Number of sockets to use during probing phase (default 10)
  -K, --keep-probing                    Keep probing (disregard --rounds)
  -p, --port-ranges string              Range of ports to probe for RTP/RTCP (default "10000-20000,35000-65000")
      --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) (default 1)
      --rtcp-attack-interval duration   Interval to send RTCP packets during attack phase (default 2s)
      --rtcp-payload string             set the RTCP payload file to be used for the probing and attacking phase
      --rtcp-probe-count int            Number of RTCP packets to use on each port during probe phase (default 1)
      --rtcp-probe-interval duration    Interval to send RTCP packets during probe phase (default 1ms)
  -s, --rtp-attack-interval duration    Interval to send RTP packets during attack phase (default 20ms)
      --rtp-payload string              set the RTP payload file to be used for the probing and attacking phase
      --rtp-probe-count int             Number of RTP packets to use on each port during probe phase (default 8)
      --rtp-probe-interval duration     Interval to send RTP packets during probe phase (default 1ms)
  -P, --save-pcap string                Save received RTP and RTCP packets to PCAP file
  -w, --save-wav                        Save received audio to wav files

Flags inherited from parent commands

  -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")

Examples

sipvicious rtp bleed udp://target -p10000-11000 -K

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 --keep-probing

# 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 -P 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 -s 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 --rtcp-probe-count 5 --rtcp-probe-interval 10ms --rtcp-attack-interval 10s --probe-all-ports --probe-during-attack

Exit codes

This tool returns exit code 3, i.e. security issue detected when RTP is received as a result of the attack. The tool never returns exit code 4, i.e. network connectivity problems, since no network feedback is typically expected from the target during attack unless the target is vulnerable.

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

Flag: debug

Tells the logger to print out debug messages.

Flag: keep-probing

When the keep-probing flag set, the target ports are probed infinitely so that the tool does not need to be restarted. This is useful when demonstrating various other features such as saving of the received media or making use of the attack to cause Denial of Service.

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

The number of rounds for how many times the port ranges are tested is specified by the rounds argument. The default is 1 and this flag is overwritten by the keep-probing flag.

Flag: rtcp-attack-interval

The RTCP packet timing can be modified by setting the rtcp-attack-interval argument. This applies to the attack phase.

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: rtcp-probe-count

Specify how many RTCP packets to send per port in each round during the probe phase. The default is 1 packet.

Flag: rtcp-probe-interval

Specify the duration between each probe for RTCP.

Flag: rtp-attack-interval

The RTP packet timing can be modified by setting the rtp-attack-interval argument. This applies to the attack phase.

Flag: rtp-payload

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

This functionality allows identification of vulnerabilities similar to the one fixed in this patch in Asterisk.

Flag: rtp-probe-count

By default, the tool sends 8 RTP packets to each port being probed. This is done to override certain assumptions during learning mode in RTP proxies which may rely on receiving more than a certain amount of RTP packets before the attacker’s IP is accepted This value can be changed by making use of the rtp-probe-count argument.

Flag: rtp-probe-interval

The RTP probe interval can be modified by setting the duration between each probe.

This can be set to 19ms to win race conditions where the legitimate endpoint is sending RTP packets at a slightly lower speed, without raising any alarms.

Flag: save-pcap

When save-pcap argument is passed a filename, a pcap 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.

Flag: save-wav

When the save-wav flag is switched, wav files are created in the current directory for each RTP stream that can be decoded. The file name is formatted as follows: [srcIP_srcPort]-[dstIP_dstPort].wav.

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:

  • TODO: --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.