# RTPEngine susceptible to Denial of Service via DTLS Hello packets during call 

- Fixed versions: mr12.1.1.2, mr12.0.1.3, mr11.5.1.16, mr10.5.6.3, mr10.5.6.2
- Enable Security Advisory: 
- Vendor Patch: 
- Tested vulnerable versions: mr11.5.1.6
- Timeline:
        - Report date: 2023-10-02
        - Triaged: 2023-10-02
        - Fix provided for testing: 2023-11-16
        - Enable Security verified fix: 2023-12-14
        - Vendor release with fix: 2023-12-14
        - Enable Security advisory: 2023-12-15

## TL;DR

When handling DTLS-SRTP for media setup, RTPEngine is susceptible to Denial of 
Service due to a race condition in the hello handshake phase of the DTLS 
protocol. This attack can be done continuously, thus denying new DTLS encrypted 
calls during the attack.

## Description

Our research has shown that key establishment for Secure Real-time Transport 
Protocol (SRTP) using Datagram Transport Layer Security Extension (DTLS)[^1] is 
susceptible to a Denial of Service attack due to a race condition. If an 
attacker manages to send a ClientHello DTLS message with an invalid CipherSuite 
(such as `TLS_NULL_WITH_NULL_NULL`) to the port on the RTPEngine server that is 
expecting packets from the caller, the media session is torn down.

This behavior was tested against RTPEngine version mr11.5.1.6, which was found 
to be vulnerable to this issue.

The following sequence diagram shows the normal flow (i.e. no attack) involving 
SIP, STUN and DTLS messages between a UAC (the Caller), Kamailio and an 
RTPEngine server capable of handling WebRTC calls.

Diagram showing a call setup against RTPEngine that uses SIP, STUN and DTLS:

In a controlled experiment, it was observed that when the Attacker sent a DTLS 
ClientHello to RTPEngine's media port from a different IP and port, RTPEngine 
gave an internal error and did not process the call any longer.

Diagram showing a call setup against RTPEngine that fails due to an attacker 
controlled DTLS ClientHello:

During a real attack, the attacker would spray a vulnerable RTPEngine server 
with DTLS ClientHello messages. The attacker would typically target the range 
of UDP ports allocated for RTP. When the ClientHello message from the Attacker 
wins the race against an expected ClientHello from the Caller, RTPEngine 
terminates the media session resulting in Denial of Service.

The following log shows that RTPEngine resets the DTLS connection context:

DEBUG: [... port 39910]: [ice] Received ICE/STUN response code 0 for candidate 
pair TUk2hmDhRdEwbjA1:6249488300:1 from to
DEBUG: [... port 39910]: [ice] Setting ICE candidate pair 
TUk2hmDhRdEwbjA1:6249488300:1 as succeeded
DEBUG: [... port 39910]: [ice] Best succeeded ICE pair with all components is 
DEBUG: [... port 39910]: [ice] ICE not completed yet, but can use pair 
INFO: [... port 39910]: [ice] ICE negotiated: peer for component 1 is
INFO: [... port 39910]: [ice] ICE negotiated: local interface
DEBUG: [... port 39910]: [srtp] Processing incoming DTLS packet
ERR: [... port 39910]: [crypto] DTLS error: 1 (no shared cipher)
ERR: [... port 39910]: [srtp] DTLS error on local port 39910
DEBUG: [... port 39910]: [crypto] Resetting DTLS connection context

## Impact

Abuse of this vulnerability may lead to a massive Denial of Service on 
vulnerable RTPEngine servers for calls that rely on DTLS-SRTP. In practice, 
this results in all new calls appearing to be on mute.

## How to reproduce the issue

1. Run an RTPEngine instance with the following command:

        rtpengine -f \
                --interface=<interface> \
                --listen-ng="<listen-ng>" \
                --pidfile=<pidfile> \
                --port-min=35000 \
                --port-max=40000 \
                --log-stderr \
1. Run a Kamailio instance with the following configuration:




        loadmodule "pv.so"
        loadmodule "xlog.so"
        loadmodule "rtpengine.so"
        loadmodule "sl.so"
        loadmodule "tm.so"
        loadmodule "textops.so"
        loadmodule "siputils.so"

        modparam("rtpengine", "rtpengine_sock", "udp:<listen-ng>")


        request_route {

                if ($rm == "INVITE") {

                if ($avp(caller_source) == "$si:$sp") {
                        if ($rm == "INVITE") {
replace-session-connection pad-crypto RTP/SAVPF ICE=force");

                } else {
                        xlog("L_INFO","got a request from callee [$rm]\n");

                if ($avp(caller_source) != "$si:$sp") {
                        if (!is_request()) {
                                xlog("L_INFO","got a reply from callee [$rs 
                                if has_body("application/sdp") {
replace-session-connection pad-crypto RTP/SAVPF ICE=force");

1. Send an INVITE message to Kamailio with WebRTC SDP:

        INVITE sip:1000@ SIP/2.0
        Via: SIP/2.0/WSS;rport=36742;branch=z9hG4bK-jQcnXJadB2VGfGmQ
        Max-Forwards: 70
        From: <sip:1000@>;tag=L9kc5NfpYG1u67cT
        To: <sip:1000@>
        Contact: <sip:1000@>
        Call-ID: DzGnBLt0z9SK3MC0
        CSeq: 5 INVITE
        Content-Type: application/sdp
        Content-Length: 385

        o=- 1695296331 1695296331 IN IP4
        t=0 0
        c=IN IP4
        m=audio 45825 UDP/TLS/RTP/SAVPF 0 8 101
        a=rtpmap:0 PCMU/8000/1
        a=rtpmap:8 PCMA/8000/1
        a=rtpmap:101 telephone-event/8000
1. Note RTPEngine's media port and IP values, which will be used as the 
`<rtpengine-ip>` and `<media-port>` parameters by the Attacker
1. Send a DTLS ClientHello message from a (attacker-controlled) host, which is 
different from the Caller but has network access to the RTPEngine server

        echo -n "${CLIENT_HELLO}" | base64 --decode | nc -u <rtpengine-ip> 
1. Observe that RTPEngine reports that the DTLS context has been reset

## Solution and recommendations

To address this vulnerability, upgrade RTPEngine to the latest version which 
includes the security fix. The solution implemented is to drop all packets from 
addresses that have not been validated by an ICE check.

## About Enable Security

[Enable Security](https://www.enablesecurity.com) develops offensive security 
tools and 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 

[^1]: Datagram Transport Layer Security (DTLS) Extension to Establish Keys for 
the Secure Real-time Transport Protocol (SRTP) 

    Sandro Gauci, CEO at Enable Security GmbH

    Register of Companies:       AG Charlottenburg HRB 173016 B
    Company HQ:                       Neuburger Stra├če 101 b, 94036 Passau, 
    RTCSec Newsletter:               https://www.rtcsec.com/subscribe
    Our blog:                                https://www.rtcsec.com
    Other points of contact:       https://www.enablesecurity.com/contact/
Sent through the Full Disclosure mailing list
Web Archives & RSS: https://seclists.org/fulldisclosure/

Reply via email to