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.
New Vitelity Special. Vitelity has generously offered a new discount for PBX in a Flash users. 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. And, when you use our special link to sign up, the Nerd Vittles and PBX in a Flash projects get a few shekels down the road 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 PBX in a Flash 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 for just $3.99 a month. To check availability of local numbers and tiers of service from Vitelity, click here. Do not use this 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 and any balance is fully refundable if you decide to discontinue service with Vitelity.
Some Recent Nerd Vittles Articles of Interest…