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: 3CX, RentPBX, Amazon, Vitelity, DigitalOcean, Vultr and others provide financial support to Nerd Vittles and our open source projects through advertising or referral revenue. We’ve chosen these providers not the other way around. Our decisions were based upon their corporate reputation and the quality of their offerings and their pricing. Our technology recommendations are reached independently of financial considerations 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.

Awesome Vitelity Special. Vitelity has generously offered a terrific discount for Nerd Vittles readers. You now can get an almost half-price DID from our special Vitelity sign-up link. If you’re seeking the best flexibility in choosing an area code and phone number plus the lowest entry level pricing plus high quality calls, then Vitelity is the hands-down winner. Vitelity provides Tier A DID inbound service in over 3,000 rate centers throughout the US and Canada. When you use our special link to sign up, Nerd Vittles gets a few shekels down the road to support our open source development efforts while you get an incredible signup deal as well. The going rate for Vitelity’s DID service is $7.95 a month which includes up to 4,000 incoming minutes on two simultaneous channels with terminations priced at 1.45¢ per minute. Not any more! For our users, here’s a deal you can’t (and shouldn’t) refuse! Sign up now, and you can purchase a Tier A DID with unlimited incoming calls and four simultaneous channels for just $3.99 a month. To check availability of local numbers and tiers of service from Vitelity, click here. NOTE: You can only use the Nerd Vittles sign-up link to order your DIDs, or you won’t get the special pricing! Vitelity’s rate is just 1.44¢ per minute for outbound calls in the U.S. There is a $35 prepay when you sign up. This covers future usage. Any balance is refundable if you decide to discontinue service with Vitelity.


​​3CX is a software PBX that’s easy to install & manage. It includes integrated softphones, WebRTC conferencing and essential add-ons out of the box, at no additional cost. Try the free edition at www.3cx.com. Better yet, download the PIAF5 ISO powered by 3CX. Free version includes support for 8 simultaneous calls with a SIP trunk.

  • Run on Premise or in the Cloud, on Windows and now on Linux
  • Softphones for iOS, Android, Win & Mac
  • Easy install, backup & restore, version upgrades
  • Automatically configures IP Phones, SIP Trunks & Gateways

  • RentPBX, a long-time partner and supporter of PIAF project, is offering generous discounts for Nerd Vittles readers. For all of your Incredible PBX hosting needs, sign up at www.RentPBX.com and use code NOGOTCHAS to get the special pricing. The code will lower the price to $14.99/month, originally $24.99/month. It’s less than 50¢/day.


    Some Recent Nerd Vittles Articles of Interest…

    Be Sociable, Share!

    Tags:

    This article has 2 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.]

    Leave a comment

    Your email address will not be published. Required fields are marked *

    *