Schneier on Security
A blog covering security and security technology.
« "The Logic of Surveillance" |
| Hacking Best-seller Lists »
March 12, 2013
Cisco IP Phone Hack
All current Cisco IP phones, including the ones seen on desks in the White House and aboard Air Force One, have a vulnerability that allows hackers to take complete control of the devices.
Posted on March 12, 2013 at 1:43 PM
• 23 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
Reading up on this highlights the value of defense-in-depth. It also shows why threat-based security management provides better outcomes than vulnerability-based management.
The attacks require either physical access to the phone, or SSH access. Any controls at these layers will effectively mitigate the vulnerability. Security-conscious entities will have already controlled these attack vectors, so the vulnerability would be essentially neutralized already.
In this case vulnerability-based security management would require patching. However threat-based management would also include attack vectors (and already controlling those vectors, as mentioned above) . Monitoring and managing physical and SSH access will provide much stronger security for those who are looking at the threats rather than just issuing a patch. I would go so far as to argue patching this, in itself, is of relatively little value.
Forgot to mention - these phones produce logs, which can be monitored, and firmwares are monitored with signatures and checksums, so additional controls area available.
Stories like this used to excite me. Truly though, this kind of thing is pretty basic: it runs on an OS that has problems; turn a problem into an exploit; give it some extra (common) malware features. It takes skill but it's exactly what people should expect would happen to these IP phones.
Now, their symbiote work is really clever and took a lot of thinking. I kind of slammed it in the past for it's weaknesses (below). That said, I like radical approaches b/c they sometimes lead to breakthroughs. I look forward to seeing how their symbiote system evolves.
@ Nick P,
Their "patent pending" symbiote idea has a problem...
As you and severa other readers of this blog know I have prior art and have described this as part of the Castle-v-Prison conversations on this blog.
The question is have they done their due diligence or not, and I think not...
The 'feeping creaturism' aspect always irritated me about these devices. They have an embedded web server - yes, *server*, not just a browser. Do you actually need that, or is that a pointless extra attack surface?
"Keep it simple" and "minimal necessary services" don't just apply to desktops and servers - apparently Cisco need reminding it applies to telephones too.
@ James - while it's true that the web server is a major attack surface (especially when phones have public, non-NATed IPs and are indexed by Google), it's also very useful. It allows you to tinker with the config on the phone, which is great in debug/prototyping situations. This feature is standard on all major IP phones for a good reason. I'd certainly advise it to be disabled in production environments, though.
I'm not sure that this is a serious hack, though -- it sounds scary, but presumably you could just as easily plant a bug if you have physical access to the phone. If they find a way to hack a phone with the web interface disabled, then I'll be scared.
We used VoIP phones at work for awhile. They actually had a lot of configuration settings available, in terms of what all the buttons did, etc.
You could use a web interface to configure them, or you could point them at an http server, a tftp server, or I think DHCP could give them the location to download their config files from.
The UI on the front panel would let you adjust only a small subset of the settings. The config file was the way we ended up deploying them, but the web interface let you immediately change settings, and was helpful for testing features out.
A simpler system would unquestionably be possible, but I am generally not a fan of proprietary protocols that require custom client apps. If the phone used that, and/or was hooked up to a custom back-end, then it wouldn't need a web server on it. But, in my experience, configuring it with an Asterisk back end that I was managing myself, I found that it was a lot easier with the 'feeping creaturism'. The XML parser that could be used to create custom menus based on the server was also nifty - you could use that to create your own interactive menu system to, say, customize away messages or routing behavior if you wished.
(The phone was made by Aastra.)
"while it's true that the web server is a major attack surface (especially when phones have public, non-NATed IPs and are indexed by Google), it's also very useful. It allows you to tinker with the config on the phone, which is great in debug/prototyping situations. "
A Web Server isn't necessary for that. There's much safer and just as usable solutions, admittedly most requiring a custom client like Gopiballava said. Let's ignore that and say we do use a web server for those situations. The web server and other non-phone-critical functionality can be off by default. An authenticating command can be used to activate those services. These services shutoff immediately after the admin is finished. This gives you the feature w/out the constant attack surface.
So we should stop using those phones right away, right? Like Java?
Sorry: Pet axe. It's pretty clear that the hyperbole about, "You must stop using Java right away," is being pushed by a certain large computer manufacturer that makes an operating system that is always full of holes and we should stop using it right away. Java is certainly no greater risk, but the cries to stop using it immediately have been so strident as to expose the competitive assault they really are.
@ Coyne Tibbets,
So we should stop using those phones right away right? Like Java?
In an ideal world the answer would be obvious...
But we don't live in an ideal world, even though stoping using them would stop a large number of potential security holes the reality is there is probably nothing to replace them with currentl. And even if there were the rreplacments would like as not be just as buggy.
Now irrespective of if a certain OS and Office product software house is behind the claims to stop using java you need to look a little closer at the current owner of java...
Lets be honest Oracle are very slow at fixing problems with java and have been for some time and I suspect will continue to be so if not worse with time. In fact Oracle have a poor reputation when it comes to security and fixing problems. So they are kind of taking target practice at their feet...
Further what makes it worse is java is cross platform and thus effects MS / *nix and other OS in equal ammounts which has made it a very active target foor attackers.
Further since 1995 java has been "the get to go" development language that has replaced many others. So much so it's getting harder and harder to find apps that don't use java in some way. Which makes it even more atractive to attackers.
Lastly java has an issue which started at Sun and realy should have been fixed a long time ago. When you install java for most ordinary mortals it's all or nothing. This is never desirable from the security perspective. Thus enabaling and disabaling java in it's various guises should be made much easier but so far it's not happened.
But java is not the only offender think about variouss Adobe products, chunks of HTML5 oh and then there's the afore mentioned OS and Office develepment organisation who atleast give the appearence currently of trying...
You're a bit wrong on the Java/Oracle front. Oracle internal security folks desperately want to up the security of Java, but there's organizational resistance from the Java team. Furthermore, the way Java releases makes security-focused updates difficult (this problem lays at the feet of the Java team). Nearly all of these issues are carried over from Sun days and have nothing whatsoever to do with (prior to the join) Oracle personnel. Oracle is not monolithic.
As for Oracle's reputation at fixing problems, I seriously doubt you've spent much time speaking with folks who handle Oracle's incident response or the majority of Oracle's customers who have to install security patches. The incident response team spent years honing the process for identifying, prioritizing, fixing and releasing security patches in a manner that would be reasonably speedy, well-tested and least impactful for their customers. Enterprise level software that runs massive corporate systems cannot be patched as simply as a Windows PC. Quite honestly, their patching process is a model that many other s/w companies servicing businesses should study and adopt.
I do agree on your all or nothing point: that Java continues to have an ORB deployed inside of it is the worst kind of technological flotsam and jetsam.
As somebody who both does software development for VoIP platforms and has also experience managing phone systems for call centers and reseller scenarios, I *do* want my phones to come with a web server enabled by default. How is a web server REALLY that more of a security hole than an SSH daemon, or anything else that is accessible by the network? I'd assert that pretty much anything that is open is also open for attack. But I'd rather have some basic functionality available out of the box that I can then later disable (i.e. if I switch to a centralized provisioning model).
If you're so worried about the phone being hackable but are transmitting your RTP on the clear, I suggest re-evaluating one's security policies first. Granted, there are very few if any ITSP's that support back-to-back SRTP or other methods. And even as such, SRTP has a weakness in how the key exchange takes place. If you're serious about security, I'd first secure the streams using ZRTP (http://zfoneproject.com/) or a product that uses Phil Zimmermann's ZRTP implementations.
@ Nick P
True, it's probably not necessary, but in my experience the feature can be very convenient (although configuring and troubleshooting IP phones is my day job, so I have more cause to use the web interface than most admins would). I'd really rather not have to install a custom client per phone vendor that I work with, and how do we even know they'd implement the client correctly?
I do agree that the web server should default to being disabled. It's currently not very well documented, and even worse is often left with the default admin passwords enabled.
A lot of service providers fail to realise that if one phone gets owned, they could be on the hook for tens or even hundreds of thousands of dollars worth of fraudulent calls.
Rather than using ZRTP, the "industry standard" approach to securing your RTP stream is to encrypt your signalling as well, SIP over TLS being the common case. This has the advantage of being supported on most major VoIP handsets. You really want to encrypt your signalling anyway because SIP uses MD5 for its authentication scheme, so it's preferable not to perform your authentication exchange in the clear.
Out of curiosity, are you aware of any applications that this approach isn't appropriate for?
I know not of this "industry standard approach" that you speak of. Again, it's the same problem as SRTP - who supports SIP with TLS from a carrier standpoint? Sure you might be able to implement SIPS+SRTP on your own system, but traversing carriers kind of kills that. In other words, it's not an ubiquitous solution.
SIP authentication using md5 isn't necessarily an issue. If I'm not mistaken (and I'd have to check my pcap's or rfc's again to be 100% certain), there's a challenge/response. So what if you can collide md5? That still doesn't mean you can respond to the challenge with the correct response. A lot of SIP traffic uses on the internet do not require authentication, so the only other real reasons to use SIP over TLS is to obfuscate who you are calling (as the when is known regardless), whether you are hitting DTMFs (assuming SIP INFO method, as rfc2833 would be an RTP EVENT, and inband is... well, inband...) and to try to hide the key exchanges for SRTP.
The nice thing about ZRTP is that it has built-in methods to verify that the integrity of the encryption is good end-to-end (in the endpoint-to-endpoint mode, which was the original intention of ZRTP anyway) and is not compromised.
As for what is or isn't appropriate, I actually think I'd defer to Phil's judgment on that. I think he's far more qualified to discuss this matter than I am. I wonder if he ever pops on by this site.
" How is a web server REALLY that more of a security hole than an SSH daemon, or anything else that is accessible by the network? I'd assert that pretty much anything that is open is also open for attack."
The use case was said to be configuration or debugging. Web servers are often complex and increase the TCB. Sending data from one machine to another doesn't require a web server. It can be done with a simple text- or binary format, UDP, and a simple auto-generated parsing system. These can be implemented in a rigorous way with little effort. Have been, if you consider DO-178B and INRIA's work. Secure web servers, on the other hand, are still an open issue all around.
" If you're serious about security, I'd first secure the streams using ZRTP (http://zfoneproject.com/) or a product that uses Phil Zimmermann's ZRTP implementations."
I agree. I've used VOIP over Secure IP, OpenVPN SSL, ZRTP, the Cryptophone protocol, and handrolled solutions. There's quite a few options when someone demands encrypted calls. The issue at hand is many managers or users think they bought at phone that plugs into IP networks. They actually bought a mini-PC that does plenty of other stuff & is easy to subvert.
" But I'd rather have some basic functionality available out of the box that I can then later disable (i.e. if I switch to a centralized provisioning model)."
That's quite sensible, esp. from a business perspective. I allowed for it in my previous comment. The difference is that I promote secure by default, meaning it would be off by default. It would also be easy for legitimate owner to enable it. I also promote the use of compartmentalization in special purpose devices, like using MAC or MILS. Stopping the web server functionality from being a step in a series of advances might be infeasible. However, limiting it to network and config file access using existing software isolation techniques would give users the benefits while greatly reducing the risk.
One can often get far with small steps.
"True, it's probably not necessary, but in my experience the feature can be very convenient (although configuring and troubleshooting IP phones is my day job, so I have more cause to use the web interface than most admins would)."
Totally. In my designs, I let the interface be whatever people want it. What get's sent down the wire and interacts with the network is quite simple. That data doens't need to be human readable, the protocol is immaterial, etc. The middle layer does all that. So, you get the security benefits of simpler stack on the embedded device and a convenient interface on the admin end.
" I'd really rather not have to install a custom client per phone vendor that I work with, and how do we even know they'd implement the client correctly?"
There's where the inconvenience will appear. Modern development tools make it easy to code a configuration tool that's a single executable. There's also RAD tools that can automate some of it. This is one of the easier types of programs to do correctly. If anything the companies are more likely to screw up on the user interface design. Also, different vendors will do different things. (But that happens anyway for web configuration, right?)
My approach might imply a solution to the problem you mention. The approach calls for a simple, M2M transport system. It would inherently be in a separate module from the actual interface. So, if you wanted, you could actually roll your own using whatever technology or layout you chose. A third party or open source product might provide integrated management of vendors' products. So, your conveniences are still possible, but the VOIP device has less complexity.
"A lot of service providers fail to realise that if one phone gets owned, they could be on the hook for tens or even hundreds of thousands of dollars worth of fraudulent calls."
In the dialup era, it was 900 numbers dialing to Nigeria and other places. Those 900 operators let the crooks use their service for around a 30% cut. Many didn't work if people's PC modems were unplugged when not online. There were more effective solutions, but this slightly inconvenient and simple one save quite a few users big money. Convenience vs risk is a recurring tradeoff.
Completely agree with you that the implementation (re: web servers on the phones) that's at issue here. I suspect you would have less reservations if they put the most simplistic and secure web server there. Something akin in spirit to vanilla Qmail for security (and equally as limited in functionality).
There are certainly simple ways that having the web server off by default but allowing the admin to enable it upon installation (i.e. something not too buried in the mess of configuration menus, with maybe a shortcut keypress sequence). That type of scenario I wouldn't be against per say. I do try to balance my security concerns with business concerns.
As for the comments between you and Paul re: toll fraud, pre-paid only service ftw. At least you minimize your risk in that scenario. (unless you ARE the carrier) :-)
" I suspect you would have less reservations if they put the most simplistic and secure web server there. Something akin in spirit to vanilla Qmail for security (and equally as limited in functionality)."
I see you're getting the idea. ;) Further with that idea, there are quite a few managed languages that have web serving libraries. This can eliminate most code injection attacks while raising the developer's productivity.
@ A former ORCL emp,
Clive You're a bit wrong on the Java/Oracle front.
I may well be so as I only have the information available to an outsider, therefor when you say,
Oracle internal security folks desperately want to up the security of Java, but there's organizationa resistance from the Java team
I can only say that, that may be true but it's not how it comes across to those outside Oracle.
Microsoft got slated for it's lack of security practices and eventualy after Bill Gates intervention got it's act together. Adobe likewise got slated for it's lack of security but appears to be making amends. Apple although not slated to the same degree has also upped it's security practices.
Now we know that all three of those organisations developers got bitten via a "watering hole" attack involving java and they are far from happy. One in particular is a bit more vociferous than the others and appears to have taken some direct action (which has produced the usual pro-con arguments) which has ruffled feathers.
However Oracle is seen by many as "the bad boy" because it has been slated for many years even prior to taking over Sun for it's security practices and appears to be at best reluctant to sort things out.
The fact that Java sits on a 4month patch/release cycle and appears to be not properly tested befor release is doing Oracle no favours in the industry irrespective of what part of Oracle maybe responsible.
Have a read of the following Computer World appraisal of java's problems and how one of their industry commentators also casts a shadow on other Oracle products,
Oracle may be changing, and improving and the task they face due to the basic nature of java is far larger than the other major industry players faced. But it's not showing outside of Oracle and that's a major problem for them.
Thus industry pundits are in effect calling for "heads must roll" style sacrificial executions. Which unfortunatly is aided and abetted by one of the aformentioned major industry players...
It's right that these Cisco IP Phones are not the most secure telephones, and therefore one wonders why they are still so often used in highly sensitive environments, like for military VoIP networks and also for the relatively new secure VoIP network for the president and senior government officials.
However, this latter system runs over a secured separate network, but still a network is as vulnarable as its weakest link. But as commercial-of-the-shelf (COTS) seems to become the only way the US government wants to build things, these risks are included...
With DTMF solutions being deployed to protect card data in call recordings under the PCI DSS standard, people are now being asked to enter their card data into IP phones in the work environment. It would now seem possible to collect card data from IP phones remotely. Worse still the card number will be accompanied by the expiration date and the security code. Does the president or his secretary use a credit card?
Schneier.com is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc.