VOIP security

For unclear reasons our school has rushed to install a Voice-over-IP (VOIP) system for telephoning. The fancy new phones come with lots of difficult-to-use menus and have more bells and whistles than a Brazilian Carneval costume. But as a true computer grrl I bravely went through all the menus after the phone was installed and was shocked to see the information available directly on my phone: all the data I would need to impersonate a phone (IP-Address, MAC Address, DNS Server, TFTP Server, Subnet mask etc. etc). As an idle joke I typed the IP number of my phone into the nearest browser - I almost fell out of my chair. Up came a web site with all of this information, nicely printable.

Now, the IP addresses are in the 172.16. x.x subnet that Cisco uses, and since they are not password protected, I can guess valid IP numbers - they map nicely to telephone numbers, which are included on the information summary. So all I have to do is find the president's extension, and I can flip through looking for the IP number of his phone.

So what?

Well, there is a menu item on the page called "logs". I am a sucker for stuff like this - but this will be password protected, won't it? Well, no. The log contains a date stamp every hour, so I know the day:

07:00:00.001338 NTP: Thu Mar 2 07:00:00 2006

And then we have:

07:42:48.049300 MT: ====== A phone call starts ....

Hmm. I wasn't in my office until 8.30 this morning. Maybe we have a time drift here. But it is clear that I now have a phone call on the log. And a bit on down we have:

07:53:29.805367 Flushed: cip.midp.rms.n@4c5fb07:43:29.806803
07:53:53.610771 on hook

So I quit gabbing. There are some fun numbers around that look suspiciously like call IDs (not the telephone numbers themselves, in this file). There are a half a dozen other files available, but I have had enough. The next student who walks in the door begging for a thesis topic is given "Security in VOIP Systems". [And he takes it, too!]

I informed the worker's representative group leader (Personalrat) and she was concerned, as she was being pressured to sign off on an agreement stating that the workers at our school are happy with the security of the VOIP system.

It took a few months for this to boil up, and today we had a meeting that included the computer center chief. At the start he admitted that the voice packets go over the line unencrypted. He actually has a USB-Stick with the encryption algorithm and key. But the usability of the administrative package is rather low - he has to sit at an application and mouse through a set of menus to set up a phone with encryption for each of the 900 or so telephones in the school. There are no batch files possible. So this had not yet been done.

As I demonstrate what I found out on my first playing around, that I can grep the logfiles to see how many calls a number made during the day, and with a few lines of Perl calculate how long each call was, I see his face getting whiter and whiter. The worker's group representative asks if these menus can be disabled. Sure - one telephone at a time for 900 telephones.... Smart man - he tackles this head on and offers to spend the night fixing the telephones.

There are some questions here: Why is Cisco delivering a phone in a default state like this? Sure, it makes finding errors easier, but it opens up another can of security worms. Why is it so difficult to enable encryption? Why does Cisco have some fancy security certificates for this phone system that they copied for our administration? Why do people hope that there will be no problems with things they cannot see and do not understand?

I'm not going to be using this phone for anything I wouldn't want published in a blog anytime in the near future.

No comments: