Cisco SPA300/500 IP Phones Vulnerable To Remote Eavesdropping

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."

Re:So lemme get this right:

[Sique]

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.

Re:

[Sique]

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.

Re:

[Anonymous Coward]

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

Re:So lemme get this right:

[Anonymous Coward]

> 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.

Re:

[Himmy32]

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.

Re:

[petermgreen]

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.

Re:

[BlueBlade]

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

Re:

[Nethead]

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.

Re:So lemme get this right:

[Marginal Coward]

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?

Re:

[quetwo]

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

Re:

[Nutria]

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...

Re:

[Bacon Bits]

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.

Re:

[quetwo]

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).

Re:

[BlueBlade]

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.

Pickpockets Rejoice

[dmomo]

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

NVD link

[Gravis Zero]

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

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

Have IPv6-only phones

[unixisc]

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.

Re:

[Himmy32]

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.

Re:Have IPv6-only phones

[ledow]

"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.

Re:

[ledow]

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.

Don't assume your phone is secure

[davidwr]

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.

You don't say?

[Ol Olsoc]

I also hear the sun is bright, and rain is wet.

Who knew?