CVE-2023-49786

Executive Summary

CVE-2023-49786 is a denial-of-service (DoS) vulnerability in Asterisk, the open-source private branch exchange (PBX) and telephony toolkit. The flaw resides in the DTLS hello handshake phase during media setup for DTLS-SRTP encrypted calls, where a race condition allows an unauthenticated remote attacker to disrupt call establishment. Successful exploitation can be repeated continuously, effectively blocking all new DTLS-SRTP-encrypted calls on the affected server, resulting in a significant availability impact for organizations relying on secure media transport.

Technical Analysis

The vulnerability is rooted in the Datagram Transport Layer Security (DTLS) protocol's "hello" handshake phase, which is used to negotiate encryption keys for Secure Real-time Transport Protocol (SRTP) media streams. Asterisk implements DTLS-SRTP to secure media channels between endpoints and the PBX. The flaw is a race condition during the hello handshake phase — a temporal window between the receipt of the ClientHello message and the completion of state setup in the DTLS state machine.

During this race window, multiple concurrent or malformed hello packets can cause the DTLS state machine to transition into an inconsistent or locked state. Because DTLS runs over UDP, there is no built-in congestion control or connection state tracking at the transport layer; each hello packet is treated as a potential new session. An attacker who targets this race condition can force the DTLS handshake handler into a state where it can no longer process new handshake requests.

The attack requires the ability to send crafted DTLS hello packets to the server's media port. Significantly, the attacker does not need to complete the SIP signaling layer — the vulnerable code path is triggered during the media setup process before any successful DTLS handshake completes. Each attack attempt consumes server resources in the handshake state machine. Because the condition can be triggered repeatedly and continuously, the attacker can maintain the server in a denied state for extended periods.

The patch, contained in commit d7d7764cb07c8a1872804321302ef93bf62cba05, addresses the race condition by serializing the hello-handshake state transitions, ensuring that concurrent hello packets do not corrupt the DTLS state machine. The fix is included in Asterisk versions 18.20.1, 20.5.1, 21.0.1, and certified-asterisk 18.9-cert6. Two independent sources (the CNA and Debian) confirm the availability and validity of the patch, giving a patch confidence rating of 3/4 (LIKELY). Note that the NVD description does not provide specifics on the exact function names or code paths affected, so the vulnerability is best characterized at the class level as a race condition in a network protocol state machine.

Exploitation Scenarios

This vulnerability allows an unauthenticated remote attacker to prevent the establishment of new DTLS-SRTP-encrypted calls. The attack chain proceeds as follows:

1. Reconnaissance/Target Identification: The attacker identifies Internet-facing Asterisk servers that support DTLS-SRTP for media encryption. This can be accomplished via SIP OPTIONS probing, port scanning for the RTP/DTLS media ports (typically UDP 10000–20000 range), or Shodan-style search engines using fingerprints such as "Server: Asterisk" in SIP responses. The attacker may also use SIP REGISTER or INVITE messages to trigger media negotiation and confirm DTLS-SRTP support.

2. Flaw Triggering (Vulnerability Class): The attacker sends a rapid succession of DTLS hello packets (ClientHello) to the target server's media port. The packets target the DTLS handshake handler during the hello phase. Because the vulnerability is a race condition, the attacker does not need to craft a specific payload beyond valid DTLS ClientHello messages — the exploit relies on concurrency and timing rather than memory corruption. Multiple simultaneous or near-simultaneous hello requests cause the handshake state machine to enter a conflicting state, effectively blocking subsequent handshake processing.

3. Payload/Execution at Class Level: The "payload" is a stream of DTLS ClientHello datagrams sent at high frequency. The attacker can use standard DTLS client libraries or custom scripts to generate these packets. No authentication is required, and no prior interaction with the PBX is necessary beyond reaching the media port. The race condition is triggered by the sheer volume and timing of hello packets during the handshake state transitions, not by malformed or oversized data.

4. Post-Exploitation Impact: Once the DTLS handshake state machine is wedged, all new calls that attempt to establish DTLS-SRTP media sessions will fail. Existing calls continue to operate, but new call setup is denied. The attacker can repeat this process continuously, maintaining the denial-of-service condition for an arbitrary duration. This effectively blackholes the secure-call capacity of the PBX, causing a full availability loss for DTLS-SRTP-encrypted communications. The CVSS score of 7.5 (High) reflects this significant availability impact; the attack requires no privileges (PR:N), is remotely exploitable (AV:N), and has low attack complexity (AC:L).

No public PoC is available at the time of writing; the attack chain above is inferred from the vulnerability class (race condition in DTLS hello handshake) and the NVD description. The EPSS score of 0.05338 (91.9th percentile) indicates the vulnerability is considered likely to be exploited in the wild relative to other published CVEs.

Impact Assessment

• CVSS Score: 7.5 (High) — CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. The high severity stems from the complete availability impact (A:H) combined with no privilege requirement and no user interaction.
• Confidentiality Impact: NONE — the attack does not expose call content or encryption keys.
• Integrity Impact: NONE — call content and signaling integrity remain intact.
• Availability Impact: HIGH — the ability to place new DTLS-SRTP-encrypted calls is fully denied during the attack. Repeated attacks can cause extended or permanent denial of secure call service.
• Business Impact: Organizations using Asterisk as an enterprise PBX rely on DTLS-SRTP for secure voice and video communications (e.g., compliance with GDPR, HIPAA, PCI-DSS, or internal security policies). An attacker denying all new secure calls forces: (a) loss of telephony service for new callers, (b) potential failover to insecure RTP if fallback is enabled (which would degrade security), (c) operational disruption for contact centers, and (d) reputational damage.
• Affected Systems: All Asterisk versions prior to 18.20.1, 20.5.1, 21.0.1, and all certified-asterisk versions prior to 18.9-cert6 that enable DTLS-SRTP for media encryption. Systems not using DTLS-SRTP (e.g., plain RTP or ZRTP-only configurations) are not exposed to this specific attack vector.
• Blast Radius: The attack is network-based and does not require valid SIP credentials. Any server on the public Internet with DTLS-SRTP enabled and reachable media ports is vulnerable, making the blast radius large in terms of externally exposed Asterisk deployments.

Detection Guidance

Sigma Rule

title: Asterisk DTLS Hello Flood DoS (CVE-2023-49786)
id: 3f9d62b4-1b3c-4a8e-9c2d-1f0e8a7c5d22
status: experimental
description: Detects high-frequency DTLS ClientHello packets targeting a single Asterisk media port, potentially indicating exploitation of CVE-2023-49786.
logsource:
  product: asterisk
  service: security
detection:
  selection:
    EventID:
      - 'DTLS'
      - 'SIP'
    message|contains: 'DTLS-SRTP'
  timeframe: 10s
  condition: selection | count() by src_ip > 100
level: high
falsepositives:
  - Legitimate high-volume telephony traffic during peak call periods
  - Misconfigured DTLS clients performing rapid retransmissions
tags:
  - attack.t1498
  - cve.2023-49786

YARA Rule

rule Asterisk_DTLS_DoS_CVE_2023_49786
{
    meta:
        author = "Valter's IT SOC"
        description = "Detects DTLS ClientHello payload patterns used in potential Asterisk DoS exploitation"
        cve = "CVE-2023-49786"
        date = "2024-01-15"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2023-49786"
    strings:
        $dtls_header = { 16 FE FD } // DTLS 1.2 handshake header (content type 22, version 0xFE FD)
        $clienthello = { 01 } // Handshake type: ClientHello
        $srtp_ext = { 00 0F } // SRTP protection profile extension
        $cookie_ext = { 00 0E } // DTLS cookie extension
    condition:
        uint16(0) == 0x16FE and // DTLS record header
        any of them and
        filesize < 1500 // UDP datagram size
}

Suricata IDS Rule

alert udp any any -> any 10000:20000 (msg:"ET DOS Asterisk DTLS Hello Flood Attempt (CVE-2023-49786)"; dsize:50<>1500; content:"|16 fe fd|"; depth:3; content:"|01|"; offset:13; within:1; threshold:type both, track by_dst, count 50, seconds 10; classtype:attempted-dos; reference:cve,2023-49786; sid:20249786; rev:1;)

Elastic Detection

network where event.category == "network" and network.transport == "udp" and
  destination.port >= 10000 and destination.port <= 20000 and
  dns.question.name == null and
  /* DTLS ClientHello detection: record type 22, version 0xFEFD */
  network.bytes >= 50 and
  /* High frequency from same source IP */
  event.start with +10s, maxspan 10s by source.ip, destination.ip, destination.port
  | stats count = count() by source.ip, destination.ip, destination.port
  | where count >= 100

Splunk SPL Query

index=netflow OR index=firewall sourcetype=cisco:asa OR sourcetype=fortigate:utm
| where dest_port >= 10000 AND dest_port <= 20000
| where transport = "udp"
| eval dtls_hello = if(len(payload) >= 50 AND substr(payload, 0, 1) = "16" AND substr(payload, 1, 2) = "fe fd", 1, 0)
| where dtls_hello = 1
| bucket _time span=10s
| stats count as hello_count by _time, src_ip, dest_ip, dest_port
| where hello_count >= 100
| table _time, src_ip, dest_ip, dest_port, hello_count

Wazuh OSSEC Rule

<group name="asterisk,">
  <rule id="100497" level="10">
    <decoded>dtls</decoded>
    <match>hello|handshake</match>
    <regex>ClientHello</regex>
    <description>Asterisk DTLS Hello Flood - possible CVE-2023-49786 exploitation</description>
    <mitre>
      <id>T1498</id>
    </mitre>
  </rule>
  <rule id="100498" level="10" frequency="50" timeframe="10">
    <if_matched_sid>100497</if_matched_sid>
    <same_source_ip />
    <description>Asterisk DTLS Hello Flood - high frequency from single source (CVE-2023-49786)</description>
    <group>attack.t1498,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 3/4 (LIKELY) — Two independent sources (CNA and Debian) confirm the fix; apply the patch as the primary remediation.

1) Immediate Mitigations

• If patching is not immediately possible, disable DTLS-SRTP for media encryption and fall back to plain RTP or ZRTP if acceptable per security policy. This removes the attack surface but degrades media encryption.
• Restrict media port access at the firewall/ACL level to only allow UDP traffic from known SIP peer IP addresses or trusted carrier networks. This significantly reduces the exposure to unauthenticated Internet attackers.
• Set rate-limiting on the firewall or Asterisk's res_rtp_asterisk module to limit DTLS ClientHello packets per source IP per second, mitigating the race condition trigger.
• Use a session border controller (SBC) that terminates DTLS-SRTP at the edge, shielding the core Asterisk server from direct media port exposure.

2) Patch/Upgrade Steps

• Upgrade to Asterisk 18.20.1, 20.5.1, 21.0.1, or later. Update certified-asterisk to 18.9-cert6 or later.
• The fix is contained in commit d7d7764cb07c8a1872804321302ef93bf62cba05. Verify the commit hash in the installed version's changelog after upgrade.
• For source builds: git fetch && git checkout <fixed-version> then recompile and install.
• For Debian/Ubuntu systems: apt update && apt upgrade asterisk (ensure the repository provides the patched version per Debian's advisory).
• Restart the Asterisk service after the upgrade and verify DTLS-SRTP calls establish successfully.

3) Long-Term Hardening

• Keep Asterisk updated automatically or via a weekly patch-review process. Track security announcements from the Asterisk project.
• Implement network segmentation so that media ports are not directly routable from the public Internet; place PBX behind an SBC or proxy.
• Monitor media ports for anomalous DTLS ClientHello rates and integrate detection rules (Sigma, Suricata, Elastic) into the SIEM pipeline.
• Conduct regular penetration testing focused on SIP/RTP/DTLS attack surfaces.
• Document and test failover scenarios: if DTLS-SRTP is critical, ensure the system can fall back to alternate media encryption mechanisms without manual intervention.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2023-49786
2. Asterisk Security Advisory (CNA): https://www.asterisk.org/security/ (referencing CVE-2023-49786)
3. Debian Security Tracker: https://security-tracker.debian.org/tracker/CVE-2023-49786
4. Commit Reference: d7d7764cb07c8a1872804321302ef93bf62cba05 (Asterisk Git repository)
5. CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (CVE-2023-49786 not currently listed)

Threat Actor Activity: No known threat-actor campaigns or exploit-in-the-wild evidence specifically attributed to CVE-2023-49786 have been publicly documented at the time of this writing. However, the EPSS percentile of 91.9% indicates elevated exploitation likelihood relative to other published CVEs, and DTLS-based DoS attacks against SIP infrastructure are a known TTP in the threat landscape.