A few years ago I had an email conversation with Chris Lyman, the former CEO of Fonality, the makers of trixbox IP-PBX systems. I expressed concern that their trixbox Pro system was using the MAC address both
for the password and the username, which for obvious reasons isn't very secure.
Below is the email conversation slightly edited for security and clarification reasons, followed by some further thoughts on SIP security:
Security is going to be a huge competitive advantage after we see some high profile VoIP intrusions.
How bout forcing users to change their voicemail PIN after X number of days? TMC's voicemail was hacked many years ago. (see link/story below)
More importantly, how about automatically changing extension passwords every month and then flash all of the phones with the new passwords at 3am? This can be done easily with Aastra phones.
Read my article including the comments from Ward Mundy: http://blog.tmcnet.com/blog/tom-keating/voip/analysis-of-a-voip-attack.asp
Interesting article. DISA is not enabled on trixbox Pro or PBXtra, so no worries there.
However, you can cause some financial or privacy damage if you get a vm password. On the financial side, if the extension has the ability to make outbound calls from the voicemail system, then you could make free calls that way. On the privacy side, you could listen to someone's voicemail.
So, here is what we will do in the 2.1 release of trixbox Pro (coming to you in a couple of months):
1. Force strong vm passwords (no "1111", etc.)
2. Auto-expire all existing weak vm passwords (next login to the User Panel will force you to change it)
3. Auto-expire *all* vm passwords every 180 days.
4. Randomize vm passwords for all new systems provisioned.
5. Disable "CallOut" on all existing and new extensions. This should eliminate the financial risk.
In addition, trixbox Pro 2.1 carries a few other new security features coming:
1. Force strong password on user panel
2. Force strong password on admin panel
3. Auto-expiry of admin password every 180 days on admin panel
Why aren't we auto-expiring user panel password? Huge pain! People's FONcall will break. Their click-to-call will break. Their HUD won't log-in - very disruptive!
FYI, trixbox Pro and PBXtra already (for a long time now) have brute force protection with IP-address lockout for the Web Admin and Web User Panels.
Good stuff Tom...thanks!
Should I reach out to you when we launch 2.1, I bet the telephony world would like to see some of the measures we have already and are *soon* to be taking in the area of security.
Good stuff! Sounds like I may have given you some ideas for password security.
You covered 2 out of the 3 passwords in your email.
You didn't mention IP phone passwords.
For instance, aastra phones have this in the .cfg file for each MAC address:
sip line1 auth name: 00085D3D23E0
sip line1 password: 00085D3D23E0
sip line1 user name: 00085D3D23E0
By default auto-provisioned phones use the MAC address for BOTH the username & password. A hacker that finds a trixbox server listening on port 5060 could in theory guess the MAC address and password. Don't forget, each IP phone provider like any network device is assigned a unique 6 string MAC address (1st 6 digits/letters). So for Aastra, it's 00085D
You can see that with this nifty mac address lookup tool: http://www.coffer.com/mac_find/?string=00085D
That only leaves 3D23E0 remaining in the password or 6 additional characters. I believe the number of combinations is 6 letters (A-F) + 10 digits = 16^6 = 16,777,216 combinations to try and register with the SIP server by "hacking" all the Aastra combinations (assuming auth name is the same as the password). Once you get a successful registration, voila' free calling!
Still, probably pretty hard to do. [they'd have to guess a MAC address you're using plus assume you are using the same for the password]
Still, my idea in my original email is to change the password in the .phone's cfg file periodically. Though I don't think anyone is doing this yet.
Would require trixbox pro to modify each MAC address file, pick a random password, and then "push" out the new password to the phones & reboot them at say 3am. Could do this once per 3 months or something.
>Tom: Good stuff! Sounds like I may have given you some ideas for password security.
Yes, actually you did! Some of this was stuff already on the table, but the random expiry was a really nice call. Tx for the nudge. :)
>Tom: You didn't mention IP phone passwords.
Ah, yes...figured you were going to ask about this...
trixbox Pro 2.1 will have randomly generated SIP passwords. We considered auto-expiring them, but given that our customers use every type of phone from Astra, to Cisco, to Poylcom, to Counterpath, to Snom, to Grandsream...you can imagine the headache of auto-expiry. In fact, it actually becomes dangerous to do so because you can't guarantee a phone will get its new configuration file in case it's remote or is specifically configured not to get its configuration file or pointing to a different TFTP/FTP server. If the phone is unable to get the new configuration file, we've just prevented the phone from working.
It's actually pretty hard to pull of the attack you described. Not that I like publicly providing a blueprint for how to hack the baby I have spent 5 years building, but...
Assuming you knew a trixbox Pro's public IP address, it had port forwarding enabled for remote phones, and you knew a model of phone it was using (such as Polycom or Aastra), you would be able to brute force a username and password in a few days to a few weeks...you could hijack the phone. That is what I call the "stackable if" problem and probability starts decreasing in step functions at each layer.
There are 16^6 combos (16,777,216). With this number, at 10 attempts a second, assuming you knew a trixbox Pro's public IP address, it had port forwarding enabled for remote phones, and you knew a model of phone it was using (such as Polycom or Aastra)...your half life toward a brute force attack would be 9.709 days of sustained 24 hour attacking and you would reach a 100% intrustion rate at 19.42 days.
I agree would be tough to crack. Not to mention you'd have to throttle the brute force attack since some SIP servers might get overloaded thus tipping off the IT/phone admin.
[end email thread]
Even though I wrote 'Great reply' in my last reply to Chris, I still didn't like his answer. Essentially, trixbox Pro was relying on "security by obscurity" and hoping a brute force SIP cracker couldn't guess a MAC address number to use for both the username and password.
Fortunately, as Chris promised, trixbox 2.1 (& later) no longer chooses a password that matches the SIP username. It chooses a random 12 alphanumeric password consisting of letters upper & lowercase and numbers. However, even with more complex passwords, the hackers have several VoIP hacking tools in their arsenal, including Cain & Able
, and others that can scan for VoIP systems & extension numbers and then brute-force attack them.
trixbox Pro isn't alone in the Asterisk-based IP-PBX world in choosing insecure passwords. Many other Asterisk distributions also started out with very simple passwords that are easy to crack. In fact, early on most Asterisk PBXs had the extensions configured with the password secret being the same as the extension number. i.e. username=101 password =101. If you followed this password scheme and you configured your Asterisk-based system to be open to the outside (i.e. to allow remote phones), then you are just inviting hackers to make phone calls on your dime
That's probably what happened to a SMB who received a whopping $120,000 phone bill
after hackers took control of his IP-PBX and made 11,000 international calls in 46 hours. The article doesn't specifically state it was an Asterisk system and it's true that other IP-PBX vendors aren't immune from easy to crack passwords, so my intention isn't to point fingers specifically at Asterisk.
In fact, the beauty of Asterisk is how quickly is to fix bugs or in this case solve a security issue though the Asterisk community. I read one solution was to use an AGI script that is executed on every call to keep track of the number of calls per minute, and also the average length of calls per hour, in a MySQL db. Then the script has certain triggers (i.e. 10 calls per minute), and if the trigger is ever reached, the script emails and sends an SMS to warn of the abuse. Alas, he didn't share the AGI script or I'd include a link to it. If anyone volunteers to write an AGI script that does something similar, send me a link and I'll update this post.
Still another popular solution is fail2ban
. Although, this rudimentary intrusion protection system wasn't initially designed by Asterisk developers with Asterisk in mind, it was developed by someone in the Linux community to ban abusive IP addresses that attempted to brute force attack SSH, FTP, and Web systems. Later, it was easily extended to support brute force SIP password attacks simply by monitoring an Asterisk log file. As such, fail2ban has become one of the most useful tools you can have loaded on your IP-PBX (or any other Linux-based server), since it can monitor SIP, IAX, SSH, FTP, and Web for brute force attacks. It works by automatically adding a brute force attacker's IP address to iptables (Linux firewall) after 3 (by default) failed logon attempts. This will make your system much harder to compromise.
Nerd Vittles' 'PBX in a Flash', now called Incredible PBX, is an Asterisk-based distro that ships with fail2ban built-in, which is nice. All Asterisk-based PBXs should come with this pre-installed. On a related note, Nerd Vittles has a nice rundown of 10 rules you should follow
to secure your IP-PBX, including using VPNs, checking your logs, using iptables, and more.
Nerd also just today posted an article
, with a very interesting twist on securing Incredible PBX. He launched Travelin' Man, a web-based, one-click Asterisk application that automatically reconfigures your Asterisk PBX to enable remote SIP phone access from your cellphone, iPad, remote PC, NetBook, or desktop telephone. The application locks out all IP addresses and only
allows an IP address after the user visits a special web page designed for this specific user, i.e. http://myserver.dyndns.org:83/184778
. Check out the diagram which explains how it works:
The idea behind this is to allow traveling employees (hence Travelin' Man) to travel and have their new
IP address allowed into the IP-PBX system. Of course, this does require the user launch a web page first before using a SIP softphone or SIP telephone, but it certainly does make the IP-PBX much more secure while still allowing traveling sales folks and telecommuters to have remote phone access with no IT/telecom admin intervention to allow a certain IP address.
Unfortunately, many Asterisk systems and indeed other PBX vendor products often sit untouched, unmonitored (log files), and un-upgraded in a telecom closet. It can be tedious to maintain updates and often the motto is "If it ain't broke, don't fix it." Updates, especially major ones can be a nightmare for an IT/telecom administrator, which can break certain features, introduce bugs, or perhaps even bring the phone system down, making for a long day/evening/weekend for the IT administrator. Thus, it often isn't worth the hassle to install the latest updates just to get some bug fixes or some obscure new feature. This means there are hundreds, perhaps thousands of IP-PBX systems out there running older software, just waiting
for hackers to exploit their trivial passwords. This not only will result in a hefty
phone bill, but perhaps the heave-ho
from your job. Exit question: Are you responsible for one of them?