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.
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.
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.
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.
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.
No. While Heartbleed leaked memory due to a bug in OpenSSL, RTP Bleed leaks RTP packets due to a design issue in vulnerable systems.
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.
RTP packets which usually contain audio or video payloads. The implication is that phone call audio may be leaked or hijacked by an attacker.
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.
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.
The following software was tested and found to be vulnerable:
Exploitation of this bug often does leave clear traces including phone calls going mute and choppy audio.
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.
We don't know but during our testing, we did find vulnerable systems on the Internet.
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.
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.
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.
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.
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.
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.
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.
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.
Usually not.
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.
Enable Security provides Information Security services, including Penetration Testing, Research and Development, to help protect client networks and applications against online attackers.