We interrupt our regularly scheduled content to bring you an urgent security alert. A couple days ago, a FreePBX® user reported unusual call activity. He traced the calls to a System Admin Dashboard module that was linked back to an IP address in the Netherlands. When the problem was reported, the FreePBX Community Manager quite accurately noted that it wasn’t FreePBX code. When a second user reported the exact same exploit, alarm bells apparently went off.

Further digging by the FreePBX Dev Team found that the legacy ARI module (once again) had been compromised, this time with a Remote Code Execution and Privilege Escalation exploit. Previous security vulnerabilities in this module led the PBX in a Flash developers many years ago to abandon the FreePBX security model in favor of Apache security so that we could totally block ARI access unless the user had administrator privileges. We want to stress that this wasn’t the fault of any of the current FreePBX developers. Instead, our move to Apache security was based upon our realization that this old legacy code was difficult to maintain because none of the original developers were still around. To their credit, the FreePBX developers have introduced a new User Control Panel with the strongest recommendation that the older ARI module be abandoned. Unfortunately, it still exists on all but the very latest FreePBX 12 systems including FreePBX 12 systems which were upgraded from a previous release. In addition, FreePBX 12 now provides checksum protection for all registered modules which will go a long way toward eliminating attacks such as this. So what can you do to protect your servers and your wallet today? For openers, upgrade your FreePBX fw_ari module NOW and clean the malicious module off your server:

rm -rf AMPWEBROOT/admin/modules/admindashboard
amportal a ma upgrade fw_ari

If you encounter an error that FreePBX cannot connect to the Asterisk Manager, do the following from the Linux CLI:

sed -i 's|localhost|127.0.0.1|' /etc/freepbx.conf
amportal restart
amportal a r

Protecting Your Server from Remote VoIP Attacks

Let’s approach the long-term solution on several levels starting with vulnerability exposure. If you can access TCP ports 22 (SSH) and 80 (HTTP) and TCP/UDP port 5060 (SIP) of any of your Asterisk® and FreePBX-based servers anonymously from the Internet, you’re either nuts or rich.

We’ve cautioned against this for nearly a decade and yet even some developers still configure Asterisk and FreePBX-based servers with port 80 Internet exposure. Why? We can only assume it’s because it makes their job of accessing and maintaining these systems easy. Don’t do it! There still are numerous ways to gain access to the FreePBX GUI on any server. Here’s our short list…

Safest. Put your server behind a hardware-based firewall with no Internet port exposure. Then use a VPN to access the FreePBX GUI. In a perfect world, you can run a VPN on all of your VoIP phones so that you have end-to-end protection for your server and all of your users.

Safer. If a hardware-based firewall isn’t possible, use the Linux IPtables firewall and lock down all the ports on your server, especially TCP ports 22 and 80 and TCP/UDP port 5060. Then create a WhiteList of IP addresses that need access privileges. It’s worth stressing that Fail2Ban is completely worthless when it comes to security vulnerabilities such as the ARI RCE flaw because the bad guys walk right in without even being challenged for a password.

Safe. If you need remote access from various remote locations and these sites have dynamic IP addresses, then deploy the Port Knocker technology in addition to locking down your server with the IPtables firewall. This lets you gain temporary access to your server without providing a blank check (literally) to everybody on the Internet. There’s a reason it’s called the World Wide Web and not the Good Guys Web!

Worse. Exposing TCP port 5060 and UDP port 5060 to public Internet access is dangerous. Some providers unfortunately still require direct access to 5060 to make VoIP calls with SIP. TIP: Switch to a provider that allows SIP registrations so that you don’t have to expose port 5060 directly to the Internet EVER!

Worser. Pardon our grammar, but exposing TCP port 22 to public Internet access is a bad idea. At the very least, change the SSH port so that typical port scanners don’t discover your open SSH port. SSH has been compromised in the past. It probably will happen again, or it may have already happened and we just don’t (yet) know about it. Fail2Ban helps with SSH attacks, but it’s not infallible particularly when high performance servers are used in the attacks. Fail2Ban has to scan your logs and, before it can do that, it has to have a sufficient time slice to accomplish the scan, something that may never happen with an attack launched from a platform such as Amazon EC2.

Worst. Never expose TCP port 80 to public Internet access. If you do, then you obviously haven’t had the pleasure of trying to maintain a public web server. TIP: Unless you are a web expert or sleep with one, don’t do it EVER! Earlier this week BASH provided a revolving door to your Internet assets using simple web requests. Earlier this year, OpenSSL was compromised. There will be another vulnerability because it’s the easiest attack target. So it’s just a matter of time until your server is compromised unless you deploy an effective firewall that blocks public access to port 80.

Server Design Still Matters

For our own PBX in a Flash and Incredible PBX users, you can sleep well tonight. Today’s vulnerability is mostly academic for you. PBX in a Flash blocks all access to ARI without the maint password. Incredible PBX blocks all access to ARI through its IPtables WhiteList. It’s still a good idea to apply the FreePBX update just to be double-safe. And Incredible PBX users will have the patch applied the next time they log into their server as root. For everyone else using FreePBX, keep reading.

With our Incredible PBX open source project, we provide state-of-the-art security methodology. While it is not infallible, all of the code is freely available for any and all VoIP developers to review, improve, and deploy. We would encourage our fellow VoIP developers to do so. There were reasons in the past for not deploying Apache security. After all, it lacks the flexibility of the FreePBX security model, and Apache also can be compromised. But we can’t think of any reason today for not deploying a hardened, preconfigured IPtables firewall AND a functional WhiteList as an integral component in every VoIP server install. This is especially important for any product deployed with the FreePBX GUI. Our Travelin’ Man 3 WhiteList implementation has been available for more than 2½ years! While there are downsides to any sort of push technology, we also believe the Incredible PBX (opt-in) update service is worth a careful look. It has been a godsend for us. With every new login, the server checks for important updates and processes them unless the administrator chooses not to use the service.

Keep in mind that FreePBX masquerading as the asterisk user has complete read/write privileges to virtually every Asterisk and web asset on your server. Any compromise is extremely dangerous because the asterisk user on these platforms has such expansive privileges. We recently encountered a trojan authorization lurking inside the permissions list of Asterisk’s manager.conf table. The matter is still under investigation so we can’t reveal much more other than to note that the entry was harmless on the few affected Incredible PBX servers because of the hardened IPtables WhiteList which is a key component of every Incredible PBX server. Had this happened on a server with no firewall protection, the intruder would have had complete access to the Asterisk AMI which pretty much gives the intruder a blank check to Asterisk… using your checkbook. The silver lining was the Incredible PBX update utility which provided a quick way to remove the vulnerability.

The FreePBX Dev Team’s efforts to design and deploy a checksum-based system for FreePBX 12 modules is certainly a step in the right direction. We think more safeguards are warranted. We already are exploring new ways to provide alerts when critical Asterisk or FreePBX resources are modified on PBX in a Flash and Incredible PBX servers. Something akin to the Mac’s admin authorization requirement before critical Asterisk or FreePBX changes are made would be ideal, but we have some other ideas as well. Stay tuned!

Originally published: Wednesday, October 1, 2014



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


 

Special Thanks to Our Generous Sponsors

FULL DISCLOSURE: RentPBX, Amazon, Vitelity, DigitalOcean, Vultr, Digium, Sangoma, 3CX, TelecomsXchange and others have provided financial support to Nerd Vittles and our open source projects through advertising, referral revenue, and/or merchandise. 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 their 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.

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.


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…

Print Friendly, PDF & Email

Be Sociable, Share!

This article has 1 comment

  1. Your advice is sensible but, for people who are willing to keep their system updated, i think it is too conservative. Running ssh on port 22 and apache on port 80 is something numerous people do, and which is not all that risky so long as you keep your system updated and take reasonable security precautions (like using strong passwords). Without letting these ports remain accessible, it is impossible to run some important and useful services, such as a web site.

    [WM: A telephony server is NOT the appropriate place to host a public web site! There are plenty of web hosting options which cost next to nothing to implement without jeopardizing your telephony server. All of the services you mention can be utilized on a telephony server with implementation of a WhiteList-enhanced IPtables firewall. In this way, you don’t jeopardize the overall security of your server.]