[on-asterisk] Is it just me or does this Cisco vulnerability seem more dangerous than Cisco would have us believe?

[Jim Van Meggelen]

http://www.itnews.com.au/News/401928,cisco-confirms-ip-phone-eavesdropping-flaw.aspx

[David Donovan]

On 24 March 2015 at 15:22, Jim Van Meggelen <jim.van...@gmail.com>
wrote:

>
> http://www.itnews.com.au/News/401928,cisco-confirms-ip-phone-eavesdropping-flaw.aspx
>


Hi Jim,

I can understand them ranking it lower than "Critical" because of their
assumption that these are business devices and should be behind a firewall
of some kind, but I agree that I was surprised to see the low designation
of "Harassment." Being able to intercept audio and execute arbitrary code
isn't just a nuisance.

The opportunity to spearfish is pretty big. I know people should have
802.11x and vlans but I'd imagine that if I showed up at many offices and
asked to give a 5 minute presentation on some cost saving measure, I'd be
received in the board room at plenty of places and I'd have an opportunity
to jack into a LAN port. From there I'd have a decent chance to detecting
some SPA devices with a quick scan of the subnet. That's only to mention
one of many, many possible attack vectors.

I was curious so I hit up ShodanHQ without even knowing what the header
was. Helpfully, Cisco made it the model of the phone so anyone can go to
this URL and see that there are almost 1500 Cisco 525g2s with their web
interface exposed to the public Internet. It's a one stop shop, you can
also get the IPs.

What's more surprising to me is that there's no patch. I doubt that many
IT departments keep their phones on the bleeding edge of phone firmware
anyway but if I did the risk assessment and found that one or two of my
devices were high risk, now I don't really have a choice other than to take
them offline.

Best of luck to anyone on the list who's dealing with this. If you come up
with a good solution, I'd be interested to know it.

Dave

[David Donovan]

On 24 March 2015 at 20:27, David Donovan <donova...@gmail.com> wrote:

> On 24 March 2015 at 15:22, Jim Van Meggelen <jim.van...@gmail.com>
> wrote:
>
>>
>> http://www.itnews.com.au/News/401928,cisco-confirms-ip-phone-eavesdropping-flaw.aspx
>>
>

> What's more surprising to me is that there's no patch.
>

I did some more reading on this because I felt like I must be missing
something. It turns out I was.

It looks like there isn't a software patch because the solution is to
correct the incorrect "as shipped" default setting. Cisco says
"Administrators are advised to enable XML Execution authentication in the
configuration settings of affected devices."

I'm not an expert and I haven't tested this but, as I read it, the problem
can be solved by pushing a simple config value through auto provisioning.

Also, I did a more specific query on Shodan and it looks like the affected
firmware isn't the most common one. Again, helpfully, Cisco included the
firmware version in the HTTP response so it's easy for an unauthenticated
remote user to tell if the device is affected and worth exploiting. It's
still thousands of devices though when you consider several models are
affected.
http://www.shodanhq.com/search?q=SPA525G2-7.5.5
http://www.shodanhq.com/search?q=SPA504g-7.5.5

All the best,
Dave

[Jim Van Meggelen]

We just had a customer plug a phone into the carrier interface in front of
the firewall (the carrier drops off a DPC3825 as their demarcation (set to
bridge ... no firewall), and it happily hands out public IP addresses to
whatever is plugged into it). Told them they ought to keep that set behind
the firewall; they're working on it ...





On Tue, Mar 24, 2015 at 9:42 PM, David Donovan <donova...@gmail.com>

[Jim Van Meggelen]

We just had a customer plug a phone into the carrier interface in front of
the firewall (the carrier drops off a DPC3825 as their demarcation (set to

bridge), and it happily hands out public IP addresses to whatever is

plugged into it). Told them they ought to keep that set behind the
firewall; they're working on it ...

It sounds like verifying that 'XML Authentication' would be a good thing.
How I wish manufacturers would ship things with a default setting of
'secure' for such things, but of course then they'll get hammered with 'it
doesn't work' support calls, so they quickly learn to set things to
permissive, and put a little security caveat/lecture in the docs to cover
their ass.

On Tue, Mar 24, 2015 at 9:42 PM, David Donovan <donova...@gmail.com>