Asterisk RTP bug worse than first thought: Think intercepted streams
Thanks for using Asterisk. Your call is transparent to us, so stay on the line to get p0wned
One of the Asterisk bugs published last week is worse than first thought: Enable Security warns it exposes the popular IP telephony system to stream injection and interception without an attacker holding a man-in-the-middle position.
A reader (@kapejod, who collaborated with @sandrogauci on the work) alerted The Register to this advisory last published Friday.
In it, Enable Security explains that a bug it's dubbed “RTPbleed” (the “RTP” stands for Real Time Protocol) which first emerged in September 2011, was patched in the same month, but was then reintroduced in 2013. As this page states, it doesn't only affect Asterisk, because the bug's in RTP proxy code.
The problem occurs when comms systems like IP telephony have to get past network address translation (NAT) firewalls. The traffic has to find its way from the firewall's public IP address to the internal address of the device or server, and to do that, RTP learns the IP and port addresses to associate with a call.
The problem is, the process doesn't use any kind of authentication.
For Asterisk, the bug is triggered when the system “is configured with the
strictrtp=yes” – and because NAT is pretty much ubiquitous, those are default settings.
What's special about this bug is that the attacker doesn't need to be between the two ends of the conversation: a system with a vulnerable RTP implementation can be persuaded to reflect media streams towards the attacker.
“To exploit this issue, an attacker needs to send RTP packets to the Asterisk server on one of the ports allocated to receive RTP. When the target is vulnerable, the RTP proxy responds back to the attacker with RTP packets relayed from the other party. The payload of the RTP packets can then be decoded into audio.”
It's a pretty knotty problem: admins can turn off the
nat=yes flag, but only if they're not using NAT; they can authenticate and encrypt media streams with Secure Real Time Protocol (SRTP), but only if both ends support it.
The Asterisk patch “limits the window of vulnerability to the first few milliseconds”, which is good because the other suggested mitigations could be troublesome for sysadmins: turning off NAT; or using Secure RTP (SRTP) which can authenticate and encrypt streams if both ends support it.
There are still issues with the patch:
Note that as for the time of writing, the official Asterisk fix is vulnerable to a race condition. An attacker may continuously spray an Asterisk server with RTP packets. This allows the attacker to send RTP within those first few packets and still exploit this vulnerability.
The official Asterisk fix also does not properly validate very short RTCP packets (e.g. 4 octets, see rtcpnatscan to reproduce the problem) resulting in an out of bounds read disabling SSRC matching. This makes Asterisk vulnerable to RTCP hijacking of ongoing calls. An attacker can extract RTCP sender reports containing the SSRCs of both RTP endpoints.
@kapejod links to his own contribution to fixing the issue. ®