Home » Incredible PBX » CentOS/SL Platform » RTPbleed Security Alert: Asterisk Calls Can Be Intercepted

The Most Versatile VoIP Provider: FREE PORTING

RTPbleed Security Alert: Asterisk Calls Can Be Intercepted


If you’ve installed Asterisk® during the past 4½ years, your server has a MAJOR security problem. If you didn’t already know, with Asterisk, your VoIP conversations actually are carried over a random UDP port using the Real Time Protocol (RTP), not the SIP port (UDP 5060) which handles the setup and teardown of your VoIP connections. It turns out that, since March 2013, all of that RTP traffic and thus your conversations could be intercepted and redirected by anyone on the Internet. As this recent article in The Register noted:

The problem occurs when [communications] 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.

This is exacerbated by the fact that, by default, Asterisk and FreePBX® traditionally use the NAT=yes setting (whether needed or not) to enable this navigational magic just in case your calls need it. Without it, you may end up with no audio or one-way audio on your calls. Traditional wisdom was that an attacker needed to be positioned between the caller and the Asterisk server in order to intercept this media stream. As luck would have it, it turns out the man in the middle didn’t need to be in the middle after all. He could be anywhere on the Internet. The old adage to talk on the phone as if someone else were listening turns out to have been pretty good advice in the case of Asterisk communications. Even if you had a firewall, chances are you protected UDP port 5060 while exposing and forwarding UDP 10000-20000 to Asterisk without any safeguards.

According to last week’s Asterisk advisory, “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.” Specifically, if UDP ports 10000-20000 are publicly exposed to the Internet, anybody and everybody can intercept your communications without credentials of any kind. WOW!

So, there’s a patch to fix this, right? Well, not exactly:

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 other recommended "solutions" aren’t much better:

  • When possible the nat=yes option should be avoided
  • To protect against RTP injection, encrypt media streams with SRTP
  • Add config option for SIP peers to prioritize RTP packets

The nat=no option doesn’t work if you or your provider employs NAT-based routers. The SRTP option only works on more recent releases of Asterisk, and it also requires SRTP support on every SIP phone. Prioritizing RTP packets is not a task for mere mortals.

Surprisingly, the one solution that is not even mentioned is hardening your firewall to block incoming UDP 10000-20000 traffic that originates outside your server. Our recognized SIP expert on the PIAF Forum had the simple solution. Bill Simon observed:

If the SDP in the INVITE or subsequent re-INVITE contains routable IP addresses, then use them for media. If the SDP contains non-routable IP addresses, then the client is behind a NAT and not using any NAT traversal techniques like SIP ALG, ICE/STUN, so send to the originating IP. Why are we making allowances here for media to come from anywhere? I think you can probably clamp down your firewall as much as you want, because symmetric RTP should allow media to get through by way of establishing an outbound stream (inbound stream comes back on the same path).

Our testing confirms that simply blocking incoming RTP traffic on your firewall solves the problem without any Asterisk patch. In short, RTP traffic cannot originate from anonymous sources on the Internet.

For those using Incredible PBX® or Travelin’ Man 3 or an IPtables firewall, the fix is easy. Simply remove or comment out the INPUT rule that looks like this and restart IPtables:

-A INPUT -p udp -m udp --dport 10000:20000 -j ACCEPT

On RedHat/CentOS servers, the rule is in /etc/sysconfig/iptables. On Debian/Ubuntu and Raspbian servers, you’ll find the rule in /etc/iptables/rules.v4. On Incredible PBX for Issabel servers, you’ll find the rule in /usr/local/sbin/iptables-custom. On all Incredible PBX platforms, remember to restart IPtables using only this command: iptables-restart.

Published: Friday, September 8, 2017  



Need help with Asterisk? Visit the PBX in a Flash Forum.


 

Special Thanks to Our Generous Sponsors


FULL DISCLOSURE: ClearlyIP, Skyetel, Vitelity, DigitalOcean, Vultr, VoIP.ms, 3CX, Sangoma, TelecomsXchange and VitalPBX have provided financial support to Nerd Vittles and our open source projects through advertising, referral revenue, and/or merchandise. As an Amazon Associate and Best Buy Affiliate, we also earn from qualifying purchases. We’ve chosen these providers not the other way around. Our decisions are based upon their corporate reputation and the quality of their offerings and pricing. Our recommendations regarding technology are reached without regard to financial compensation except in situations in which comparable products at comparable pricing are available from multiple sources. In this limited case, we support our sponsors because our sponsors support us.

BOGO Bonaza: Enjoy state-of-the-art VoIP service with a $10 credit and half-price SIP service on up to $500 of Skyetel trunking with free number porting when you fund your Skyetel account. No limits on number of simultaneous calls. Quadruple data center redundancy. $25 monthly minimum spend required. Tutorial and sign up details are here.

The lynchpin of Incredible PBX 2020 and beyond is ClearlyIP components which bring management of FreePBX modules and SIP phone integration to a level never before available with any other Asterisk distribution. And now you can configure and reconfigure your new Incredible PBX phones from the convenience of the Incredible PBX GUI.

VitalPBX is perhaps the fastest-growing PBX offering based upon Asterisk with an installed presence in more than 100 countries worldwide. VitalPBX has generously provided a customized White Label version of Incredible PBX tailored for use with all Incredible PBX and VitalPBX custom applications. Follow this link for a free test drive!
 

Special Thanks to Vitelity. Vitelity is now Voyant Communications and has halted new registrations for the time being. Our special thanks to Vitelity for their unwavering financial support over many years and to the many Nerd Vittles readers who continue to enjoy the benefits of their service offerings. We will keep everyone posted on further developments.
 



Some Recent Nerd Vittles Articles of Interest…


5 Comments

  1. I would hope people would start talking about two long-term solutions…

    1. Require RTP to carry some level of authentication or be transmitted through a secure tunnel established using SIP.
    2. Abandon SIP for IAX2. You avoid the need of the ridiculous shenanigans required to traverse a NAT firewall, you get built-in trunking, and you have security built into the protocol. The fact that IAX2 hasn’t gotten more exposure is a shame.

    [WM: The problem is that most VoIP phones don’t support IAX2, but a few do. Otherwise, I agree.]

  2. I tried doing that on iptables on centos running travelinman. I get oneway audio. Others can hear me, I cannot hear outsiders.I have selected NAT=no and gsm and ulaw codes. the server is on cloud with public IP.

    [WM: I responded to you in the PIAF Forum thread, but my suggestion is to try nat=yes even on the cloud platform. I know it sounds crazy, but it works for me.]

  3. I’ve started to encrypt everything since Snowden revelations. That includes using TLS+SRTP on cell phones (only use for apps that support it), deploying openvpn between fixed locations. Not surprised that RTP packets are trivial to intercept once they leave your network.

  4. All seems to work after the change. Great!

    Assume this change to the FW rules will make it in to future snapshots/upgrades of IPBX Wazo?

    [WM: Already has.]

Comments are closed.