The RTP bleed Bug

The RTP bleed Bug is a serious vulnerability in a number of RTP proxies. This weakness allows malicious users to inject and receive RTP streams of ongoing calls without needing to be positioned as man-in-the-middle. This may lead to eavesdropping of audio calls, impersonation and possibly cause toll fraud by redirecting ongoing calls.

How does the vulnerability work?

RTP proxies try to address NAT limitations affecting RTC systems by proxying RTP streams between two or more parties. When NAT is in place, the RTP proxy software often cannot rely on the RTP IP and port information retrieved through signalling (e.g. SIP). Therefore, a number of RTP proxies have implemented a mechanism where such IP and port tuplet is learned automatically. This is often done by by inspecting incoming RTP traffic and marking the source IP and port for any incoming RTP traffic as the one that should be responded to. This mechanism, which may be called "learning mode", does not make use of any sort of authentication. Therefore attackers may send RTP traffic to the RTP proxy and receive the proxied RTP traffic meant to be for the caller or callee of an ongoing RTP stream. We call this vulnerability RTP Bleed because it allows attackers to receive RTP media streams meant to be sent to legitimate users.

Another interesting behaviour of RTP proxies and RTP stacks is that sometimes, even if not vulnerable to RTP Bleed, they will accept, forward and/or process RTP packets from any source. Therefore attackers can send RTP packets which may allow them to inject their media instead of the legitimate one. We call this attack RTP injection because it allows injection of illegitimate RTP packets into existent RTP streams. This vulnerability may be found in both RTP proxies and endpoints.

Both attacks require sending of RTP packets to a port allocated by the RTP proxy for legitimate RTP sessions. In the case of RTP Bleed, however, this leads to the attacker receiving the RTP packets that are being proxied. This can therefore lead to leakage of confidential media, insertion of wrong media and denial of service. On successful exploitation, the attacker can convert the RTP stream into its media equivalent and, for example, listen in on an ongoing phone call or save the audio to disk.

What leaks in practice?

We have seen RTP proxies leak RTP packets containing unencrypted audio and allow audio injection of ongoing calls. We have also seen encrypted RTP (i.e. SRTP) packets being leaked out, which has different security implications to when RTP is not encrypted. We assume that any RTP traffic passing through a vulnerable RTP proxy may be sent to an attacker who has network access to the system.

Q&A

Why it is called the RTP bleed Bug?

The naming convention follows a number of other security vulnerabilities, first being Heartbleed, suffixed with the keyword bleed. Also, our imagination when naming this vulnerability, was rather limited.

When this vulnerability is exploited it leads to the leakage of RTP packets which are sent to the attacker instead of the legitimate caller or callee.

Is this a design flaw in RTP protocol specification?

Sort of, a bit. There is no authentication of RTP packets in unencrypted RTP session. Even when NAT is not involved the source of the packets cannot be known (except if symmetric RTP (RFC4961) is used by both endpoints).

However, poorly designed RTP proxies make exploiting this flaw easier than necessary when trying to cater for endpoints behind NAT.

Is this like Heartbleed but for RTP?

No. While Heartbleed leaked memory due to a bug in OpenSSL, RTP Bleed leaks RTP packets due to a design issue in vulnerable systems.

How is this different to sniffing unencrypted RTP traffic?

To sniff unencrypted RTP traffic, an attacker usually needs to be strategically positioned within the target network. Examples of strategically positioned attackers include those that can successfully mount an ARP cache poisoning attack, abuse compromised routers or perform BGP hijacking.

RTP Bleed does not require the attacker to be strategically positioned within the target network. All that is required is for the attacker to send RTP packets to the vulnerable system.

What is being leaked?

RTP packets which usually contain audio or video payloads. The implication is that phone call audio may be leaked or hijacked by an attacker.

Am I affected by the bug?

You may be affected either directly (e.g. if you are a RTC vendor or service provider) or indirectly. The RTP protocol and media gateways are used in various telephony systems, including PBX systems, "landline phones" connected to customer premises equipment, smart phone apps and so on.

How widespread is this?

The most notable software vulnerable to this bug is Asterisk and RTP Proxy. We do expect a number of commercial as well as custom RTP proxies to be vulnerable to this bug.

What software is known to be affected?

The following software was tested and found to be vulnerable:

  • Asterisk 14.4.0
  • RTPproxy (tested 1.2.1-2ubuntu1 and RTPproxy 2.2.alpha.20160822 (git))

Can I detect if someone has exploited this against me?

Exploitation of this bug often does leave clear traces including phone calls going mute and choppy audio.

Can IDS/IPS detect or block this attack?

It is likely that UDP port scan detection can be used to detect and mitigate attack. This does not, however, address the vulnerability itself and should only be seen as temporary mitigation.

Has this been abused in the wild?

We don't know but during our testing, we did find vulnerable systems on the Internet.

How does this vulnerability lead to Denial of Service?

Normally, the vulnerable RTP proxy will proxy the same RTP stream to only one IP and port tuple. This means that when the attacker starts receiving the RTP stream, the original legitimate caller stops receiving the RTP stream.

An attacker who simply floods an RTP proxy with RTP packets can cause all RTP streams to be sent to the attacker. Therefore legitimate users are denied service and will be unable to get their calls through the system.

Does this vulnerability always lead to Denial of Service?

No, in our experience, we have seen vulnerable systems that will send some of the packets to the attacker and some to the legitimate user. When this happens, the audio quality may appear to be choppy but the call may carry on.

This happens when the vulnerable system sends RTP to the IP address and port that last sent valid RTP. Therefore this leads to a constant race condition between the victim and the attacker.

Does SRTP mitigate this?

If incoming SRTP is validated by the proxy, then SRTP would mitigate the security issue. We have seen dumb RTP proxies that simply forward SRTP and in this case SRTP could be leaked.

What are the security implications of leaking SRTP?

If a vulnerable system is leaking SRTP, the confidentiality or integrity of the SRTP packets is not compromised. However this may lead to denial of service which is still a major security issue for real-time communications systems.

It is recommended to make use of SRTP to avoid the confidentiality and integrity impact of this vulnerability. SRTP should ideally be between two endpoints without any proxy in the middle. Authenticated STUN could help introduce some form of authentication to RTP.

What about having a learning mode or probation period?

Learning mode or probation period is when the choice of IP and port to relay RTP to is limited to a certain amount of time or packets. RTP proxies that we have tested did implement this feature to try to prevent attackers from the attack that we describe. However, what this feature does in terms of security is to limit the exposure to this attack to a short period of time. In practice, we think that this is an insufficient solution because attacker may continuously spray the vulnerable server with RTP packets. This allows the attacker to send RTP within those first few packets and still exploit this vulnerability.

Any other solutions or mitigation?

RTP proxies could match the IP of incoming RTP packets to those hinted through signalling during an initial learning phase. If multiple IPs are seen during this phase, priority should be given to the previously hinted IPs. This behaviour may be repeated whenever the call gets transferred, put on hold or resumed.

Valid IPs could be hinted within SIP as well as by looking at the IP header of the signalling network traffic.

This mitigation does not address all cases where the signalling and media are using separate systems. It can, however, be combined with other solutions (such as using static IPs, supporting ICE and STUN authentication etc), to reduce the exposure to this attack.

Is there a bright side to all this?

Service providers who may be affected may take this as a good opportunity to test their systems and take a hard look at their RTP proxies that are often forgotten from a security standpoint.

What can be done to prevent this from happening in future?

The security, VoIP and RTC, community, we included, must learn to find these inevitable human mistakes sooner. Please support the development effort of software you trust your privacy to.

WebRTC avoids this particular security bug, and various others, by mandating the usage of SRTP, making use of authenticated STUN and supporting TURN whenever proxying is needed.

So is WebRTC also vulnerable?

Usually not.

Who found the RTP bleed Bug?

This bug was independently discovered by Klaus-Peter Junghanns and Sandro Gauci of Enable Security. Klaus-Peter found this vulnerability while implementing his own RTP stack while Sandro Gauci came across it while security testing media gateways for Enable Security's clients.

References

What is Enable Security?

Enable Security provides Information Security services, including Penetration Testing, Research and Development, to help protect client networks and applications against online attackers.