VoIP Security — You Are Doing it Wrong

“Your guide says to set this feature like so, but can you tell me why that isn’t insecure?”

My first ticket of the day revolved around the security posture of a well known VoIP Software in an on-premises implementation. After reading it I could only shake my head and say, “you are asking the wrong questions.” Some of you who read this may be outraged right now. “Why shouldn’t I question a vendor’s recommended settings for a software I will use?” You ask. The remainder of this post is about helping you ask the right questions, and understanding why this one screams “HACK ME!”

Lesson 1: Stop Assuming Your Vendors are Looking Out For You

I am fortunate to work for a company where I can speak openly and be frank when it comes to poor decisions being made, or less than sound instructions being given. My company is fortunate enough to have someone with a fair understanding of networking, security, VoIP, and even development in their employ. This mixture is not typical. Further, the guy who wrote the guide for getting your phone system hooked up to the provider’s network was probably definitely more concerned with making sure it would actually work than paying attention to the security concerns that it might create.

Do your research and see if you can find out what the settings you are being told to input are actually doing (Use this Link). This may take another hour or two of your precious time, but could save you from a terrible mistake. Furthermore, you will immediately be able to discern whether your vendor is staffed by genuinely experienced IT personnel or just some paper tigers (I once taught somebody with a B.S. in Cyber Security how to use Wireshark, and had to explain to a CISSP why Telnet was bad (if you didn’t chuckle at those and you make more than 60k per year in IT, you should be resigning from your position tomorrow), when you point out your understanding of which step in their guide might open you up to security vulnerabilities.

Lesson 2: Don’t Make Problems Where They Don’t Exist

I once worked for a company that mandated all Windows XP computers must be upgraded or discarded due to a security vulnerability. I casually pointed out that one of their machines was running on DOS and another on Windows 95. My orders were clear, “get rid of those vulnerable machines.” However, these machines were not networked and were not even capable of being networked without a significant undertaking. Even after explaining that there was no way to exploit the vulnerability remotely (which was the concern) management wanted these machines removed. However, when i threw around the figures to write custom software necessary replace the tasks these machines were doing already, suddenly people wanted to listen. Ultimately the ultimatum was hedged and brought into line with reason. Only networked machines needed to be upgraded.

Had the company involved in the original question learned lesson 1, they would have been in a position to understand that lesson 2 applied to them. In order for the feature they were discussing to make them vulnerable, the provider’s servers would need to be hacked. Their firewall was only allowing one port directly from our server’s IP address to their VoIP server. Then the software was configured to only respond to our server’s IP address. Therefore, our server would need to be the one to exploit their system. If our server get’s hacked, changing this feature to be more secure is a moot point especially since the goal of the feature change is only to ensure that it’s only our server that can use the feature. Therefore, the problem doesn’t really exist and furthermore will never be solvable at the application level.

Lesson 3: Know Your Weak Points

In a room with 4 concrete walls and 1 steel door, you can bet I am going to break in through your floating ceiling; but first I am going to knock on the door to see if somebody will let me in. Having worked in security and law enforcement I understand a little bit about criminals. The primary thing I have learned is that we typically only catch the slow and the stupid. I believe the same is true with regard to crackers (note that hackers are not bad, crackers are). If someone wants to get into your network, they probably will. If you are really serious about security you will be periodically monitoring your network traffic for abnormalities.

Every week I get a call from someone who can no longer make international calls because our fraud monitor detected unusual activity on their system. In most cases their system got hacked somehow. In the vast majority of these cases one of the following happened:

* A network port was left open for ANY IP and was forwarded to a critical piece of infrastructure

* Somebody on their network downloaded malicious software allowing a hacker onto their network

* Some combination of the above with some weak passwords mixed in

I won’t go over how to mitigate these items here, but if you don’t know how to do that, or your IT guy can’t explain to you how they have mitigated these concerns, you need help. Before I close, I’ll leave you with one concrete example which illustrates all three of these in the VoIP domain.

If you buy VoIP service from SIP.US, and you have a consumer grade router (or a less than stellar enterprise grade router), we will tell you to open the ports which your server needs for RTP (audio) to ANY IP and forward them to your VoIP System’s private IP address. We are doing this so we don’t have to introduce more points of failure into the path your audio is taking to and from the other end of the call, but there are side benefits to us (Lesson 1).

You do your research and figure out that opening up all of these ports from ANY IP could create a security concern. However you call Kent and he says, as long as your VoIP software is configured correctly, and your firewall is only forwarding those ports to the device running that software, there isn’t an issue. Further research (which you are only able to do because you chose an open source system) reveals that your software will not respond on those ports unless it has an associated SIP call. Since the SIP port is locked down to SIP.US’ servers, this isn’t really an issue unless SIP.US gets hacked somehow (Lesson 2).

After your bout with researching network security you decide to run nmap (a network enumeration tool) just to see what holes may exist on your network to the outside world. You find that Billy from accounting is running a bit-torrent on port 6881 to stream the new Star Wars release, and somebody wanted to be able to access your Wireless router from the outside world so they left port 443 open for any IP to access. Whatever your feelings are about how SIP.US is doing RTP, you have much bigger fish to fry (Lesson 3).

VoIP Security isn’t just about your connection to a provider. It’s about the security of your network, the programming and configuration of your software, and the willingness to look inward for problems before pointing the finger at other people.