EDIT: It now appears that a fix has been implemented that addresses the problem described below, starting with the 2.5 branch of FreePBX (you may need to upgrade FreePBX if you don’t see it). If you are running FreePBX, you probably should read this article anyway, so that you know about the security threat and how to use this security feature.
Every now and then, when I have absolutely nothing else to do, I watch Don Melvoin’s Hollywood Theater – no, wait, I can’t do that, Mr. Melvoin is no longer among the living. Instead, I peruse the FreePBX ticket system, which shows bug reports and feature requests, and the FreePBX forums. By doing so I sometimes can see the direction that will be taken in future upgrades.
However, once in a while you see signs of a problem or issue. Unfortunately, it has always seemed to me that ever since Rob Thomas retired as the lead developer of FreePBX (formerly known as Asterisk@Home), the new development team has not been nearly as responsive to feature requests and user-submitted improvements. The new team seems to have a certain direction in mind, but they can’t seem to lay it out in such a way that others can understand where they’re headed. Worse yet, they don’t make it easy for others to develop new modules for FreePBX – there is virtually ZERO useful information on how to do that – and even when someone does take the trouble to figure out how to develop a module, chances are it won’t be accepted into the “official” FreePBX distribution. At best it might wind up consigned to the list of Third-Party Unsupported Modules. Even user-submitted patches to existing modules are frequently ignored.
This apparent lack of responsiveness to user concerns may come back to bite the developers in the butt. It seems that over two years ago, a user with the nickname vregnard submitted a feature request entitled Add permit/deny boxes for iax and sip devices. In this request, he asked for this:
Could be nice to have extra permit and deny boxes in the ‘device options’ in iax and sip device configuration pages. Maybe just after or before the already existing disallow and allow boxes.
Now, in case you are not certain what he’s asking for, take a moment and look at this link: Asterisk sip permit-deny-mask – IP address mask for SIP traffic. Basically, this is a security feature that can be set on a per-extension basis. In other words, let’s say you have set up FreePBX (or one of the several all-in-one distributions that utilize FreePBX) and you have several extensions, but they all connect from inside your local network. Or maybe some of them connect from a different network, but they always come in from the same network. By using the appropriate deny and permit statements, you can disallow connections that appear to be from a particular extension if that connection is coming from an unknown or unapproved IP address.
The only problem is that in FreePBX there is no way to set the deny and permit statements on a per extension basis. It’s not that this would be a difficult thing to do, in fact vregnard and another user with the nick shag submitted patches that would add these fields to the extension setup pages. If you look at the patches they are not complicated – they add a grand total of eight new lines of code on two pages. But for some reason that is unfathomable to me, the FreePBX developers have never appeared to give this request so much as a moment’s notice, despite having two years to include these additions. Which is really too bad, because it could have helped avert a major problem for some FreePBX users. Skip ahead a couple of years, and we find that hackers (the bad kind) have discovered a major security hole in FreePBX, which is detailed in this FreePBX forum post by user by jperry999 (excerpt follows):
I found out the hard way this last weekend that if the SIP port (5060) is available to the public Internet on the Asterisk box that it is VERY easy for someone out there to find your extensions then scan for the valid “secret” password. With that, they simply “Register” as the extension and Asterisk now thinks they ARE the internal extension! They then can freely make calls using your outgoing phone lines at a massive rate, e.g. less than a second between calls. In a few hours they made over 1000 calls to all over. What those phone calls were is even worse — phishing for bank card numbers and pins, obviously to do bank fraud — all from my caller-ID.
Now in case you’re not catching this, the problem is that someone outside your local network can connect to your system, and by using a “brute force” approach to guessing passwords, they can pretend to be one of your internal extensions. But if what I am reading is correct, this would not be possible if you had the ability to appropriately set the correct permit and deny values for each internal extension, so that they would simply ignore any connection requests from an “unexpected” IP address, even if the correct password were guessed.
Not only was a feature request for this submitted two years ago, but a different user submitted essentially the same request (on a different ticket) about six months ago. And the only comment on that one was a reference to the first ticket, suggesting that they install the patch. The problem with installing a patch of that type in FreePBX is that any time you allow an update to one of your patched modules, or any time you upgrade FreePBX, the patches are lost, and you have to go back and keep adding them back in. It would be much easier for everyone concerned if these patches were applied to the distributed versions of FreePBX (Edit: And at some point after this article was originally published, it appears this has finally happened).
This problem is described more fully in this FreePBX forum post by jperry999, which I will repost below in its entirety. My only concern is that if any FreePBX user ever incurs a major loss because of this type of attack, and it can be shown that the FreePBX developers consistently ignored requests for even this small amount of increased security, they might possibly incur some liability (bear in mind that I am not a lawyer, and you might think that anyone providing a free app should not be held liable no matter what, but I could envision a situation where some judge might say, “What, it would have taken you all of five minutes to add this, and you ignored two requests for it?” and decide that the FreePBX developers have some culpability. Personally, I am not convinced that they have any legal obligation, but I do think they have a moral obligation to make this easy to implement security feature available. But again, I am not a lawyer).
Having said all that, anyone that is concerned about this type of attack really ought to consider installing and configuring fail2ban – here are some relatively easy-to-follow instructions for doing that.
Here’s the post by jperry999 that I mentioned above:
Security Alert: Is port 5060 open on your router?
Posted November 27th, 2008 by jperry999 (tadpole)
Alert: Your system is likely under attack to hijack your phone system to make calls if you have port 5060-5061 open on your broadband router (that is the SIP port).
There is someone out there who has gotten quite active at finding any system with port 5060-5061 open on the router, and finding what extensions the system has, and using trial-and-error to find the passwords (which might only take minutes due to the speed of computers).
Hijackers out there are ramping up finding systems with this port open, and using them to make calls using your system to “phish” for credit-card/ATM-card info. Note that since this comes from your phone system and your Caller-ID, you might have some legal liability, so this is more than just the cost of the phone-calls to consider.
If you believe that because you did not give out your IP address, and there are “so many IP addresses out there, they will never happen on my system”, or similar logic, let me tell you that happened to me and others:
Here are three individual hijack threads in just this forum in just recently. There are probably many more undetected and unreported.
http://www.freepbx.org/forum/freepbx/development/security-too-easy-for-i…
http://www.freepbx.org/forum/freepbx/tips-and-tricks/voip-hijack
http://www.freepbx.org/forum/freepbx/users/hijacked-phone-systems
If you do not have adequate and extensive security measures in place, or do not fully understand how anyone can hijack your system, I strongly recommend you immediately close port 5060-5061 in your broadband router.
Note that in many cases you really do not need to have it open. With most VOIP providers, your system sends a “register” command out, and thus the port does NOT need to be open (if I understand this correctly).
You would only need to have the port open to receive anonymous SIP calls or to have remote extensions, or similar things.
If you do need to have port 5060 open, I cannot stress enough how important it is to have extremely strong passwords for ALL your extensions. Even then, you should seriously consider fail2ban and further security measures.
Please see the above threads for good suggestions by experienced people on this subject.
Subscribe to Michigan Telephone, VoIP and Broadband blog
