When Asterisk is configured with the `nat=yes` and `strictrtp=yes` (onby default) options, it is vulnerable to an attack which we call RTPBleed. Further information about the attack can be found at<https://rtpbleed.com>.

## Impact

Abuse of this attack allows malicious users to inject and receive RTPstreams of ongoing calls **without** needing to be positioned asman-in-the-middle. As a result, in the case of an RTP stream containingaudio media, attackers can inject their own audio and receive audiobeing proxied through the Asterisk server.

## How to reproduce the issue

The vulnerability can be exploited when a call is taking place and theRTP is being proxied. To exploit this issue, an attacker needs to sendRTP packets to the Asterisk server on one of the ports allocated toreceive RTP. When the target is vulnerable, the RTP proxy responds backto the attacker with RTP packets relayed from the other party. Thepayload of the RTP packets can then be decoded into audio.

This issue can be reproduced by making use of[rtpnatscan](https://github.com/kapejod/rtpnatscan) (freely available)or [SIPVicious PRO](https://sipvicious.pro) (will be commerciallyavailable).

## Solutions and recommendations

We have the following recommendations:

- It is recommended to apply the fix issued by Asterisk which limits thewindow of vulnerability to the first few milliseconds. - When possible the `nat=yes` option should be avoided.- To protect against RTP injection the media streams should be encrypted(and authenticated) with SRTP.- A configuration option for SIP peers should be added that allows toprioritize RTP packets coming from the IP address learned through SIPsignalling during the initial probation period.

Note that as for the time of writing, the official Asterisk fix isvulnerable to a race condition. An attacker may continuously _spray_ anAsterisk server with RTP packets. This allows the attacker to send RTPwithin those first few packets and still exploit this vulnerability.

The official Asterisk fix also does not properly validate very shortRTCP packets (e.g. 4 octets, see[rtcpnatscan](https://github.com/kapejod/rtpnatscan) to reproduce theproblem) resulting in an out of bounds read disabling SSRC matching.This makes Asterisk vulnerable to RTCP hijacking of **ongoing** calls.An attacker can extract RTCP sender reports containing the SSRCs of bothRTP endpoints.

A patch for this is available at(https://raw.githubusercontent.com/kapejod/rtpnatscan/master/patches/asterisk/too-short-rtcp-bugfix.diff)

The information in the advisory is believed to be accurate at the timeof publishing based on currently available information. Use of theinformation constitutes acceptance for use in an AS IS condition. Thereare no warranties with regard to this information. Neither the authornor the publisher accepts any liability for any direct, indirect, orconsequential loss or damage arising from use of, or reliance on, thisinformation.