Slashdot Mirror

← Back to Stories (view on slashdot.org)

Cisco SPA300/500 IP Phones Vulnerable To Remote Eavesdropping

Posted by samzenpus on from the protect-ya-neck dept.

Bismillah writes Cisco has confirmed that its SPA300 and SPA500 are vulnerable to remote eavesdropping and dialing, and is working on a patch. Meanwhile, the advice is not to have the phones on internet-facing connections. From the article: "Cisco has confirmed the issue reported by Watts, which is a result of wrong authentication settings in the default configuration of firmware version 7.5.5. An attacker can send a specially crafted Extended Markup Language (XML) request to devices which will allow them to both make phone calls remotely, and listen in on audio streams. Successful exploits could be used to conduct further attacks, Cisco warned. Despite the confirmed vulnerability, Cisco said the flaw was unlikely to be used and gave it a low 'harassment' severity rating."

45 comments

  1. Feature, Not Bug by Anonymous Coward · · Score: 0

    specially crafted Extended Markup Language (XML) request

    Someone spent a lot of time implementing that! Keep your grubby mitts off.

    1. Re:Feature, Not Bug by Anonymous Coward · · Score: 0

      Yeah, I guess it would've taken a lot of time to implement such an alternative to Extensible Markup Language.

  2. So lemme get this right: by Anonymous Coward · · Score: 0

    Someone can take my phone over from the internet and Cisco gives it "a low 'harassment' severity rating."?

    What does take Cisco to acknowledge a plain, straight security hole: that said internet malfeasant can make the phone (physically) explode in my pocket?

    Gah. Another company which goes into my no-buy list. Because they don't give a flying fuck about their customers, it seems.

    1. Re:So lemme get this right: by Sique · · Score: 4, Informative
      Normally, your phone is not reachable by the public network, the attacker has to be within the LAN to sent an XML packet to your phone. And if you have a SIP phone reachable from the outside, it still sits behind a Session Border Controller, which only forwards SIP, but not XML.

      So yes, the severity is low, as the attacker has to be within your LAN in almost all scenarios.

      --
      .sig: Sique *sigh*
    2. Re:So lemme get this right: by Nutria · · Score: 1

      and Cisco gives it "a low 'harassment' severity rating."?

      Honestly, how many companies give their SIP phones externally routable IP addresses, and how many give them private 10.0.0.0/8 or 172.16.0.0/12 addresses?

      Meanwhile, the advice is not to have the phones on internet-facing connections.

      That's just good practice to begin with...

      --
      "I don't know, therefore Aliens" Wafflebox1
    3. Re:So lemme get this right: by Anonymous Coward · · Score: 0

      Luckily none of the other devices on the LAN have any vulnerabilities, so there's nothing to worry about.

    4. Re:So lemme get this right: by Anonymous Coward · · Score: 4, Insightful

      > Normally, your phone is not reachable by the public network, the attacker has to be within the LAN to sent an XML packet to your phone

      Thanks for the clarification. So "within the LAN" as in "my smart TV, which is acting on behalf of the vendor anyway", or "my laser printer, which can be subverted with this little PDF"?

      So technically you're right, and thanks for the info, but relying on this classical "inside: all friends; outside: the evil" is a bit unrealistic these days, where your food processor is awaiting to become the next attack bridgehead due to some murky flash vulnerability.

      I think it's the damned responsibility of those appliance vendors towards their customers to own up to each of those vulns and to do their best to fix 'em instead of having some PR Department blowing hot air in the general direction of their customers.

    5. Re:So lemme get this right: by Nethead · · Score: 1

      The proper way to install your VoIP system is to run all the phones on their own VLAN that does not have Internet access. There is no reason for the phone set to have Internet access so why would you even have that on its wire? It shouldn't even have access to your desktops or servers, and vice-versa. The only thing that should be able to talk to the phones is the VoIP controller.

      --
      -- I have a private email server in my basement.
    6. Re:So lemme get this right: by Anonymous Coward · · Score: 0

      It's not a bug, it's a feature?

      Between bugs, compromised firmware, and counterfeit hardware (even the government has been stuck with some), don't count on routers, firewalls, or border controllers to actually work perfectly. Even if they did, what's to stop something else from doing port translation and sliding "secure" data through with permitted traffic? Best put a big Pimp-U-Matic sticker on every controller.

      What prevents the various flash in your (everyones') systems from being written to? It's under software control? Excuse me, is there a trust-me hormone in the food supply?

      Low severity doesn't mean so much when it is probable that there are other holes.

    7. Re:So lemme get this right: by Himmy32 · · Score: 2

      Even more than within your LAN, the best practices should put the phones on a separate VLAN with nothing except for the call manager to communicate with them. If you are putting smart TV's and printers on the same VLAN as your phones, your doing it wrong and trying really hard to do it wrong.

    8. Re:So lemme get this right: by petermgreen · · Score: 1

      and trying really hard to do it wrong.

      Putting everything internal on one network is the lazy option. Seggregating stuff onto VLANS is extra work and cost and is only generally done by places large enough to have an IT department.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    9. Re:So lemme get this right: by Anonymous Coward · · Score: 0

      All very true. And of course these type of Cisco SIP phones are also generally only used in places large enough to have an IT department. For folks who don't have IT or who have very limited IT, something like Ring Central is more common.

    10. Re:So lemme get this right: by Anonymous Coward · · Score: 0

      Your username is nethead. I am sure that you know how clueless the CS crowd is to these sorts of things and thus there are plenty of "reasons" they come up with while doing devops such that this is probably a prevalent problem anywhere that does not have in-house dedicated IT.

    11. Re:So lemme get this right: by Marginal+Coward · · Score: 3, Interesting

      My phone system at home is provided by my cable company, which uses VoIP (I assume) to provide phone service over the same cable that my Internet traffic flows through. In this common scenario, are the network and phone somehow logically isolated from each other even though they use the same physical medium?

    12. Re:So lemme get this right: by Sique · · Score: 1

      Yeah, luckily also the lock to your house doesn't have any vulnerabilities, thus we don't have to fear every local exploit automatically being a remote exploit, as the attacker could not break into your home first and then use the local exploit.

      --
      .sig: Sique *sigh*
    13. Re:So lemme get this right: by Anonymous Coward · · Score: 0

      Yes, I'd never want to listen to my manager's phone, or they mine, or the NSA mine, etc, etc.

      How did this "specially crafted XML problem" come about ? Someone wanted to listen to the phone ?

      This is why allowing someone special access is allowing everyone access.

    14. Re:So lemme get this right: by Anonymous Coward · · Score: 1

      That's true. When you get down to it, nothing is secure. Therefore no vulnerability is serious.

    15. Re:So lemme get this right: by BlueBlade · · Score: 1

      That's not quite true. The SPA line is the Cisco small business line, typically used with small Call Manager Express or UC500 series boxes.

      At the same time though, if a device on your LAN is compromised enough that it can be used to upload XML files to another host, you have a lot more to worry about than a vulnerable phone. In fact the attacker could also install a SIP gateway on the compromised host with a phone's MAC address and it would work, so having the physical phone itself be vulnerable is not much of an extra threat. Whence the low severity.

      --
      Religion is the best example of mass psychosis
    16. Re:So lemme get this right: by quetwo · · Score: 1

      I don't get what an SBC has to do with phone reachable from the outside. If it is reachable from the outside, then it is reachable, and people can POST XML documents to it to make it do weird things. An SBC only protects the inside of your network from the outside (like a firewall), but once the phone has been compromised then the SBC sees that traffic as legal traffic from a known device.

      This could be a huge issue for toll-fraud. Scammers I'm sure will start scanning for this vulnerability and use valid phones that are exposed to the outside to route calls through people's phone systems.

    17. Re:So lemme get this right: by Anonymous Coward · · Score: 0

      But you only have to trust your switch, over identical telephones, and your SBC. Because, why on earth would you have your smart TV or laser printer on your SIP vlan?

      You do use VLANs right?

  3. THEY DON'T want you to make LIGERS!!!! by Anonymous Coward · · Score: 0

    Deb: What are you drawing?

    Napoleon Dynamite: A liger.

    Deb: What's a liger?

    Napoleon Dynamite: It's pretty much my favorite animal. It's like a lion and a tiger mixed... bred for its skills in magic.

  4. Security - remove from dictoinary please by Anonymous Coward · · Score: 0

    Does not exist anymore

  5. Cisco Kid was no friend of mine by Anonymous Coward · · Score: 0

    He strikes again!

  6. Pickpockets Rejoice by dmomo · · Score: 1

    I'm not so sure I'd want to enable this feature.

  7. Hmm by Anonymous Coward · · Score: 0

    So the solution for securing their Internet Phone is to not connect it to the Internet?

    You know, at some point people are going to stop giving these companies money for these products.

  8. NVD link by Gravis+Zero · · Score: 1

    https://web.nvd.nist.gov/view/...

    The debug console interface on Cisco Small Business SPA300 and SPA500 phones does not properly perform authentication, which allows local users to execute arbitrary debug-shell commands, or read or modify data in memory or a filesystem, via direct access to this interface, aka Bug ID CSCun77435.

    Impact

    CVSS Severity (version 2.0):
    CVSS v2 Base Score: 6.9 (MEDIUM) (AV:L/AC:M/Au:N/C:C/I:C/A:C) (legend)
    Impact Subscore: 10.0
    Exploitability Subscore: 3.4

    CVSS Version 2 Metrics:
    Access Vector: Locally exploitable
    Access Complexity: Medium
    Authentication: Not required to exploit
    Impact Type: Allows unauthorized disclosure of information; Allows unauthorized modification; Allows disruption of service

    --
    Anons need not reply. Questions end with a question mark.
  9. Not a bug... by Anonymous Coward · · Score: 0

    This is a 'feature'. Surely requested (and demanded) by various government agencies, to make their job easier

  10. Re:Just more proof by Bacon+Bits · · Score: 1

    Because no networking vulnerability ever requires the use of packet crafting unless it uses XML. Yes, this is a failure of a plain text data serialization format. If only they'd used JSON, this never would have happened.

    --
    The road to tyranny has always been paved with claims of necessity.
  11. Citizenfour revealed it's an NSA spy feature by Anonymous Coward · · Score: 0

    If you watched Citizenfour, you'll have the creeps reading about this accidental vulnerability. It is put in there on purpose from all indications. I guess half the vulnerabilities that are not immediately patched are those put out there for spying. Hey guys, stop spying on the innocents, OK? Stick to stopping bad people. You are ruining things, seriously.

  12. Have IPv6-only phones by unixisc · · Score: 1

    Looks like a solution to this would be to have phones that support the IPv6, but not the IPv4 protocol. It would be next to impossible to scope the phone's address behind a firewall - the port scan would take forever.

    1. Re:Have IPv6-only phones by Himmy32 · · Score: 1

      Or the best practices of having these all on a separate subnet/VLAN that can only communicate with the call manager. That's why Cisco has marked this as a low threat because if you've configured your equipment right nothing else should really be able to communicate with the phone outside of the call manager.

    2. Re:Have IPv6-only phones by ledow · · Score: 4, Insightful

      "Hiding" the phones among the IPv6 ranges is just stupid and not "security" at all (literally, security by obscurity!).

      Even then, chances are that there's a range of consecutive IP's and just block-scanning through the IP's at random (say, scan every sensible address suffix because most people will start them on something sensible) will narrow it down quite quickly before you'll notice anything's happened. And chances are that most people will split at the usual boundaries, use the same IPv6 range (or the next one up) as their web servers are on, etc.

      As stated above, the phones themselves have NO need to be on a public network. Push them through a VPN or similar if you really must but they should be on their own VLAN anyway (so you can QoS them properly and easily) and they shouldn't require direct access to the Internet anyway (the voice gateway is another matter that's separately handled).

      But, better, stop buying, producing and selling devices that have debug interfaces that let you do ANYTHING on the device, remotely, without authentication. Because that's so dumb it's orders of magnitude more dumb than trying to hide your IP ranges in a IPv6 haystack.

  13. The only solution is to have a physical switch by Anonymous Coward · · Score: 0

    If mobile phones had a physical break switch for the microphone(s), it would be possible to guarantie no possible eavesdropping. Of course manefacturers are going to not want to do that because it would add a microscopic fraction to the cost.

    1. Re:The only solution is to have a physical switch by ledow · · Score: 1

      Not only that, it'd generate thousands of support calls and people would end up just taping it to "on" all the time.

      More important and useful (and cheaper and easier) would be a mic indicator light as an option. If you want to see whether the mic is active, like you want to see if the webcam is active, just look at the light.

      No disturbance, no unnecessary support calls, and an option to turn it off if it bothers you.

  14. VOMIT by Anonymous Coward · · Score: 0

    We've been sniffing voip phones for decades now.... Whats with the news flash "IP Phones Vulnerable To Remote Eavesdropping"?
    http://vomit.xtdnet.nl/

  15. Don't assume your phone is secure by Anonymous Coward · · Score: 0

    Don't assume your typical non-military-grade-hardened phone is secure.

    Even if nobody knows how to compromise it today, you shouldn't assume someone won't figure out how to compromise it "tomorrow".

  16. Don't assume your phone is secure by davidwr · · Score: 1

    Don't assume your typical non-military-grade-hardened phone is secure unless it's so-dumb-that-its-unhackable* or the phone resides on an isolated network over which you and only people you trust can see.

    Even if nobody knows how to compromise it today, you shouldn't assume someone won't figure out how to compromise it "tomorrow".

    * think "analog phone on a cross-bar switch" - but even that is subject to hacking, but few people have the skills to do more than a simple wiretap.

    --
    Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
  17. Extended Markup Language (XML) = FAIL by Anonymous Coward · · Score: 0

    It's Extensible Markup Language. This is a technology oriented website!

    Editor?

  18. You don't say? by Ol+Olsoc · · Score: 1
    I also hear the sun is bright, and rain is wet.

    Who knew?

    --
    The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
  19. Re:Just more proof by Anonymous Coward · · Score: 0

    Cisco phones don't generally (rather they don't at all by default) do any SIP handshaking over the internet.
    All of an organizations IP phones talk to their internal Call Manager server.
    To make a call between companies the two CM servers handshake, and one phone connects outbound to the other companies CM.

    Basically only the CMs need to accept connections FROM the Internet. The phones are expected to have no more than NAT access outbound to the Internet, and are only expected to receive any IP handshaking commands from the internal CM.

    Guess Cisco doesn't expect people to use Voice-over-Internet-Protocol phones over the Internet.

    So WinXP box A talks to SQL server A, and SQL A talks to a SFTP A server.
    Same setup at a different company but all "B" instead.
    Only the two SFTP daemons need incoming Internet connectivity to exchange batch data for EDI.

    Your claim is like saying "Well clearly the XP boxes have an IP stack, so of Course they both need public Internet IPs with no firewall rules!" - Despite the fact these machines never need to speak to each other at all.

  20. Re:Just more proof by BlueBlade · · Score: 1

    When they say internet-facing, they mean incoming, not outgoing. The fact that the phone itself has access to the internet doesn't change anything, because if it's compromised, it's going to be able to make calls in any case since it has access to the IPBX.

    --
    Religion is the best example of mass psychosis
  21. Re:Just more proof by quetwo · · Score: 1

    Cisco has been pushing SIP based IP phones for remote workers for years. Those remote workers may or may not have their phone in front of their firewall. These phones connect back through a session border controller at the edge of the company's network and then brings that traffic inside (think of a application-layer VPN tunnel).