Slashdot Mirror
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."
So yes, the severity is low, as the attacker has to be within your LAN in almost all scenarios.
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
> 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.
I'm not so sure I'd want to enable this feature.
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.
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.
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.
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.
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.
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
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.
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?
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.
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.
Who knew?
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
That's true. When you get down to it, nothing is secure. Therefore no vulnerability is serious.
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
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
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.
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).