Hackers turn Cisco phones into remote bugging devices Internet phones sold by Cisco Systems ship with a weakness that allows them to be turned into remote bugging devices that intercept confidential communications in a fashion similar to so many Hollywood spy movies, SC Magazine reported. The publication quoted consultants from Australia-based HackLabs, who said customers had lost …
With a Microsoft driven device you are expected to sit down, take the keyboard and enter some settings.
With a cisco device you are expected to power it up, log in over the _NETWORK_ from a machine which has _NO_ special provisions using the minimal tools available on any PC for the last 15 yeas and configure it.
There is a 5 digit number of CCIEs, 6 of CCNPs and probably 7 digit number of people who know how to get around a cisco CLI with no certification. They all have the expectation that they can do that. I am not surprised that as a result Cisco continues to ship it in this form.
Now, as far as the phones. While most of them do not have a CLI, the mentality that it should be easy for a professional to configure it is still there. As a result they are wide open. I have broken into them in the past. It takes 90 seconds with a Linux laptop for 99% of the ones you will find sitting on a corporate desk in the City. In most places, nobody will notice anything.
In fact, I am not surprised with Cisco's answer either. If they answered anything else they would have depreciated the need to actually read their documentation and take their courses. That is something Cisco will never ever do even if this means continuing to ship stuff with laughable basic security settings. First of all, they make a shedload of money from certification. Second, the entire "premium" ecosystem they have created is kept alive by the fact that it is provisioned by people and requires people to operate it properly. If they make it automated and default they will drop to a much lower margin level straight away.
That is not going to happen. No way.
Disclaimer: I work on a small CallManager system.
Switching off the HTTP & SSH services on the phones will probably help to mitigate these security problems.
However, other products (Cisco or otherwise) depend on this HTTP access to the phones to do stuff.
The ultimate answer, is for Cisco to implement some (half-decent) access controls on the phones so that all-and sundry can't abuse them like this.
This also comes down to doing a proper security evaluation of your VoIP system and putting in proper access controls.
Anybody out there ever heard of access lists & vlans perhaps?
Why would you ever put a voip phone accessible to the public on the same vlan as the rest of your phone network (or regular data network)
Why would you allow http, telnet, ssh (or any other protocol) apart from the bare necessities (to initiate the phone call) to thter the rest of your infrastructure ?
Then again I bet that the reception PC is also on the regular corporate lans as well I assume that is also Cisco's fault ?
As for the quote “The book says to shut off web services,” HackLabs' Peter Wesley was quoted as saying, referring to the manual that shipped with the phones. “Who's going to read all that.”
Perhaps somebody who isn't clueless?
When it comes down to it it's the fault of the muppet that plugs a networked (computing) device into a network with no thought about what they are doing.
Then I'd say its the fault of the manufacturers and resellers marketing this stuff to home users and small business. Your position is that these devices shouldn't be used without the oversight of a skilled $100K a year specialist, that sort of knocks the bottom out f the whole "internet telephony is cheaper" argument doesn't it?
I actually agree with you, these things are not for home users and small biz, despite the marketing lies.
[/Ken Olsen mode]
I don't know where you are getting 100K pa from.
For setting up a cisco voip system you need either a call manager server installed or a router configured to set up your dialling or interface with your pabx.
You want a voip system then you have to pay somebody to set it up otherwise you end up with a POS The same thing happens with a PABX you configure it wrong & some little shit will provide you with a phone bill to get upset about.
However I dont hear anybody complaining about pabx mfgrs?
"However I dont hear anybody complaining about pabx mfgrs?"
Alright then... Avaya. Their (management and end user) software is indescribably awful in almost every way and their product retention and support for anything over a couple of years old is along the lines of "what product? don't remember making that!"
Happy now? :p
As you know my comment was pointed at the "Ooooh it's not plug & go" issues raised with voip phones.
Avaya are quite horrible as are the ever present Meridians but it's accepted that they're complex beasties that require some training on.
The bad news is of course that voip isn't any less fraught with complexities and gotchas.
But for some reason people are surprised that it actually requires some knowledge to install and maintain a voip system.
In many cases it may have a web front end but it's not like posting on facebook, it's a bit more difficult than that.
>Anybody out there ever heard of access lists & vlans perhaps?
My thoughts exactly (well, different words but same idea). I'm not in any way a network guru or security guy, but it just seems plain stupid to me to take a VoIP device and stick it on the same LAN as other devices.... It's asking for trouble, especially if you have public access phones (hotel rooms, conference rooms, etc).
I did read a story about a guy who connected his laptop to the VoIP phone's socket in his hotel room... Gave him access to the whole hotel LAN (which presumably their guest internet access didn't).
This applies specifically to the 7xxx series CISCO touchscreen phones (I forget the specific number) but the ones with a colour touchscreen that you see on many famous desks.
It's "not a bug, it's a feature" as it is part of the XML API provided by CISCO where the phone can be controlled by http GET and PUT commands using XML to change what is displayed in the touchscreen and also provide a type of third party call control. One of the options is a 'silent' call placement
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
