CVE-2017-14099 in Asterisk
Summary
by MITRE
In res/res_rtp_asterisk.c in Asterisk 11.x before 11.25.2, 13.x before 13.17.1, and 14.x before 14.6.1 and Certified Asterisk 11.x before 11.6-cert17 and 13.x before 13.13-cert5, unauthorized data disclosure (media takeover in the RTP stack) is possible with careful timing by an attacker. The "strictrtp" option in rtp.conf enables a feature of the RTP stack that learns the source address of media for a session and drops any packets that do not originate from the expected address. This option is enabled by default in Asterisk 11 and above. The "nat" and "rtp_symmetric" options (for chan_sip and chan_pjsip, respectively) enable symmetric RTP support in the RTP stack. This uses the source address of incoming media as the target address of any sent media. This option is not enabled by default, but is commonly enabled to handle devices behind NAT. A change was made to the strict RTP support in the RTP stack to better tolerate late media when a reinvite occurs. When combined with the symmetric RTP support, this introduced an avenue where media could be hijacked. Instead of only learning a new address when expected, the new code allowed a new source address to be learned at all times. If a flood of RTP traffic was received, the strict RTP support would allow the new address to provide media, and (with symmetric RTP enabled) outgoing traffic would be sent to this new address, allowing the media to be hijacked. Provided the attacker continued to send traffic, they would continue to receive traffic as well.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 12/17/2019
The vulnerability described in CVE-2017-14099 represents a critical media takeover issue within the Real-time Transport Protocol (RTP) stack of Asterisk PBX systems. This flaw exists in multiple versions of Asterisk including 11.x before 11.25.2, 13.x before 13.17.1, and 14.x before 14.6.1, along with certified versions of the software. The vulnerability stems from a combination of security features that were designed to enhance RTP handling but inadvertently created an exploitable condition. The core issue manifests when the strictrtp option, which is enabled by default in Asterisk 11 and later versions, interacts with symmetric RTP support that is commonly enabled to handle NAT traversal scenarios.
The technical implementation of this vulnerability involves a specific interaction between three key RTP stack features that creates an unintended behavior pattern. The strictrtp option in rtp.conf is designed to learn the source address of media for a session and drop packets not originating from the expected address, serving as a security mechanism to prevent unauthorized access to media streams. However, when combined with symmetric RTP support enabled through nat option for chan_sip or rtp_symmetric for chan_pjsip, a problematic interaction occurs. The fix for handling late media during reinvite operations introduced a change that allowed new source addresses to be learned at any time rather than only when expected. This modification, while intended to improve robustness in media handling, created a window of opportunity for attackers to exploit.
The operational impact of this vulnerability is severe and directly affects the confidentiality and integrity of voice communications within SIP-based telephony systems. An attacker with network access can exploit this vulnerability through careful timing and packet flooding to hijack media streams by learning new source addresses and redirecting outgoing traffic to their own addresses. This creates a persistent media takeover condition where the attacker can both receive and potentially manipulate voice communications. The vulnerability is particularly dangerous because it leverages legitimate features of the system that are commonly enabled in production environments, making it difficult to detect and prevent without specific awareness of the flaw.
The attack vector requires an attacker to send a flood of RTP traffic to the target system while maintaining continuous communication to sustain the hijacking. This condition can be exploited by attackers who have access to the network path between the PBX and endpoints, potentially through network monitoring or man-in-the-middle positions. The vulnerability is classified under CWE-200 (Information Exposure) and relates to improper handling of network media streams in telephony applications. From an ATT&CK perspective, this vulnerability maps to T1046 (Network Service Scanning) and T1071.004 (Application Layer Protocol: DNS) as attackers may need to identify target systems and potentially manipulate network communications. The exploitation requires specific timing and network conditions, making it more sophisticated than typical network-based attacks but still feasible in environments where attackers have network access.
Mitigation strategies for this vulnerability include upgrading to patched versions of Asterisk where the RTP stack behavior has been corrected to properly handle address learning only when expected, disabling the problematic combination of strictrtp and symmetric RTP features, or implementing additional network-level security controls such as firewall rules that restrict RTP traffic to known good addresses. Organizations should also consider monitoring for unusual RTP traffic patterns that might indicate exploitation attempts and ensure that network segmentation prevents unauthorized access to PBX systems. The fix implemented in patched versions addresses the core issue by restoring the intended behavior where new source addresses are only learned under specific expected conditions rather than allowing arbitrary learning during active media streams.